role of guile-lib

role of guile-lib

[Julian Graham]

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

Re: role of guile-lib

[Andy Wingo]

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/

Re: role of guile-lib

[dsmich]

---- 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

Re: role of guile-lib

[Julian Graham]

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

Re: role of guile-lib

[Neil Jerram]

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

Re: role of guile-lib

[Ludovic Courtès]

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'.

Re: role of guile-lib

[Ludovic Courtès]

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'.

Re: role of guile-lib

[Andy Wingo]

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/

Re: role of guile-lib

[Ludovic Courtès]

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'.