bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build problem with lilypond-2.17.24 & 25


From: David Kastrup
Subject: Re: build problem with lilypond-2.17.24 & 25
Date: Wed, 28 Aug 2013 10:50:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Thomas Klausner <address@hidden> 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 <address@hidden>
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]