Re: Crash with simultaneous-duplicating music function and \once\offset

[Aaron Hill]

On 2018-07-17 11:46, David Kastrup wrote:
> Aaron Hill <address@hidden> writes:
> > I tried manually duplicating the music:
> >
> > %%%%
> >   \version "2.19.82"
> >   music = { \once \offset length 5 Stem c'4 c'4 }
> >   musicCopy = { \once \offset length 5 Stem c'4 c'4 }
> >   \new Staff { c'4 << \music \musicCopy >> c'4 }
> > %%%%
> >
> > This variant does compile, although the side-effect here is that the
> > stem length is twice as long.
>
> As expected.

Agreed.  Would this be worth documenting in some way, or is this just 
too contrived a scenario to care about?

> > I suppose this would make sense providing simultaneous music results
> > in a single stem shared by the notes so that the two \offsets stack
> > their effects.  But then that doesn't explain why the same behavior
> > isn't seen when omitting \once in the first example.
>
> Try with \temporary (though avoiding the crash with the same kind of
> manual copy).  Without either \temporary or \once, any preceding
> override (such as another \offset) is replaced, so you see only one 
> stem
> length increase.

With the underlying crash resolved, should we also expect the same 
behavior with the double \offsetting?  Again, as above, I am perfectly 
content with ignoring this if this is too esoteric.

> > Based on that success, I tried to get the original approach to compile
> > using either music-clone or ly:music-deep-copy, but perhaps I do not
> > understand those functions well enough to use properly.  I would have
> > expected that it would be possible to programmatically achieve the
> > equivalent to \musicCopy as in my second example, with something like
> > this:
> >
> > %%%%
> >   \version "2.19.82"
> >   music = { \once \offset length 5 Stem c'4 c'4 }
> >   \new Staff { { c'4 << \music $(music-clone music) >> c'4 } }
> > %%%%
> >
> > It still fails in the same way.
>
> That one's the bug that my patch is supposed to, well, not fix but
> lessen its consequences and giving a warning.  There is another one (a
> failed assertion) that's still open.

Sounds good.  Many thanks, David!

-- Aaron Hill