Thomas Morley <thomasmorle...@gmail.com> writes:
> 2017-01-04 16:01 GMT+01:00 Chris Yate <chrisy...@gmail.com>:
>> On Wed, 4 Jan 2017 at 14:25 Thomas Morley <thomasmorle...@gmail.com> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
