git server broken?
My autobuild failed, and on checking: list gdt 12 ~/BUILD-GUILE-1.8/guile git pull git.sv.gnu.org[0: 199.232.41.69]: errno=Connection refused fatal: unable to connect a socket (Connection refused) pgpMCBsYyRpJV.pgp Description: PGP signature
Re: git server broken?
On Mon, 2009-06-01 at 07:15 -0400, Greg Troxel wrote: My autobuild failed, and on checking: list gdt 12 ~/BUILD-GUILE-1.8/guile git pull git.sv.gnu.org[0: 199.232.41.69]: errno=Connection refused fatal: unable to connect a socket (Connection refused) Yeah, savannah was mostly dead. When it recovers, it will actually have lost most of the info in the git repositories since their backup a month ago. Info here. http://lists.gnu.org/archive/html/savannah-users/2009-05/msg00023.html
Re: r6rs libraries, round two
Hey Julian, On Sun 31 May 2009 01:22, Neil Jerram n...@ossau.uklinux.net writes: Julian Graham jool...@gmail.com writes: 1. Add an optional `version' field to the module record type Sounds good. Agreed. * What's a good format here? We could mirror the requirements of R6RS here (i.e., (v1 v2 ...) where vx is a whole number) or be more flexible. Given that your objective is to get R6RS library support in, I'd say just stick to the R6RS format for now. It sounds like it will be fairly easy to extend this in future, if we want to. Also agreed. * Should we establish some rules for what you get when you don't specify a version? Yes! The latest available? I don't know. To me this could be a distro decision, like Debian's alternatives system. It would be nice to minimize the number of `stat' calls it takes to load a library -- which would fall out nicely if when asking for a module without specifying a version, like `(foo bar)', we give foo/bar.scm. In the presence of multiple versions, installation rules could handle making the symlink so there is a default version -- typically the version that was installed most recently. Given what we've decided about loading multiple versions of a library (i.e., you can't) I didn't follow why we decided that, but it feels wrong to me. (It seems to me that Guile should be able to handle loading ((foo) v1) and ((foo) v2) simultaneously as easily as it could handle loading ((foo-v1)) and ((foo-v2)) simultaneously.) I guess I should look up the previous thread, please let me know if you have a convenient reference. I agree it would be nice, but as I said in the thread that Julian referenced, that would take some more thought -- more than the R6RS editors were willing to give the problem. And for us, I suspect we would need some changes to our hierarchical namespaces. We probably shouldn't let this be a sticking point for Guile's R6RS libraries support. Regards, Andy -- http://wingolog.org/
Re: Publishing the manual...
On Sun 31 May 2009 02:11, Neil Jerram n...@ossau.uklinux.net writes: I should let you all know that Brian Gough has approached me about publishing the Guile manual. How lovely! This is great news :-) If you have any ideas about this, or would like to help out, or have any concerns, please let me know. Consider adding a section on GOOPS, from the GOOPS manual and tutorial. Folding that into the Guile manual would be great. We need to document syntax-rules and syntax-case, and the concept of hygiene wrt macros and modules. We should document the new REPL. Anyway, just some scattered evening thoughts. Good luck, and let me know if I can help in any specific way! Andy -- http://wingolog.org/
Re: r6rs libraries, round two
Hello! Andy Wingo wi...@pobox.com writes: * Should we establish some rules for what you get when you don't specify a version? Yes! The latest available? I don't know. This is IMO a terrific part of version handling in R6 modules. What will it mean for a 2009 program to import `(rnrs base)' when R27RS is released? This was discussed and questioned back then: http://lists.r6rs.org/pipermail/r6rs-discuss/2007-May/002332.html . I think such issues should lead us to have a `:version' option that does just what's needed for R6RS, and does not try to do anything smart (which could seem to be non-deterministic). We could even go as far as discouraging its use in the manual. Thanks, Ludo'.
