Re: Blockers for Guile 2.2

[Jean Abou Samra]

[There is much to reply to so I'll make several emails.]


Hi Luca,

Le 24/02/2022 à 09:13, Luca Fascione a écrit :
> In case it's useful, I'll share my impressions as a recent addition to 
> this group.
>
> I have some experience with rolling out software, gathered in a 
> different field.
> Where I come from we release often (I think we've averaged in the 30+ 
> cuts
> per year, roughly 2 every 3 weeks), and our users have tolerance for 
> the occasional
> rollback, and they roll forward relatively happily.
> One very important difference is that in that environment it is built 
> into the
> infrastructure a solid mechanism for picking the software version per 
> project,
> so that you could be working on several different versions of the 
> software in the
> same day or so that were transparently tracked for you to stay on their
> corresponding working files.
>
> It seems to me the people that I hear speaking (maybe with the 
> exception of HanWen)
> have a low level of confidence in the ability of the regression/test 
> suite to provide
> adequate coverage of the scenarios needed by your current users.
> (Otherwise I don't even know why this is a discussion in the first place)
>
> I would consider this your highest priority: trusting your tests is 
> absolutely crucial.
> A release going out that passes tests and fails in the field should be 
> brought to be
> a "0 probability" event. This won't ever be the case for real, hence 
> the occasional rollback:
> when user X rolls back, a test is made and added to the suite so this 
> won't happen again
> (preaching to the choir, I get it). I wouldn't give a second of 
> thought to folks rolling back a
> binary as long as a) you're proactive in saying clearly that there's 
> be a problem and here's
> how you fix it (roll back, and roll forward once you get the next 
> binary, say);
> b) this happens rarely, obviously.



Guile 2.2 has been under daily by individual developers and some power
users for some time now. The problem is more with different operating
systems, architectures and setups. Pretty much all developers are
running some flavor of GNU/Linux with relatively up-to-date software.
The issues that popped up on the release of 2.23.6 (see
https://lists.gnu.org/archive/html/lilypond-user/2022-02/msg00155.html)
are mostly related to different OSes, OS versions, and locales.
Other matrix dimensions we have are the versions of GhostScript,
FontConfig, Pango and FreeType. The problem is not the test suite,
but the variations in setup.



> The other aspect that I observe reading this exchange is that nobody 
> is talking about
> Scheme source in client code. I see you discussing how to pick up the 
> differences between
> Guile 1.8 and 2.2 in the shipped source, but I don't recall seeing a 
> discussion focusing on user-side
> changes. And in fact, this is a similar point to the previous one: 
> either these differences are there and
> are material or they are not. In the second case, you should go ahead 
> and move to 2.2.
> In fact I'd think you ought to ship current-ish (read non 
> 2.2-specific) scheme source (with bugfixes)
> with the new runtime, and let that soak in userland for a bit (say 
> 2.24 is that, and then 2.26 contains
> 2.2 specific source). As I read some people saying certain 
> distributions are already shipping
> binaries based on Guile 2.2, I suspect maybe 2.22 (on those 
> distributions) is a passable
> proxy for this stage.
>
> In the first case (Guile 1.8 vs 2.2 actually makes a real difference 
> in source semantics and
> correctness(*), forget about the speed) your first concern must be 
> what to do about users
> migrating their source and what cost will that be, in terms of time 
> investment, instabilities
> or defects introduced and all that, which will dominate your ability 
> to reduce your
> maintenance exposure making sure the majority of your user base will 
> in fact pick up the new
> release line.



This is not too much of an issue. Guile 2 was a big change on the
"infrastructure" side: a bytecode compiler in addition to the
normal interpreter, which puts requirements on the code for being
used (the normal interpreter still works but is vastly slower), a
new garbage collector, relevant on the C (for us C++) side, Unicode
support. Have I missed something? I think these are the outstanding
points. Scheme code in LilyPond files is not precompiled, so it
doesn't have to make the byte compiler happy; it doesn't need
to care about the underlying GC; and Unicode support, of which
the poor performance has been an issue for the scale of LilyPond,
should not be an issue performance-wise for typical Scheme code
and will more often than not just make code work with special
characters that didn't before. The main differences for Scheme
code are the deprecation of omitting the port argument to format
(just prints a warning, still works), the move of curried definitions
to a module (not problematic in LilyPond since we include it
by default), and the impossibility to use definitions in the
body of a cond form (easily worked around with let). Again, I
may be missing a few (it's hard to hide that I am somewhat
fatigued), but I think those are the main ones.

Practically, it took me maybe 20 minutes to crank out a patch
for Guile 2 support in oll-core
(https://github.com/openlilylib/oll-core/issues/62), and that's
one of the main "somewhat large" pieces of user Scheme code in
the wild. This is also another factor: we're not a library
used by thousands of projects putting hard backwards
compatibility restrictions. We do care about backwards
compatibility for LilyPond code not using Scheme features,
but Scheme interfaces are less stable, which is not an issue
with respect to the size of the ecosystem, and allows
us to move forward.



> (*) not that this seems to me a very realistic thing for the Guile 
> folks to do intentionally
>
> Last thought: as I am currently learning Scheme and Guile, and I 
> noticed 3.0.x has been out for a couple years now
> and seems to be benchmarking with speeds comparable to the 1.8.x line 
> (according to their release notes).
> Given the switch to 2.2 hasn't happened yet, and as I am reading 
> through these emails, it has been
> a long process, wouldn't moving to 3.0 instead be a better way to 
> capitalize on the effort and push
> out the next round of this level of pain to a later date?
> (Again, I am expecting this has been discussed before, but still 
> occasionally it's good to re-evaluate
> decisions: circumstances change, new evidence comes up, time goes by)


3.x should not at all be troublesome to migrate to. It is
the move to 2.x that suddenly changed the direction of
the project towards a more static compiler and less focus
on our use case, plus the new GC. I didn't try, but the a
priori is that the transition should be comparatively painless.
It will just require more testing, which is going to delay
the transition from Guile 1. We really really want to be
on the new infrastructure with static binaries and Guile 2
or 3 because (1) GUB (the old infrastructure) is horrible
(see Han-Wen's reply) and (2) that is what it takes to finally
ship 64-bit binaries for macOS which is the *major* distribution
painpoint of LilyPond these days.

Once that is done, we can migrate to Guile 3 at our leisure.



> I do realize this will stir many folks, and that this subject is 
> understandably very sensitive,
> but it's possible that a pause and refocusing could be of use. I feel 
> a lot of drive and
> energy and dedication to the project from all of you, and it seems 
> very clear to me the folks
> that are writing maintain very high ethical standard and truly want 
> the best for the project.
> This is the reason why I joined lilypond-devel btw, the people are 
> awesome.
> (and I'll admit I also think the program is pretty cool ;) ).
>
> However, I also think I observe you all having a difficult time 
> trusting that things will go well,
> there seems to be a high level of fear that "something bad" will 
> happen. If I may propose a
> perspective: don't have fear of that, because something will break for 
> sure.
> Nobody can avoid that, but what you can do, and what will make a 
> positive difference to your
> users is your ability to help them through the stumble, support them 
> in their difficulties,
> and keep moving ahead together.
>
> Thanks for your time, hopefully some of these thoughts can be of use.


Thanks for sharing these.

Best,
Jean