I appreciate this is going back a whole 9 months, but I've just started
looking again at one of my projects and I'm back, stuck against this
completely debilitating bug.
I'm now using 2.19.80 and it's not been fixed. Granted, a release build
probably wouldn't throw on "assert", but is anyone plann
e they occur in.
I don't know whether this tells you anything more?
thanks,
Chris
GNU LilyPond 2.19.53
Processing `manual-breaking-assertion-failure-1a.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Draw
On Fri, 6 Jan 2017 at 12:31 David Kastrup wrote:
Chris Yate writes:
> On Fri, 6 Jan 2017 at 11:34 David Kastrup wrote:
>
>>
>> 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
t;
> > Log attached (although I don't think this will be very helpful).
>
>
>
> Strange that your log file (I assume default loglevel) differs
> significantely from mine.
> Seems the order what is done at which time is very different.
>
> $ lilypond manual-breakin
Chris Yate writes:
> On Fri, 6 Jan 2017 at 11:34 David Kastrup wrote:
>
>>
>> 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
e that your log file (I assume default loglevel) differs
significantely from mine.
Seems the order what is done at which time is very different.
$ lilypond manual-breaking-assertion-failure-04.ly
GNU LilyPond 2.19.52
Processing `manual-breaking-assertion-failure-04.ly'
Parsing...
Interpreting
2017-01-06 13:10 GMT+01:00 Chris Yate :
> Curiously, this didn't fail with assertions. I've just upgraded to 2.19.54,
> and the test cases that crashed for me previously still crash :)
Could you remove all "Test 3x"-scores from the test-file and redo
compilation, please.
Cheers,
Harm
__
ion = ##f
> > \override Score.NonMusicalPaperColumn.page-break-permission = ##f
> > }
>
>
>
> Hi Chris,
>
> 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
= {
>>> %\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 cre
On Fri, 6 Jan 2017 at 11:34 David Kastrup wrote:
>
> 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 assertio
aperColumn.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 nex
imited 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
ed the attached test-file (and the pdf I get [*])
> >>
> >> Please uncomment the test-scores one by one.
> >>
> >> I'd expect test 1 and test 1a to work
> >> Not sure with test 2 and test 2a
> >> test 3 and test 3 will likely fail with asserti
Hi everybody!
On 64-bit Linux I also saw failures caused by manual page breaking
with too few space a few months ago. I had no time to investigate
the problem then, but there definitely is a problem not only on windows.
I saw assertion failures, but I also managed to immediately kill lilypond
wit
expect test 1 and test 1a to work
>> Not sure with test 2 and test 2a
>> test 3 and test 3 will likely fail with assertion.
>>
>> How does it work for you?
>>
>> Cheers,
>> Harm
>
>
> Hi,
>
> I ran these tests individually and together. All
n.
>
> How does it work for you?
>
> Cheers,
> Harm
>
Hi,
I ran these tests individually and together. All succeed and none throw the
assertion failure!
I've attached the PDF.
Chris
HarmsTestRunOutput.pdf
Description: Adobe PDF document
___
xplodes from 60.4KB to 1.2MB.
Why??
manual-breaking-assertion-failure-03.pdf
Description: Adobe PDF document
manual-breaking-assertion-failure-03.ly
Description: application/download
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://li
mn.page-break-permission = ##f
>
> autoPageBreaksOn =
> \override Score.NonMusicalPaperColumn.page-break-permission = #'allow
>
> autoBreaksOff = { \autoLineBreaksOff \autoPageBreaksOff }
>
> autoBreaksOn = { \autoLineBreaksOn \autoPageBreaksOn }
>
> %% new defs end
2017-01-03 18:04 GMT+01:00 Chris Yate :
> On Tue, 3 Jan 2017 at 16:23 Thomas Morley wrote:
>>
>> Do you have the same problems, while putting it in \layout and using
>> manual breaks? Like:
>>
>> \layout {
>> \autoBreaksOff
>> }
>>
>> { \repeat unfold 22 b2
>> \repeat unfold 320 b2
>> \brea
On Tue, 3 Jan 2017 at 16:23 Thomas Morley wrote:
> 2017-01-03 17:10 GMT+01:00 Chris Yate :
> >
> >
> > On Tue, 3 Jan 2017 at 16:03 Thomas Morley
> wrote:
> >>
> >> This replies to
> >> http://lists.gnu.org/archive/html/lilypond-devel/2017-01/msg00010.html
> >>
> >> 2017-01-03 12:23 GMT+01:00 Chr
2017-01-03 17:10 GMT+01:00 Chris Yate :
>
>
> On Tue, 3 Jan 2017 at 16:03 Thomas Morley wrote:
>>
>> This replies to
>> http://lists.gnu.org/archive/html/lilypond-devel/2017-01/msg00010.html
>>
>> 2017-01-03 12:23 GMT+01:00 Chris Yate :
>> >
>> > Hmm. No, agreed, not ready for release yet. This on
On Tue, 3 Jan 2017 at 16:03 Thomas Morley wrote:
> This replies to
> http://lists.gnu.org/archive/html/lilypond-devel/2017-01/msg00010.html
>
> 2017-01-03 12:23 GMT+01:00 Chris Yate :
> >
> > Hmm. No, agreed, not ready for release yet. This one prevents me using
> > Lilypond on Windows for anythi
This replies to
http://lists.gnu.org/archive/html/lilypond-devel/2017-01/msg00010.html
2017-01-03 12:23 GMT+01:00 Chris Yate :
>
> Hmm. No, agreed, not ready for release yet. This one prevents me using
> Lilypond on Windows for anything other than pathologically small projects
> (i.e. nothing that
> I've just tested the updated i386-linux mpost binary in TeXLive
> (rev. 30602), and I get exactly the same assertion, unfortunately.
And with rev. 30652, everything works fine again, thanks.
Werner
___
lilypond-devel mailing list
lilypond-devel
> [This is the i386-linux 2013 binary of mpost, version 1.802,
> TeXLive SVN rev. 30584]
>
> I've just got this while processing lilypond's fonts:
>
> mpost: ../../../texk/web2c/mplibdir/mp.w:2968:
> mp_free_value_node: Assertion `p->has_number==2' failed.
I've just tested the updated i3
Dear Werner LEMBERG,
[This is the i386-linux 2013 binary of mpost, version 1.802,
TeXLive SVN rev. 30584]
I've just got this while processing lilypond's fonts:
mpost: ../../../texk/web2c/mplibdir/mp.w:2968:
mp_free_value_node: Assertion `p->has_number==2' failed.
Attached are the input fil
Dear Werner LEMBERG,
Attached are the input files to reproduce the assertion. Note that
the code has always worked without any problems.
It seems that the w32 binary works for the example.
I attach feta-noteheads11.log.
Best regards,
Akira KAKUTO
feta-noteheads11.log
Description: Binary dat
>> Attached are the input files to reproduce the assertion. Note that
>> the code has always worked without any problems.
>
> It seems that the w32 binary works for the example. I attach
> feta-noteheads11.log.
Thanks. It seems to be a compiler issue, as Peter's e-mail indicates.
Werner
[This is the i386-linux 2013 binary of mpost, version 1.802,
TeXLive SVN rev. 30584]
I've just got this while processing lilypond's fonts:
mpost: ../../../texk/web2c/mplibdir/mp.w:2968:
mp_free_value_node: Assertion `p->has_number==2' failed.
Attached are the input files to reproduce the
On Tue, Aug 28, 2012 at 08:28:05PM +0200, m...@mikesolomon.org wrote:
> Slightly changing subject, I'm of the opinion that no user
> input, however unconventional, should lead to an assertion
> failure. When someone puts an assertion failure in the code, to
> me, it is saying
FWIW I checked 2.15.32 (the \version of tota-pulchra.ly),
and the assert is triggered there too.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On 28 août 2012, at 15:17, David Kastrup wrote:
> "m...@mikesolomon.org" writes:
>
>> Hey all,
>>
>> With --disable-optimisation passed to configure, Janek's score at:
>>
>> www.mikesolomon.org/tota-pulchra.zip
>>
>> f
"m...@mikesolomon.org" writes:
> Hey all,
>
> With --disable-optimisation passed to configure, Janek's score at:
>
> www.mikesolomon.org/tota-pulchra.zip
>
> fails with the assertion failure on line 252 of the current grob-property.cc
>
> assert (v
On Aug 28, 2012 12:14 PM, "m...@mikesolomon.org"
wrote:
> I'm a bit short on time but could someone do some snooping to try and
figure out what the problematic commit is?
I don't think there is one. I can't double check at the moment, but
there's a dubious callback for BarNumber self-alignment-
2012/8/28 m...@mikesolomon.org :
> Hey all,
>
> With --disable-optimisation passed to configure, Janek's score at:
>
> www.mikesolomon.org/tota-pulchra.zip
>
> fails with the assertion failure on line 252 of the current grob-property.cc
>
> assert (value == SC
Hey all,
With --disable-optimisation passed to configure, Janek's score at:
www.mikesolomon.org/tota-pulchra.zip
fails with the assertion failure on line 252 of the current grob-property.cc
assert (value == SCM_EOL || value == marker);
I started a git bisect but have no clue when the
"m...@apollinemike.com" writes:
> On Oct 1, 2011, at 9:29 PM, David Kastrup wrote:
>>
>> This sounds really really icky. The sort of code I hope never to
>> need to deal with. Could you file a suitable "Enhancement" issue so
>> that redoing this in a less hackish manner does not get forgotten?
On Oct 1, 2011, at 9:29 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> But I just pushed the actual cure.
>>
>> The problem was that positions stores two Y positions - a left and a
>> right. If the left is higher than right, than the interval is read as
>> empty. So, the cent
"m...@apollinemike.com" writes:
> But I just pushed the actual cure.
>
> The problem was that positions stores two Y positions - a left and a
> right. If the left is higher than right, than the interval is read as
> empty. So, the center needs to be calculated manually.
>
> Interval is not real
On Oct 1, 2011, at 7:48 PM, David Kastrup wrote:
> "m...@apollinemike.com" writes:
>
>> On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote:
>>
>>> On 1 October 2011 18:19, Peekay Ex wrote:
>>>
Neil what command do you run when you do a test-baseline so that I
might get something like yo
"m...@apollinemike.com" writes:
> On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote:
>
>> On 1 October 2011 18:19, Peekay Ex wrote:
>>
>>> Neil what command do you run when you do a test-baseline so that I
>>> might get something like you do?
>>
>> I don't. :) I couldn't work out which file was
On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote:
> On 1 October 2011 18:19, Peekay Ex wrote:
>
>> Neil what command do you run when you do a test-baseline so that I
>> might get something like you do?
>
> I don't. :) I couldn't work out which file was failing, so I did what
> I usually do: run
Neil,
On Sat, Oct 1, 2011 at 6:22 PM, Neil Puttock wrote:
> On 1 October 2011 18:19, Peekay Ex wrote:
>
>> Neil what command do you run when you do a test-baseline so that I
>> might get something like you do?
>
> I don't. :) I couldn't work out which file was failing, so I did what
> I usually
On Oct 1, 2011, at 7:22 PM, Neil Puttock wrote:
> On 1 October 2011 18:19, Peekay Ex wrote:
>
>> Neil what command do you run when you do a test-baseline so that I
>> might get something like you do?
>
> I don't. :) I couldn't work out which file was failing, so I did what
> I usually do: run
On 1 October 2011 18:19, Peekay Ex wrote:
> Neil what command do you run when you do a test-baseline so that I
> might get something like you do?
I don't. :) I couldn't work out which file was failing, so I did what
I usually do: run all the regression tests until it crashes.
The output I've p
Hello,
On Sat, Oct 1, 2011 at 6:01 PM, m...@apollinemike.com
wrote:
> On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote:
>
>> Hey guys,
>>
>> I can't complete test-baseline due to an assertion error running
>> mozart-hrn-3.ly. Here's the backtrace:
>>
>> Drawing systems...lilypond: ../flower/includ
On 1 October 2011 18:16, Graham Percival wrote:
> The problem is verified; I see exactly the same behaviour as Neil
> with 4f49b000d6e257724e311b406e2346b8388c1f0e
Here's a minimal snippet which fails:
\version "2.15.14"
\relative c' {
\times 2/3 { f8 e d }
}
Cheers,
Neil
_
On Sat, Oct 01, 2011 at 07:04:25PM +0200, m...@apollinemike.com wrote:
>
> On Oct 1, 2011, at 7:01 PM, m...@apollinemike.com wrote:
>
> > On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote:
> >
> >> Drawing systems...lilypond: ../flower/include/interval.hh:226: T
> >> Interval_t::center() const [wit
On 1 October 2011 18:04, m...@apollinemike.com wrote:
> A follow-up: I can't figure out how the error could come about.
> Interval::center should, in Tuplet_number::calc_y_offset, always be getting
> an interval for which it can find the center (it uses robust_scm2interval).
> Does anyone wi
On Oct 1, 2011, at 7:01 PM, m...@apollinemike.com wrote:
> On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote:
>
>> Hey guys,
>>
>> I can't complete test-baseline due to an assertion error running
>> mozart-hrn-3.ly. Here's the backtrace:
>>
>> Drawing systems...lilypond: ../flower/include/interv
On Oct 1, 2011, at 6:53 PM, Neil Puttock wrote:
> Hey guys,
>
> I can't complete test-baseline due to an assertion error running
> mozart-hrn-3.ly. Here's the backtrace:
>
> Drawing systems...lilypond: ../flower/include/interval.hh:226: T
> Interval_t::center() const [with T = double]: Assertio
Hey guys,
I can't complete test-baseline due to an assertion error running
mozart-hrn-3.ly. Here's the backtrace:
Drawing systems...lilypond: ../flower/include/interval.hh:226: T
Interval_t::center() const [with T = double]: Assertion `!is_empty
()' failed.
Program received signal SIGABRT, Abor
With latest git, make web fails on mozart-hrn-3.ly:
$ ./out/bin/lilypond input/mutopia/W.A.Mozart/mozart-hrn-3.ly
GNU LilyPond 2.11.10
Processing `input/mutopia/W.A.Mozart/mozart-hrn-3.ly'
Parsing...
Interpreting music... [8][16][24][32][40][48][56][64][72][80][88][96]
warning: cannot find start
53 matches
Mail list logo
