lilypond-devel
[Top][All Lists]
Advanced

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

Re: 2.15.8 Regtests


From: David Kastrup
Subject: Re: 2.15.8 Regtests
Date: Sat, 06 Aug 2011 17:50:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Neil Puttock <address@hidden> writes:

> On 6 August 2011 15:31, David Kastrup <address@hidden> wrote:
>
>> I have a hard time counting the removal of a band aid for an artificial
>> test case with undefined behavior (try finding a place in the user
>> documentation that declares this kind of code as producing predictable
>> results) as a regression because the original code did not fix the
>> underlying problem, but merely masked it.
>
> So how would you expect the following code to behave?  It's the
> snippet from the original bug report, which segfaulted in stem.cc.
>
> \relative c' {
>   \time 2/4
>   \voiceOne
>   s16 [g s g ] s16 [g s g ] |
>   s16 [g s g ] \override Stem #'(details beamed-lengths) = #'(15 15)
>   s16 [g s g ] |
>   s16 [g s g ] s16 [g s g ] |
>   s16 [g s g ] \revert Stem #'(details beamed-lengths) s16 [g s g ] |
>   s16 [g s g ] s16 [g s g ] |
> }
>
> The regression test is deliberately artificial since it gives a clear
> indication of failure, which this code doesn't (the segfault no longer
> occurs due to checking the nested property is a pair before using
> robust_list_ref).  I don't think it's unreasonable to expect this code
> to return 'beamed-lengths to the default value defined in
> define-grobs.scm.

The problem is that you can't reliably distinguish

\override Stem #'(details) = #'(beamed-lengths 15 15)
from
\override Stem #'(details beamed-lengths) = #'(15 15)

Maybe something like
(eq? (assq-ref (cdr alist) (caar alist)) (cddar alist))
could determine whether we are still on the spine leading to the
nested override or beyond it, but I am skeptical, and it still does not
solve the problem that updating a nested property in a parenting context
will require updating of the copies in the current context.

In any case, I am not interested in policies.  Mark this whatever you
like, use whatever inconsistent behavior you like.  The smaller code is
more useful as a starting point for reasonably sensible and correct
behavior, and I never suggested that it stay in either of the incorrect
states.

-- 
David Kastrup



reply via email to

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