Re: Error Code

[Aaron Hill]

On 2020-01-27 7:07 pm, Mark Stephen Mrotek wrote:
> I am still flummoxed by this matter. I have extracted both into small
> snippets. In both cases they compile. Yet when I add them to the full 
> score
> the one with "(...)" throws the error.
> I have removed code to the last known clean complication. Then each
> subsequent line was added to confirm compilation. Each time it worked. 
> It is
> only the last line - with the addition of the "(...)" that the error is
> thrown.

Adding a little in at a time until failure might not be the best way to 
go about isolating an issue.  Think of it like a bridge where you are 
adding objects one at a time.  When the structure finally collapses, you 
would not normally assign total blame to the last object that was added. 
 Rather it would be the collective weight of all objects that matters.

The divide and conquer approach, on the other hand, is often much more 
useful.  Start with a score that fails.  Divide the musical content into 
two halves and compile each individually.  If just one half compiles 
successfully, then you can safely discard that content as not relevant 
to the issue.  For the half that still fails, repeat the same process, 
further subdividing it.

When the two halves both compile successfully on their own, then you 
know there must be an important interaction between them, so you cannot 
discard either in its entirety.  In that case, put the halves back 
together and try dividing them in another manner.  Sometimes you will 
have to go line by line, commenting out parts of the score, to determine 
what matters.  This is the opposite of your strategy.  We are not slowly 
adding things until failure, we are slowly removing things until 
success.  Each item that can be removed while still reproducing the 
failure likely is irrelevant and can be discarded.

Ultimately, what you are left with is the minimal working example.

----

How "full" is your full score?  There are known limitations with the 
32-bit Windows build of LilyPond where the process can run out of memory 
trying to compile certain scores.  This is simply because a 32-bit 
process can only access up to 2GB* of memory, even when running on a 
64-bit operating system with extra physical RAM installed.  On Windows, 
you can use the built-in Task Manager (or better yet Sysinternals' 
Process Explorer) to monitor the memory usage of a process.

(* 32-bit applications that are specifically built as "large address 
aware" are able to access up to 3.25GB of memory.)

If you suspect you might be hitting the memory limit compiling your 
entire score, try breaking it up into sections and compiling each 
individually.  You should find that each section will compile 
successfully on its own, then only requiring of you to stitch the 
results together for the final product.  When limited to the 32-bit 
build of LilyPond, this is the only workaround for large projects.

Of course, the 64-bit build of LilyPond likely would be able to compile 
a large project without manual intervention.  On Windows, this could 
mean running the Linux-64 build of LilyPond either from the Windows 
Subsystem for Linux (WSL), a Docker container, or a hosted virtual 
machine running Linux.


-- Aaron Hill