2017-07-28 1:16 GMT+02:00 Guy Stalnaker <jimmyg...@gmail.com>:
> Simon,
>
> That was my tack -- the dirty way was to slowly comment out sections and see
> what happened. It's the oddest thing. I'm writing a piano reduction mostly
> from string parts, so I'm doing this:
>
> <lilypond>
> pianoRH = {
> << { ViolinI } \\ { ViolinII } >>
> }
> pianoLH = {
> << { Violo } \\ { Cello } >>
> }
> </lilypond>
>
> As shown, did not compile. Comment out ViolinI, compiles. Add it back,
> compile fails. Comment out ViolinII, compiles, add ViolinII back, compile
> fails. WTH? So, I think you're right, it's some sort of memory/resource
> something.
>
> But ...
>
> I replaced the ViolinI code with the original code (from the composer) AND
> IT NOW COMPILES in its entirety.
>
> That is maddening. But, I've no time to waste on it now, and thankfully I've
> little hair to pull out over it.
>
> Thanks for your reply, MUCH appreciated.
>
> Guy
>
> On 7/27/2017 6:06 PM, Simon Albrecht wrote:
>>
>> On 28.07.2017 00:55, Guy Stalnaker wrote:
>>>
>>> I'm not trying to figure out how to do something here. This is a code
>>> file that compiled to midi/pdf output a few hours ago (last successful pdf
>>> output at 4:31p CDT).
>>
>>
>> Can you restore the file version that compiled successfully? Or is there
>> any other chance of narrowing down the part of the code that’s problematic?
>> There have been problems with memory that are triggered by the size of the
>> score, but IIRC those had three-digit page numbers.
>>
>> Best, SimonOccasionally I had smiliar problems, with files I was working on. Eventually I must have added some whitespace-characters at unfortunate place without noticing. Because it worked again after doing "Remove Trailing Whitespace" (provided by my editor). Cheers, Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
