Re: How to debug std::bad_alloc
Le 12/06/2013 20:45, Jean-Charles Malahieude disait : Hi all, I've typeset BWV246 and printed an Urtext version without any problem. A modern version spits me (version 2.17.20) terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc For anyone interested, a tarball of the sources is available on demand (87ko). As soon as I add another score to number 42, I get this very message, and invoking with -l DEBUG is of no help for me. TIA, Jean-Charles ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Weird Stems with beam::align-with-broken-parts and beam::slope-like-broken-parts
Hi,
the following code returns missing Stems.
(A larger example would show not only missing but also all sorts of weird Stems.
see:
http://lists.gnu.org/archive/html/lilypond-user/2013-06/msg00334.html
)
%%
\version 2.17.20
\paper {
%indent = 0
ragged-right = ##t
}
\layout {
\override Beam #'breakable = ##t
\override Beam #'positions = #beam::align-with-broken-parts
%\override Beam.positions = #beam::slope-like-broken-parts
}
\relative c' {
c2.. c''8[ \break
a,] r c2.
}
The terminal returns:
warning: weird stem size, check for narrow beams
c2..
c''8[ \break
warning: Not drawing a box with negative dimension, 0.13 by -0.24.
Some observations:
1)
The bug is triggered if only _one_ beamed Stem is present before line-break.
Two or more beamed Stems make the bug disappear:
\relative c' {
c2. c''8[ c \break
a,] r c2.
}
works always nice.
2)
The relevant regtest beam-broken-classic.ly doesn't test this case
(i.e. only one beamed Stem before line-break)
3)
When uncommenting `indent = 0' no warning is printed to the terminal,
though the printed output is still worse.
4)
With \override Beam.positions = #beam::slope-like-broken-parts no
terminal-output appears, though the pdf is bad, too.
5)
The bug is present in 2.16.2, too.
Cheers,
Harm
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: How to debug std::bad_alloc
Jean-Charles Malahieude lilyfan at orange.fr writes:
terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc
I think I've narrowed the problem to a particular score which, when
alone, compile fine.
LilyPond asks for more memory than your computer has. The reason the
changes you describe would cause her to need more memory are not clear
to me.
My only suggestion is to use \bookpart{} to divide the book into smaller
sections for page-breaking, and maybe use the minimal page breaking
method if you are not depending on LilyPond to choose the page breaks.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: If incipit has soprano clef, its staves are not aligned with main score
David Kastrup dak at gnu.org writes:
Thomas Morley thomasmorley65 at gmail.com writes:
As a work-around you could add:
\override Staff.Clef #'Y-extent = #'(0 . 0)
I am actually rather appalled that there seems to be no easier way to
keep instrumentName from getting centered with disregard to its
baseline. It would seem that this would be a reasonably common use case
(not just with a \score markup but also with other potential material).
It is also strange that we have a command to override both X and Y
extents of a markup completely, but nothing that would override less.
Thomas' seems pretty easy? You can also override one dimension only of
the instrument name.
incipit = \markup \score {{\clef soprano s4 \bar } \layout{} }
\new Staff \with {
\override InstrumentName #'Y-extent = #'(-4 . 4)
instrumentName=\incipit
} { g'1 }
The bug report remains, though, that someone expected a (generalized)
InstrumentName to be aligned on its baseline, whereas it is centered.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: If incipit has soprano clef, its staves are not aligned with main score
Keith OHara k-ohara5a5a at oco.net writes: The bug report remains, though, that someone expected a (generalized) InstrumentName to be aligned on its baseline, whereas it is centered. The primary use of InstrumentName is to print the instrument name, and we would rather have the text centered than have its baseline centered. (Maybe another reason to shift the baseline to the center of the ex-height?) So I think the behavior is what we want overall, but maybe we should put one of the Y-extent overrides in the examples that put an incipit in the Instrument Name. I suggest this be a documentation request; any project member please open an item if you agree, complain if not. I'll open a doc suggestion in a few days if my opinion remains the same. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
