Don't reload initialization files when processing multiple files

Don't reload initialization files when processing multiple files

There should probably be something approaching an option for that.  It
should mostly speed up the regtests.  It helps "make doc" less than
expected, but probably still some.

[Graham Percival, 2012-03-22 03:43:47]

This feels like a dangerous change.  Obviously we don't /want/ "bleed-through"
of parameters or memory from one file to the next, but I would be shocked if we
don't have any of that right now.  I also have vague memories of some problems
with this in the past.

I guesstimate that not reloading init files will expose 2-5 critical regressions
even after the regtests themselves compile ok.  Note that I use the word
"expose", not "create" or "cause" -- the bugs are there already.  We'll just get
reports dribbling in over a few weeks.

If you want 2.16 to be as good as possible, then speeding up the regtest compile
and exposing those potential bugs is certainly a good thing.  If you want 2.16
to be out soon, then you may want to consider sitting on this patch until 2.16
is out.  I'm content with either option.

[dak, 2012-03-22 09:14:34]

On 2012/03/22 03:43:47, Graham Percival wrote:
> This feels like a dangerous change.  Obviously we don't /want/ "bleed-through"
> of parameters or memory from one file to the next, but I would be shocked if
we
> don't have any of that right now.

Don't overestimate the issue.  What is involved here is bleedthrough from
init.ly, namely from one parser incarnation to the next.  Any bleedthrough in
scm is left unchanged.

It turns out that
git grep hash ly
appears surprisingly sufficient for diagnosing the bleedthrough we are actually
seeing.

Bleedthrough is from destructively changed data.  That means hashtables need to
be either unchanged by user code, or reset each time.  The same holds for
everything else of course, like destructively modified alists and output
definitions and what else.

But there is a rather surprising absence of those.

> We'll just get reports dribbling in over a few weeks.

I doubt it.  The only situation where bugs can show is when multiple files are
being compiled at once.  That is not the usual command line usage.  So reports
can be basically about

a) documentation differences
b) problems with lilypond-book documents

I doubt we'll get to see anything outside of lilypond-book usage.  Note that we
already have bleedthrough potential in .scm (which we apparently managed to keep
under control).

My original plan was to split the various init files into parts that need to be
rerun every time, and parts that can be preloaded once.

But it turned out that the "need to be rerun" stuff basically concerned output
definitions, and cloning them looked feasible.

[Graham Percival, 2012-03-23 04:08:12]

On 2012/03/22 09:14:34, dak wrote:
> Don't overestimate the issue.  What is involved here is bleedthrough from
> init.ly, namely from one parser incarnation to the next.  Any bleedthrough in
> scm is left unchanged.

ah, I misunderstood that part.  Ok, in that case I feel much better about the
patch.  :)

[Julien Rioux, 2012-03-23 11:32:29]

LGTM