[Top][All Lists]
[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
- 2.15.8 Regtests, Phil Holmes, 2011/08/06
- Re: 2.15.8 Regtests, David Kastrup, 2011/08/06
- Re: 2.15.8 Regtests, Keith OHara, 2011/08/06
- Re: 2.15.8 Regtests, David Kastrup, 2011/08/06
- Re: 2.15.8 Regtests, Keith OHara, 2011/08/06
- Re: 2.15.8 Regtests, David Kastrup, 2011/08/06
- Re: 2.15.8 Regtests, Keith OHara, 2011/08/06
- Re: 2.15.8 Regtests, Graham Percival, 2011/08/07