Re: Guile 3.0

[Luca Fascione]

This also makes a lot of sense to me, yes.

L

On Mon, 23 May 2022, 13:12 Jean Abou Samra, <jean@abou-samra.fr> wrote:

>
>
> Le 22/05/2022 à 21:52, Luca Fascione a écrit :
> >
> > On Sun, May 22, 2022 at 9:05 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> >
> >     On Sun, 2022-05-22 at 20:14 +0200, Luca Fascione wrote:
> >     > So at the cost of rocking the cage a bit hard, I came asking the
> >     > uncomfortable question:
> >     > what would happen if (for this unique circumstance) we'd do what
> one
> >     > would normally consider poor practice?
> >
> >     Let's call your proposal by its true, scary name: we would
> essentially
> >     *fork* Guile and, in the longer term, make it fit exactly what we
> need
> >     for LilyPond.
> >
> >
> > Well, I was not thinking the delta between "true" Guile and "ours"
> > would ever get big.
> > If it did, that is what I'd call a fork. And no, I'm _not_ advocating
> > that.
> >
> > I'm more thinking something along the lines of make 3.81, actually:
> > largely "mainline",
> > plus a few small patches to adjust little details. (*)
> >
> > It's clear that a real fork is not useful here, I agree with you
> > completely
> > (*) 3.81 is famously incompatible with 3.82, and many large make
> > systems are stuck in .81 land.
> > So it's common for folks in that condition to build their own make
> > applying a few (3? maybe 4) small
> > patches to fix a few problems with the program instead. Effectively
> > they run some kind of 3.81+
> >
> >     The second implication is that we get technologically stuck.
> >
> >
> > Well, the idea is that much like now you'd state a dependency against
> > Guile 2.2.x,
> > you would then just ship the version you want. I don't see much of a
> > difference there.
> > (Again, the key in mind is that the changes from us are a _small_ set,
> > so the fact that
> > we would on occasion change the base checkout and reapply the diffs
> > should be a
> > small overhead. If you compound this with changed built to maximize
> > the chances of
> > eventual adoption, you'd risk eventually getting into a place where
> > these changes are zero)
> >
> >     With all that said, I think there are good reasons why things are
> >     considered bad practice.
> >
> >
> > There were what felt like good reasons at the time when the practices
> > were established, yes.
> >
> > However, as the hypotheses mutate, it can come a point where the
> > conclusions don't follow any longer.
> >
> > For example:
> > one doesn't want to fork because
> >  - it duplicates code and it's difficult to keep up the two diverged
> > branches
> >   -> with RCS _definitely_, with git I'm not so sure. Space cost of
> > duplication these days is zero. Time taken compiling one more repo,
> > also zero.
> >   -> this means that now this part of the reason is reduced to
> > understanding whether the divergence is large or small
> >
> > I've seen things that were bad practice when I was a student become
> > acceptable or recommended now.
> > I've come to see that "old wisdom" is sometimes not that wise after
> > all (premature optimization for example,
> > although in that case that's more an issue of misunderstanding of the
> > original meaning, than actual change).
> >
> >     Similar discussions have already taken place
> >     before, and I'm not sure if we're adding value by repeating them.
> >     Maybe
> >     we can come back to the original topic of this thread?
> >
> >
> > Forgive me for making poor use of your and the others' time.
> > I thought this might turn out to be pertinent if it opened up new ways
> > of thinking about this choice.
>
>
>
> I might have introduced confusion with the mention of the bug
> with source locations. In the specific case of LilyPond, this
> bug is not very important. Almost all the warnings Guile gives
> are pure noise in our case anyway (I haven't taken the time to
> prepare an MR for silencing them yet). It was to illustrate the
> fact that there can be serious bugs in Guile, and one could
> well affect us.
>
> Apart from that, including the Guile sources in our tree and
> building with them is something I would only do in a desperate
> situation, e.g. Guile introducing changes that are fundamentally
> incompatible with LilyPond's use case. It will be a nuisance
> not to be able to use a Guile from the system since Guile these
> days is quite slow to build. (The C code compiles fast,
> but there is a whole bootstrap sequence to generate Scheme
> compilers from Scheme code, which takes a lot of time.)
> It will require synchronization with upstream if that is
> desired. Also, while upstream isn't really active, they
> do keep it at least building which is already something.
> Rather, if it becomes clear that Guile is stuck, it would be
> more reasonable to create a fork of Guile separate from LilyPond,
> put it in a repository somewhere, invite the folks from guile-devel
> who'd appreciate commit access on Guile but don't have it to
> hack on it, advertise it for distros, apply patches from
> the tracker, and try to either get upstream to realize its
> model is not working and change it, or to make that a new
> Guile with a community around it that can survive for the
> decades to come. If we get a need to fork Guile (I don't
> see a pressing need at the moment now that we are on
> Guile 2/3), let's not do it in isolation.
>
> Jean
>
>