Re: language translator help

[Marius Vollmer <mvo@zagadka.ping.de>]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 15 May 2002 22:49:06 +0200
> 
>    Please don't do this in the context of 1.4 releases.  We have the 1.7
>    series for experiments like that.  Please keep the 1.4 releases
>    (if you feel that you must divert resources to them) as bug fixing
>    releases.
> 
> who uses libguilereadline independent of using libguile?  who uses
> libqthreads independent of using libguile?  moving these things inside
> is a bugfix; the user experience is not changed incompatibly.

What is the bug?

The point is not to allow linking to libguilereadline without also
linking to libguile.  We want to support linking to libguilereadline
and to the other extension libraries together with libguile using the
ld linker.

I don't know nearly as much about shared libraries as the libtool guys
do, but I do know that treating them right is far from trivial.  So my
position is that without good reasons we should keep our shared
libraries things as simple as possible and deviate as little from the
usual way of handling shared libraries as possible.

Unix shared libraries are in a flat namespace with versioning, cobbled
together via some environment variables.  I don't like this design
either, but putting our extension libraries into this namespace poses
no problems (that I could see).  We can't use the versioning from
'dynamic-link' yet, and that is a problem, but we should ideally fix
this by making the versioning available to all users of lt_dlopen, not
by working around it via implementing our own versioning on top of the
existing one (by putting shared libraries outside their natural
namespace).

The hack for 1.6 to include the versioning information explicitely in
the filename is such a workaround, and will hopefully be very
temporary.

> overall maintenance is eased.  (all 1.4.x releases aim for this --
> sorry, i was not clear about that goal.)

I don't think we should have an extended 1.4.x series.  If anything,
the fixes should be backported from the HEAD branch.  But I haven't
heard enough convincing arguments for continuing the 1.4.x release
series, yet.

>    On the specific point of what exactly a Guile extension or plugin is,
>    where to install it, how to link to it, etc, I remain convinced that
>    Guile itself should continue to treat its extensions as standard
>    operating system shared libraries, using libtool as the interface to
>    the operating system.
> 
> of course you do (because you don't take user feedback into account on
> this issue perhaps),

I like to think I do.

> and because of this, no third party can produce guile plug-ins
> cleanly w/o major hassle,

The "Guile plug-in" is just a shared library.  Where is the major
hassle in producing it?

>    Experimentation can occur outside of Guile.  Packages that need to go
>    beyond the simplistic shared library view of the core Guile and want
>    to impose additional rules on the use of their shared libraries can do
>    so to a very large degree without needing any cooperation from Guile
>    itself.
> 
> you don't get it.  packages WANT cooperation from guile (otherwise guile
> is seen as un-cooperative and a PITA to work with -- duh!).

Yes, they want cooperation and the are entitled to it, of course.  I
said "experimentation".  Package developers that are dissatisfied with
Guile's approach can try to do better without cooperation from Guile.
Being able to proceed without needing explicit cooperation from Guile
is a feature.  Not needing to proceed on ones own because there
already just the right cooperation from Guile is even better, of
course.

I'm not saying that the last word on the extension/plugin issue has
been said.  The first thing I ask you to is to not engage in private,
isolated experiments in the 1.4.x series.  Maybe I have misunderstood
your intentions.

> i can harp on this more, but because you don't take user feedback
> into account on this issue, what's the point?

As I said, I think I do take feedback into account (from users _and_
developers ;).  That's how I arrived at the position that I'm
currently taking.

>    Negative.  I don't have the feeling that we are dangerously
>    incompatible in the 1.6 series.  What do others think?  It would be
>    bad to switch strategies at this point, even if you have a point.
> 
> if you can articulate your strategy in the first place, that would be a
> good start for discussion.  if you can record this, that would be best.

The strategy that I was talking about is to release 1.6 from the
'stable' branch in th immediate future.  Maybe strategy is the wrong
word for this.

>    What is wrong with Guile's current approach other than that you don't
>    like it?
> 
> guile has a bunch of people working on it for their own ego fulfillment
> (self-included), w/ varying levels of organization and maturity.  this
> is not to like or dislike but to understand and work through.

I meant Guile's specific approach towards the extension/plugin issue.

>    What?  The split is there so that people can choose not to be
>    bothered with developers chit chat.  You don't need a license to
>    subscribe to guile-devel.  It's a tool of organization, you process
>    junkie, not of dividing and conquering people.
> 
> it's a tool of insulation, and fosters this kind of dialogue:
> 
>  developer-1: hey, what do you think of BRAINDEAD-IDEA?
>  developer-2: THOUGHTLESS-AFFIRMATION.
>  user-1: i don't understand.
>  developer-1 and developer-2: don't worry, we are the experts;
>                               you'll love it, really!
> 
>  [6mo later]
>  developer-1: well, we have to start over again.
>  developer-2: THOUGHTLESS-AFFIRMATION.
>  user-2: hey, that breaks my code.
>  developer-1 and developer-2: you're a user, go away!

Is that really how things typically are?  And they would stop with
just one mailing list?  I don't think so, on both points.

> all guile users are programmers;

(but not developers of guile itself)

> if you can't see how guile developers have something in common w/
> guile users

Of course they have.  We have two _mailing lists_, not two strictly
divided groups of people.

We must be talking past each other here.

Anyway, you can't really have write privs and be unsubscribed from
guile-devel at the same time.  So even if you protest the existence of
guile-devel, do it by not posting to it instead of ignoring it
completely.

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user