Lilypond braucht plötzlich ewig zum Kompilieren - Windows Problem (gelöst?)

[Manuela]

Hi,

ich hoffe, es kann mir jemand helfen. Plötzlich braucht Lilypond ewig, etwa 30 Sekunden um die einfachste aller Dateien, \relative c' { c } zu kompilieren.

Ich habe bereits Lilypond 2.19.48 deinstalliert und 2.19.49 installiert. Das Problem trat jedoch schon mit 2.19.48 auf, das gestern noch tadellos funktionierte.

Ich weiß nicht, ob ein neuer Font daran schuld ist, ich habe versucht, einen Font umzudefinieren

Code: [Auswählen]

\version "2.19.49"

\paper {
#(define fonts
     (set-global-fonts
      #:music "gonville"  ; (the main notation font)
      #:roman "Traditional Arabic" ; (the main/serif text font)
      ))
}
Anschließend ging nichts mehr. Die Anzeige bei Frescobaldi springt relativ bald auf 100%, aber dann werden anscheinend noch irgendwelche Nachbearbeitungen durchgeführt, die ewig brauchen.

Jetzt braucht auch dieser Code mindestens 30 Sekunden:

Code: [Auswählen]

\version "2.19.49"

\relative c' { c }
Heraus kommt das

Code: [Auswählen]

Starte lilypond-windows.exe 2.19.49 [Ohne Titel]...
»c:/users/ich/appdata/local/temp/frescobaldi-fjw9dz/tmpxp3nlf/document.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf eine Seite angepasst...
Systeme erstellen...
Layout nach »./tmp-lilypond-MLif9Q« ausgeben...
Konvertierung nach »document.pdf«...
Löschen von »./tmp-lilypond-MLif9Q«...
Kompilation erfolgreich beendet
Erfolgreich abgeschlossen in 35.0".
Die Datei kompiliert, braucht aber ewig. Vll. hat jemand von den Windows-Usern eine Ahnung, was schief läuft.
Frescobaldi ist auch nicht schuld, denn auch von der Kommandozeile aus dauert es ewig.

[Manuela]

Es scheint so, dass jeder Kompiliervorgang um etwa 30 Sekunden länger braucht als früher. Fast so, als ob die Layoutkontrolle jedesmal aktiv wäre (ist sie aber nicht, außerdem tritt bei Kommandozeilenaufruf ohne Frescobaldi der gleiche Effekt auf).

[harm6]

Siehe dazu:

http://lilypond.1069038.n5.nabble.com/Long-Compile-time-with-version-2-19-44-td192343.html

http://lilypond.1069038.n5.nabble.com/Long-compile-times-on-Windows-10-status-td195384.html

um nur zwei threads zu nennen.

Allein das Problem einzugrenzen, ist äußerst schwierig, da man LilyPond nur unter größten mühen auf windows kompilieren kann.
Insoweit wird GUB benutzt, um cross-platform-Versionen herzustellen.
Kompilieriengsdauer ca 12h - auf einem schnellen Rechner - für die komplette chose, einzelne Sachen werden wahrscheinlich schneller gehen, aber dann hat man immer noch nur eine Version, die dann noch getestet werden muß.
Und damit bin ich schon raus, ich hab nie auch nur versucht GUB zu verwenden. Dazu ist mein kleines laptop einfach zu schwach auf der Brust. Und windows kommt mir sowieso nicht auf den Rechner.

Ich hoffe es ist klar geworden warum das Problem nur so langsam angegangen werden kann.
Ich habe aber irgendwo in den links oben oder auch in ähnlichen gelesen, das manche user irgendeinen workaround gefunden haben. Aber mich betrifft das Problem nicht, insoweit hab' ich dem nicht so viel Aufmerksamkeit geschenkt...


Du könntest natürlich eine VB mit Linux für LilyPond verwenden, falls Du dein OS wirklich behalten willst...

Gruß,
  Harm

[Manuela]

Aha, ein bekanntes Problem also.

Das seltsame ist, dass ich bisher problemlos mit 2.19.48 gearbeitet habe und mir nicht bewusst bin, etwas geändert zu haben. Außer in Frescobaldi ein paar Einstellungen umgestellt, aber das sollte sich nicht direkt auf Lilypond auswirken.

Hmm, auch ein Downgrade auf 2.19.37 hat nichts gebracht. Werde ich wohl damit leben müssen.

Ich hatte noch vermutet, die Option "embed source code" hätte die Verlangsamung gebracht, aber das habe ich wieder abgewählt gehabt.

Update: ich denke, ich habe die Ursache des Problems gefunden 

Ich hatte eine Datei $$$$.ly
Ich versuchte, die Sitzung, in der diese Datei enthalten war, zu exportieren und erhielte eine Fehlermeldung ($$$$.ly is not serializabile oder so ähnlich).

Daraufhin benannte ich diese Datei um,  und alles war wieder normal.

No ein Update: nur mit der alten Version (2.19.37) geht es normal, mit 2.19.49 nicht 

[Manuela]

So, jetzt kein Update mehr, ein neuer Beitrag...

Wie in dem einen Thread erwähnt, habe ich probiert, auf 2.19.42 downzugraden, da ist noch alles normal. Ich könnte es jetzt noch mit 2.19.43 probieren...

Update: die Vermutung in der Mailingliste ist richtig, irgendwas ungutes für Windows ist zwischen 2.19.42 und 2.19.43 passiert....

[Manuela]

Ich hätte es ja nicht für möglich gehalten, aber...

das zuerst erwähnte Kommando

Code: [Auswählen]

\paper {
#(define fonts
     (set-global-fonts
      #:music "gonville"  ; (the main notation font)
      #:roman "Traditional Arabic" ; (the main/serif text font)
      )
}
hat tatsächlich etwas mit der Geschichte zu tun!

Als ich probehalber diesen Code mit 2.19.42 ausgeführt habe, ist der Verzögerungseffekt wieder eingetreten. Nur eine Deinstallation und Neuinstallation von Lilypond hat Abhilfe gebracht.

[Hilflos-im-Code]

Das Ratzfatz deinstallieren hilft, hast du schon gemerkt. Wenn aber die neue Lilypondversion installiert ist, dauert der erste Kompilierungsversuch via Frescobaldi ab und zu ewig. Nicht abbrechen, sondern einfach geduldig warten. Dann flutschen die weiteren Versuche. Wenn ich abbreche, dann dauern auch die weiteren Kompilierungsversuche.

[Manuela]

Es scheint so, dass die Sache mit dem Lilypond Font Cache (zu finden in Windows unter %user%\.lilypond-fonts.cache-2 zusammenhängt. Möglicherweise hätte ein Löschen geholfen anstatt deinstallieren.

Nach dem Löschen des Caches tritt nämlich genau dieser Verzögerungseffekt auf, weil der Wiederaufbau so lange dauert. Ich vermute, dass beim Kompilieren jedesmal dieser Cache neu aufgebaut wird, wenn der Fehler eingetreten ist.

Ich mag es jetzt nicht ausprobieren, da ich happy bin, dass Lilypond wieder anstandslos läuft.

[Manuela]

Ich habe jetzt die neueste Version (2.19.52) installiert. Nach dem Löschen des Font-Cashes braucht Lilypond eine Weile, aber dann klappt es wieder anstandslos.