Re: To branch or not to branch

[Jonas Hahnfeld]

On Wed, 2022-09-21 at 20:16 +0200, Jean Abou Samra wrote:
> Le 21/09/2022 à 08:29, Jonas Hahnfeld via Discussions on LilyPond 
> development a écrit :
> > Hi all,
> > 
> > according to the plan laid out in
> > https://lists.gnu.org/archive/html/lilypond-devel/2022-08/msg00032.html
> > we are supposed to branch stable/2.24 this week "unless some really big
> > problems are reported". In the last discussion on this topic in
> > https://lists.gnu.org/archive/html/lilypond-devel/2022-09/msg00070.html
> > the rare crashes on Windows were identified as a blocker. These seem to
> > be fixed now, at least for reasonable user scores (we can still trigger
> > it when running the garbage collection in every translator slot); see
> > https://gitlab.com/lilypond/lilypond/-/issues/6361 for full details.
> > 
> > There is also https://gitlab.com/lilypond/lilypond/-/issues/6430 which
> > is a problem for OLL on Windows. I can't personally comment if it's
> > "critical enough" to block the branching / release.
> > 
> > Please comment, also with other issues and thoughts. It's a bit
> > frustrating if there are no clear replies and I'm left to guess...
> 
> My thoughts:
> 
> I don't think the call/cc issue should block branching,
> especially now that it's worked around in OLL. The classical
> use for call/cc is escape continuations, emulating "return"
> statements from imperative languages. Guile 2 has call/ec
> (and its variant let/ec) that support this case (also
> more efficiently). I didn't see them crash, and they're
> implemented completely differently, so I don't see a reason
> for them to be broken. I expect that almost all uses of
> call/cc can be replaced with let/ec. The one in OLL actually
> couldn't, but this is a pretty rare programming style.
> 
> I'm undecided on whether call/cc should eventually block
> the stable release if we don't have a fix for it. I'm
> a fan of call/cc (I mean, introducing it in the Curry-Howard
> correspondence changes the logic from intuitionistic to
> classical :-), but I doubt many people use it or even know
> what it is.
> 
> On the other hand, there is actually one use in LilyPond
> (in articulate.ly), and I didn't investigate what other tools
> Guile implements in terms of call/cc...

Ok, that would be interesting to know... However, given that we haven't
heard about that yet, it might not be all that important.

> So, to be continued, but I'm less worried about this one
> than the GC one.
> 
> Now to GC. I'm a bit worried by the report from "Ya Gloops"
> that some 200-pages scores still crash
> (https://lists.gnu.org/archive/html/lilypond-user/2022-09/msg00238.html).
> Yes, they're artificial, but they don't call the GC
> explicitly, and some people do write scores with the same size...
> 
> So I'd be cautious about releasing 2.24 without a full fix
> for this one. That said, Ivan Maidanski is making some
> comments on the BDWGC issue. A fix in 3 months is not
> hopeless, is it?

Not hopeless, but the suggestion involves making some inline assembly
work to "catch" the crash and then continue. And it's still not clear
to me if that is the correct solution, we would need to debug what is
actually happening for the newly reported crashes (which I can't even
reproduce)...

> And if we do get a fix, waiting before branching won't have
> helped stability, so overall I think it's OK to branch now,
> although I don't have deep insights on the BDWGC issue.

signature.asc
Description: This is a digitally signed message part