Re: State of LilyPond with Guile 2.2

[Jonas Hahnfeld]

Am Sonntag, dem 18.04.2021 um 10:35 +0000 schrieb Werner LEMBERG:
> > > Working towards a fork of Guile 1.8 was never meant to be a good
> > > option, rather as a last resort if speed differences make normal
> > > work too painful.
> > 
> > Well, the question of this thread was: What is "too painful"? Do we
> > require less "speed differences" than what I measured? In general:
> > What are the criteria to "switch"?
> 
> For me, the speed of Guile 2.x without compiled Scheme bytecode would
> be too painful.

Agreed for user installations, but we have a work-around there. So what
about development? Do we *require* compiled bytecode to work there? Let
me quote my initial message here:

> In my opinion, the numbers show that we *must have* compiled bytecode
> for user installations in order to reach acceptable performance
> (memory usage seems to be fine). And while compilation by invoking
> LilyPond is somewhat odd, it works and would be viable for the
> beginning.

> For development, I'm less convinced. Sure, 'make test' and 'make doc'
> get faster but the compilation itself takes a considerable amount of
> time. Moreover it is my understanding the Guile is notoriously bad at
> determining which files to recompile, in particular when macros are
> involved.

> Personally, I would be ok with the moderate slowdown if that was the
> only thing preventing a hypothetic switch to Guile 2.2, and the
> arising question is really a matter of prioritizing: There are other
> items that need solutions before that switch could happen (in
> particular the release process for binary builds and documentation).
> What do others think? Or would you say that proper bytecode
> compilation is required before moving to Guile 2.2? (with no clear
> estimate how feasible that is and how long it would take)

Jonas

P.S.: This is getting a bit annoying, but I honestly have no clue how I
could ask the questions in a better way that you answer all of them in
one reply...

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