David Kastrup <d...@gnu.org> writes:
> Thomas Morley <thomasmorle...@gmail.com> writes:
>
>> Hi,
>>
>> I stumbled across
>> (equal? #{ \voiceOne #} voiceOne)
>> returning false.
>>
>> Is it expected behaviour?
>
> equal? is not implemented all that great for "probs" but Music::equal_p
> is implemented in a manner where at least
>
> #(display (equal? voiceOne (ly:music-deep-copy voiceOne)))
>
> would be expected to display #t and it doesn't.
>
> Sigh. I'll see what I can find out.
Tracker issue: 5391 (https://sourceforge.net/p/testlilyissues/issues/5391/)
Rietveld issue: 363740043 (https://codereview.appspot.com/363740043)
Issue description:
Prob::equal_p: discard "origin" property Previously elements of
class Input was considered equal when compared as part of Music
property lists but this did not take into account that some music
might store its origin (if any) at different locations in its
property lists. So we just discard any "origin" property
completely, regardless of position in the property list and its
actual value type. Also contains commit: Don't set origin on
copied music explicitly There would be some mild incentive if the
origin were accessed an inordinary amount of times (and thus leaving
it unset would maximize access times to it) but there is no evidence
for that. One reason might be to ensure greater structural
similarity between copies of music, but Prob::equal_p has been
changed to be robust against differences here.
--
David Kastrup
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
