Re: Moving most initialization to .scm files

[Jean Abou Samra]

Le 05/09/2022 à 21:22, Thomas Morley a écrit :
> Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via
> Discussions on LilyPond development <lilypond-devel@gnu.org>:
> > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote:
> > > This needs to be done for lots of code in lots of files, so it will be
> > > quite a major change to the source even though it is just a straightforward
> > > translation.
> > I don't like this idea very much just two weeks before branching for a
> > new stable release. No matter how "straightforward", I find the risk
> > too high that something goes wrong, or that it turns out not to be a
> > good idea for some other reason, or that we still find it insufficient
> > and an entirely different solution is required...
> >
> > For me, this also means we should go without !1510 for the release.
> > It's unfortunate, but not the end of the world; and I personally think
> > it's worse to delay the entire release by weeks / months or even an
> > undetermined amount of time.
> >
> > Jonas
> I think a stable release without meaningful error-messages as promised
> by !1510 is unusable for power-users.
> While working on zither-ly[*], I was tempted to trash a few weeks of
> coding work, because of shitty error messages, making it unpossible to
> proceed...
> Unless Jean pointed me to the possibility to port all (critical)
> scheme-codings in ly-files to scm-files and use GUILE_AUTO_COMPILE=1
> I would not have reached the current state without it.
>
> I'm not sure it's the best way but currently it looks like the only one.



For 2.24, I think that providing a -dcompile-scheme-code option for
byte-compiling user code is a viable route. This could later become
the default if it gets robust enough. In particular, since Guile
doesn't support compiling more than ~2000 or ~8000 expressions (depending
on the BDWGC configuration), we can't use it for make check, which
is a strong reason IMHO not to make it the default. I don't think
this Guile problem can be worked around. I do *believe* it can be fixed
in Guile, but it will take time until Linux distros have the potential fix,
and I don't know if the Guile maintainers will accept to backport it to
Guile 2.2, which potentially means we'd have to switch to Guile 3 before
making byte-compilation of user code the default. And, as we've experienced
with the MRs I had to do to fix test failures when I was trying to make
compilation the default (!1541, !1540, !1539), the switch could break
certain user files that do things not allowed by the byte-compiler, like
mutating quoted data. So it is safer not to do shortly before a stable 
release.
Since we don't currently provide binaries of a stable release that work
under 64-bit macOS, and it has been some time since 2.22, I also wish a
stable release soon, so I think an option is best for the time being.