Re: Guile 3.0

[Jean Abou Samra]

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