Assertion failed - abhängig von global-staff-size

Begonnen von Arnold, Montag, 27. Mai 2019, 10:23

« vorheriges - nächstes »

Arnold

Hallo zusammen,

ich habe beim Abschreiben einer Partitur nur noch den letzten Takt in den Holzbläsern hinzugefügt, und dann stürzte Lilypond bei jedem Übersetzungsversuch mit folgender Meldung ab:
   This application has requested the Runtime to terminate it in an unusual way.
   Please contact the application's support team for more information.
   Assertion failed!

   Program: ...Lilypond\usr\bin\lilypond.exe
   File: /home/gub/NewGub/gub/target/mingw/src/lilypond-git.sv.gnu.org--lilypond.git-stable-test/lily/page-breaking.cc, Line 1180

   Expression: ret <= cached_line_details_.size ()

Die Suche nach der Fehlerquelle, um ein Minimalbeispiel zu extrahieren, gestaltete sich irgendwie unspezifisch - man konnte diese oder jene Notenzeile (bzw. nur den letzten Takt daraus) weglassen, und es wurde wieder übersetzt.
Bei näherem Herantasten erschien der Absturz noch bei Reduktion auf die letzten 16 Takte, aber nicht mehr bei einer Reduktion auf die letzen 3 Takte - und ohne den letzen Takt klappte es ja auch.
Schließlich kam ich auf die Idee, auch mal den Wert in #(set-global-staff-size 13.0) abzuändern.

Meine Beobachtungen unter Win7:
  • Mit Version 2.18.2 keine Probleme.
  • Mit Version 2.19.83 nur dann keine Probleme, wenn global-staff-size entweder auf 12.875 bzw. kleiner, oder auf 14.101 bzw. größer gesetzt wurde
  • Mit Versionen 2.19.80 bis 2.19.83 der besagte Absturz, wenn für global-staff-size ein Wert zwischen 12.876 und 14.1 geählt wurde.

Nun, ein richtiges Minimalbeispiel kann ich natürlich nicht liefern, die ZIP-Datei mit dem reduzierten Beispiel ist immernoch 14 kB groß.

Meine Fragen sind nun, da ich ja mit einer geringfügig kleineren global-staff-size einen Workaround gefunden habe:

  • Tritt dieses Problem auch bei anderen Windows-Anwendern auf? (Schließlich habe ich mehrere Versionen von Lilypond auf meinem Rechner installiert)
  • Tritt dieses Problem auch unter anderen Rechnerarchitekturen (Unix / Linux) auf? Vielleicht bei anderen Größen?
  • Ist vielleicht schon eine Bug-Beschreibung bekannt, die dazu passen könnte?
Die zu übersetzende Datei nennt sich Woyrsch53-2-Part.ly.

Arnold

harm6

Hallo Arnold,

ich kann das Problem auf Ubuntu 18.04 64-bit nicht nachstellen.

Einziges Problem:
Woyrsch53-2-Hr1-Stimme.ly:19:8: warning: cannot end slur
    g'1
       )

Es gibt allerdings issues and threads zu ähnlichen Problemen:

#3281 3 or 4 pages
https://sourceforge.net/p/testlilyissues/issues/3281/
https://codereview.appspot.com/25710043
https://codereview.appspot.com/25710043/

#4943 Manual page breaking causing assertion failure
https://sourceforge.net/p/testlilyissues/issues/4943/

http://lists.gnu.org/archive/html/bug-lilypond/2016-07/msg00101.html

http://lists.gnu.org/archive/html/lilypond-devel/2017-01/msg00012.html


Ohne das Problem nachstellen zu können, kann ich leider nicht mehr tun ...


Sorry,
  Harm

Arnold

Hallo Harm,

