- Snow-users-list - mailman.iro.umontreal.ca

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

Snowflake: Snow integration with Guile module system
by Julian Graham 07 Nov '07

07 Nov '07

Hi Schemers, So, Snow is a wonderful idea (Guile people, go to http://snow.iro.umontreal.ca/ right now if you haven't checked out Snow yet), but there are some drawbacks to its approach to library management. Among them is the fact that it doesn't integrate with your Scheme platform's native module system at all -- in fact, Snow pretty much just concatenates the bodies of all of your library implementations on load, which leads to problems with symbol name collisions [1]. And that's kind of okay. To get the benefit of Snow packages in, say, Guile, though, it's necessary to make use of the encapsulation that Guile's module system provides. To that end, I've whipped up a small Guile module called (snow snowflake) (because Scheme module systems are all unique, like snowflakes!) that converts Snow packages to Guile modules and provides a Snow-compatible mechanism for loading them. To wit: snow:package->module! package ...where 'package' is a string giving the name of a Snow package you have already downloaded and installed via Snow (e.g., "fixnum/v1.0.3"), will copy the implementation files from $SNOW_SITE_DIR to an appropriate subdirectory of %site-dir/snow (i.e., %site-dir/snow/packages/[package-name]/[package-version]) and rewrite the package's metadata as a Guile module definition. snow:use-modules module-list ...where 'module-list' is a list of symbols giving (partially-specified) Snow package names -- e.g., (fixnum/v1) or (srfi13/v1.0.0 srfi14/v1.0) -- will act as a replacement for Guile's use-modules form, locating the right versions of packages that have been installed in Guile's load path via snow:package->module!. Here's an example: (load "snowflake.scm") (use-modules (snow snowflake)) (snow:package->module! "fixnum/v1.0.3") (snow:package->module! "srfi14/v1.0.1") (snow:use-modules (srfi14/v1)) I've attached a copy of Snowflake; it works, but just barely -- you need write access to Guile's site dir, and the code does no error checking to speak of. And I'm sure there are plenty of things it doesn't get quite right, like exported syntax definitions. Still, I hope you guys can take a look and tell me what you think. Regards, Julian [1]: https://webmail.iro.umontreal.ca/pipermail/snow-users-list/2007-October/000…

1 0

Re: [Snow-users-list] [gambit-list] snowman not working
by Adrien Pierard 07 Nov '07

07 Nov '07

On Tue, Nov 06, 2007 at 12:44:07AM +0000, naruto canada wrote : > I've successfully uploaded a package, but snowman is not working: > This is not a test package, but I do need to test it. > root@localhost: /root snowman install predicate-calculus > Can't get package list from snowfort. > root@localhost: /root snowman list > Can't get package list from snowfort. % snowman download predicate-calculus predicate-calculus/v1.0.0/snow/predicate-calculus.scm -- signature file is missing! Package predicate-calculus/v1.0.0 failed verification. % snowman download --skip-verify predicate-calculus Package predicate-calculus/v1.0.0 downloaded to "predicate-calculus-v1_0_0.tgz". % tar xzvf predicate-calculus-v1_0_0.tgz x predicate-calculus/v1.0.0/ x predicate-calculus/v1.0.0/snow/ x predicate-calculus/v1.0.0/snow/predicate-calculus.scm Looks like it works perfectly here... Possible solutions to your problem: - try as a non root user - double check your DNS - install with curl instead of snowman - install with website instead of snowman - buy a new ethernet wire By the way, a few comments about your code (not that mine is perfect though...) if you don't mind: - use the <Return> key to insert newlines in your code ! - Don't redefine CAR, CDR, CADR, CDAR, CAAAR, CAADR, CADAR, CADDR... All of those *are* supported by *all* scheme hosts... - Don't redefine MAP, etc. Load SRFI-1 instead. - Do not close a parenthesis per line (in most cases) - Don't nest a dozen of IFs, use COND or CASE P! -- Note to the others on the mailing list: where are *your* snowballs? Note2 to everyone: aren't this mail and its reference supposed to be on the Snow list instead of the Gambit one? Cross-posting for this reason.

2 2

snowman not working
by naruto canada 06 Nov '07

06 Nov '07

hi I've successfully uploaded a package, but snowman is not working: This is not a test package, but I do need to test it. root@localhost: /root snowman install predicate-calculus Can't get package list from snowfort. root@localhost: /root snowman list Can't get package list from snowfort.

1 0

add test section for mypkg
by naruto canada 06 Nov '07

06 Nov '07

hi Whoever can edit "http://snow.iro.umontreal.ca/?tab=Documentation", please add a simple test section for mypkg. I have to search for existing packages for an example on how to do this. Package "gensym" has an example though, I have to search for several packages to find an example. This is for the next guy who try to contribute a package. Thanks.

1 1

is there anybody home at snow-users-list?
by naruto canada 05 Nov '07

05 Nov '07

hi I have several questions: 1. gambit-c is missing from snow hosts list: ./configure --site-root=$HOME/.snow-site --install-hosts=yes ... The following installed Scheme systems support Scheme Now!: bigloo chicken gauche guile mit mzscheme petite scheme48 scsh stklos 2. In stead of studying for eleven different FFIs, if I package my code using scheme now, can they be tested and benchmarked in all the implementations? 3. snow-generic is asking to me to choose one host, what do I do so that I can test for all hosts? 4. I'm reading "http://snow.iro.umontreal.ca/?tab=Documentation" Where do I find more info regarding providing callbacks for C libraries. Thanks

3 4

question about scheme now!
by naruto canada 05 Nov '07

05 Nov '07

hi In stead of studying for eleven different FFIs, if I package my code using scheme now, can they be tested and benchmarked in all the implementations? snow-generic is asking to me to choose one host, what do I do so that I can test for all hosts? Thanks

1 0

gambit-c is missing from snow hosts list
by naruto canada 05 Nov '07

05 Nov '07

hi gambit-c is missing from snow hosts list: ./configure --site-root=$HOME/.snow-site --install-hosts=yes ... ... The following installed Scheme systems support Scheme Now!: bigloo chicken gauche guile mit mzscheme petite scheme48 scsh stklos Thanks

1 0

bug with snow + gambit + syntax-case + define-record*?
by James Long 05 Nov '07

05 Nov '07

I can't get my module to compile when I use Gambit with syntax-case loaded as the snow host, and also use define-record* anywhere in the module. gsc just crashes. I can replicate this with the following program: (package* test/v1.0.0 (provide: (define-record* rec a b c))) % SNOW_HOST=gambit-sc; export SNOW_HOST % snow --compile test.scm /usr/share/snow/current/bin/snow: line 185: 1492 Bus error "${PROGRAM_gambit_comp}" -:dr- -prelude '(begin (include "'${SNOW_MACROS}'") (include*-cd "'${snow_file}'"))' -e '(load "~~/syntax-case")' "${snow_file}" If I change snow to include syntax-case.scm instead of load it when calling gsc, I get this error: *** ERROR IN #<procedure #2> -- Wrong number of arguments passed to procedure (sc#eval '(begin (define (_snow:macro-expand expr) expr) (cond-expand ((or guile kawa) #f) (else '(begin)))) '#(env #(top-ribcage *top* #t) ((top) #(top-ribcage *top* #t)))) This only happens if define-record* is used in the syntax-case environment. I'm not quite sure how to debug this, and any help would be appreciated. I am using Snow v1.1.1 and Gambit 4.0.1. -- James Long Coptix, Inc. longster(a)gmail.com

1 1

srfi1 cross-contamination with srfi13
by Julian Graham 11 Oct '07

11 Oct '07

Hi Schemers, Just noticed that when you 'require:' both srfi1/v2 and srfi13/v1 you get the following error in MzScheme: procedure optional: expects 3 arguments, given 2: () #<primitive:equal?> This is because the implementation of srfi1 expects the definition in srfi1.scm, which takes two arguments but which is clobbered by the definition in srfi13.scm, which takes three. This seems to me to be an issue with the scope of Snow module definitions. My inclination is that the only thing visible outside of a particular snowball should be the names in the 'provides:' section of the package definition. I don't know what the most portable way to enforce this is, though. One thing that'd be efficient would be to have Snow generate interpreter-specific module definitions based on the package* form -- in Guile, e.g., (package* srfi1/v2.0.1 (provide: ... )) ...would be isomorphic to something like (define-module (srfi1 srfi1) #:export ...). Unfortunately, each Scheme system has its own module syntax and scoping rules -- for example, Guile doesn't require, like PLT and other Schemes do, that you include all the definitions for your export within the module declaration form itself; rather, it treats (I think) the contents of the file containing the module definition and files loaded from that file as local to that module. So this approach might be best left to custom, interpreter-specific Snow implementations. An alternative might be to just encourage snowball maintainers to limit the scope of the functions that don't get exported to within the definitions of the ones that do -- e.g., (define (foo x) (define (bar x) (+ x 1)) (bar x)). This is a bit of a pain, though. Are there any other ways to limit the scope of non-exports? Regards, Julian

2 2