Re: Mysterious crash in BDWGC on Windows

data point, the bug only reproduces with address space layout randomization enabled. Do you have any idea what might be causing this? At LilyPond, we're totally lost on what could provoke such an internal crash in BDWGC. Do you have successful experience with using Guile 2.2 on Windows? Did y

Mysterious crash in BDWGC on Windows

enabled. Do you have any idea what might be causing this? At LilyPond, we're totally lost on what could provoke such an internal crash in BDWGC. Do you have successful experience with using Guile 2.2 on Windows? Did you see this kind of thing before? In short, does it ring a bell? Thanks,

Re: Crash when music of score starts with \pageBreak

Le 11/09/2021 à 16:43, Richard Shann a écrit : I came across a situation where LilyPond crashes caused by a badly placed \pageBreak. I've chopped most of the music out of the example but when I tried to remove more the crash stopped. The error message ends: Finding the ideal number of

Crash when music of score starts with \pageBreak

I came across a situation where LilyPond crashes caused by a badly placed \pageBreak. I've chopped most of the music out of the example but when I tried to remove more the crash stopped. The error message ends: Finding the ideal number of pages... Fitting music on 1 page...lilypond: /hom

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

Thanks for the ping, it's been a long time! Sadly, I haven't used lilypond for years. I tried to update my patch, but I cannot spend too much time on it. I see that my change to engraver.cc is no longer needed, as there is a check there that was missing back at the time. The change to engraver-sche

