Re: Archive of library modules for Guile

[Andreas Rottmann]

Neil Jerram <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> Neil: I looked at the page http://www.ossau.uklinux.net/guile/ and I
>>   think there is some general use code there. If you don't have
>>   something against it, i'll reap what I consider useful, and toss it
>>   along with the guile-library-0.1 tarball into a an Arch archive for
>>   public consumption and hacking. I'll announce the availability to
>>   guile-user when ready.
>
> Please do!  Please also keep me in touch with what I need to do to
> join in the hacking - I'm not yet familiar with Arch, but what I'm
> hearing sounds fun.  It's possible that I have more up to date
> versions of some of the bits that accessible from my web page, but I
> can sort that out later as a way of getting myself used to the system.
>
OK, will start things this weekend. I'll keep guile-user, you, and ttn
posted.

>> ttn: I think it would be cool if the glug people could branch off this
>>   archive and add their general-use code to their branches. I'll then
>>   happily merge this code back in. Detailed instructions on how this
>>   would happen will be provided with the archive
>>   announcement. Thoughts? ]
>> 
>> And finally: what is the general feeling about such an archive among
>> the Guile user (and developer) community?
>
> I've been wondering about (the hypothetical) GUMM again recently,
> [...]
>
I think it would be really cool if we could work together on
standardizing on a coherent module namespace, maybe with personal
modules that are integrated into the "core" namespace as they mature
and are used more widely.

> It may be that the key to a good GUMM is not so much distribution as
> hackability - in which case your Arch archive might be just what we
> need.  Definitely worth a go, anyway.
>
One the developer side, this may suffice. I intend to only host
scheme-only stuff in the archive (at least initially), since depending
on external ABIs will complicate stuff.

On a related issue I also wonder about ttn's new build system, which
seems like an automake-replacement at a first glance. Since it ties in
Guile into the configure process (or rather the autoconf run), it's
bound to be much more flexible. I imagine one would be able to make it
an interesting team together with tla's build-config command --
i.e. build different tarball distributions for different combinations
of components of the archive automatically, so we could easily release
subsystems of the library separatly, resulting in stuff like:

guile-lib-0.1.tar.gz
guile-lib-experimental-0.1.tar.gz
guile-lib-pers-ttn-0.1.tar.gz
...

With my itla-debuild tool[0], we could release stuff directly from the
archive as Debian packages in a really convinient fashion :-)

[0] See http://stud3.tuwien.ac.at/~e9926584/ITLA.html for a bit of
    info. My current working copy just sucessfully built its first
    packages, will commit to my archive soon, expect a debian package
    in < a few months.

Cheers, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Python is executable pseudocode, Perl is executable line-noise.