Re: Checks to see if tuplet brackets have bounds (issue 13582046)

[Mike Solomon]

On 13 sept. 2013, at 11:00, address@hidden wrote:

> On 2013/09/13 08:41:42, Trevor Daniels wrote:
>> On 2013/09/13 07:09:44, mike7 wrote:
> 
>> > With respect to your point about null pointers and the nature of the
> patch, I
>> > agree that there needs to be a better way to handle this.  To me,
> the general
>> > problem seems to be "what do we do when we assume a grob will have
> something
>> > (bound, object, etc.) and it doesn't?"  Is the solution to suicide
> the spanner
>> > if it doesn't have bounds?  Is the solution to raise a programming
> error like
>> we
>> > do now (I prefer that solution)?
> 
>> LilyPond should always try to continue when an error is detected.
>> If the error is thought to be a user error a warning should be
>> issued and an assumption made about what was intended.  If the
>> error is thought to be due to faulty or missing code (as here) the
>> erroneous operation should be abandoned and a programming error
>> issued.  Reported programming errors should always be recorded in
>> an issue tracker unless one already exists.  At least that, I
>> believe, was the general approach adopted in the past and it seems
>> sound to me.
> 
> Well, being defensive is always a good idea.  It's just that when we get
> to _know_ the defenses to be triggered without us expecting it, we
> should make use of the opportunity to analyze what is going wrong here.
> 
> Mike says that the change is due to more crossstaff checks happening
> now.  I have no better guess here, but the issue description of issue
> 3199 does not at all mention crossstaff, and the error does not occur in
> a context or in code mentioning crossstaff.

To be more specific, when the pure height of axis groups is being calculated, 
it iterates over all pure relevant grobs to find their heights, throwing out 
cross staff grobs because their heights cannot be calculated because they are 
by definition not part of the axis group.

Tuplet brackets used not to be tagged pure relevant because we had those huge 
lists of what was and wasn't.  Now, pure relevant is a much larger list of 
grobs because pure relationships are articulated via unpure-pure-containers and 
not lists.  So, we iterate over a larger set of grobs.  What this means is that 
certain grobs that never had their cross-staffitude checked now do.

I believe that the correct approach is to make sure that every grob has a 
cross-staff function that can be called at _any_ time after engraving is done.  
Here, perhaps we should add extra checks before parallel beam is called to weed 
out boundless spanners.

Cheers,
MS