nasty `ar' crash while building guile with gub

My attempts to build lilypond (or rather guile) with gub are stopped in the `tools' stage since a few days due to a nasty crash in `ar' in combination with its `LLVMgold.so' plugin on openSuSE 42.3, cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1117239 Does anybody else

Re: crash running translator

Hi David, wow, thank you! I will try to follow your explanations soon and read the mentioned code. Jan-Peter Am 17.09.2018 um 16:38 schrieb David Kastrup: > Jan-Peter Voigt writes: > >> Dear all, >> >> I stumbled over something that looks like a bug. >> If one uses ly:run-translator to proces

Re: crash running translator

Jan-Peter Voigt writes: > Dear all, > > I stumbled over something that looks like a bug. > If one uses ly:run-translator to process some music a dotted rest > crashes lilypond: > > \version "2.19.82" > #(ly:run-translator #{ r2. #} #{ \layout {} #}) > > The error message is: > Wrong number of arg

crash running translator

Dear all, I stumbled over something that looks like a bug. If one uses ly:run-translator to process some music a dotted rest crashes lilypond: \version "2.19.82" #(ly:run-translator #{ r2. #} #{ \layout {} #}) The error message is: Wrong number of arguments to # Does anybody know a way to circu

Issue 5345: Stop crash while merging ledger lines (issue 343270043 by d...@gnu.org)

LGTM. https://codereview.appspot.com/343270043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

RE: crash during musicxml2ly

Hello, Thanks Regards, GOHIER Frédéric De : James Lowe Envoyé : lundi 7 mai 2018 10:13 À : James Lowe Cc : Frédéric Gohier; lilypond-devel Objet : Re: crash during musicxml2ly Frederic On Wed, 02 May 2018 12:09:37 +0100 (BST), "James Lowe" wrote

Re: crash during musicxml2ly

Frederic On Wed, 02 May 2018 12:09:37 +0100 (BST), "James Lowe" wrote: > Hello Frederic, > > On Tue, 1 May 2018 16:47:24 +, Frédéric Gohier > wrote: > > > hello, > > > > I just push the patch on rietveld : > > https://codereview.appspot.com/339560043/ This has now gone through the pa

Re: crash during musicxml2ly

Hello Frederic, On Tue, 1 May 2018 16:47:24 +, Frédéric Gohier wrote: > hello, > > I just push the patch on rietveld : https://codereview.appspot.com/339560043/ > > Thank you, I have created https://sourceforge.net/p/testlilyissues/issues/5317/ for this issue. I will help start the rev

Re: crash moving DotColumn

Thomas Morley writes: > 2016-05-13 12:27 GMT+02:00 David Kastrup : > >> This is quite explicitly the case that the assertion is supposed to >> complain about. Since obviously this is triggerable by user error (in >> this case yours), maybe the assertion should be demoted to a programming >> erro

Re: crash moving DotColumn

2016-05-13 12:27 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> 2016-05-12 15:51 GMT+02:00 David Kastrup : >>> Thomas Morley writes: >>> To get more space between NoteColumn and DotColumn the following used to work with 2.18.2 foo = \override Score.DotColumn.befor

Re: crash moving DotColumn

Thomas Morley writes: > 2016-05-12 15:51 GMT+02:00 David Kastrup : >> Thomas Morley writes: >> >>> To get more space between NoteColumn and DotColumn the following used >>> to work with 2.18.2 >>> >>> foo = >>> \override Score.DotColumn.before-line-breaking = >>> #(lambda (dot-column) >>>

Re: crash moving DotColumn

2016-05-12 15:51 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> To get more space between NoteColumn and DotColumn the following used >> to work with 2.18.2 >> >> foo = >> \override Score.DotColumn.before-line-breaking = >> #(lambda (dot-column) >> (ly:grob-set-property! dot-column '

Re: crash moving DotColumn

Thomas Morley writes: > To get more space between NoteColumn and DotColumn the following used > to work with 2.18.2 > > foo = > \override Score.DotColumn.before-line-breaking = > #(lambda (dot-column) > (ly:grob-set-property! dot-column 'positioning-done > (lambda (grob) > (ly

Re: crash moving DotColumn

Thomas Morley writes: > 2016-05-10 11:28 GMT+02:00 Thomas Morley : > >>> >>> Can you give a full backtrace from the debugger? Likely something like >>> >>> gdb out/bin/lilypond >>> run /tmp/foo-test-file.ly >>> bt >>> >>> should do the trick. >> >> Will try in the evening, have to run. > > > Hop

Re: crash moving DotColumn

2016-05-10 11:28 GMT+02:00 Thomas Morley : >> >> Can you give a full backtrace from the debugger? Likely something like >> >> gdb out/bin/lilypond >> run /tmp/foo-test-file.ly >> bt >> >> should do the trick. > > Will try in the evening, have to run. Hope I did it correctly, never used gdb befo

Re: crash moving DotColumn

2016-05-10 10:59 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> To get more space between NoteColumn and DotColumn the following used >> to work with 2.18.2 > > Even when compiled with --disable-optimising ? I used the released version. > >> foo = >> \override Score.DotColumn.before-line

Re: crash moving DotColumn

Thomas Morley writes: > To get more space between NoteColumn and DotColumn the following used > to work with 2.18.2 Even when compiled with --disable-optimising ? > foo = > \override Score.DotColumn.before-line-breaking = > #(lambda (dot-column) > (ly:grob-set-property! dot-column 'positi

crash moving DotColumn

To get more space between NoteColumn and DotColumn the following used to work with 2.18.2 foo = \override Score.DotColumn.before-line-breaking = #(lambda (dot-column) (ly:grob-set-property! dot-column 'positioning-done (lambda (grob) (ly:dot-column::calc-positioning-done grob)

Issue 4767: Crash with Completion_heads_engraver and bare durations (issue 288100043 by d...@gnu.org)

LGTM https://codereview.appspot.com/288100043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Crash with tupletFullLength = ##t

hen a RehearsalMark is not so big, but if it pushes the righthand end of the TupletBracket too far, it causes a crash. This would seem to be related to issue 2362 <http://sourceforge.net/p/testlilyissues/issues/2362/> however that doesn't mention actually crashing. It would appear to be the

Crash with tupletFullLength = ##t

When tupletFullLength is set to ##t, the TupletBracket is actually *shortened* by a following RehearsalMark. This doesn't happen with tupletFullLength = ##f. This is merely ugly when a RehearsalMark is not so big, but if it pushes the righthand end of the TupletBracket too far, it causes a

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

On 2015/07/12 23:39:52, dak wrote: On 2015/07/12 17:49:44, thomasmorley651 wrote: > On 2015/07/12 17:01:06, dak wrote: > > https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm > > File scm/define-markup-commands.scm (right): > > > > > https://codereview.appspot.com/

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

On 2015/07/12 17:49:44, thomasmorley651 wrote: On 2015/07/12 17:01:06, dak wrote: > https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm > File scm/define-markup-commands.scm (right): > > https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm#

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

2011-04-15 18:31:17 Parent: 3d571d9c80b7855422c96ecc6966bcbfa4dfb9ff (Add feature to link to a particular page or a page containing a given label) Child: 7703d5ed1ce797d92449a6a79ce593e6e5601396 (Fix problem with multiple markups on chord glissandos.) Branches: dev/toc-crash-with-link, maste

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

dd links to non-existing labels in the .ps file) Branches: dev/toc-crash-with-link, master and many more (42) Follows: release/2.13.59-1 Precedes: release/2.13.60-1 Add feature to link to a particular page or a page containing a given label The main part of this patch was done by Dan Ebl

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

On 2015/07/12 17:49:44, thomasmorley651 wrote: > Do the links actually work when first-page-number is, say, 10? yes > If so, did they > not work before? No, it was broken. Well, then we probably have to thank Ghostscript for bringing this long-standing problem to our attention. It ma

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

On 2015/07/12 17:01:06, dak wrote: https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm#newcode542 scm/define-markup-commands.scm:542: (+ tabl

Re: Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm File scm/define-markup-commands.scm (right): https://codereview.appspot.com/258740043/diff/1/scm/define-markup-commands.scm#newcode542 scm/define-markup-commands.scm:542: (+ table-page-number (+ 1 (* -1 first-page-num

Table Of Contents crash with negative first-page-number (issue 258740043 by thomasmorle...@gmail.com)

Reviewers: , Description: Table Of Contents crash with negative first-page-number Issue 4494 Let \with-link point to the physical page-number Please review this at https://codereview.appspot.com/258740043/ Affected files (+20, -11 lines): M scm/define-markup-commands.scm Index: scm

Re: Crash

- Original Message - From: "tisimst" To: Sent: Sunday, June 08, 2014 12:32 PM Subject: Re: Crash Phil, The issue comes from using "R" instead of "r" when inputting rests. The "R" syntax for rests is used to indicate that an entire measure

Re: Crash

for me). -Abraham -- View this message in context: http://lilypond.1069038.n5.nabble.com/Crash-tp163090p163112.html Sent from the Dev mailing list archive at Nabble.com. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Crash

The code below causes LilyPond to crash (the windows equivalent of a segfault) with the following error: programming error: Multi_measure_rest::get_rods (): I am not spanned! continuing, cross fingers Program finished 2.14.0 fails to process the rest but doesn't crash. 2.15.2 does

Re: tracking down a crash

On Fri, 22 Nov 2013 01:32:19 -0800, David Kastrup wrote: Argh. How about this one (should likely apply using git am): That clears the crash, resolves the problem with extra barlines, and leaves no similar problems in my test case so far as I can see

Re: tracking down a crash

ential_iterator::do_quit () >> >> That change, on master, did not clear the crash. > > Argh. How about this one (should likely apply using git am): > > > From 668947b09f989342181ab3962b475b9efa3d0976 Mon Sep 17 00:00:00 2001 > From: David Kastrup > Date: Fri, 22 Nov 2

Re: tracking down a crash

"Keith E OHara" writes: > On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: > >> So one suspicion would be that iter_ points to a non-operative >> iterator. Maybe set it to zero in > >> Sequential_iterator::do_quit () > > That change, on m

Re: tracking down a crash

"Keith E OHara" writes: > On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: > >> So one suspicion would be that iter_ points to a non-operative >> iterator. Maybe set it to zero in > >> Sequential_iterator::do_quit () > > That change, on master

Re: tracking down a crash

On Wed, 20 Nov 2013 23:48:47 -0800, David Kastrup wrote: So one suspicion would be that iter_ points to a non-operative iterator. Maybe set it to zero in Sequential_iterator::do_quit () That change, on master, did not clear the crash. release/2.18 gives good output on <h

Re: tracking down a crash

"Keith E OHara" writes: > Invoking Lilypond individually for the .ly files also succeeds, so > maybe this has something to do with compiling two input files, each > setting volta repeats, in one session. Next time I have time, I > suppose I should pull the candidate 2.18 stable branch and make s

tracking down a crash

I was getting crashes while testing the page-layout changes on a big set of files, which went away when I set just one input file. It will take a while before I narrow it down to a small example. I can reproduce by taking + running

Tuplet-bracket: do not crash; issue 3551 (issue 13352053)

LGTM https://codereview.appspot.com/13352053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 3205: opening bar check causes crash if \score contains the \midi block (issue 7377057)

is with \partial, and \partial wraps its music event in (descend-to-context ... and thus is impervious to this problem (the raw music event in itself will likely crash LilyPond equally well). I have no idea what Simple_music_iterator is for. Possibly for getting triggered at most once per time step

Issue 3205: opening bar check causes crash if \score contains the \midi block (issue 7377057)

I tried skipTypesetting and showFirstLength in different situations. They seem to work. It would be nice to know at least /how/ this change causes Score_performer::prepare() to be called. On the other hand, it seems that the bar-check-iterator should not have caused Score_performer::one_time_ste

Re: [Lilypond-auto] Issue 3194 in lilypond: crash when too manybars requested

> Comment #7 on issue 3194 by philehol...@googlemail.com: crash when too many > bars requested > http://code.google.com/p/lilypond/issues/detail?id=3194 > > Sorry, Trevor, it's not that. My physical memory is 6 Gigs, and I've > written an app that repeatedly a

Re: [Lilypond-auto] Issue 3194 in lilypond: crash when too many bars requested

2013/2/18 : > > Comment #2 on issue 3194 by d...@gnu.org: crash when too many bars requested > http://code.google.com/p/lilypond/issues/detail?id=3194 > > Issue 1475 was reported fixed in version 2.13.47. Can someone check whether > a) version 2.13.47 will fail with the inp

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

http://codereview.appspot.com/5715053/diff/2001/lily/engraver-scheme.cc File lily/engraver-scheme.cc (right): http://codereview.appspot.com/5715053/diff/2001/lily/engraver-scheme.cc#newcode42 lily/engraver-scheme.cc:42: programming_error ("cannot create grob"); This gives no helpful indication o

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

On 2012/03/03 04:38:36, Pavel Roskin wrote: I'm not getting any interesting information: ... [/usr/local/share/lilypond/2.15.32/ly/context-mods-init.ly] [/usr/local/share/lilypond/2.15.32/ly/engraver-init.ly]] [bad.ly] Interpreting music... [/usr/local/share/lilypond/2.15.32/fonts/otf/

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

I'm not getting any interesting information: ... [/usr/local/share/lilypond/2.15.32/ly/context-mods-init.ly] [/usr/local/share/lilypond/2.15.32/ly/engraver-init.ly]] [bad.ly] Interpreting music... [/usr/local/share/lilypond/2.15.32/fonts/otf/emmentaler-20.otf] fatal error: failed files: "bad

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

On Fri, Mar 2, 2012 at 10:22 PM, wrote: > There are only two calls to scm_throw in Lilypond, and I could not find > out whether it should be added to engraver.cc or engraver-scheme.cc.  I > added it to the former so that other callers to > Engraver::internal_make_grob could benefit.  I could not

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

There are only two calls to scm_throw in Lilypond, and I could not find out whether it should be added to engraver.cc or engraver-scheme.cc. I added it to the former so that other callers to Engraver::internal_make_grob could benefit. I could not figure out how to catch an exception. Without ca

Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

On 2012/03/01 23:02:57, Pavel Roskin wrote: I've seen it many times that Lilypond would crash during my experiments with Scheme code. This time I decided to track it down. It's my first ever fix to the C++ code in Lilypond, so please check my coding style. How is that a fix?

Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)

Reviewers: , Message: I've seen it many times that Lilypond would crash during my experiments with Scheme code. This time I decided to track it down. It's my first ever fix to the C++ code in Lilypond, so please check my coding style. Description: Fix crash when unknown grob name is

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

On 2011/11/26 15:43:34, dak wrote: On 2011/11/26 15:15:25, Carl wrote: Any way, your patch does not fix the segfault on Ubuntu 11.10 without specific compilation options, so we can as well forget it, I guess. OK, I'll close this issue. We have a record of the conversation on -devel. Tha

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

On 2011/11/26 15:15:25, Carl wrote: On 2011/11/26 15:07:17, dak wrote: > > I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you > have a reference for Mike's analysis? http://lists.gnu.org/archive/html/lilypond-devel/2011-11/msg00556.html > > It seems we should

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

On 2011/11/26 15:07:17, dak wrote: I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you have a reference for Mike's analysis? http://lists.gnu.org/archive/html/lilypond-devel/2011-11/msg00556.html It seems we should rather fix the segfault at its source than hid

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

I know you've pushed a different patch, which fixes Issue 1900, but doesn't fix 1997. Have you tried this patch to see if it fixes 1997? I'll do so, but frankly, if it _does_ fix 1997, I don't want it pushed. Do you have a reference for Mike's analysis? It seems we should rather fix the segf

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

On 2011/11/26 07:32:48, dak wrote: The functionality seems to be there just fine. What makes you suspect that this copying-of-properties-at-definition-and-documentation-time is responsible for a crash? I'm just flying blind. Mike pointed out that using properties that weren&#x

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

responsible for a crash? Mind you, the "copying of properties" puts the whole referred function into the properties documentation (not just a symbol or so) which is kind of icky. It does have the advantage that it makes it close to impossible to accidentally create recursive referen

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

David Kastrup writes: > carl.d.soren...@gmail.com writes: > >> Reviewers: , >> >> Message: >> I've created a patch for Issue 1900. It solves the crash, but perhaps >> in a non-optimal way. >> >> David, will you please review this,

Re: Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

carl.d.soren...@gmail.com writes: > Reviewers: , > > Message: > I've created a patch for Issue 1900. It solves the crash, but perhaps > in a non-optimal way. > > David, will you please review this, since I've changed code that you > added to scm/fret-diag

Fix issue 1900 -- multiple fret-diagram-terse markups commands crash (issue 5432081)

Reviewers: , Message: I've created a patch for Issue 1900. It solves the crash, but perhaps in a non-optimal way. David, will you please review this, since I've changed code that you added to scm/fret-diagrams.scm? Thanks, Carl Description: Fix issue 1900 -- multiple fret-dia

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

On 2011/07/21 18:38:04, Neil Puttock wrote: Those are recent doc changes added by Joe. If you look elsewhere, you'll see that all nested overrides use list syntax (I converted all the docs when I add the support back in 2008). Okay, I have changed that back and pushed to git master. http://c

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

On 21 July 2011 19:27, wrote: > Really? The NR (section 5.3.6 "Modifying alists" as well as 4.4.1 > "Flexible vertical spacing within systems") only gives examples of the > form #'staff-staff-spacing #'basic-distance... I didn't even know that > the list syntax was there, let alone that it is th

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

quot;Flexible vertical spacing within systems") only gives examples of the form #'staff-staff-spacing #'basic-distance... I didn't even know that the list syntax was there, let alone that it is the syntax we are advocating. Description: Fix 1770: revert caused a crash in displ

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm File scm/define-music-display-methods.scm (right): http://codereview.appspot.com/4805043/diff/2002/scm/define-music-display-methods.scm#newcode867 scm/define-music-display-methods.scm:867: ;; nested properties a

Re: Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

Passes Make and reg tests http://codereview.appspot.com/4805043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix 1770: revert caused a crash in displayLilyMusic. (issue4805043)

Hi Reinhold, LGTM, though I wonder whether it'd be better just to junk 'grob-property and use 'grob-property-path exclusively. Cheers, Neil http://codereview.appspot.com/4805043/diff/1/input/regression/display-lily-tests.ly File input/regression/display-lily-tests.ly (right): http://coderevie

Re: PATCHES: 48-hour notice for markuplines crash and toc lines

On Tue, Feb 22, 2011 at 4:29 AM, Graham Percival wrote: > Thurs 9am. > > > Assuming we want \markuplines { } to behave like \markup { } (i.e., > produce a \null toplevel markup), then this patch works, since it > ensures a valid Paper_score in paper-book.cc: > http://codereview.appspot.com/4160059

PATCHES: 48-hour notice for markuplines crash and toc lines

Thurs 9am. Assuming we want \markuplines { } to behave like \markup { } (i.e., produce a \null toplevel markup), then this patch works, since it ensures a valid Paper_score in paper-book.cc: http://codereview.appspot.com/4160059/ Add dots to tocItemMarkup http://codereview.appspot.com/4182056/

Re: Fix bookpart identifier crash with page-marker. (issue3585042)

On 2010/12/12 16:22:24, Graham Percival wrote: LGTM; regtest comparison shows nothing unexpected, and the docs build from scratch. Please push. I've taken the liberty of pushing this; I want to release .43 soon. http://codereview.appspot.com/3585042/ ___

Re: Fix bookpart identifier crash with page-marker. (issue3585042)

LGTM; regtest comparison shows nothing unexpected, and the docs build from scratch. Please push. http://codereview.appspot.com/3585042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fix bookpart identifier crash with page-marker. (issue3585042)

LGTM http://codereview.appspot.com/3585042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Fix bookpart identifier crash with page-marker. (issue3585042)

lgtm http://codereview.appspot.com/3585042/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

release 22.13.24 crash

ges] Systeme erstellen... Layout nach »test1.ps« ausgeben... Konvertierung nach »./test1.pdf«... success: Compilation successfully completed cheers! Eluze -- View this message in context: http://old.nabble.com/release-22.13.24-crash-tp28896856p28896856.html Sent from the Gnu - Lilypond - Dev mail

Re: silent crash on large score - how to debug?

Op maandag 08-03-2010 om 13:25 uur [tijdzone +], schreef Graham Percival: > 2010/3/8 Han-Wen Nienhuys : > Given that I don't have push ability to gub, what did you expect? Please create an account on github, I'll add you. Jan. ___ lilypond-deve

Re: silent crash on large score - how to debug?

2010/3/8 Han-Wen Nienhuys : > which leaves tags in GUB, so we know with which configuration binaries > were released.  However, > >  http://github.com/janneke/gub > > only shows a tag for 2.12.2. Given that I don't have push ability to gub, what did you expect? gperc...@gperciva-desktop:/main/src

Re: silent crash on large score - how to debug?

Graham, I used to release through test-lily/upload.py which leaves tags in GUB, so we know with which configuration binaries were released. However, http://github.com/janneke/gub only shows a tag for 2.12.2. What was the difference between 2.12.2 and 2.12.3 in terms of GUB? 2010/3/3 Fré

Fix crash in script_column when suggestAccidentals = ##t is used (issue163041)

Hi Reinhold, This looks OK, but there's still a remaining problem which I've mentioned in the bugtracker for #787. The comment is too specific though, since it's nothing to do with suggestAccidentals; it just happens that this regtest has two scripts (i.e., an articulation + the accidental) stac

Re: [PATCH v3] Fix crash when a stencil routine is missing

On 2009-09-06, Michael Käppler wrote: > Hi Patrick, > I recently noticed that /input/regression/bookparts.ly gives the > warning "Missing stencil expression: utf-8-string" what I think is > related to your patchset. > Could you please have a look at this? This should be fixed in git. Thanks, Patr

Re: [PATCH v3] Fix crash when a stencil routine is missing

On 2009-09-06, Patrick McCarty wrote: > On 2009-09-06, Michael Käppler wrote: > > Hi Patrick, > > I recently noticed that /input/regression/bookparts.ly gives the > > warning "Missing stencil expression: utf-8-string" what I think is > > related to your patchset. > > Could you please have a look at

Re: [PATCH v3] Fix crash when a stencil routine is missing

On 2009-09-06, Michael Käppler wrote: > Hi Patrick, > I recently noticed that /input/regression/bookparts.ly gives the > warning "Missing stencil expression: utf-8-string" what I think is > related to your patchset. > Could you please have a look at this? Thanks, I will look at this shortly. I ha

Re: [PATCH v3] Fix crash when a stencil routine is missing

Hi Patrick, I recently noticed that /input/regression/bookparts.ly gives the warning "Missing stencil expression: utf-8-string" what I think is related to your patchset. Could you please have a look at this? Thanks, Michael ___ lilypond-devel maili

Re: Fix crash when a stencil routine is missing

On Thu, Jul 16, 2009 at 05:42:25AM +, joenee...@gmail.com wrote: > lgtm > > http://codereview.appspot.com/83046 Thanks, Joe. It's applied. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilyp

Re: Fix crash when a stencil routine is missing

lgtm http://codereview.appspot.com/83046 ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH v3] Fix crash when a stencil routine is missing

On Tue, Jul 7, 2009 at 2:44 PM, Patrick McCarty wrote: > Hello, > > The third revision of my patch set (Patch Set 5) is on Rietveld: > > http://codereview.appspot.com/83046/show > > The change from Patch Set 4 is the generalization of > -dwarning-as-error.  Note that this is a series of 8 commits t

[PATCH v3] Fix crash when a stencil routine is missing

Hello, The third revision of my patch set (Patch Set 5) is on Rietveld: http://codereview.appspot.com/83046/show The change from Patch Set 4 is the generalization of -dwarning-as-error. Note that this is a series of 8 commits that contain more in-depth commit summaries. They can be found here:

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Tue, 2009-07-07 at 01:24 -0700, Patrick McCarty wrote: > On Tue, Jul 07, 2009 at 08:16:45AM +0200, Werner LEMBERG wrote: > > > > > The new option, -dwarning-as-error, does *not* turn every warning into > > > an error. It only turns specific warnings (that don't exist without > > > this patch)

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Tue, Jul 07, 2009 at 08:16:45AM +0200, Werner LEMBERG wrote: > > > The new option, -dwarning-as-error, does *not* turn every warning into > > an error. It only turns specific warnings (that don't exist without > > this patch) into errors. > > Then the name is indeed too generic and should be

Re: [PATCH v2] Fix crash when a stencil routine is missing

> The new option, -dwarning-as-error, does *not* turn every warning into > an error. It only turns specific warnings (that don't exist without > this patch) into errors. Then the name is indeed too generic and should be temporarily renamed to something more specific until the code has been impro

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Mon, Jul 06, 2009 at 03:37:06PM -0700, Patrick McCarty wrote: > On Mon, Jul 06, 2009 at 03:08:50PM -0700, Graham Percival wrote: > > I don't see a huge urgency for this patch, so I would rather wait > > until b) was non-existent. I totally agree that we should split > > a) and c), though. > >

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Mon, Jul 06, 2009 at 03:37:06PM -0700, Patrick McCarty wrote: > > But, since the regression test suite only exercises the PostScript > backend, which doesn't currently have any missing any *defined* > stencil expressions, we won't be seeing any failures right now. I should emphasize the *right

Re: [PATCH v2] Fix crash when a stencil routine is missing

tch) into errors. The purpose is more of a long-term solution, so you're right that it's not at all urgent. For example, with this patch, if you compile a file containing three "embedded-ps" stencil expressions with the SVG backend, you'll get this output instead of a cras

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Mon, Jul 06, 2009 at 07:09:11AM +0200, Werner LEMBERG wrote: > > and I'm not certain that we have enough Frogs to eat all the issues > > that would be added if we went this route. > > Perhaps it makes sense to classify regression tests like this: > > a) intentionally emit warnings and errors

Re: [PATCH v2] Fix crash when a stencil routine is missing

On Mon, Jul 06, 2009 at 09:37:19AM +0200, John Mandereau wrote: > Le dimanche 05 juillet 2009 à 18:01 -0700, Patrick McCarty a écrit : > > On Sun, Jul 05, 2009 at 05:39:45PM -0700, Graham Percival wrote: > > > -dwarning-as-error > > > looks fine to me. > > > > I think Han-Wen suggested to enable t

Re: [PATCH v2] Fix crash when a stencil routine is missing

Le dimanche 05 juillet 2009 à 18:01 -0700, Patrick McCarty a écrit : > On Sun, Jul 05, 2009 at 05:39:45PM -0700, Graham Percival wrote: > > -dwarning-as-error > > looks fine to me. > > I think Han-Wen suggested to enable this option for the entire > regression test suite, so adding this option to

Re: [PATCH v2] Fix crash when a stencil routine is missing

>> In other words, some makefile hacking is needed, which I would >> probably need to delegate. I agree. > I doubt that the regtests compile without warnings, Correct. Some of them are even expected to emit warning or error messages. > and I'm not certain that we have enough Frogs to eat all t

  1   2   >