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

accommodating native SRFI implementations
by Julian Graham 30 Sep '07

30 Sep '07

Hi Schemers, I've been thinking about the best way to port some SRFIs to Snow, and I'm getting stuck on a few things that I'm hoping you might be able to help me with. It seems to me that SRFIs occupy kind of a unique position among the packages that should be provided by Snow, because a lot of them have some degree of support compiled into the interpreters themselves. Specifically, I've found that support for a given SRFI in a given interpreter falls into one of three categories: 1. The interpreter includes explicit support for the SRFI, either in some kind of compiled form or as part of a library of Scheme code distributed with the interpreter. 2. The interpreter doesn't include explicit support for the SRFI, but includes sufficient infrastructure such that the reference implementation for that SRFI can be used directly or one can be written (for cases in which there is no reference implementation). 3. The interpreter neither supports the SRFI directly nor does it provide the necessary infrastructure for an external implementation. An example of an SRFI with varying levels of native support is Marc's SRFI-18, "Multithreading support." Bigloo, for example, has built-in support for SRFI-18 (case #1); GNU Guile doesn't have built-in support, but its set of built-in thread functions are probably sufficient (with a patch or two) to implement SRFI-18 on top of them (case #2); SCM probably can't do SRFI-18 without some significant changes to the interpreter's code base (case #3). Given such a heterogeneous playing field: * When the interpreter provides an SRFI implementation (especially an implementation that's probably done natively for performance reasons), should a Snow package override this implementation with, say, the reference implementation from the SRFI draft, which might be less... performant? Or should including a snowball for that SRFI be a no-op for that interpreter platform? * What should the behavior be when including an SRFI that can't be implemented on all the platforms Snow supports? (Should such SRFIs use the "require" component of the Snow package structure and give a list of supported Snow hosts? Or signal an error when a non-conforming interpreter tries to use the API?) Thanks, Julian

1 0

Using Termite + Snow
by andrew cooke 26 Sep '07

26 Sep '07

[Not sure whether to use Gambit or Snow list - hope duplication not a problem] I have just installed Gambit (4.0.1), Termite (tarball) and Snow (1.1.1). Things seem OK, in that the following works: > gsi Gambit v4.0.1 > (self) #<thread #1 primordial> So I then defined the following in a Snow package: (cond-expand (gambit (define (acu-pmap f lst) (let ((parent (self))) (map (lambda (pid) (recv ((,pid reply) reply))) (map (lambda (x) (spawn (lambda () (! parent (list (self) (f x)))))) lst))))) (else (define (acu-pmap f lst) (map f lst)))) However, when I try to use code that calls acu-pmap I get the error (line 30 is the "let"): *** ERROR IN ac-utils/v1#acu-pmap, "ac-utils.scm"@30.20 -- Unbound variable: ac-utils/v1#self Can anyone suggest why this doesn't work and/or how I can fix it? Thanks, Andrew

2 4

Re: [Snow-users-list] Snowball upload
by Julian Graham 21 Sep '07

21 Sep '07

[CCing the list...] > My guess is that you didn't create the tar file correctly. If you > are in the directory containing the srfi2 directory, then you should > execute: > > tar cf srfi2-v1_0_0.tar srfi2/v1.0.0 > > You probably forgot to put the /v1.0.0 at the end. > > A much simpler approach is to use snowman to upload your package with > the command > > snowman upload srfi2 Hi Marc, Yes, you are, of course, right -- the upload's worked, now that I've sorted out the directory structure. Guess I didn't read the instructions closely enough! ;) While I have your ear, though, I'd like to make a couple of documentation requests: First off, the example documentation refers to a program called "snowrun." I don't see this program / script anywhere in the latest version of the snow-generic distribution. Is there some other way to test our snowballs from the command line? More generally, I'd really like to start using Snow snowballs in some projects of mine that are not themselves part of Snow -- that is, I'd like to bootstrap Snow using the module system of my preferred Scheme implementation. Documentation on how to do this would be really helpful (although I imagine it might have to be written on a per-implementation basis). Thanks, Julian

1 0

[ANN] Release of generic Snow v1.1.1
by Marc Feeley 21 Sep '07

21 Sep '07

Generic Snow v1.1.1 has just been released and is available on the snowfort. For installation instructions just visit: http://snow.iro.umontreal.ca/?tab=Installing This minor release adds support for Larceny, SISC and MIT-Scheme. Snow is now supported by 15 Scheme systems. Marc

3 3

Re: [Snow-users-list] high-priority snow packages and package naming
by Julian Graham 16 Sep '07

16 Sep '07

