Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
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
2
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
3
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
4
Hier eine mögliche Lösung:
#(set-global-staff-size 19.00000000000001)oder:
\layout { #(layout-set-staff-size 19) }
Gruß,
Pierre
5
Fragen und Probleme aller Art / Antw:Seltsame Platzierung eines Legatobogens
« Letzter Beitrag von harm6 am Montag, 24. Juni 2019, 23:58 »
Hallo,

sieht mir ganz nach einer weiteren Ausprägung des hier:
https://lists.gnu.org/archive/html/lilypond-user/2019-06/msg00162.html
diskutierten Problems aus.

Versuche die font-size des TabNoteHead geringfügig zu verändern, z.B.:
\override TabNoteHead.font-size = -1.95
default ist -2

Gruß,
  Harm
6
Fragen und Probleme aller Art / Antw:Seltsame Platzierung eines Legatobogens
« Letzter Beitrag von eichhofener am Montag, 24. Juni 2019, 18:45 »
so schauts bei mir aus:
7
Fragen und Probleme aller Art / Seltsame Platzierung eines Legatobogens
« Letzter Beitrag von eichhofener am Montag, 24. Juni 2019, 18:33 »
Hi,
das folgende ist mir kein ernstes Problem. Es geht nur um eine verschobene vertikale Positionierung eines Legatobogens im TabVoice , die ich nicht verstehe.
Das Problem tritt bei bestimmter global-staff-size und bei bestimmter Notenhöhe (im TabVoice nur eine Zahl) auf. Sonst nicht.

Es würde mich interessieren, ob es ein Bug ist, oder ob ich was übersehe.
Vielleicht hat ja jemand Lust, einen Blick darauf zu werfen...

Vielen Dank
Uwe

PS: Lilypond 2.19.82 auf OpenSuse

\version "2.19.82"

% problem occurs at staff-size 19, but does not occur at staff-size 18 or 20
#(set-global-staff-size 19)

\new TabStaff \with { stringTunings = \stringTuning <g' c g c' d'> }
\new TabVoice
{
    \stemDown
    d8( dis) % normal position of slur above tab-notes
    dis( e) % normal position
    e( f) % lifted position of slur - WHY
    f( fis)  % again normal position
}
8
Fragen und Probleme aller Art / Antw:Assertion failed - abhängig von global-staff-size
« Letzter Beitrag von harm6 am Montag, 24. Juni 2019, 10:16 »
Zitat
Die Ä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
9
Fragen und Probleme aller Art / Antw:Assertion failed - abhängig von global-staff-size
« Letzter Beitrag von Arnold am Montag, 24. Juni 2019, 10:08 »
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.
10
Fragen und Probleme aller Art / re: Stichnoten
« Letzter Beitrag von ingmar am Montag, 24. Juni 2019, 07:09 »
Jaja, ich beklage doch selber immer, wenn Beispiele nicht kompilieren! Da hätte ich sorgfältiger sein müssen - sorry.

Dass \new Staff die mehrfachen Staffs wieder zusammenzwingen kann, was mir nicht klar, ist dann aber natürlich logisch. instrumentCueName: Da war ich überrascht, dass das so überhaupt funktionierte. Dass das zur Voice gehört, darauf war ich auch nicht gekommen.

Die Abgrenzung, die Aufgaben und die genauen Zusammenhänge der Kontexte machen aber offenbar nicht nur mir zu schaffen... : - (

Danke für die schnelle und erhellende Hilfe!


--ingmar
Seiten: [1] 2 3 ... 10