Re: Blockers for Guile 2.2

[Jonas Hahnfeld]

Am Mittwoch, dem 23.02.2022 um 12:09 +0100 schrieb Han-Wen Nienhuys:
> On Tue, Feb 22, 2022 at 12:05 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
> > 
> > Friends,
> > 
> > I don't see this thread coming to a conclusion if it stays between the same 
> > three people, and the topic is somewhat important to LilyPond's future. 
> > More voices would be helpful.
> 
> 
> Here are my thoughts:
> 
> * GUB needs to die. Really: I don't ever want to touch that code
> again, and I can't fault anyone else for feeling the same.
> 
> * We've got GUILE 2.2 support to a state that we can vouch for. We
> need to keep that state. This means we should switch CI to run on
> GUILE 2.2

(It's "Guile", not GUILE)

> * I'm worried that introducing a new version of lilypond that is
> significantly slower than older versions creates an incentive for
> users to stay on older versions.
> 
> * I grepped our source code for "guile-2" (scm) and GUILEV2, but the
> divergence of code paths seems pretty minor. Sure, it's inconvenient
> to have the odd conditional or limit ourselves to what is both in 1.8
> and 2.2, but I'd rather see us drop 1.8 support once we see an
> obstacle that we cannot paper over.

The problem is, in order to "see an obstacle", we always have to invest
to test every single change with Guile 1.8 and 2.2 during development,
which will be a significant time sink.

> * The concern over CI minutes seems like it's the least important: we
> can buy more computing power (I'm happy to sponsor), and is the
> duration of CI much of a concern today?

In the past, you've complained the loudest about slow CI builds for
merging changes...

> I don't think we have to do the doc build across both 1.8 and 2.2, for 
> example.

I think we do because a full doc build provides coverage and stress
testing that is unachieved by the regression tests.

> * We're talking about the impact of (the lack of) byte compilation on
> users, but we haven't discussed the impact on ourselves: the startup
> slowness affects our every debug/edit cycle, and byte compilation is
> impractical because we change scm files often (by virtue of checking
> out other branches).

The same happens for C++ files, you also have to recompile. But it's
true that editing scm files isn't for free anymore.

> If we need to kill 1.8 support because it blocks
> something important, then so be it, but given the impact on lilypond
> development, I'd try to postpone it if possible.

So, you propose that development continues on Guile 1.8, but we
advertise that we consider Guile 2.2 ready for production use? I don't
think that makes for a great user experience if we let them find
problems... Also "postpone" up to what point?

> * In the discussion, we've been treating "keeping GUB alive" and
> "supporting GUILE 1.8" as equivalent, but is that really the case? We
> can't have GUILE 1.8 for 64-bit windows, but for OSX/Linux, it would
> be an option with the new release scripts too?

No, Guile 1.8 has mandatory shared libraries for some srfi modules.
There are tricks you can play to make it work with an otherwise static
build, but they are really ugly and certainly not something I think
should be done for production.

> > No, it can't. This approach fundamentally assumes that you can run the
> > lilypond binary, which is not true in cross-compilation setups. If it's
> > about the "with-target", then you've solved a problem that doesn't
> > exist: Guile bytecode (at least for version 2.2) only cares about the
> > "cpu-endianness" and "triplet-pointer-size". As all relevant CPU
> > architectures of today are little-endian, and we only care about 64-bit
> > the bytecodes are identical (tested with a simple module, compiled for
> > x86_64-pc-linux-gnu, x86_64-w64-mingw32, powerpc64le-pc-linux-gnu).
> 
> I'm glad to hear that, but do we know about the GUILE team's plans in
> this space? It would suck if they want to move to CPU dependent
> bytecode.

My understanding of Guile's development is that certain developers have
ideas in their mind, and they eventually end up fully implemented in
the repository. There is no such thing as (public) plans.

> > properly solve the setup for "downstreams" that apparently is now a
> > requirement, but at least doesn't require additional effort. I wrote
> 
> I read over this thread, but I don't understand what you mean by
> "downstreams" here.

In my understanding, it's about "downstreams" packaging LilyPond,
including Linux distributions and parties like HomeBrew and MacPorts.
But please ask Jean what exactly is required now:
https://lists.gnu.org/archive/html/lilypond-devel/2022-02/msg00123.html

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