RE: Error Code

[Mark Stephen Mrotek]

Arron, 

Thank you for the new methodology. I shall use it in the future.
The score is a movement (heavily ornamented) from a Mozart Piano Sonata
(K311). It is not much more than 80 measures.
The error does seem to come and go, once with the slur notation, once with
the beaming notation.
It has not appeared in any other of the piano scores that I have coded.

Again, many thanks for you care, concern, and thoughtful reponse.

Mark

-----Original Message-----
From: lilypond-user
[mailto:lilypond-user-bounces+carsonmark=address@hidden] On Behalf Of
Aaron Hill
Sent: Monday, January 27, 2020 9:39 PM
To: address@hidden
Subject: Re: Error Code

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