Thomas Klausner <t...@giga.or.at> writes: > I see you replied to my build issue in lilypond-2.17.24 that I should > try a clean build. > > I've done that. I built versions 2.17.23, 2.17.24, and 2.17.25 from > scratch in a sandbox, in different directories, and I still see this > issue, in 2.17.24 and 2.17.25, but not in 2.17.23. > > Also, I've heard from another person who saw this same issue and had > found my email in a search engine. > > I see that there have been quite a number of documentation changes > between .23 and .24. > > Can you please take another look? Or at least tell me which kind of > change might cause this so I can try to track it down? >
> Processing > `/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/generate-documentation.ly' > Parsing... > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/init.ly > [<string> > > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/declarations-init.ly > > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/music-functions-init.ly] > > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/toc-init.ly] > Using `nederlands' note names... > > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/drumpitch-init.ly] > > [/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/chord-modifiers-init.ly > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/ly/chord-modifiers-init.ly:26:4: > error: syntax error, unexpected REAL > < > c e gis>1-\markup { "+" } > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/lily.scmBacktrace: > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/lily.scm: > 960: {1}* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...) > 960: 2* [lilypond-all #] > 973: 3 (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...) > 985: 4* [for-each #<procedure #f #> #] > In unknown file: > ?: 5* [#<procedure #f #> > "/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/generate-documentation"] > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/lily.scm: > 987: 6* (let* (# # #) (if separate-logs #) (if ping-log #) ...) > 998: 7* [lilypond-file #<procedure #f #> ...] > 1033: 8 [catch ly-file-failed #<procedure #f ()> #<procedure #f (x . args)>] > In unknown file: > ?: 9* [#<procedure #f ()>] > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/lily.scm: > 1034: 10* [ly:parse-file > "/scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/generate-documentation"] > In /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/init.ly: > 9: 11* [session-initialize #<procedure #f ()>] > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/lily.scm: > 131: 12 (if (ly:undead? lilypond-declarations) (begin # #) (begin # # #)) > 142: 13 (begin (thunk) (set! lilypond-interfaces (filter # #)) ...) > 143: 14* [#<procedure #f ()>] > In /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/ly/init.ly: > 17: 15 [ly:parser-parse-string # "\\include \"declarations-init.ly\""] > In unknown file: > ?: 16* [construct-chord-elements {1} #<Duration 4 > ()] > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/chord-entry.scm: > 28: 17* (let* (# # # # ...) (letrec # # # ...)) > In unknown file: > ?: 18 (letrec (# # # # ...) (set! root #) (if # #) ...) > In > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/chord-entry.scm: > 116: 19* (set! root (ly:pitch-transpose root (ly:make-pitch {1} 0 0))) > 116: 20* [ly:pitch-transpose {1} #<Pitch c'' >] > > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/chord-entry.scm:116:16: > In procedure ly:pitch-transpose in expression (ly:pitch-transpose root > (ly:make-pitch 1 0 ...)): > /scratch/wip/lilypond-devel24/work/lilypond-2.17.24/out/share/lilypond/current/scm/chord-entry.scm:116:16: > Wrong type argument in position 1 (expecting Pitch): 1 Ok, now we are getting somewhere. Not anywhere making much sense, mind you. The change in question would appear to be a lexer change which would make it commit 680df85187d0f3862b1ef1cf7a14f8ad7b7f0ee9 Author: David Kastrup <d...@gnu.org> Date: Mon Jul 22 19:11:59 2013 +0200 Issue 3471: Allow decimal fractions with non-empty parts before and after '.' in music This permits writing things like mkMove = #(define-music-function (parser location x y) ( number? number? ) #{ \once \override TextScript #'extra-offset = #(cons x y) #}) { \mkMove 4.4 -3.3 c1^"XY" } Since integers are accepted in this kind of usage, not accepting floating point numbers appears inconsistent. While in INITIAL mode like inside of layout blocks real numbers can be written like 4. or -.3 for historic reasons, permitting this inside of music could easily lead to confusion with durations or articulations, so those spellings remain invalid in music modes. Decimal fractions are also not accepted in \chordmode since this would preclude chord entry like c:13.11^3.7 and similar. What does not make all too much sense is that this change was introduced in version 2.17.23 already. What also does not make all too much sense is that this is in construct-chord-elements, which is called by make_chord_elements in lily/parser.yy. This is called in the rules new_chord: steno_tonic_pitch optional_notemode_duration { $$ = make_chord_elements (@$, $1, $2, SCM_EOL); } | steno_tonic_pitch optional_notemode_duration chord_separator chord_items { SCM its = scm_reverse_x ($4, SCM_EOL); $$ = make_chord_elements (@$, $1, $2, scm_cons ($3, its)); } ; and in make_music_from_simple (which interprets Scheme expressions) as } else if (parser->lexer_->is_chord_state ()) { if (unsmob_pitch (simple)) return make_chord_elements (loc, simple, parser->default_duration_.smobbed_copy (), SCM_EOL); } Even while parser and lexer are not perfectly synchronized, it's pretty safe to assume that the lexer will not be thrown into chord mode without reason. The first argument of construct-chord-elements should be a _pitch_. It isn't: it is a number. This is from the second argument of make_chord_elements. Can only be from new_chord, via steno_tonic_pitch. steno_tonic_pitch is steno_tonic_pitch: TONICNAME_PITCH quotes { if (!scm_is_eq (SCM_INUM0, $2)) { Pitch p = *unsmob_pitch ($1); p = p.transposed (Pitch (scm_to_int ($2),0,0)); $$ = p.smobbed_copy (); } } ; And TONICNAME_PITCH is returned only with int Lily_lexer::scan_bare_word (string str) { SCM sym = ly_symbol2scm (str.c_str ()); if ((YYSTATE == notes) || (YYSTATE == chords)) { SCM handle = SCM_BOOL_F; if (scm_is_pair (pitchname_tab_stack_)) handle = scm_hashq_get_handle (scm_cdar (pitchname_tab_stack_), sym); if (scm_is_pair (handle)) { yylval = scm_cdr (handle); if (unsmob_pitch (yylval)) return (YYSTATE == notes) ? NOTENAME_PITCH : TONICNAME_PITCH; else if (scm_is_symbol (yylval)) return DRUM_PITCH; } else if ((YYSTATE == chords) && (handle = scm_hashq_get_handle (chordmodifier_tab_, sym))!= SCM_BOOL_F) { yylval = scm_cdr (handle); return CHORD_MODIFIER; } } yylval = ly_string2scm (str); return STRING; } And it's obvious that again yylval can only be a pitch here when TONICNAME_PITCH is returned. You could try running the parser/lexer with -ddebug-parser and/or -ddebug-lexer to get more info, but those only switch on the debugging when entering the main input, and the trouble is already before that. So you'd need to run lilypond in a debugger and set the respective variable triggering the debug output manually. -- David Kastrup _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond