Décembre 2007 - Snow-users-list - mailman.iro.umontreal.ca

snowman-app port problems in Guile
by Julian Graham 15 Avr '08

15 Avr '08

I'm having trouble using the latest version of Snowman to install packages -- or, well, to do very much of anything at all. I'm using GNU Guile. When run with any (valid) arguments, it produces the following error: ERROR: In procedure scm_lreadr: ERROR: #<unknown port>:19:87: illegal character in escape sequence: #\3 When I modify the core snow script to launch Guile with the --debug flag, it produces the following stack trace: In unknown file: ?: 0* [primitive-load "/usr/share/snow/current/bin/snowman"] In /usr/share/snow/current/bin/snowman: 31: 1* [snowman-main] In /usr/share/snow/v1.1.1/pack/snowman-app/v1.0.2/snow/snowman-app.scm: 1077: 2 (let* ((args #)) (split-args args (lambda # #))) In unknown file: ... ?: 3 [snowman-install-or-download-packages (install verify highest ...) () ...] In /usr/share/snow/v1.1.1/pack/snowman-app/v1.0.2/snow/snowman-app.scm: 460: 4 (let* (#) (define # # #) (define # # #) ...) 460: 5* [get-pkg-list-from-snowfort] 245: 6 (let* ((response #)) (if (and # #) (map # #) (begin # #))) ... 253: 7 [map #<procedure #f (x)> ... 265: 8* [snow-string->object-list [ SNIP -- HUGE LIST OF SNOW MODULE CODE] In unknown file: ?: 11* [#<procedure #f (port)> #<input: string 8072130>] In /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm: 127: 12* [loop ()] 128: 13 (let* ((x (read port))) (display x) ...) In unknown file: ... ?: 14 [loop (("time" # # ...) ("mime" # #) ("json" # #) ...)] In /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm: 128: 15 (let* ((x (read port))) (display x) ...) 128: 16* [read #<input: string 8072130>] /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm:128:17: In procedure scm_lreadr in expression (read port): /usr/share/snow/v1.1.1/pack/string/v1.0.2/snow/string.scm:128:17: #<unknown port>:19:87: illegal character in escape sequence: #\3 ...any ideas?

4 5

Package model suggestion
by Nikita Sidorov 23 Déc '07

23 Déc '07

Hi all, Scheme is a language of my choice and for me, as probably for many other scheme users, sharing code between different scheme systems is a concern. It is really important to have a platform like Snow where users of all major implementations could effectively collaborate. But it seems to me that Snow has unnecessary limitation of reliyng on portable code only (please, correct me if I'm wrong). It means that a package cannot use a functionality that is not available as a snow package even when the functionality is implemented by most of scheme systems. SRFI-69 (hashtables) is a good example. I think the problem is in the package model. In the current model a package provides only one feature that is the name of the package itself. It also implies that a certain functionality may have only one implementation - a portable one. I'd like to suggest a bit different package model that is alike those used in package managers of linux distributions (rpm,deb). In this model a package may provide several features and several implementations of the same api are possible. In addition, every snow system will have a preinstalled package that provides an implementation-specific feature. For mzscheme it will look something like this: (package* snow-mzscheme (provides mzscheme)) For sisc: (package* snow-sisc (provides sisc)) Having such model we can use implementations of apis specific to scheme system. Let's consider an example with srfi-69. In mzscheme srfi-69 is loaded by this: (require (lib "69.ss" "srfi")) In SISC it is done in this way: (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69) Respective implementation-specific packages will look like this: srfi-69-mzscheme.scm : (package* srfi-69-mzscheme (provides srfi-69) (requires mzscheme)) (require (lib "69.ss" "srfi")) srfi-69-sisc.scm : (package* srfi-69-sisc (provides srfi-69) (requires sisc)) (require-library 'sisc/libs/srfi/srfi-69) (import srfi-69) Similar packages are created for other systems that support srfi-69. Having this done we can create a package that uses srfi-69 and runs on all the platforms that provide it: (package* my-package (requires srfi-69)) (define table (make-hash-table)) ... What do you think about this model? Nikita

