Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Jan 07, 2017 at 09:42:51PM +0100, David Kastrup wrote:
> "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.

Wow. That sounds like a totally disastrous API. :-(


> 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.

That probably represents a significant overall performance hit. I wonder
if a significant chunk of lilypond's performance problems stem from
this.


> 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 surely we aren't the only ones facing these issues?  What about
other guile-dependent projects? Are they crying out too? I can't imagine
this state of things would continue to hold, if so. Sooner or later,
either the guile devs will capitulate and fix their API, or people will
just move away to other extension languages (or fork guile-1.8).


> > 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.
[...]

Debian does have quite a good number of libraries that can coexist with
different versions of themselves.  And in theory, I'd imagine that it
should be possible to tweak guile-1.8's build scripts so that it
installs into a version-specific path, so as not to have any conflicts
with guile-2.0.  So this should all be possible.  But I don't know how
much actual work it would take to make this all work, though.

In the short term, it will probably be easier to get a new version of
lilypond (containing a suitably-bundled guile-1.8 installation) into the
archive than it is to re-introduce guile-1.8. But I think it's worth a
shot.


T

-- 
ASCII stupid question, getty stupid ANSI.