Re: Perception of LilyPond development status
Jacques Menu 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
Re: Perception of LilyPond development status
Jacques Menu 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
Re: Perception of LilyPond development status
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 a écrit : > > Urs Liska 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 >
Re: Perception of LilyPond development status
Urs Liska 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
Perception of LilyPond development status
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
