Re: State of LilyPond with Guile 2.2

[Jonas Hahnfeld]

Now I can reply to this message with a bit more time.

Am Montag, dem 12.04.2021 um 09:28 +0200 schrieb Han-Wen Nienhuys:
> 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 fully agree, and this is part of the motivation. However Guile 2.2 is
what distributions have available right now, and I think it would be
the logical step towards eventually gaining support for Guile 3.0. It's
already a mess right now to have code for Guile 1.8 and 2.2 co-exist.
My hope is that the difference between 2.2 and 3.0 is smaller, but I
think it would still simplify things to drop support for 1.8 first.


> 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.

While I also agree with your assessment on this point, I think Guix may
have gained enough traction that the future of Guile is kind of
secured. Only time will tell, but at some point it may be less effort
to live with more up-to-date versions of Guile.


> 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  ?

Also keep in mind that even if we can make Guile 1.8 work for 64-bit
Windows, we still need means to build that. I personally don't want to
go through the hassle of teaching new tricks to GUB, and the whole
approach simply doesn't work for 64-bit on macOS where licensing
prevents cross-compilation from Linux.

Jonas

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