Re: [RFC] Moving to Guile 2.2 and away from GUB

[Jonas Hahnfeld]

Am Donnerstag, dem 25.11.2021 um 20:51 +0100 schrieb Jean Abou Samra:
> Le 25/11/2021 à 20:06, Jonas Hahnfeld a écrit :
> > Am Donnerstag, dem 25.11.2021 um 19:51 +0100 schrieb Jean Abou Samra:
> > > Le 24/11/2021 à 22:41, Jonas Hahnfeld via Discussions on LilyPond
> > > development a écrit :
> > > > This improves with compiled bytecode, as Jean replied, but this won't
> > > > be included initially (I
> > > > forgot to mention this). We should definitely have it for the next
> > > > stable release, but I'm optimistic that this is possible.
> > > 
> > > In my opinion, while not a requirement for switching
> > > to Guile 2, it would be really nicer (and wise to implement
> > > before removing Guile 1 support entirely)
> > That's exactly the thing that is *not* going to happen in that order,
> > at least not by me: Making the files byte-compilable will require many
> > changes (making all files modules on their own, as you write, plus
> > making sure that the different modules correctly depend on each other,
> > plus moving all calls to functions defined in C out of the parts that
> > are interpreted by the compiler, because they're not there unless we
> > run the full environment)
> 
> Could you explain the last part? I don't understand what you mean.

I can't reproduce right now, but I remember that when I tried I quickly
ran into errors that the compiler could not find functions that are
defined in C. My hypothesis is that the compiler tries to evaluate
"constants" to store only the result in the bytecode...

> 
> > which I think will require constructs that
> > are simply not available in Guile 1.8.
> 
> Not sure. Only actually trying will tell though.
> 
> > [...] On top of all that, I'm not actually
> > sure it's a good idea to byte-compile during development because it's
> > really, really slow - I currently estimate that compiling all *.scm
> > files can easily take as long as compiling all C++ files.
> 
> 
> Well, for me, it's proving quite fast:
> 
> $ rm -rf out/share/lilypond/current/guile/ccache/
> $ time out/bin/lilypond
> [Zillions of warnings...]
> real    0m58,060s
> user    0m57,757s
> sys    0m0,125s
> 
> (Compiling all C++ files without parallelism
> takes about 6 minutes.)
> 
> I also have good hope with optimization levels
> (only available with guild).
> 
> $ time guild-2.2 compile scm/define-grobs.scm
> wrote 
> `/home/jean/.cache/guile/ccache/2.2-LE-8-3.A/home/jean/repos/lilypond/scm/define-grobs.scm.go'
>  
> 
> 
> real    0m3,167s
> user    0m3,617s
> sys    0m0,040s
> 
> $ time guild-2.2 compile -O0 scm/define-grobs.scm
> wrote 
> `/home/jean/.cache/guile/ccache/2.2-LE-8-3.A/home/jean/repos/lilypond/scm/define-grobs.scm.go'
>  
> 
> 
> real    0m1,392s
> user    0m1,678s
> sys    0m0,025s

Fun fact: Did you try placing the compiled file (with only the
extension .go) into out/lib/lilypond/current/ccache/lily and make
lilypond load it? It results in "Unbound variable: all-grob-
descriptions", likely because the compiler doesn't understand define-
session-public which is defined in lily. Actually, this points to yet
another problem where some files (to become modules) use the module
(lily) which in turn will have to load all other modules. So we likely
have to re-think the entire layering of the scm/ directory...

Jonas

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