Re: Blockers for Guile 2.2

[Han-Wen Nienhuys]

On Wed, Feb 23, 2022 at 12:36 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > * 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...

A build for 2.2 and 1.8 could be run in parallel, I think?

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

The doc build is exactly the same as the regtest: a lot of small files
that are rendered mostly in per-system mode (rather than per page).
It's just more of the same, so you get better coverage for small
windows of time where objects aren't GC protected.

Also, you make it seem as if perfect coverage is the only alternative
to scrapping the code altogether. I think that is a false dilemma.

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

The Scheme compilation felt much slower, and for C++ ccache takes away
a lot of the pain of recompiles. It also appears to be
single-threaded? I admit not having timed it in detail.

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

If we drop 1.8 support now, we can drop just a tiny sliver of
complexity (places marked GUILEV2 and guile-2 in C++ and Scheme
respectively), while we make work slower for folks that work on large
scores and can afford to side-install Guile 1.8. It also makes
development slower for ourselves. Yes, that means some of us will
develop on a different platform than many users. This has been the
case since we started supporting OSX and Windows. Everyone who is
passionate about Guile 2.2 can develop against Guile 2.2.

I'm not opposed to dropping 1.8, as long as we get something
substantial in return for it. For example, we might be able to drop
all of the GC marking code if we defer to BDWGC for all memory
management. That is an attractive proposition, but I'd like to see a
prototype before we actually go there.

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

ack.

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen