[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Morley
Subject: Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows
Date: Fri, 6 Jan 2017 12:55:34 +0100

2017-01-06 12:34 GMT+01:00 David Kastrup <address@hidden>:
> 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 = #'allow
>>> }
>>> myAutoBreaksOff = {
>>>   %\override Score.NonMusicalPaperColumn.line-break-permission = ##f
>>>   \override = ##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
>> 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?

On Linux no assertion failure happens and the output _is_ as expected.
Lines running out of page or compressed over-full pages are forced by
the test-cases.
So the bad output is intended in the tests.

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

The function which does the assertion is min_page_count from
Btw, not triggered if one does in the ly-file:
\paper { page-breaking = #ly:minimal-breaking }

I tried to insert some print-functions in, but I'm
really not a C++-guy...
All I managed was to display simple text-strings, which indeed confirm
the problem in min_page_count but no computed data.
But that was already clear from the error-message Chris had posted.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]