Re: Exited with return code -1073741819.

[David Wright]

On Wed 02 Nov 2016 at 07:44:29 (+1100), Andrew Bernard wrote:
> I am not sure for whom you mean error prone - the user, or the compiler.

The user. Constructions like   seq 1 10   (eg, in bash) are designed
to avoid the need for   1 2 3 4 5 6 7 8 9 10. Computers are good at
this, humans aren't. We slip up. Compilers don't.

> It seems like after many many repetitions of the variable constructs
> representing each bar lilypond just loses the plot and runs out of
> resources. It's probably a really obscure bug. It's a use case hardly worth
> testing, it being so unusual.

That may well be the problem, but it ought to detect the fact and say so.

> I could not see what the fixes were from your email David, unless I am
> missing an attachment. What did you do to make this work?

Three or four global replacements for the RHS variables,
a few copy&pastes to fill in the "borrowed" parts like \expandVar \sop 23 38
then a macro to erase the LHS variables and their = sign.
I left the redundant braces around each bar.

> -----Original Message-----
> From: David Wright 
> Subject: Re: Exited with return code -1073741819.
> 
> Well, the reasons were given in
> http://lists.gnu.org/archive/html/lilypond-user/2016-03/msg00609.html
> but I can't see that a construction like
> 
> sop.12 = \sop.1
> sop.13 = \sop.1
> sop.14 = \sop.1
> sop.15 = \sop.1
> sop.16 = \sop.5
> sop.17 = \sop.1
> sop.18 = \sop.1
> sop.19 = \sop.1
> sop.20 = \sop.1
> sop.21 = \sop.5
> 
> is any less error-prone than
> 
> R1 * 5 \break
> R1 * 5 \break
> 
> nor can I imagine that it involves any less copy&paste, unless all the sop
> sop sop stuff was actually typed in. At least the source is not obfuscated,
> which it was last time.

Cheers,
David.

wow.ly
Description: Text document