Re: Do you recognize these modules?
() Noah Lavine noah.b.lav...@gmail.com
() Tue, 10 Jul 2012 23:02:29 -0400
What do you think?
WRT style, the texi imported from 1.4 is littered w/
‘@twerpdoc’, ‘@twerpmacdoc’ and ‘@twerpcommentary’
comments. IWBN to filter them before committing.
WRT content, IIRC 1.4.x (ice-9 calling) was re{designed,written}
so its documentation should not be imported w/o thorough review.
E.g., 1.4 has and 1.8 lacks ‘save-bindings-excursion’. There are
probably various other skewings (mostly additions, one hopes) in
other modules, which need to be reconciled at some point, as well.
(Maybe you know all this and are planning to make these changes in
another patch set -- in that case, no worries, sorry for the noise!)
Re: Guile build failure
Hi, David Pirotte da...@altosw.be skribis: This was using stable. No I didn't try the tarball, but since you asked i just did and did in 2 different locations: /opt [no nfs] and /usr/local/src [uses nfs] and make check passes on /opt but fails on /usr/local/src So the problem seems to be NFS-related. Could you check rmdir /mnt/galia/linux/64/local/src/guile/guile-2.0.6/load-test.dir fails? Thanks, Ludo’.
Re: Do you recognize these modules?
On Wed 11 Jul 2012 05:02, Noah Lavine noah.b.lav...@gmail.com writes: I'm sorry to miss 2.0.6 by only a few days, but I have turned this documentation into some patches. Here they are; I think they are ready to apply to stable-2.0. Cool. I applied the first one. When applying the rest, I got: /home/wingo/src/guile/doc/ref//lineio.texi:12: Prev reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//hcons.texi:12: `Eq? Hash Consing' has no Up field (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//gap-buffer.texi:12: Next reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//guile.texi:375: Menu reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//hcons.texi:12: warning: unreferenced node `Eq? Hash Consing'. makeinfo: Removing output file `guile.info' due to errors; use --force to preserve. make[4]: *** [guile.info] Error 1 As Thien-Thi suggests, it's probably good to filter out the @twerpcommentary etcetera in your next patches. Cheers, Andy -- http://wingolog.org/
Re: Do you recognize these modules?
Ooops, I think those errors are because I forgot to commit my changes to guile.texi for patches 3 and 4. Here are updated versions. (I believe the second patch from earlier should work.) I will make another patch to clean out the @twerpcommentary lines. Noah On Wed, Jul 11, 2012 at 6:44 AM, Andy Wingo wi...@pobox.com wrote: On Wed 11 Jul 2012 05:02, Noah Lavine noah.b.lav...@gmail.com writes: I'm sorry to miss 2.0.6 by only a few days, but I have turned this documentation into some patches. Here they are; I think they are ready to apply to stable-2.0. Cool. I applied the first one. When applying the rest, I got: /home/wingo/src/guile/doc/ref//lineio.texi:12: Prev reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//hcons.texi:12: `Eq? Hash Consing' has no Up field (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//gap-buffer.texi:12: Next reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//guile.texi:375: Menu reference to nonexistent node `Double-Key Hash Tables' (perhaps incorrect sectioning?). /home/wingo/src/guile/doc/ref//hcons.texi:12: warning: unreferenced node `Eq? Hash Consing'. makeinfo: Removing output file `guile.info' due to errors; use --force to preserve. make[4]: *** [guile.info] Error 1 As Thien-Thi suggests, it's probably good to filter out the @twerpcommentary etcetera in your next patches. Cheers, Andy -- http://wingolog.org/ 0001-Documentation-style-change.patch Description: Binary data 0002-Document-ice-9-string-fun.patch Description: Binary data
Running non-scheme scripts: some thoughts
Hi, Though guile is really a multi-language vm, it does not provide a simple way to run scripts for languages other scheme from the command line. I think we should add a --language switch that takes a mandatory argument, and use that to determine the language. Other solutions for dealing with multiple languages have been proposed before, including guessing the language from the file extension[0], or from the file itself (via a something like racket's #lang). While guile could move towards those at a later date, I think the --language switch is a good one for now. Firstly, it could be implemented simply with, I think, only modifications to (ice-9 command-line). Secondly, it is compatible with these other designs; a future language guessing guile could honour --language, and where that switch is not provided would be free to guess; a similar situation would occurs if we went with a #lang type solution. Anyway, some thought needs to be taken as to how this will integrate with the other switches. In particular: -s, -c, -l, -e, and maybe --listen, -q, and --use-srfi. I think that if --language=LANG is specified, then the files given by -s, and -l should be treated as though they contained LANG source code. Similarly, the string argument to -c, as a string of LANG. -e would ideally be a function in LANG, but I don't know the details of how this works in the other languages, and so could be left off for now. If guile was used interactively with the --language switch, it would give you a guile repl already in that language, similar to if we did ,L. I think this is how it should interact with --listen too, though I'm not positive. -q, or rather, when -q is not supplied, is tricky. I think we should just assume that it is always going to be in Scheme. I'm open to suggestions. I don't know how module interaction works in other languages, so I also can't comment on the suitability of --use-srfi. So, thoughts? Counter-proposals? Flames? Have I missed out anything particularly obvious? tl;dr +1 to add a --language switch to guile :P [0]. I don't personally like this solution, since it seems fragile, and it's not clear how it would interact with the -x switch. -- Ian Price Programming is like pinball. The reward for doing it well is the opportunity to do it again - from The Wizardy Compiled
Re: Running non-scheme scripts: some thoughts
On Wed, Jul 11, 2012 at 11:31 AM, Ian Price ianpric...@googlemail.com wrote: Hi, Though guile is really a multi-language vm, it does not provide a simple way to run scripts for languages other scheme from the command line. I think we should add a --language switch that takes a mandatory argument, and use that to determine the language. Seems smarter to just have different executables: guile (and guile-scheme for completeness via hard/soft link) guile-elisp ... guile-LANG That seems like it'd lead to far less confusion overall. Andrew -- http://www.apgwoz.com
Re: Running non-scheme scripts: some thoughts
Personally I would think that having Guile guess by extension would be the, in most cases, most reliable. Otherwise there could be problems loading several files in different languages etc. I would think that one of the best solution would be to have a switch to execute arbitrary commands such as ,L so you would call guile with `guile --switch ,L elisp`. The separate executables could then be done as aliases if one wanted. On Wed, Jul 11, 2012 at 5:37 PM, Andrew Gwozdziewycz apg...@gmail.comwrote: On Wed, Jul 11, 2012 at 11:31 AM, Ian Price ianpric...@googlemail.com wrote: Hi, Though guile is really a multi-language vm, it does not provide a simple way to run scripts for languages other scheme from the command line. I think we should add a --language switch that takes a mandatory argument, and use that to determine the language. Seems smarter to just have different executables: guile (and guile-scheme for completeness via hard/soft link) guile-elisp ... guile-LANG That seems like it'd lead to far less confusion overall. Andrew -- http://www.apgwoz.com
Re: Running non-scheme scripts: some thoughts
Personally I would think that having Guile guess by extension would be the, in most cases, most reliable. Otherwise there could be problems loading several files in different languages etc. Yes, my vote is gussing by extension. But also provide an option --lang to specify in case the extension name conflicts or other problems. I would think that one of the best solution would be to have a switch to execute arbitrary commands such as ,L so you would call guile with `guile --switch ,L elisp`. The separate executables could then be done as aliases if one wanted. Personally, I think this syntax is a little too long. I prefer --lang. Anyway, I'm happy that someone raised such a topic since I'm interested in multi-language feature in Guile. ;-)
Re: Running non-scheme scripts: some thoughts
On 12 July 2012 13:12, nalaginrut nalagin...@gmail.com wrote: Personally I would think that having Guile guess by extension would be the, in most cases, most reliable. Otherwise there could be problems loading several files in different languages etc. Yes, my vote is gussing by extension. But also provide an option --lang to specify in case the extension name conflicts or other problems. For most entry-points, there is no extension. When you install your program, you normally install it as /usr/bin/foo, rather than /usr/bin/foo.[ss|scm|py|js|whatever]. This is the motivation for guile-foo symlinks or --lang options. I favour the symlinks slightly, because not all languages are going to work with guile's extended mesh-wow system, and indirection via env already costs you one argument. For modules, specifically in languages where the module system has some abstraction above the filesystem, the mechanism that locates the module should be responsible for setting the module language. In other words, allow guile to defer to the language implementation to figure out the language of the loaded module in most situations. I think that otherwise, it should be up to the code using the module to supply the language with which it should be run. Extensions are one thing, but there is quite a bit that they can't handle, like rakefiles. And extensions don't allow you to specify a language level, either. -- William Leslie
