* role of guile-lib @ 2008-12-24 21:14 Julian Graham 2008-12-25 11:23 ` Andy Wingo 0 siblings, 1 reply; 9+ messages in thread From: Julian Graham @ 2008-12-24 21:14 UTC (permalink / raw) To: Guile User Hi everyone, So I found myself with a little bit of spare time this week and so I dusted off a Guile-based project I've been working on and was dismayed to be reminded that the current version of guile-lib (0.1.6) includes a distribution of SSAX that flat-out doesn't work. I've posted about this on the guile-lib mailing list and filed a bug on gna.org, but that was a year ago and since neither of those locations is controlled by active guile-lib contributors [1], I don't expect to see much movement on this in the immediate future. But it does raise the question of what the proper role for guile-lib is, given that no one seems to have touched it in more than a year. Its stated purpose is to serve as a "a down-scaled, limited-scope CPAN for Guile," and several of the included modules (e.g., the texinfo code) are appropriate to that description, but there are other modules in there that seem like they belong somewhere else -- not necessarily in Guile core, but in a comprehensive, maybe-obligatory library of code whose companion relationship to the Guile core distribution emphasizes the fact that its contents are things users are going to expect to have as part of a modern language platform, a la the Java "classpath libraries" or CPAN. Some examples of this type of module are: SSAX, statprof, the unit testing code, and the logging stuff (although I've actually never used those last two). So maybe the entity I'm describing above is what guile-lib is supposed to be, but it's not what it is right now. In addition to what I've already mentioned, there are package that aren't currently in guile-lib -- like Evan Prodromou's (net http) -- that would optimally be part of a more complete system. Another possibility is that the Snow project could meet this need, but there are some Guile-side technical hurdles to be jumped before it'd be viable -- and it's not like they don't have their own problems with bit-rot. It seems like other parts of Guile are being re-organized a bit right now -- any chance we could take a look at this as well? Regards, Julian [1] - http://www.wingolog.org/archives/2008/08/02/on-the-many-roads-to-perdition ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-24 21:14 role of guile-lib Julian Graham @ 2008-12-25 11:23 ` Andy Wingo 2008-12-25 13:48 ` dsmich ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Andy Wingo @ 2008-12-25 11:23 UTC (permalink / raw) To: Julian Graham; +Cc: Guile User Heya Julian, On Wed 24 Dec 2008 22:14, "Julian Graham" <joolean@gmail.com> writes: > So I found myself with a little bit of spare time this week and so I > dusted off a Guile-based project I've been working on and was dismayed > to be reminded that the current version of guile-lib (0.1.6) includes > a distribution of SSAX that flat-out doesn't work. I've posted about > this on the guile-lib mailing list and filed a bug on gna.org, but > that was a year ago and since neither of those locations is controlled > by active guile-lib contributors [1], I don't expect to see much > movement on this in the immediate future. Ooh, sorry about that. I've been spread a little thin recently. And the hosting situation does suck a bit. On the other hand, I've been trying to get another guile-lib maintainer for a while now -- you interested? > But it does raise the question of what the proper role for guile-lib > is, given that no one seems to have touched it in more than a year. What do you want to do with it? A few different options come to mind: * Include (parts of?) it within Guile itself. This probably would require copyright assignment, though perhaps not, if we put them within a contrib/ section of the source distro (I would not want to put `contrib' in the module name, however). * Make it a part of Guile, but not a part of the guile source distribution. This way all Guile committers could administer it, and perhaps it could just share the same mailing lists. > Evan Prodromou's (net http) I haven't seen this code, but I want it! :) > Another possibility is that the Snow project could meet this need, but > there are some Guile-side technical hurdles to be jumped before it'd > be viable -- and it's not like they don't have their own problems with > bit-rot. Yes, and another option (parallel effort?) is to hack in support for R6RS modules, and rely on other distributions. > It seems like other parts of Guile are being re-organized a bit right > now -- any chance we could take a look at this as well? Let's make this situation suck less! Do you want to handle this? (Also, it would be nice to move this code to git.) Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-25 11:23 ` Andy Wingo @ 2008-12-25 13:48 ` dsmich 2008-12-25 21:08 ` Julian Graham 2009-01-05 21:16 ` Ludovic Courtès 2 siblings, 0 replies; 9+ messages in thread From: dsmich @ 2008-12-25 13:48 UTC (permalink / raw) To: Julian Graham, Andy Wingo; +Cc: Guile User ---- Andy Wingo <wingo@pobox.com> wrote: > > On Wed 24 Dec 2008 22:14, "Julian Graham" <joolean@gmail.com> writes: > > > Evan Prodromou's (net http) > > I haven't seen this code, but I want it! :) If you can't find this anymore (I can't), I have a copy. -Dale ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-25 11:23 ` Andy Wingo 2008-12-25 13:48 ` dsmich @ 2008-12-25 21:08 ` Julian Graham 2008-12-26 11:50 ` Neil Jerram 2009-01-05 21:16 ` Ludovic Courtès 2 siblings, 1 reply; 9+ messages in thread From: Julian Graham @ 2008-12-25 21:08 UTC (permalink / raw) To: Andy Wingo; +Cc: Guile User Hola Andy! Sorry if that email sounded bitchy. > Ooh, sorry about that. I've been spread a little thin recently. And the > hosting situation does suck a bit. On the other hand, I've been trying > to get another guile-lib maintainer for a while now -- you interested? Well, I would be, except I'm spread a bit thin right now, too (working for a startup that's on the verge of a release). Plus, I don't know that I have a thorough enough understanding of Guile or Scheme to do the job effectively. I'd be happy to help out as much as I can, though. Is it possible to, uh, wrest control of the hosting situation? Or would it be better to start fresh with a new location / list? >> But it does raise the question of what the proper role for guile-lib >> is, given that no one seems to have touched it in more than a year. > > What do you want to do with it? > > A few different options come to mind: > > * Include (parts of?) it within Guile itself. This probably would > require copyright assignment, though perhaps not, if we put them > within a contrib/ section of the source distro (I would not want to > put `contrib' in the module name, however). > > * Make it a part of Guile, but not a part of the guile source > distribution. This way all Guile committers could administer it, and > perhaps it could just share the same mailing lists. I like that second option (although it doesn't do anything for cross-Scheme compatibility), and I'd imagine it'd go over better with Guile developers than making it part of Guile itself. >> Evan Prodromou's (net http) > > I haven't seen this code, but I want it! :) I think this is the most recent release: http://evan.prodromou.name/software/net-http/ From what I can tell, it's no longer maintained (and as I remember was only partially complete), but even as a starting point for a real HTTP client implentation for Guile, you could do a lot worse. >> Another possibility is that the Snow project could meet this need, but >> there are some Guile-side technical hurdles to be jumped before it'd >> be viable -- and it's not like they don't have their own problems with >> bit-rot. > > Yes, and another option (parallel effort?) is to hack in support for > R6RS modules, and rely on other distributions. Hey, sure -- although we'd still need a way to locate modules. And could we actually rely on other distributions? My outsider impression is that there was a minor revolt when R6RS was passed (but maybe the library system was less offensive to people?). The only reason I suggested Snow was that it seemed, for whatever reason -- and however briefly -- to have a tiny bit of cross-platform traction. The R6RS library syntax ain't bad, though, now that I read the spec. I'll take a look at how hard it'd be to wedge it into Guile. >> It seems like other parts of Guile are being re-organized a bit right >> now -- any chance we could take a look at this as well? > > Let's make this situation suck less! Do you want to handle this? (Also, > it would be nice to move this code to git.) Well, I can make some suggestions! In addition to the above, maybe we could do a module-by-module audit of the current suite of code in guile-lib and see what the current state of each is -- i.e., whether it's compatible with Guile 1.8 / HEAD; if it's been superceded by code added to Guile core, etc. Would that be useful? Regards, Julian ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-25 21:08 ` Julian Graham @ 2008-12-26 11:50 ` Neil Jerram 2009-01-05 21:11 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Neil Jerram @ 2008-12-26 11:50 UTC (permalink / raw) To: Julian Graham; +Cc: Andy Wingo, Guile User 2008/12/25 Julian Graham <joolean@gmail.com>: > >>> But it does raise the question of what the proper role for guile-lib >>> is, given that no one seems to have touched it in more than a year. >> >> What do you want to do with it? >> >> A few different options come to mind: >> >> * Include (parts of?) it within Guile itself. This probably would >> require copyright assignment, though perhaps not, if we put them >> within a contrib/ section of the source distro (I would not want to >> put `contrib' in the module name, however). >> >> * Make it a part of Guile, but not a part of the guile source >> distribution. This way all Guile committers could administer it, and >> perhaps it could just share the same mailing lists. > > I like that second option (although it doesn't do anything for > cross-Scheme compatibility), and I'd imagine it'd go over better with > Guile developers than making it part of Guile itself. Apart from the need for copyright assignment, and wanting to avoid making incompatible Scheme API changes, I personally see no problem with gradually rolling more and more Scheme library code into the core Guile. It doesn't AFAIK seem to have hurt Emacs to do this, and it's a massive convenience that when you install Emacs, everything that you might need is just there. (Even including massive subsystems like Calc.) On copyright assignment, I'd like to know if there are other GNU projects with "contrib" sections where assignment isn't requirement; anyone know? Avoiding incompatible changes just means that stuff should only be rolled in when its (believed to be) ready. >> Yes, and another option (parallel effort?) is to hack in support for >> R6RS modules, and rely on other distributions. > > Hey, sure -- although we'd still need a way to locate modules. And > could we actually rely on other distributions? My outsider impression > is that there was a minor revolt when R6RS was passed (but maybe the > library system was less offensive to people?). IMO no; I'd say the library system is one of the more offensive parts of R6RS. Even so, I wouldn't object to someone trying to hack in a way of loading R6RS libraries into Guile. Regards, Neil ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-26 11:50 ` Neil Jerram @ 2009-01-05 21:11 ` Ludovic Courtès 0 siblings, 0 replies; 9+ messages in thread From: Ludovic Courtès @ 2009-01-05 21:11 UTC (permalink / raw) To: guile-user Hi, "Neil Jerram" <neiljerram@googlemail.com> writes: > Apart from the need for copyright assignment, and wanting to avoid > making incompatible Scheme API changes, I personally see no problem > with gradually rolling more and more Scheme library code into the core > Guile. It doesn't AFAIK seem to have hurt Emacs to do this, and it's > a massive convenience that when you install Emacs, everything that you > might need is just there. (Even including massive subsystems like > Calc.) Agreed. > On copyright assignment, I'd like to know if there are other GNU > projects with "contrib" sections where assignment isn't requirement; > anyone know? Avoiding incompatible changes just means that stuff > should only be rolled in when its (believed to be) ready. GNUnet, at least, has that, but many (most?) things in there are subject to bit-rot and are not documented. Besides, copyright of GNUnet core is not assigned to the FSF either. Thanks, Ludo'. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2008-12-25 11:23 ` Andy Wingo 2008-12-25 13:48 ` dsmich 2008-12-25 21:08 ` Julian Graham @ 2009-01-05 21:16 ` Ludovic Courtès 2009-01-06 9:27 ` Andy Wingo 2 siblings, 1 reply; 9+ messages in thread From: Ludovic Courtès @ 2009-01-05 21:16 UTC (permalink / raw) To: guile-user Hello! Andy Wingo <wingo@pobox.com> writes: > A few different options come to mind: > > * Include (parts of?) it within Guile itself. This probably would > require copyright assignment, though perhaps not, if we put them > within a contrib/ section of the source distro (I would not want to > put `contrib' in the module name, however). > > * Make it a part of Guile, but not a part of the guile source > distribution. This way all Guile committers could administer it, and > perhaps it could just share the same mailing lists. Another solution: move the code to Git at Savannah (but as a project of its own) and provide the interested parties with commit access (I'd be one of these ;-)). (Practically, you'd be the one in the best position to do this, but then you'd be almost freed, Andy!) Then have somebody arrange to make releases periodically and voilà! :-) Guile-Lib could indeed point its users to `guile-user@gnu.org'. Thanks, Ludo'. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2009-01-05 21:16 ` Ludovic Courtès @ 2009-01-06 9:27 ` Andy Wingo 2009-01-06 15:14 ` Ludovic Courtès 0 siblings, 1 reply; 9+ messages in thread From: Andy Wingo @ 2009-01-06 9:27 UTC (permalink / raw) To: Ludovic Courtès; +Cc: guile-user Hi, On Mon 05 Jan 2009 22:16, ludo@gnu.org (Ludovic Courtès) writes: > Andy Wingo <wingo@pobox.com> writes: > >> * Include (parts of?) [guile-lib] within Guile itself >> >> * Make [guile-lib] a part of Guile, but not a part of the guile source >> distribution. > > Another solution: move the code to Git at Savannah (but as a project of > its own) and provide the interested parties with commit access (I'd be > one of these ;-)). So, sounds like the current situation with git instead of bzr, and hosted on savannah. > Guile-Lib could indeed point its users to `guile-user@gnu.org'. Yes this should be the solution in any case -- fragmenting fora for Guile discussion is not in our interest. Maybe your solution is best -- it lets us keep guile-lib's unit tests and documentation system intact, doesn't bind us quite to the quality standards of guile, but still gives us the advantages of the git/savannah switch. > (Practically, you'd be the one in the best position to do this, but > then you'd be almost freed, Andy!) Then have somebody arrange to make > releases periodically and voilà! :-) OK, ok, ok... ;-) So I'll see about doing this this afternoon, if everything works out. Cheers, Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: role of guile-lib 2009-01-06 9:27 ` Andy Wingo @ 2009-01-06 15:14 ` Ludovic Courtès 0 siblings, 0 replies; 9+ messages in thread From: Ludovic Courtès @ 2009-01-06 15:14 UTC (permalink / raw) To: guile-user Hello! Andy Wingo <wingo@pobox.com> writes: > So, sounds like the current situation with git instead of bzr, and > hosted on savannah. Yes. > Maybe your solution is best -- it lets us keep guile-lib's unit tests > and documentation system intact, doesn't bind us quite to the quality > standards of guile, but still gives us the advantages of the > git/savannah switch. Yes. Eventually we can consider moving parts of it to Guile core, e.g., the SXML infrastructure to start with. However, I think there are dependencies on Guile-Lib's framework, e.g., for the on-line macro documentation stuff, which would complicate things. Thanks, Ludo'. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-01-06 15:14 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-12-24 21:14 role of guile-lib Julian Graham 2008-12-25 11:23 ` Andy Wingo 2008-12-25 13:48 ` dsmich 2008-12-25 21:08 ` Julian Graham 2008-12-26 11:50 ` Neil Jerram 2009-01-05 21:11 ` Ludovic Courtès 2009-01-05 21:16 ` Ludovic Courtès 2009-01-06 9:27 ` Andy Wingo 2009-01-06 15:14 ` Ludovic Courtès
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).