guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile-PG 0.91 - what am I doing wrong?


From: Chris Hall
Subject: Re: Guile-PG 0.91 - what am I doing wrong?
Date: Sun, 06 Jun 2004 01:32:13 -1000
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux)

On Sun, Jun 06, 2004 at 05:21:06AM +0200, Thien-Thi Nguyen wrote:
> 
> if you're installing guile anyway, you might as well try 1.4.1.98,
> with which guile-pg 0.19 was tested, available in directory:
> 
>   http://www.glug.org/alt/

Thanks, I was wondering where this was!


> (works for me under debian woody w/ gcc 2.95.4.)  you can use the
>

I've got both gcc 2.95.4 and 3.0.4 on debian woody, so this is good to
know.


>   http://www.glug.org/alt/guile-1.4.1.98.TESTED
>

Again, very good information to have.


> 
>   http://www.muppetslab.org:8001/

That's an impressive amount of software!


> alternatively, if you can provide patches for guile-pg to make it work
> w/ guile 1.6.x w/o breaking builds using guile 1.4.x, i will be happy to
> look them over and give you feedback.
> 
> thi

Cool - as soon as I get settled (I'm moving soon) I'll look into doing
just that.

I'm new to guile and and the guile newsgroup, and I really appreciate
your taking the time to respond.

I imagine you get asked this a lot, and I'll understand if you are
hesitant to answer (Eeek! A flame war!), but may I ask what reason(s)
led to you taking on the immense effort of maintaining a separate Guile
distribution?

If you'd like, we can take this off-list, and I'll promise to keep
anything you tell me confidential (I also realize what a leap of faith
that would be on your part!).

I've downloaded and unpacked the distribution and looked at the README,
docs/, etc., but couldn't find any explanation - perhaps I missed it?  I
also couldn't seem to find anything on your web site.

I've been developing software professionally for a long time (a few
years longer than you, going by your web page), so I have some idea what
is involved in an undertaking such as yours.  Personally speaking, it
would have to be a *seriously* major issue - something like the original
maintainers stopping work on the project, or the entire purpose/basis of
the project changed, or something like that, and I had clients whose
businesses depended on the software and its features.

I've asked a few people on the list, and my sense is that everyone is
highly appreciative of your upgrading and maintaining so many guile
extensions, a bit awed by how productive you seem to be, and generally
feeling miserable about the whole situation.  In short, they seem to
love Guile, respect you and speak well of you, but they really wish
there was only one version of Guile.

And no one seems to really know much about or understand *why* there
are two somewhat incompatible versions of Guile, other than that there
was some sort of falling out.

The most detailed explanation I've received so far mentioned rather
tentatively something about 'bound?' and C-only modules.  Based on my
research there seem to exist fairly reasonable, straightforward
work-arounds for these - I saw a procedure for searching the
environment's symbol table on comp.lang.scheme just last night,
<address@hidden>, and surely
'load-extension' isn't all _that_ much bother.

So, speaking as a newbie, and for potential other newbies, how is one
supposed to go about choosing which version to use?  Realistically,
what information do we have to base our decision on?

One the one hand, we see the 'official' Guile 1.6.4, backed by the
FSF/GNU Project, and presumably blessed by RMS - who after all, got
the whole Guile effort rolling 'in the beginning'. ;-)

On the other hand, we see the self-described 'dissident Guile
hackers', http://www.glug.org/alt/, hinting at some sort of censorship
as being the reason behind the 'dissident' version 1.4.1 - and no
further information at all, at least that I have been able to find so
far.  Nary a mention that I could find on the FSF site, either.

The consequence being that we newbies cannot easily (if at all)
determine how the two versions differ, or why, and thus cannot
possibly be expected to be able to make an informed choice between the
two distributions.

As a consultant, when I am faced with situations of this sort I
usually recommend the more 'reputable' vendor, all other things being
equal.  In this case, that would almost _have_ to be the FSF.  Nothing
personal - you have been responsive to me, you are demonstrably very
dedicated to Guile, and pretty obviously feel strongly about it and
are committed to furthering its usefulness and 'audience'.  But I
think most clients would probably settle on FSF Guile as the 'better
bet', unless they had other information available to them - e.g.,
distinguishing (and compelling?) technical differences, performance or
reliablity improvements, etc.

The truly awkward bit, from both a client's perspective and a
user/programmer's (my own) point of view, is that by far the 'lion's
share' of active development, at least in the extension arena, is done
by the 'dissident' movement, incompatibilities are becoming increasingly
troublesome, and thus the need to choose is becoming more important,
more painful and more difficult.

So I really appreciate your willingness to consider patches that would
allow the distributions to continue 'sharing' extensions.

To my mind, though, this strategy seems far from optimal for either of
the parties involved - and even as a newbie I seem to sense that the
time of uneasy coexistence is nearing its end as the differences between
the distributions increase.

Scheme is Scheme is Scheme, and there are many implementations that
can more or less share code - Scheme seems better, in this respect,
than Lisp, though I don't really know.

Guile is simply an implementation of Scheme specialized and optimized
for use as an extension language, so perhaps there is a middle ground we
could find here, so that we can continue to share extensions?  I.e.,
could differences be isolated to specific modules/locations/idioms and
thus allow a generalized build mechanism for the extensions so that
build adapts to the host version of Guile?  Of course, the respective
camps would be responsible for supplying and testing the respective
build steps.

If something along these lines were possible, multiple benefits would
accrue:

 * your work with extensions would be useful to many more people,

 * other people could write extensions usable by either Guile version,

 * confusion as to what runs where would be considerably reduced,

 * people could select the Guile version most appropriate to their
   applications' requirements,

 * _all_ of us could feel better about things! :-D

At the very least, could the information as to how and why the
different Guile versions differ be made generally available?

Thanks again, and Aloha!,
+Chris

__
No single drop of water thinks it is responsible for the flood.
-- Old adage

-- 
Don't you wish there were a knob on the TV to turn up the
intelligence? There's one marked 'Brightness,' but it doesn't work.
-- Gallagher

Attachment: pgpz32hQGwq7u.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]