Le vendredi 25 décembre 2009 à 22:17 +, Graham Percival a écrit :
> The regtests are not used in the docs. Period.
>
> It's possible that a new feature might a file in
> Documentation/snippets/new/ which is an exact copy of a new
> regtest (actually, I've encouraged this), but we don't have m
On Fri, Dec 25, 2009 at 11:21:17AM +0100, John Mandereau wrote:
> Le jeudi 24 décembre 2009 à 22:21 +0100, Reinhold Kainhofer a écrit :
> > I would definitely like that option. Every now and then, when working with
> > lilypond-book based projects, I also need to send e.g. an image per mail or
>
On Fri, Dec 25, 2009 at 11:02:03AM +0100, John Mandereau wrote:
> Le jeudi 24 décembre 2009 à 20:52 +, Graham Percival a écrit :
> > I can now confirm that the regtest comparison is done on the files in
> > input/regression/out-test/ , which are created via "make test".
>
> More precisely, the
Le jeudi 24 décembre 2009 à 22:21 +0100, Reinhold Kainhofer a écrit :
> I would definitely like that option. Every now and then, when working with
> lilypond-book based projects, I also need to send e.g. an image per mail or
> insert an image into some word-processing app. In these cases, such an
Le jeudi 24 décembre 2009 à 10:18 -0800, Patrick McCarty a écrit :
> Thank you for noticing this, John. I'll admit I did not think through
> the issue carefully enough when I made that commit.
>
> I'm not qualified to comment on your patch to fix the issue, but I
> trust your judgment here.
OK,
Le jeudi 24 décembre 2009 à 19:30 +, Graham Percival a écrit :
> Ah, we're talking about two different kinds of hashes. One hash
> decides if the snippet should be (re)processed -- I don't care
> about that one. Do whatever seems sensible for that.
>
> The other kind of hashing produces the
Le jeudi 24 décembre 2009 à 20:52 +, Graham Percival a écrit :
> I can now confirm that the regtest comparison is done on the files in
> input/regression/out-test/ , which are created via "make test".
More precisely, the comparison is done between
input/regression/out-test/ and input/regressio
Am Donnerstag, 24. Dezember 2009 21:52:10 schrieb Graham Percival:
> If the files in those directories had names corresponding to their
> actual regtest file names, then the regtest comparisons would be more
> robust against changing lilypond-book options. I'm not certain
> whether this would be b
On Thu, Dec 24, 2009 at 7:30 PM, Graham Percival
wrote:
>> 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?).
>
> I think it's actually via "make test", following by tarring the
> produced input/r
On Thu, Dec 24, 2009 at 01:06:19AM +0100, John Mandereau wrote:
> Le mercredi 23 décembre 2009 à 23:17 +, Graham Percival a écrit :
> > Yes; that's why we changed the hash calculation from self.ly() to
> > self.full_ly()
>
> You meant the opposite.
err, yeah.
> > -- produced lily-abcd1234
2009/12/23 John Mandereau :
> Hi guys,
>
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impact on music typesetting
Le jeudi 24 décembre 2009 à 03:28 +0100, Francisco Vila a écrit :
> Now I understand why I had to touch the music itself to make snippets
> regenerated on a set of exercises.
I hope my patch on Rietveld will completely fix this:
- all fragment options are taken into account in the hash, so a chang
2009/12/23 John Mandereau :
> Hi guys,
>
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impact on music typesetting
2009/12/23 John Mandereau :
> Hi guys,
>
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impact on music typesetting
Le mercredi 23 décembre 2009 à 23:17 +, 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 rel
On Thu, Dec 24, 2009 at 12:05:32AM +0100, John Mandereau wrote:
> Le mercredi 23 décembre 2009 à 22:45 +, Graham Percival a écrit :
> > Remember why we did this: the regtest filenames weren't matching
> > up between versions because the [options] changed.
>
> Sorry for having been idle at that
Le mercredi 23 décembre 2009 à 22:45 +, Graham Percival a écrit :
> Remember why we did this: the regtest filenames weren't matching
> up between versions because the [options] changed.
Sorry for having been idle at that time, but regtest comparison
shouldn't prevent us from changing lilypond-
On Wed, Dec 23, 2009 at 08:55:23PM +0100, John Mandereau wrote:
> In my way of fixing lilypond-book hashing, I'm afraid I'll have to
> revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
> md5 hashing strategy", because ignoring fragment options for the hash
> which have an impac
Hi guys,
In my way of fixing lilypond-book hashing, I'm afraid I'll have to
revert 4c5a581ca25398669b9ecbc7a606febb09e60214 "lilypond-book: Change
md5 hashing strategy", because ignoring fragment options for the hash
which have an impact on music typesetting is wrong. I'll not simply
revert that
19 matches
Mail list logo
