Re: crash moving DotColumn

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2016-05-13 12:27 GMT+02:00 David Kastrup <address@hidden>:
>
>> This is quite explicitly the case that the assertion is supposed to
>> complain about.  Since obviously this is triggerable by user error (in
>> this case yours), maybe the assertion should be demoted to a programming
>> error.  I don't see that this can trigger except by a callback directly
>> (or indirectly) setting a value and then returning *unspecified*.  In
>> which case there does not seem the danger of recursion unless the
>> callback directly or indirectly reinstated itself.
>
> In earlier versions (<= 2.18)
>
> {
>   \override NoteHead.stencil =
>     #(lambda (grob) (ly:grob-set-property! grob 'stencil point-stencil))
>   c''2
> }
>
> used to work without any warnings or errors.

Only when assertions were turned off (which they were by default until
something like 2.19.20, an abuse of the assertion mechanism).  I repeat:
I reproduced the assertion failure with the normal Ubuntu binary for
version 2.18.2.

>> So there does not seem to be much of a point in an assertion failure.
>> It does seem to constitute a programming error in general, however: a
>> callback should likely always return a specific value here in order
>> to let the caching mechanisms work properly.
>>
>> So maybe always complain about value == SCM_UNSPECIFIED here but only
>> on programming_error level?
>
> Well, one could think to make it work as in earlier versions,

No, I don't want to disable assertions by default.

> but I'm absolutely against this route, although I'm pretty sure
> there's a lot of user-code around doing so and likely in the LSR as
> well.
>
> I'd vote for the programming error.

I think that makes most sense.  I'll probably try for an unconditional
programming error with a reasonably illuminating error message.  So we'd
get messages in more situations but no abort.  Hopefully people will
then start fixing their callbacks.  Hopefully we don't have too many of
our own...

-- 
David Kastrup