Re: Which Linux distro for Lilypond

[David Kastrup]

"H. S. Teoh" <address@hidden> writes:

> Of course, the best scenario is that we figure out how to fix the
> current guile2-related issues before LP 2.20 is released...

A lot of them require fixing Guile2.  Guile2 has a string API where it
will not accept anything but Latin-1 strings in a native encoding.
Everything else requires recoding: it cannot work with utf-8 strings
even though its API offers only utf-8 as encoding to pass into Guile's
native (but inaccessible) UCS-32 strings.  It does not allow string
ports in any encoding but utf-8.  It cannot even pass its own native
strings through string ports without reencoding.

Its reencoding is not transparent for non-proper utf-8.  The Guile
developers are in complete denial about the unsuitability for an
extension language about Guile's call gates requiring reencoding for
every string parameter.

They are also in complete denial about the importance of interpreter
speed for an _extension_ language: for them, compiler performance is
everything.

They also consider it "somebody else's problem" to organize the
compilation and storage of byte code for an application.

There is a lot in there where a solution simply cannot be achieved by
LilyPond on its own, and a lot where a LilyPond-only solution makes very
little sense in the overall Guile universe.

> but that might need a lot more time. And we might want to keep LP 2.18
> in the distros in the meantime, which would mean bundling guile1.8
> with LP 2.18.

I think that the most promising way of attack is to make sure that
Guile-2.0 and Guile-1.8 libraries can be installed in parallel, and with
parallel architectures (most libraries can, Guile-1.8 was not
multiarch-capable when it was removed).

When Debian can include Guile-1.8 without significant cost, why wouldn't
they?  I think that there lies our most promising approach in the short
term.

-- 
David Kastrup