lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lilypond-book is hosed


From: John Mandereau
Subject: Re: lilypond-book is hosed
Date: Thu, 24 Dec 2009 01:06:19 +0100

Le mercredi 23 décembre 2009 à 23:17 +0000, Graham Percival a écrit :
> Yes; that's why we changed the hash calculation from self.ly() to
> self.full_ly()

You meant the opposite.


>   -- produced lily-abcd1234 filename would not
> depend on the fragment options,

This is wrong.  lilypond-book relies on hashing to decide whether a
snippet should be (re)processed by lilypond, so framgent options that
change processing by lilypond must be taken into account in the hash;
that's why I started this thread to announce we should revert the commit
4c5a581ca25398669b9ecbc7a606febb09e60214 in some way.  If we don't, then
we can happily ignore all lilypond-book fragment options that have an
impact on lilypond processing, as we won't ever be sure that they will
be really respected by lilypond-book/lilypond :-)


> I mean not using xx/lily-xxxxxxx.ly files for the regtests.
> Instead, use files of the form:
>   out/lybook-db/regtest/xxxxxxxxxxxx.ly
> where the filename is used directly.  Like:
>   out/lybook-db/regtest/ancient-accidental.ly
>   out/lybook-db/regtest/slur-broken.ly
>   out/lybook-db/regtest/tuplet-numbers-avoid-slurs.ly

This is doable and interesting to do for writing files in
input/regression/out-www, but this makes no sense in out/lybook-db,
where files should have a name predictable by lilypond-book (namely
obtained using a hash), so it can decide for each snippet whether it's
already been compiled or not.



> ?  All that will happen is that if somebody modifies a regtest
> (like adding an additional bar to slur-broken.ly), that regtest
> will show up in the regtest comparison for the next version.  On
> average I think that adds 3-4 images per release?

You misunderstood me.  I was afraid that the regtest comparison script
would issue false positive differences because of a change in
lilypond-book hashing, but maybe this fear is purely virtual.


> The regtest naming issue should be fairly simple: add a new option
> to lilypond-book that turns off the snippet hash calculation.
> Wherever hash(self.ly()) is called, check the option and return
> the filename if it's set.

No, as I argumented at the beginning of this message, this would
completely break the idea of a shared snippet database.  However, a
lilypond-book command-line option to write nice filenames in
input/regression/out-www is fine, and will achieve what you explained
above (regtest comparison is based on input/regression/out-www or its
mirror in out-www/offline-root, right?).


>   Modify the stepmake/stepmake/ or
> input/regression/GNUmakefile to add this option.  Etc.

OK for this point.


> If you're not intersted, please add this to the issue tracker, and
> I'll tackle it once I'm done the website.

The problem is not that I'm not interested, but rather that I don't know
the scripts that generate regtest comparison (so I don't know exactly
what was the problem with 'make check'), while I'd like to make sure the
efficiency of a shared snippet database for lilypond-book works well and
is preserved.

Best,
John

Attachment: signature.asc
Description: Ceci est une partie de message numériquement signée


reply via email to

[Prev in Thread] Current Thread [Next in Thread]