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 <d...@gnu.org> a écrit : > > Urs Liska <li...@openlilylib.org> 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 >