ich bin soweit fündig geworden,
aber jetzt lieber alles der Reihe nach:

  • Die Warnung »slur kann nicht beendet werden« kommt vom »showLastLength« - der Bindebogen beginnt im unterdrückten Anfang der Musik.
  • Ich habe eine weitere Partitur abgeschrieben und dabei ebenfalls den gleichen Fehler erhalten. Abbruch bei global-staff-size = 14.454, 14.450, 14.410, 14,400, 14,300, 14.250, 14.240, 14.238, 14.237, 14.236, 14.235, 14.234, 14.233, 14.232 bzw. 14.231 . Erfolg mit global-staff-size = 14,455, 14.453, 14.452, 14.451, 14.440, 14.430, 14.420, 14.239, 14.230 bzw. 14.200
  • Ich fand einen weiteren Workaround: eine Leerseite hinten anfügen »\pageBreak \markup \null«. Aber ich gebe auch zu, die Postscript-Ausgabe in ».../scm/output-ps.scm« so abzuändern, daß die letzte (leere) Seite wieder entfernt wird, erscheint mir etwas zu aufwändig.
  • Ja, es ist offenbar der Issue 4943, und er tritt generell in der Windows-Version auf, nicht in der UNIX-Version.
  • Ich dachte nun, um mich an der »Suche nach der Stecknadel im Heuhaufen« zu beteiligen bräuchte ich eigentlich ein »erweitertes LILYDEV VM Image«, in welchem neben der UNIX-Version auch die Windows-Version übersetzt werden kann. Dann könnte ich Textausgabe-Spuren in die Quellcode-Dateien hinzufügen und durch Vergleichsläufe (UNIX-Version in der VM, Windows-Version auf dem Host) herausfinden, wo die beiden Betriebssystem-Varianten auseinander laufen.
  • Auch ohne diese Kompilier-Möglichkeit für Windows begann ich dann trotzdem im Quelltext der Version 2.19.80 (welche ich zufällig schon in einer LILYDEV VM vorliegen hatte) meine Spuren zu legen (siehe »page-breaking--modification.cc« in der Dateianlage, immer nur ganze Zeilen mit entsprechendem Kommentar am Zeilenende wurden hinzugefügt) und dann die Absturzbeispiele mit LILYPOND in der VM zu übersetzen. (Protokoll auch in der Dateianlage: » TraceOnLilydef.txt«)
  • Nun konnte ich beobachten, daß der Rückgabewert (Variable »ret«) in der Funktion »Page_breaking::min_page_count()« schon nach dem letzten Durchlauf der Schleife »for (vsize i = 0; i < cached_line_details_.size (); i++)« seinen erlaubten Maximalwert erreicht hatte.
    Im folgenden »if (is_last ())«-Abschitt wurde unter UNIX nur deshalb die Variable »ret« nicht weiter erhöht, weil der gespeicherte Wert »cur_rod_height« gleich dem (soweit ich sehe) neu berechneten Wert »cached_line_details_.back().full_height()« war.
  • In SCHEME werden die Fließkommazahlen zu Recht als »inexact« bezeichet. Ein Vergleich zweier Fließkommazahlen auf Gleichheit ist immer risikobehaftet - je nach Berechnungsweg und Rundung können unterschiedliche Ergebnisse herauskommen. Noch schlimmer wird es, wenn die Zahlen unterschiedliche Genauigkeiten (Mantissen-Längen) aufweisen. Zudem habe ich erst kürzlich auf einer Microsoft-Seite gelesen, daß solche unterschiedlichen Mantissen-Längen gerne zwischen gerade berechneten und bereits gespeicherten Werten auftreten, denn dort (unter Windows) soll es üblich sein, daß Berechnungen mit 64 Bit Mantissenlänge ausgeführt werden, die Funktionsrückgabewerte im Stack der FPU bleiben und also dort immernoch 64 Bit Mantissenlänge besitzen, und dann erst beim Speichern in eine »double«-Variable auf 53 Bit Mantissenlänge gekürzt werden.
Das beobachtete Fehlerbild deckt sich also gut mit der Vermutung, daß in der Windows-Version von Lilypond hier unterschiedliche Mantissen-Längen in den Fleißkommazahlen verwendet werden, und die Zahlenwerte dann verglichen werden. Aber sogar bei gleichen Mantissen-Längen bliebe noch ein kleines Risiko, daß bei unterschiedlichen Rechenwegen sich die Ergebnisse doch noch unterscheiden.
Womöglich funktioniert die Umstellung der FPU-Genaugkeit (Datei »main.cc«, Zeilen 192 bis 208) auch nicht (mehr) in der Windows-Übersetzung.
Sollte der Datentyp »Real« etwa durch Überschreiben der Vergleichsoperationen (»ähnliche« Werte noch als gleich betrachten) dieses Rundungsproblem auch ohne Umstellen der Mantissen-Längen ausbügeln, tut es aber im vorliegenden Fall doch nicht?

Also,

  • ich muß mir noch mal den Typ »Real« genauer ansehen.
  • Harm, siehst Du eine Chance für ein erweiteres LILYDEV-Abbild, mit dem zusätzlich auch Windows-Builds erstellt werden können?
  • Vielleicht noch Vorschläge, damit in Zukunft nicht mehr die Gleichheit von zwei Fließkommazahlen (eine gespeicherte und eine neu berechnete) als Kriterium herangezogen werden.

