bug-lilypond
[Top][All Lists]
Advanced

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

Re: barNumberCheck broken in LilyPond 2.19.22


From: David Kastrup
Subject: Re: barNumberCheck broken in LilyPond 2.19.22
Date: Sat, 04 Jul 2015 06:59:26 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Thomas Morley <address@hidden> writes:

> 2015-07-03 21:07 GMT+02:00 markdblackwell <address@hidden>:
>>
>> \version "2.19.18" % Please ignore this version number!
>> notes = {
>> c'2 d'
>>   \barNumberCheck #3
>> }
>> \book {
>>   \bookOutputName "barNumberCheck-tiny-example-test"
>>   \score {
>>     \notes
>>     \layout { }
>>   }
>> }
>>
>> I'm using Windows XP.
>
>
>
> Confirmed on Linux.
>
> Seems the call for (*location*) inside (make-music 'ApplyContext
> 'procedure ...) doesn't work.
>
> As workaround use:
>
> barNumberCheck =
> #(define-music-function (n) (integer?)
>    (_i "Print a warning if the current bar number is not @var{n}.")
>    (let ((location (*location*)))
>    ;(display "location: ")(display (*location*))
>      (make-music 'ApplyContext
>                  'procedure
>                  (lambda (c)
>                    (let ((cbn (ly:context-property c 'currentBarNumber)))
>                    ;(display "location: ")(display (*location*))
>                      (if (and  (number? cbn) (not (= cbn n)))
>                          (ly:input-warning location
>                                            "Barcheck failed got ~a expect ~a"
>                                            cbn n)))))))

Three possible fixes for that.  Your fix is the straightforward one but
only covers this particular case.  A somewhat more obscure fix would be
to have Apply_context_iterator pick off 'origin from the music and put
it in %location when calling its procedure.

The overkill solution would be to have iterators generally be called
with the %location setting from the respective music.

I have to admit that I'm leaning towards the last solution.  However, we
have had a few regressions in 2.19.22.  If Phil was thinking about
rolling 2.19.23 this weekend, I'd probably roll in your local fix (and
see whether we have similar cases elsewhere) and leave the more invasive
change for proper review/discussion for later.

-- 
David Kastrup



reply via email to

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