Hi Tom, I'm confused -- I think Snow already "supports" SCSH, platform-wise. Unless you mean that SCSH's abstractions for processes and other shell objects should be separated out packaged? That reminds me, though -- what about a common interface for doing FFI stuff? That'd let us add bindings for any number of other languages / libraries (Snow support for GLib, anyone?) But, yeah -- SREs! Shamefully enough, I wasn't aware of Olin Shivers' spec (http://www.ccs.neu.edu/home/shivers/papers/sre.txt) until just now. I really like the syntax, but it seems like he intended SREs to be used in conjunction with a Scheme platform's (e.g., SCSH) native regexp implementation / API... which sort of leaves us where we were. Any thoughts on Dorai Sitaram's portable regexp implementation (http://www.ccs.neu.edu/home/dorai/pregexp/pregexp.html)? - Hide quoted text - On 9/14/07, Thomas Lord <lord(a)emf.net> wrote: > Julian Graham wrote: > > Hi Schemers and Snow maintainers, > > > > I'm curious as to whether there are any particular modules / > > functionality people really want to see ported to Snow. (I believe > > Kirill Lisovsky is working on getting SSAX packaged up.) How about a > > common API for regular expressions? SRFIs? (If so, any in > > particular?) > > > > A probably crazy and too ambitious idea: SCSH (and SREs). > > Those would be very good for duct-taping together systems that > mix Scheme programs with other kinds of program in typical host > environments. > > -t > >

3 12

Latest install (v1.1.1) fails silently w Gambit 4.0beta22
by andrew cooke 15 Sep '07

15 Sep '07

Not a big deal really, but I thought I might as well flag the issue. If you run snow's "configure" with gambit 4.0beta22 then no scheme is reported as found - there's no warning about versions, just the message you'd get if no scheme at all is present. With verbose="very" two extra lines are printed, indicating that gsi and gsc were found on the path, but that's all. With gambit 4.0.1 things are fine. I found this a bit surprising because I already had snow v1.1.0 working fine with the earlier version of gambit. Andrew

1 0

high-priority snow packages and package naming
by Julian Graham 15 Sep '07

15 Sep '07

Hi Schemers and Snow maintainers, I'm curious as to whether there are any particular modules / functionality people really want to see ported to Snow. (I believe Kirill Lisovsky is working on getting SSAX packaged up.) How about a common API for regular expressions? SRFIs? (If so, any in particular?) On a somewhat related note, is there a rationale for the way modules get named -- any reason you guys decided to go with the symbol/version form instead of some kind of hierarchical model? Regards, Julian

2 1

Minor expression missing in grammar
by James Long 05 Sep '07

05 Sep '07

Hello, I was looking through the grammar for snow packages in the documentation: http://snow.iro.umontreal.ca/?tab=Documentation I was hoping that I would be able to export global variable definitions (constants in my case), but I didn't see that in the grammar. I tried it out and I was happy to find it worked, like so: (package* var/v1.0.0 (provides: (define a))) (define a 5) but it seems like this is missing in the grammar: <provide-form> --> ( provide: <provide-form-body> ) <provide-form-body> --> <interface-definitions> <interface-definitions> --> <interface-def>* <interface-def> --> <procedure-prototype> | <macro-def> | <record-def> <procedure-prototype> --> ( define ( <var-name> <R5RS def formals> ) ) | ( define* ( <var-name> <prototype formals> ) ) Just a small note. James

1 0

Macro expansion and snow ?
by Adrien Pierard 05 Sep '07

05 Sep '07

I have an issue right now, and I wonder if this can be fixed easily, since its depends on the macro system of the host... Here is a trivial example that fails: - - - - - - - - - - - - - - - - - (package* test-pi/v1.0.1 (require: pi/v1)) (define-macro* (foo x) (let ((v (pi-digits ,x))) `(display ,v))) (foo 42) - - - - - - - - - - - - - - - - - snow -- test-pi.scm *** ERROR IN #<procedure #2>, "test-pi.scm"@5.12 -- Unbound variable: pi-digits - - - - - - - - - - - - - - - - - As we see, the values imported by snow seem not to be usable during macro expansion... Any way to do that ? Adrien -- "I am not a Church numeral; I am a free variable!" (The Scheme Underground) For every complex problem, there is a solution that is simple, neat, and wrong.

1 0

bug in _snow:get-req-packages-aux?
by James Long 02 Sep '07

02 Sep '07

I feel like I'm blame-shifting, but I can't figure out why this is happening and I think it could be a bug in Snow (feel free to correct me). I was playing around with implementing a few basic heuristics that inline modules. At one point I wanted to get the shallow dependencies of a module, which seemed easy enough, as _snow:get-req-packages takes "deep?" as a parameter. So, I went into _snow:expand-macro-load-or-include-program* and changed it so that it called _snow:get-req-packages with the deep parameter to #f, and now I get this error when calling load-program*: *** ERROR IN #<procedure #2> -- (Argument 1) PAIR expected (car '()) I tried tracking it down, but I couldn't pinpoint the problem. It has something to do with the code in get-req-packages-aux, like this: (define (add-reqs pi) (if deep? (append (_snow:package-dependencies pi kind) (cdr reqs)) (cdr reqs))) which seems to add the required packages of the current package info. However, I can't quite figure out the 'reqs' is. expand-macro-load-or-include-program only passes in (list verspack-or-filename), and so a cdr of that would return '(), but I can't figure where (car (cdr reqs)) is happening. Also, sorry if I'm using this list as a technical support list if it's supposed to be more a user support list. James

1 0