Re: Size of test output binaries has doubled

[Graham Percival]

On Sat, Jul 18, 2009 at 09:14:40PM -0600, Carl Sorensen wrote:
> In preparing information on regression testing for the Contributors' Guide,
> I happened to check the downloadable regression test results at
> 
> http://lilypond.org/download/binaries/test-output/
> 
> I noticed that prior to 2.13.2 the test results were approximately 70-80 MB.
> 
> For 2.13.2 and 2.13.3, the results are approximately 136 MB.
> 
> Is this an intended (or understood) behavior, or is it a bug of some sort?

Well, it happened when I started making releases.  We /have/ been
adding a lot of regtests recently, but I don't imagine that there
were _that_ many between .1 and .2.

My initial guesses:
- GUB uses the system's convert (imagemagick) or pnmtopng or
  something like that, and kainhofer has a different version of
  those files than Han-Wen's system.  (and the other version has
  poorer compresson)
- 64-bit CPUs naturally produce larger png files.  (hey, I didn't
  say these were all *good* guess.  ;)
- Seriously: GUB might be adding extra files to the tarball...
  maybe a "make clean" somewhere is failing, resulting in a bunch
  of intermediate files being included?

I'd encourage any interested parties to compare the files in the
.1 and later tarballs, and to compare the filesizes.  Remote
debugging from Vancouver to Germany is a pain, and in any case I'm
at a music camp starting in 12 hours, so I won't be looking at
this soon.  (if it's still a problem in Sep, I should have a
desktop computer available, so debugging GUB will be *much*
easier)


The steps I take are outlined at the end of
Documentation/devel/release-notes.itexi, with the following
additions:

- checkout commit c1645812f5c2707640961085cdccc77d27dffccb
  (later versions seem to have some instability with git
  downloads)
- apply the attached patch.  Yes, it's a marvel of bad python, but
  I couldn't change m.group(2) or find out how to make a new
  "group" (or whatever variable type m is) within 10 minutes.
  (random python annoyance: when I do "print m", I want
  information about that variable.  Don't tell me a memory address
  or something like that -- that's what perl would do!)

  better solution: revert change to output -HEAD instead of -1 (or
  whatever the build number is).  Patches appreciated.

Cheers,
- Graham