Arnold

harm6

Hallo Arnold,

wir bewegen uns hier in einer Region, mit der ich nicht vertraut bin. Bei der eigentlichen bug-Suche bzw einem Fix dafür werde ich wohl nicht direkt helfen können.
Auch gibt es in meinem ganzen Haushalt kein windows-system.

Aber ich habe GUB lauffähig, zumindest hats beim letzten Test funktioniert.
Ich könnte Dir also windows-installer nach Deinen Spezifikationen herstellen und zukommen lassen.
Wohl eher per privater mail, 30+MB sind zu viel fürs Forum hier. Aber per mail noch machbar, soweit ich erinnere (habs nicht nachgeschlagen).


Gruß,
  Harm

Arnold

Danke Harm,

darauf komme ich zurück.

Zuerst werde ich aber noch meine »Studien« in der LILYDEV-VM mit der Version 2.19.83 fortsetzen.
Außerdem möchte ich einen Massentest durchführen - bei wie vielen von 100 (oder 1000 oder gar 10000) unterschiedlichen global-staff-size die Übersetzung abbricht. Vermutlich genügt ja als Quasi-Minimal-Beispiel ein einziges System mit so vielen eintaktigen Notenzeilen (vielleicht Akkord <g c''''>1\f darin), daß dieses System ein wenig komprimiert werden muß.
Voraussichtlich werde ich zwei CC-Dateien »zum Spurenlesen« abändern.
Eigenlich solte es dann nur die neu übersetze »lilypond.exe« sein, die ich benötige.
Die »Zustellmöglichkeiten« klären wir dann - neuerdings werden sogar ZIP-Dateianlagen mit einer EXE-Datei drin (sogar an der Magic-Number als solche erkannt) als potentielle Schadsoftware aus der Email herausgefiltert.

Arnold

harm6

Zitat von: Arnolddarauf komme ich zurück.

Ich hoffe, ich habe nicht zu viel versprochen, bisher habe ich nur master durch GUB gejagt.
Im Zweifel frag ich noch auf -devel nach...

Gruß,
  Harm

Arnold

Und auch ich dachte, daß es einfacher sei, dieses Verhalten zu reproduzieren.

Ich habe einfach ein einziges System mit so vielen gleichen eintaktigen Notenzeilen erstellt, bis dieses System leicht komprimiert war.
Und mittels programmierter Schleife ließ ich alle global-staff-sizes von 14.0000 bis 14.9999 in Schritten von 0.0001 durchlaufen.
Nach drei Stunden Rechenzeit (mit eigentlich nur einem Prozessorkern, also wäre durch eine Parallelisierung eine Steigerung des Durchsatzes auf das vierfache realistisch) hatte ich keinen einzigen Absturz (kein Assertion-Fail) - aber bei zwei Partituren, die ich nacheinander abschreib, habe ich jeweils diesen Effekt.

Aber, ich bleibe dran,

Arnold

harm6

Zitat von: harmIch hoffe, ich habe nicht zu viel versprochen, bisher habe ich nur master durch GUB gejagt.
Im Zweifel frag ich noch auf -devel nach...

Siehe:
http://lilypond.1069038.n5.nabble.com/GUB-with-local-git-repo-td222366.html

Scheint jetzt zu klappen.
Auf jeden Fall hatte ich einen erfolgreichen Testlauf mit einem lokal veränderten lily-repository.
Bislang habe ich nur eine Zeile zu init.ly hinzugefügt, die im Terminal "THIS IS A GUB-TEST" schreibt, sobald ein file kompiliert wird.

Zitat von: ArnoldUnd auch ich dachte, daß es einfacher sei, dieses Verhalten zu reproduzieren.
Falls kein minimal möglich ist, kannst Du dann nicht einen der scores nehmen die sich als buggy erwiesen haben?

Sobald Deine cc-Dateien zum Spurenlesen fertig sind schick sie mir doch als git-formated patches. Dann kann ich sie meinem lokalen branch hinzufügen und die installer erstellen.

Von welchem branch soll ich dann ausgehen?
Mein aktueller test-branch ist von master. Ich könnte aber auch von release/2.19.83-1 ausgehen:

Zitatcommit c9134465360dfb53419f749747d28c6d04d23839
Author: Phil Holmes [...]
Date:   Wed Mar 20 13:52:23 2019 +0000

    Release: update news.
Sollte dann kein Problem sein (berühmte letzte Worte lol )



Gruß,
  Harm

Arnold

Hallo Harm,

das letzte Wochenende mußte ich mich um ein neues Musikinstrument kümmern, da fand ich keine Zeit für's Lilypond.

Normalerweise lade ich den kompletten Verzeichnisbaum als TGZ-Datei herunter,
z Bsp. »Source: lilypond-2.19.83.tar.gz« von http://lilypond.org/development.de.html,
oder eventuell auch einen Schnappschuß von http://git.savannah.gnu.org/gitweb/?p=lilypond.git .
Meine VM-Ware (noch Debian 8, 32-Bit basierend) läuft dann auf einem Rechner ohne Netzwerkanbindung.

Hast Du einen anderen Archiv-Link, auf den ich aufbauen soll? Sonst würde ich den erstgenannten (der Version 2.19.83) nehmen.


Von den beiden Bäumen (original und arbeit) kann ich dann mittels »git diff lilypond-2.19.83-orig/lily lilypond-2.19.83-work/lily« (oder so ähnlich) ein Delta extrahieren. Die aufgeführten Dateinamen-Pfade sehen dann aber nicht ganz so aus wie im »commitdiff« von http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=summary als Beispiel angezeigt.


Meinen angedachten Testdurchlauf kann ich natürlich auch mit der ganzen Partitur ausführen. Ich muß zuvor aber noch ein Beispielprogramm so anpassen, daß es bei den aufpoppenden Fehlermeldungsfenstern immer »auf O.K. drückt«.


Arnold

harm6

ZitatMeine VM-Ware (noch Debian 8, 32-Bit basierend)
Hab' ich auch als VM, da mach ich z.Zt. auch die gub-Arbeit drin.
Allerdings konnte ich den Erfolg eines lokalen gub-builds nicht wiederholen. Bin am testen worans liegt ...

Mit einem diff zu lilypond-2.19.83 käm ich klar.

Gruß,
  Harm

Arnold

Hallo Harm,

Eine betroffene Partitur habe ich jetzt unter Win7 mit global-staff-size von 14.0000 bis 18.0000 in Schritten von 0.0001 getestet.
Es paßt jeweils nur ein System auf eine Seite.
Ab global-staff-size = 14.2847 (Noten-System der letzten Seite wird komprimiert) kommen die ersten Assertion-Abbrüche, mit einer Wahrscheinlichkeit von etwa 50 %.
In der beiligenden Grafik (AssertRage.png) ist der Anteil als Duchschnitt über die Zone von einhundert kleineren bis einhundert größeren »global-staff-size« ermittelt.
Bis global-staff-size = 14.6827 werden die Noten auf "3 oder 4" Seiten eingepaßt,
ab global-staff-size = 14.6828 dann auf "4 oder 5" Seiten.
Das Problem tritt nicht bei allen Partituren auf, und manche Zielsystemvarianten (z. Bsp. Linux-Kompilate) sind offenbar gängzlich von diesem Effekt verschont.

Das Assertion-Abbruch-Kriterium ist »ret <= cached_line_details_.size ()« in Zeile 1180 von ../lily/page-breaking.cc, also in Funktion Page_breaking::min_page_count() .
Ein Verfolgen dieser Funktion in der LILYDEV-Linux-Umgebung bei den betroffenen Partituren zeigte,
daß dort die Zeile 1189 (Variable »ret« erhöhen - in diesem Fall über das zulässige Maximumg hinaus) nicht ausgeführt wird,
weil das Kriterium in Zeile 1188 »cur_rod_height > cached_line_details.back ().full_height ()« nicht erfüllt ist,
sondern die beiden verglichenen Fleißkomma-Werte exakt gleich sind.
Als Kommentar zu dieser Prüfung steht in Zeile 1177: /* don't increase the page count if the last page had only one system */

Da ein Test von zwei Fließkommazahlen auf Gleichheit immer kann kritisch ist, wenn die Zahlen auf unterschiedlichen Rechenweg berechnet werden (Rundungsdifferenzen! Eventuell verstärkt durch Coprozesserhandhabung »Berechnung und Funktionswertrückgabe mit 80-Bit-Fließkommarepräsentation, runden auf die 64-Bit-double-Repräsentation erst beim speichern in eine Variable des Typs double),
habe ich nach einem alternativen Prüfkriterium gesucht, diees aber noch nicht durchgetestet.
Diese alternative Prüfung (mit Ganzahlen- anstelle Fließkommazahlenvergleich) habe ich eingebaut, und kann mit Umgebungsvariable LILYDEV_WIN_DEBUG_SWITCH_01 (Wert "1") aktiviert werden.

Wüßte ich, wie man (im C-Quellcode) den Compiler abfragen kann, welche Fließkommaeinheit (X87 oder SSE oder anderes?) für die Berechung der Double-Variablen benutzt wird, hätte ich dies auch noch eingebaut.
So lasse ich nur anzeigen, ob die Mantissenlänge des X87 gesetzt wurde.

Die Änderungen in den zwei Dateien aus dem lily-Verzeichnis sind in der Dateianlage (gitdiff.txt) abgelegt.
Harm, ich hoffe, das Übersetzten klappt wieder.

harm6

ZitatDie Änderungen in den zwei Dateien aus dem lily-Verzeichnis sind in der Dateianlage (gitdiff.txt) abgelegt.
Harm, ich hoffe, das Übersetzten klappt wieder.

gub-builds funktionieren wieder.
Ich mach mich mal dran...

Gruß,
  Harm

harm6

Hallo Arnold,

ich hab den gub-build jetzt gemacht. Seh ich das richtig, daß linux-systeme lediglich:

FPU control  n_o_t  initialized.

bekommen, weitergehender output nur auf windows erfolgt?


Ansonsten habe ich Schwierigkeiten beim verschicken, da das Ding ~34MB groß ist.
Ich hab's jetzt hochgeladen und Dir den link geschickt, ich hoffe es klappt, ansonsten müssen wir uns was anderes überlegen...


Gruß,
  Harm

Arnold

Danke Harm,

bei mir lief alles ohne Probleme.

Nach dem Download des Installationspaktes habe ich nur ein »Light-Update« auf dem Win7-Rechner durchgeführt:
Installationspaket mit 7zip geöffnet, die beiden Dateien lilypond.exe und lilypond-windows.exe (sind ja eigentlich identsisch) herausgeholt und in das bisherige Installationsverzeichnis hineinkopiert, die alten beiden Dateien überschreibend.

Die Ausgabe der Textmeldungen in der »Eingabeaufforderung« bereitet unter Win7 Probleme. Umleitung der Fehlermeldungen in eine Datei (quasi: 2>error_out.txt) ist die einfachste Lösung.

Ich habe gestern abends noch zwanzig Größenvarianten ausprobiert (welche mit Assertion und welche ohne), konnte das herauslesen, was ich erwartet habe zu erfahren:
FPU control  n_o_t  initialized.
GNU LilyPond 2.19.83
»test4478.ly« wird verarbeitet
Analysieren...
Interpretation der Musik...[8][16]
Vorverarbeitung der grafischen Elemente...
Ideale Seitenanzahl wird gefunden...
Musik wird auf 3 oder 4 Seiten angepasst...
min_page_count(): checks values for last page inc of 'ret' ...
                  TrialSwitch = (null)
                  sizeof(Real) = 8
                  cached_line_details_.size() = 5
                  page_starter = 4
                  line_count = 1
                  too_few_lines(...) = 0
                  cur_page_height = 209.08266926288971
                  cur_rod_height = 211.78014963760285
                  cached_line_details_.back().full_height() = 211.78014963760285
                  cur_rod_height - cached_line_details_.back().full_height() = 6.8833827526759706e-015
Bitmask compare of cur_rod_heigth and cached_line_details_.back().full_height(),
while stored as double:
   oLoo oooo oLLo LoLo oLLL Looo LLLL oLLo LLLL LLoo oLoL LLLL oLLo LLLL LoLL ooLo
   oLoo oooo oLLo LoLo oLLL Looo LLLL oLLo LLLL LLoo oLoL LLLL oLLo LLLL LoLL ooLo
min_page_count(): going to increment 'ret' for last page ...
min_page_count(): going to check assertion
                  ret = 6
                  cached_line_details_.size() = 5
                  assertion violated!!!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Assertion failed!

Program: C:\Programme_privat_32\Lilypond\usr\bin\lilypond.exe
File: .../gub/target/mingw/src/lilypond-localhost--lilypond.git-dev-arnold-2-19-83/lily/page-breaking.cc, Line 1264

Expression: ret <= cached_line_details_.size ()


  • fpu_control in main.cc wurde nicht gesetzt, d. h. dort wurde die Rechengenauigkeit der x87-Arithmetikeinheit nicht auf 64-Bit-Fließkommazahlen eingestellt. Es könnte zwar auch laut GCC-Handbuch über die Kommandozeilenoption »-mpc64« bewerkstelligt werden, aber aus den folgenden Beobachtungen sieht man, daß dies auch nicht passiert ist.
  • Entscheidend für die betroffenen Partituren ist der Vergleich cur_rod_height > cached_line_details_.back ().full_height (). Hier wird ein gespeicherter Wert mit einem neu berechneten Wert (Rückgabewert der Funktion) vergleichen. Es sollten nur die Fälle »größer« und »gleich« vorkommen (wie unter Linux), das »gleich« wenn ein einzelnes System auf der letzen Seite komprimiert wurde. Diesen Zustand herauszufiltern ist der als Kommentar im Quellcode dokumentierte Zweck dieser Abfrage.
    Effektiv wird also die Funktion cached_line_details_.back ().full_height () aufgerufen, darin der Rückgabewert als 80-Bit-Fließkommazahlen berechnet, im Stack der Arithmetikeinheit das Berechnungsergebnis zurückgegeben, dann die (beim Speichern) auf eine 64-Bit-Fließkommazahl gerundete Zahl in cur_rod_height ebenfalls in den Stack der FPU geladen, und dann miteinander vergleichen.
    So ist etwa bei der Hälfte aller Fälle der Vergleich »größer«, bei der anderen Hälfte »kleiner« - die Gleichheit ist entsprechend der Mantissenlänge sehr, sehr selten - eigentlich sollten in diesen Beispielpartituren alle (bei unendlicher Genauigkeit) gleich sein, das »minimal größer« führt dann zum Abbruch des Programms via Assertion-Prüfung.

Meine Maßnahmenvorschläge wären:
  • Auf den Fließkommazahlenvergleich verzichten. Anstelle von cur_rod_height > cached_line_details_.back ().full_height () solte page_starter + 1 != cached_line_details_.size() den gleichen Zweck erfüllen, wäre aber immun gegen Fließkommarundungsfehler.
    Diese Änderung will ich vorab aber erst noch testen.
  • Per Kommandozeilenopeion »-mpc64« für gcc die X87-Genauigkeit auf 64-Bit-Fließkommazahlen einstellen, auch wenn der entsprechende Code in main.cc nicht erreicht wird. Wäre also eine Änderung im GUB (und eigentlich auch in LILYDEV).
    Leider kenne ich aber keine Prüfung, mit der dann sichergestellt werden könnte, daß diese Einstellung wirklich aktiviert wurde! Als prüfbare Preprozessor-Defiines habe ich sie nicht im gcc entdeckt.
  • Zuletzt gäbe es noch die Möglichkeit, für den Fließkommazahlenverleich selbst geschriebene Funktionen zu verwenden. Diese können dann definitiv 64-Bit-Fließkommazahlen vergleichen, indem diese in einer solchen Variable zwischengespeichert werden. Sollte noch eine gewisse Unschärfe (ein »epsilon«. ob linearer Zahlenwert, relativer Faktor, oder in Schritten der in double-precision darstellbaren Zahlenwerte gemessen) für die Gleichheit berücksichigt werden, wird eine so geartete Funktion unausweichlich, auch wenn es die Ausführung des Programms etwas bremsen würde.

Also:
Als nächstes teste ich das oben angegebene alternative Kriterium page_starter + 1 != cached_line_details_.size() (als Ersatz für das jetzige cur_rod_height > cached_line_details_.back ().full_height ()) in der LILYDEV-Umgebung mittels make test-baseline und make check.
Dann werde ich diese Ergebnisse ins Englische übersetzen. Wenn ich die Berechtigung dazu habe, dann im issue einstellen - wenn nicht, muß ich Harm nochmal um Unterstützung bitten.

Arnold

harm6

Nur ganz kurz (muß mich gleich um meinen regulären Job kümmern..)

Zitat
Dann werde ich diese Ergebnisse ins Englische übersetzen. Wenn ich die Berechtigung dazu habe, dann im issue einstellen - wenn nicht, muß ich Harm nochmal um Unterstützung bitten.

Frag doch kurz auf devel, mir Angabe Deines SourceForge user-name. Es geht idR sehr schnell Dir dann dort Zugang zu gewähren,


Gruß,
  Harm