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

configure instructions in README
by Julian Graham 12 Mar '07

12 Mar '07

Hi everyone, Just downloaded the generic Snow framework package (http://snow.iro.umontreal.ca/?viewpkg=snow-generic) and noticed that the installation instructions in the README are wrong. "snow-site" doesn't appear to be an option that configure recognizes. (Upon inspection, it looks like the script accepts options called "site-root" and "user-root.")

2 1

Suggestion and seeking advice
by Dominique Boucher 12 Mar '07

12 Mar '07

Hi, Over the past few months, I have developed a number of Scheme libraries, but they were written mainly (if not exclusively) for Gambit-C. I think Snow would be a nice way of packaging those libraries, by I don't intend to port them myself to all the numerous Scheme implementations. On the other hand, it would be great if they could be ported to other systems. So my question is this : what is the best process to handle this situation? Provide the package as is and wait for contributions? And my suggestion: would it be interesting to specify on which Scheme systems a package can run directly in the snow package specification? Dominique Boucher

2 1

Re: [Snow-users-list] define-syntax*
by Marc Feeley 10 Mar '07

10 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9-Mar-07, at 12:06 PM, Jan Skibinski wrote: >> > expect most of the lesser Schemes will not support define-syntax at >> > all (e.g. EdScheme, Elk, JScheme, LispMe, SIOD, TinyScheme, to >> name a >> > few). >> > >> > So it boils down to a portability issue. If Snow adds support for >> > define-syntax, then packages that use it will not be portable to >> many >> > Scheme systems. Should we care? > > This seems like a lot of them would be left out on the cold. But maybe > you, the Snow parents, should first answer this question: What exactly > motivated you to create Snow in the first place? I know - portability. > But in what sense? It is really about practical Scheme programming, i.e. using Scheme to write real applications. To achieve this goal we need packages for lots of different functionality. To achieve that goal we need the bulk of the combined manpower of the various Scheme subcommunities. For that we need a framework that is portable, i.e. where everyone involved feels they can benefit from the Snow packages in their favourite Scheme system. Portability is also important to attract new users to Scheme by giving them the freedom to select the Scheme system best suited for their application, and to change the system during the course of developing and maintaining their application as their needs change. > > If it was mainly done for pedagogical reasons, then we should only > worry about such subset of Scheme implementations that is currently > taught, or aspire to be taught, at schools. But if Snow is to be > industrially portable, then we should be more careful here and perhaps > consider each case separately. > > For example, of those lesser known Schemes, Elk and TinyScheme are > mostly used for embedding, so we should not worry about those, right? > They are to be customized, cut, or extended to suit specific needs of > standalone applications, such as Impromptu, > http://impromptu.moso.com.au/. [Nota bene, a very nice application, in > my opinion] I don't think Snow should exclude embedded Schemes. Embedded systems are one of the many applications of Scheme. > > Then there are implementations that target Java: Kawa, SISC and > JScheme. I am not exactly sure what is their target audience. If their > main goal is to provide nifty Scheme ideas to Java users, then I would > not worry about them that much. But maybe this is not the main reason > of their existence. I don't understand your reasoning here. Those systems fill an important niche. > > Maybe we should ask them: do they really care to be compatible with > Snow? Problem is... who is "they"? The authors of those systems? The current users? The future users? > > For those and other Schemes that care to be Snow portable there is > always > the portable define-syntax, psyntax by Dybvig and Waddel, > http://www.cs.indiana.edu/chezscheme/syntax-case/, or possibly its > revised version, currently in R6RS. > > The caveat is: "The portable system is designed to be adaptable with > minimal effort to any Revised5 Report implementation of Scheme, with > the provision of a small set of implementation-dependent hooks to > install the expander." > > Jan The way I see it the real issue is political. I want to maximize the impact of Snow on the practice of "real-world" Scheme programming. How many users and package writers will Snow attract if define-syntax is supported, and how many users will we lose because define-syntax is supported? My intuition is that globally it will be a win to support define-syntax. Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF8aZb//V9Zc2T/v4RAupIAJwN7a91YX/XDUNfLRjo5Zimho0v/gCfcGQI X7HVuoaZwknjMdKySZaR1nI= =EW6E -----END PGP SIGNATURE-----

2 1

SXML/SSAX
by Julian Graham 10 Mar '07

10 Mar '07

Hi Marc et. al., MJ Ray brought this project to my attention -- I think it's a great idea! I write a lot of Guile Scheme code, and I'd love to contribute packages / ports / support / etc. One package I noticed (conspicuously) missing from the repository, though, is Oleg Kiselyov's SSAX/SXML modules (http://okmij.org/ftp/Scheme/SXML.html) Might I suggest the creation of an "XML" category to house it? It's already been ported to, I think, all of the Scheme platforms that Snow supports. Full disclosure: I develop and maintain two Scheme packages, SDOM (http://www.nongnu.org/sdom/) and SCSS (http://www.nongnu.org/scss/) respectively a DOM implementation and CSS parsing/query system, both of which depend on SXML and which I'd love to see included in Snow at some point. Independently of anything I'm doing, though, I think XML parsing is a pretty important component of modern systems interoperability, and I hope there's a place for it in Snow. Regards, Julian

2 1

define-syntax*
by Marc Feeley 09 Mar '07

09 Mar '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4-Mar-07, at 9:05 AM, Marc Feeley wrote: > I am playing with the idea of adding define-syntax* to > the Snow specification. I have a prototype of this in my working > copy of the generic Snow. A quick experiment indicates that all of > the currently supported Scheme systems except Gambit, Guile and SCM > support define-syntax. Out of the major Scheme systems not yet > supported by Snow, I expect Kawa, Larceny, MIT-Scheme and SISC to > also support define-syntax, but not RScheme and Stalin. Finally, I > expect most of the lesser Schemes will not support define-syntax at > all (e.g. EdScheme, Elk, JScheme, LispMe, SIOD, TinyScheme, to name a > few). > > So it boils down to a portability issue. If Snow adds support for > define-syntax, then packages that use it will not be portable to many > Scheme systems. Should we care? I think we should add define-syntax* to the Snow spec. Any one opposed? Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF8V68//V9Zc2T/v4RAkjbAJ9HIqI4L/Yh07Dqx4I1cpGlx/VvYwCbBRG9 ArrrkvvchO+nySlDbL8apqA= =+4Mi -----END PGP SIGNATURE-----

1 0

include relative path
by Anakim Border 09 Mar '07

09 Mar '07

Hi all. I'm trying to write a package using multiple .scm files. My idea was to put auxiliary functions inside an util.scm file that I'd later include* from the main .scm of that package. To make things clearer, let's take as an example the "examples" tree in the snow-generic tarball. I'm doing something like this: $ cd pi/v1.0.0/snow $ cat >pi2.scm (define* (pi2-hello) (display "hello world") (newline)) ^D $ cat >>pi.scm (include* "pi2.scm") ^D $ cd ../../.. # back into the examples dir $ snow -- hello/v1.0.0/snow/hello.scm open-input-file: cannot open input file: "/tmp/snow-generic/v1.0.0/examples/pi2.scm" (No such file or directory; errno=2) >From this error message it seems like the include* relative path is resolved with respect to the path where I invoked snow, not the path of the file actually holding the include* form. Is this the intended behaviour? Thanks for your help. AB

2 1

Errors compiling Snow with Scheme48-1.4
by David House 09 Mar '07

09 Mar '07

Hey all. I installed Snow with Scheme48-1.5, and quickly found it had problems with UTF-8. So I installed Scheme4-1.4 over the top, made /usr/local/bin/scheme48 point to the 1.4 version and tried to use snow. However, this leads to errors, which members of #scheme put down to 'A bug in Snow'. http://paste.lisp.org/display/37887#1 I'm only a beginner, but it looks like someone left a #\n in the Snow source somewhere. I've grepped around, but I couldn't find it. Is this indeed a problem with Snow, or have I messed something up along the line somewhere? If there's a quick fix (as in changing a #\n to a #\newline somewhere), I'd love to know about it. Thanks in advance. -- -David House, dmhouse(a)gmail.com

2 1

Snow Patrol
by Jan Skibinski 04 Mar '07

04 Mar '07

Hi, A very good initiative! I will certainly use it in my scheme-osa project. Do you envision setting some sort of Snow Patrol to assure consistency, portability and quality of the Snow packages? Is there any grand library design concept in Snowfort, or is it intended to be just a loose system of individual packages? I have no idea how the self-control of package authors work in practice in other repositories of this sort. But I wonder how Egg or PlaneT deal with duplication of effort (for example, 10 HTTP oriented packages, rather than one or two), or proliferation of low quality "hello world" entries. Jan P.S. To illustrate why I wonder about the latter I point to a great democratic initiative for publishing scientific papers -- arxiv, the repository of e-prints in Physics, Mathematics, Computer Science and Quantitative Biology, http://arxiv.org/. The idea is great and the arxiv archive has served us well for many years. However, there are some problems with this repository, as David Bacon, the owner of Quantum Pontiff blog (http://dabacon.org/pontiff/?p=1418) explains: "... while the arxiv is a amazing tool, one of the problems was that the volume of papers was high and, to put it bluntly, the quality of these papers was not necessarily so great." Consequently, he established the scirate.com site to rate the papers (initially quant-phys), in order to filter out the noise. More details in the article I cited, which is sort of FAQ on subject of rating, presented rather humorously.

2 1

Packages can only be viewed/downloaded with javascript.
by Friedrich Delgado Friedrichs 04 Mar '07

04 Mar '07

Hi! I just got pointed to your website and I think it's an excellent idea. However I think it's a bad idea that packages can only be viewed/browsed when javascript is turned on in the webbrowser. Also the cursor (in firefox) does not change when it's moved over a package name, so that it's not even clear that there is something clickable. (See http://www.webpagesthatsuck.com/mysterymeatnavigation.html and http://en.wikipedia.org/wiki/Don't_Make_Me_Think) This way the packages won't be accessible to visiually impaired or blind people using w3m or w3 (or any other browser lacking javascript). I hope your mailing list at least moderates non-subscriber posts, like this one. Kind regards FDF -- Friedrich Delgado Friedrichs <friedel(a)nomaden.org>

2 1

Test
by Marc Feeley 28 Fév '07

28 Fév '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFF5LK2//V9Zc2T/v4RAkGzAJ9NUYAT6dM/s1drx7YsQ7FeUP4pTwCeMWb9 l8/MbcU2uB104nk/KRu3FBc= =zoNU -----END PGP SIGNATURE-----

1 0