Neil Puttock <[email protected]> writes: > On 6 August 2011 15:31, David Kastrup <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
