Arne Babenhauserheide <arne_...@web.de> writes: > David Kastrup writes: > >> Arne Babenhauserheide <arne_...@web.de> writes: >>> This choice is much, much better than before. The choice before was "I’m >>> losing Lilypond!" (and not much of a choice). >> >> No, the choice was "I need to use the installer provided on LilyPond's >> web page". > > Then let me rephrase: The choice for most GNU/Linux users was "I’m > losing Lilypond", now it is "Lilypond might be slower". > >> Frankly the only feasible choice for users on Windows and >> MacOSX for the last ten years, and we have a _strong_ followership >> particularly among Windows users. > > That’s good, but for them there never was a problem, right? It does not > matter for them whether Lilypond devs compile for Guile 1.8 or for Guile > 2.x > >>> and no longer a roadblock users cannot cross without losing all >>> ability to compile their music. And it is something which hits people >>> who might actually have the skills to fix it (those who embedded >>> scheme in the lily documents). >> >> That's far too optimistic since many expressions provided to LilyPond >> functions are delivered in "embedded Scheme" (every occurence of # in a >> LilyPond file causes the Scheme reader and interpreter to run) > > This means that the user knows that the embedded Scheme is there, > right?
No. For many, #0.5 is just how you have to write floating point number arguments to LilyPond constructs, for whatever strange reason the language developers came up with. > So even if they cannot fix it themselves, they can provide the snippet > which creates the problem. They know where to start. Since when was "show somebody else the source" something new with any batch processing system? >> and besides, much of the core functionality is defined using >> "embedded Scheme" as well, making it just as crash-prone as >> user-defined code. > > This can be fixed incrementally, too. I don't see how incremental fixes could apply here since the problem does not lie with the embedded Scheme. > I might sound too optimistic. I think that’s needed to provide a new > perspective which can help to reduce the negative bias from the > problems in the past years. I think you are comingling personal and technical problems here. The latter are not amenable to positive thinking. The former certainly have lots of potential for improvement. > Please allow me to provide this as a spark of happiness and give it a > chance to support more positive feelings during collaboration. > > It might still be a few years until Lilypond on Guile 2.x is as stable > as Lilypond on 1.8, but the main roadblocks have been removed: > Lilypond can already compile complex ly files with Guile 2.x The "main roadblocks" in relation to which goal? To make Guile 2 a step forward as compared to Guile 1, we are more or less struggling to reach the starting line, namely being able to use Guile 2 reliably enough as to be able to start targeted, well-defined, effective and reasonably achievable improvements. -- David Kastrup
