[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: segfault in grob.cc
From: |
John Galbraith |
Subject: |
Re: segfault in grob.cc |
Date: |
Tue, 5 Jun 2001 00:20:59 -0600 (MDT) |
package included in Debian 2.2. My guess is that the Python program
changes the max stack size of its own process and this setting is
then inherited when you call system(). I haven't checked the source
code, though. I can also confirm that it helps to increase the
limit. Great, this problem has been bugging me for quite some time.
Yeah, I can remember a weird crash like this one from over a year ago. I
don't remember how I worked around it at the time, but it could be the
same issue.
> > What is the largest score that has been processed with lilypond so
> > far? Mine is 830 measures of a score with 12 parts. Not quite a
> > Mahler symphony, but pretty big.
The one I had problems with was a bit smaller than the Coriolan,
so you probably have the biggest Lilypond score so far. The good
news is that there's no inherent limit in the program itself, the
bad news is that you need lots of RAM unless you're willing to
wait a night or two for the computer to swap memory back and forth.
I hope you've seen the property Score.skipTypesetting which can be
used to speed up the turn-around time while you correct the errors
in a score.
Well, when I made the first version of this score a year ago I didn't
know about skipTypesetting. It may not have existed yet. Instead,
I had this big python hack that would assemble the parts of the score
I was working on. At the time, I had each part divided into a bunch of
sections that would eventually be concatenated together. The advantage
of that was that the relative octave was reset all the time, so I didn't
end up with parts four or five octaves off (pretty easy to do with a
score that long). It was also easier to just process part of the score.
The big problem with it was that lilypond would report error line numbers
that were totally useless to me because it wasn't actually processing the
file that I was editing.
I don't exactly know how I will do my next big composition. I know that
it won't be with that python hack, though.
John
Re: segfault in grob.cc, Han-Wen Nienhuys, 2001/06/03