Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2017-01-04 16:01 GMT+01:00 Chris Yate <address@hidden>:
>> On Wed, 4 Jan 2017 at 14:25 Thomas Morley <address@hidden> wrote:
>
>> Well, it's odd. I'm not sure this is anything to do with /overrideProperty.
>>
>> Referring back to my original tests, I can change your definitions to the
>> following, and it will crash on each of your test cases:
>>
>> Uncomment the \override line-break-permission and it renders OK.
>>
>> Chris
>>
>> ------------
>> myAutoBreaksOn = {
>>   %\override Score.NonMusicalPaperColumn.line-break-permission = #'allow
>>   \override Score.NonMusicalPaperColumn.page-break-permission = #'allow
>> }
>>
>> myAutoBreaksOff = {
>>   %\override Score.NonMusicalPaperColumn.line-break-permission = ##f
>>   \override Score.NonMusicalPaperColumn.page-break-permission = ##f
>> }
>
> meanwhile I'm at the end of my knowledge.
> So I limited myself to the attempt of creating a meaningful test-file.
> It should display in terminal which Staff is currently compiled.
>
> I hope lilypond will proceed with the next score once an assertion
> failure happens (not sure about that, though)
>
> In order not to clutter the terminal output you could compile it with
> lilypond --loglevel=WARN manual-breaking-assertion-failure-04.ly
>
> I'd expect some assertion failures, but at least some scores should
> work for you (hopefully).
> Please post the terminal output.

Assertions should not be used when LilyPond has a sane way to continue:
for that case, programming errors are more appropriate.  The question is
whether this is the case here: I think we are also dealing with bad
output even when assertions are disabled: right?

But as long as it is not _dangerous_ to continue (like using 0 pointers
or uninitialized data), a programming error might be more suitable.

-- 
David Kastrup