Re: State of LilyPond with Guile 2.2

[Han-Wen Nienhuys]

On Sun, Apr 11, 2021 at 7:55 PM Werner LEMBERG <wl@gnu.org> wrote:

> > Guile 2.2 also makes binary distribution much nicer (because there
> > no more shared srfi libraries, so lilypond can be linked as one
> > static executable) and makes it possible to offer 64 bit executables
> > for Windows.
>
> ... especially to support some 64bit architectures.
>
> > But given the reactions, I'll reduce activity on my work towards
> > Guile 2.2...
>
> Hopefully there is not a misunderstanding: I very much appreciate your
> activities (and I'm quite sure that Han-Wen thinks the same) and
> invaluable tests!
>
> It is very unfortunate that more recent Guile versions cause such a
> serious deterioration for LilyPond.  Maybe it makes sense for the
> foreseeable future to stay with the status quo, this is, using Guile
> 1.8 as much as possible, and offering support for 2.x (or 3.x) for
> platforms where version 1.8 can't be used.  And if we go this route it
> makes sense to do what Han-Wen suggests, namely to add Guile 1.8 as a
> submodule.

Jonas didn't include 3.0 in the benchmarking because it's not
generally available yet, but I think it is relevant data. Part of the
reason why we want to be on an up-to-date release of GUILE is the
promise that future releases will be better for LilyPond. By looking
at 3.0, we can predict what the user experience will be in a few
years.

I am mainly worried that GUILE will further evolve into an optimizing
compiler system, where the compilation takes more time, the
interpreted code runs more slowly, and the build process creates
increasingly complicated requirements.

In this sense, the move to GUILE 2+ is a watershed moment: once we
drop support for 1.8 (dropping GC glue), it will be really hard to go
back, and we basically sign up to follow GUILE in their roadmap. By
contrast, GUILE 1.8 is mostly C, so there is a fair chance that we can
fix problems we find by ourselves.

It seems that most of the core work on GUILE is done by a single
person (Andy Wingo). If he leaves the project for one reason or
another, is there anyone who can productively get things done on the
GUILE codebase? I don't think I am confident about becoming versed in
Scheme enough to tinker with an optimizing compiler written in a
dynamically typed language.

Not being able to use 64-bit addressing on Windows with GUILE 1.8 is
an extremely serious problem. What is the reason for this? Is it
because dynamic loading doesn't work correctly, and GUILE tries to
load SRFI modules as .dlls  ?