Perception of LilyPond development status

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Perception of LilyPond development status

Urs Liska-3
Any LilyPond dev who does have a Facebook account might have a look at
this interesting, although somewhat sad, discussion. I think it gives a
clear picture of how our current state of development is perceived by users:

https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/

Urs


Reply | Threaded
Open this post in threaded view
|

Re: Perception of LilyPond development status

David Kastrup
Urs Liska <[hidden email]> writes:

> Any LilyPond dev who does have a Facebook account might have a look at
> this interesting, although somewhat sad, discussion. I think it gives
> a clear picture of how our current state of development is perceived
> by users:
>
> https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/

The problem with the "obsolete version of Guile" is that Guile
development is falling apart.  The only person actually working on the
development version of Guile is Andy Wingo.  He does not participate on
the Guile developer list, he does not bother with bug reports, he does
not take input and does whatever he currently is interested in without
communicating it, and frequently breaking master.  What he is interested
in is basically compiler/optimization development.  He is not interested
in fixing the performance and design problems with Guile 2+'s string
implementation and design.  There are about a dozen developers (probably
less by now) cleaning up on the stable branch, but they cannot do
significant independent development since they cannot coordinate with
the development version.

This has been the case for 2.2, and it's more so for 2.3.  I don't see
that there is a viable way for LilyPond to move forward to "current"
versions of Guile which have become completely unpredictable as a target
as well as as a platform.  I think there will not be much of a way
around forking 1.8 and making that work for us as long as no
well-performing string-interface is available that would efficiently
facilitate the C/Scheme string passing density of LilyPond.

Maybe we can coordinate something with Thien-Thi Nguyen who has been
keeping the Guile-1.8 branch tip in the official Guile repository from
bitrot due to Texinfo and language changes.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Perception of LilyPond development status

Jacques Menu Muzhic
Hello David,

Maybe this is totally stupid, but would it be meaningful to pick a Guile 2 version, fix the issues in string
implementation and design, and freeze that fixed version for Lily’s own use, without depending on Andy Wingo’s work for some time?

JM

> Le 14 déc. 2019 à 22:58, David Kastrup <[hidden email]> a écrit :
>
> Urs Liska <[hidden email]> writes:
>
>> Any LilyPond dev who does have a Facebook account might have a look at
>> this interesting, although somewhat sad, discussion. I think it gives
>> a clear picture of how our current state of development is perceived
>> by users:
>>
>> https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/
>
> The problem with the "obsolete version of Guile" is that Guile
> development is falling apart.  The only person actually working on the
> development version of Guile is Andy Wingo.  He does not participate on
> the Guile developer list, he does not bother with bug reports, he does
> not take input and does whatever he currently is interested in without
> communicating it, and frequently breaking master.  What he is interested
> in is basically compiler/optimization development.  He is not interested
> in fixing the performance and design problems with Guile 2+'s string
> implementation and design.  There are about a dozen developers (probably
> less by now) cleaning up on the stable branch, but they cannot do
> significant independent development since they cannot coordinate with
> the development version.
>
> This has been the case for 2.2, and it's more so for 2.3.  I don't see
> that there is a viable way for LilyPond to move forward to "current"
> versions of Guile which have become completely unpredictable as a target
> as well as as a platform.  I think there will not be much of a way
> around forking 1.8 and making that work for us as long as no
> well-performing string-interface is available that would efficiently
> facilitate the C/Scheme string passing density of LilyPond.
>
> Maybe we can coordinate something with Thien-Thi Nguyen who has been
> keeping the Guile-1.8 branch tip in the official Guile repository from
> bitrot due to Texinfo and language changes.
>
> --
> David Kastrup
>


Reply | Threaded
Open this post in threaded view
|

Re: Perception of LilyPond development status

David Kastrup
Jacques Menu <[hidden email]> writes:

> Hello David,
>
> Maybe this is totally stupid, but would it be meaningful to pick a
> Guile 2 version, fix the issues in string
> implementation and design, and freeze that fixed version for Lily’s
> own use, without depending on Andy Wingo’s work for some time?

That "fix" would consist in making Guile strings UTF-8 only.  Throw out
everything else.  Problem is that Scheme has in-place string
manipulations that don't work with variable-size characters.  It may be
that recent Scheme standards have tried to become more UTF-8 friendly,
no idea.

A beyond-LilyPond fix would turn the internal string coding into some
extension of UTF-8 like Emacs does.  That is actually also a
prerequisite of making something like Guilemacs ever take off.  Getting
Emacs' string implementation to its current quality took decades.

A few seminal points:

Code points for large characters are supported (at one point 32-bit
characters, but it may be reduced to the theoretic maximum with 4-byte
characters these days).  Out-of-sequence bytes from 128–255 are
represented with 2-byte sequences (overlong representations of 0–127 not
valid as UTF-8), valid UTF-8 is represented as itself.  That makes any
binary data representable with a blow-up factor of at most 2.

With Emacs, the details are in the various encoding itty-bitties: the
internal processing is comparatively straightforward.  Buffers are
addressed by character positions, not bytes.

The itty-bitty details mostly concern conversion into/out of the
internal UTF-8 though and don't have much of an impact on the normal
processing.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: Perception of LilyPond development status

David Kastrup
In reply to this post by Jacques Menu Muzhic
Jacques Menu <[hidden email]> writes:

> Hello David,
>
> Maybe this is totally stupid, but would it be meaningful to pick a
> Guile 2 version, fix the issues in string
> implementation and design, and freeze that fixed version for Lily’s
> own use, without depending on Andy Wingo’s work for some time?

By the way, we need to find a solution handling the byte-compiled files
of Guile2.  I think that's part of our current slowdown but I may be
wrong.

--
David Kastrup