[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State of LilyPond with Guile 2.2

From: Jonas Hahnfeld
Subject: Re: State of LilyPond with Guile 2.2
Date: Mon, 12 Apr 2021 09:12:33 +0200
User-agent: Evolution 3.38.4

Am Montag, dem 12.04.2021 um 09:00 +0200 schrieb Werner LEMBERG:
> > > Almost all developers use a Unix-like OS and can be thus served
> > > with Guile 1.8.x!  Are there actually LilyPond developers who
> > > work
> > > natively with Windows or MacOS?  With 'natively' I mean using a
> > > binary specifically compiled for that platform and not a virtual
> > > box.
> > 
> > Adding a mix of Guile versions will make the situation much worse
> > because we know for sure that 1.8 and 2.2 are sufficiently
> > different
> > that it can cause bugs on their own.
> While this is true, I believe...
> > Claiming support for both will make reproducing issues much harder,
> > and things will get outright horrible if, say, we continue to offer
> > 32 bit for Windows using Guile 1.8 and 64 bit with Guile 2.2.
> ... that this is greatly exaggerated.  AFAICS, we have managed that
> quite well up to now (partially due to your heroic efforts).

Yes, because nobody uses it. Just look at the number of GC related
crashes that I fixed in the past months, and I know of at least two
more that I didn't get the chance to analyze in full detail yet.

> > Also consider what this means for extension writers: They'll have
> > to take two Guile versions into account and possibly test both of
> > them. I fear this split will be equally bad as Python 2 vs 3 was
> > over years...
> Are the differences for users really that significant?  Looking into
> LilyPond's `scm` directory I only see very low-level stuff that needs
> explicit use of `guile-2`.

Maybe not as bad as Python 2 vs 3, but there are differences and heavy
use of Scheme will break.

> Note that I don't want that we stay with Guile 1.8 forever, but the
> slowness of 2.x and 3.x is a serious issue.  To sacrifice this still
> enormous speed advantage just for the sake of orthodoxy seems wrong
> to me.

So 10% performance regression for users is enormous? What would be
acceptable, in your opinion? After all, this was the *real* purpose of
this thread, which nobody bothered answering so far.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]