2 2

Transitivity of "require" for macros
by François Magnan 22 Déc '07

22 Déc '07

Hi, I suspect a bug in snow (maybe I am wrong) but let's say I have 3 snowballs (dummies for my explanation): ===== moda.scm ====== (package* moda/v1.0.0 (provide: (define (square x)) (define-macro (add x y) `(+ ,x ,y)))) (define (square x) (* x x)) ===== modb.scm ====== (package* modb/v1.0.0 (provide: (define (power4 x))) (require: moda/v1)) (define (power4 x) (* (square x) (square x))) (write (add 1 2)) (newline) ===== modc.scm ====== (package* modc/v1.0.0 (provide: (define (power6 x))) (require: modb/v1)) (define (power6 x) (* (square x) (square x) (square x))) (write (power6 12)) (newline) (write (add 1 2)) (newline) ========================================== Then I type: snow -- modb/v1.0.0/snow/modb.scm 3 which is what I expected. And then I type: snow -- modc/v1.0.0/snow/modc.scm 3 2985984 *** ERROR IN "modc/v1.0.0/snow/modc.scm"@10.9 -- Unbound variable: moda/v1#add which is NOT what I expected. It seems that macros are not transitively transported through dependencies. Normal functions are. Is this a bug? Thank you, Francois Magnan

1 1

srfi1, gambit, mac osx
by Siegfried Gonzi 17 Déc '07

17 Déc '07

hello: i would like to install srfi-1 on gambit-c. i installed snow (also set path in .bashrc), but whenever i do the following i get an error message: snowman install srfi1 == *** WARNING -- Variable "_" used in module "extio.o1" is undefined *** WARNING -- Variable "define*" used in module "extio.o1" is undefined *** WARNING -- Variable "extio/v1.0.3" used in module "extio.o1" is undefined *** WARNING -- Variable "i/o" used in module "extio.o1" is undefined *** WARNING -- Variable "lgpl/v2.1" used in module "extio.o1" is undefined *** WARNING -- Variable "obj" used in module "extio.o1" is undefined *** WARNING -- Variable "package*" used in module "extio.o1" is undefined *** WARNING -- Variable "port" used in module "extio.o1" is undefined *** WARNING -- Variable "snow" used in module "extio.o1" is undefined *** WARNING -- Variable "snow-force-output" used in module "extio.o1" is undefined *** WARNING -- Variable "snow-pretty-print" used in module "extio.o1" is undefined *** ERROR IN | extio.o1| -- Operator is not a PROCEDURE (#!unbound #!unbound) == Is it possible to install srfi-1 by other methods on gambit-c and Mac OSX Leopard? Btw: if anyone here to have Bigloo installed on Mac OSX Leopard please let me know i am in dire need of Bigloo but it does not compile on Leopard. For the moment I am using Gambit-C Thanks, Siegfried Gonzi -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

1 0

srfi-40 A Library of Streams
by Tony Sidaway 05 Déc '07

05 Déc '07

I've uploaded this package to snowfort, currently at srfi40/v1.0.1, containing a port of the srfi-40 reference implementation by Philip L. Bewig with adaptations and bug fixes by Andre von Tonder and catfive/chaosnet.org. The code is substantially that provided in the srfi-40 egg of Chicken Scheme. The package contains some simple regression tests, which are passed by the following Scheme implementations when using the generic snow framework implementation: bigloo chicken gauche mzscheme I have also tested with scheme48 (probably a fairly old one, it's the stock Ubuntu package) and scsh 0.6.7. Both of the latter fail the test with the following error message: Error: undefined variable gensym (package (for-syntax 1 user)) The basic functions such as stream-cons, stream, stream-null?, stream-car and stream-cdr, are tested, plus stream-filter, but not stream-unfoldn, stream-map and stream-for-each. I would be most grateful for further bug reports or reports of success on other implementations.

2 3