[Top][All Lists]

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

Re: New read/eval Scheme syntax inconsistent in handling existing code

From: David Kastrup
Subject: Re: New read/eval Scheme syntax inconsistent in handling existing code
Date: Mon, 21 Nov 2011 21:35:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

Valentin Villenave <address@hidden> writes:

> On Mon, Nov 21, 2011 at 7:39 PM, David Kastrup <address@hidden> wrote:
>> A bug that made it through the reviews, nothing inherently bad about
>> the design.  Thanks for the test example, by the way.
> Yes, it looks probably a bit far-fetched but said bug did break all of
> my scores! (Hence the disruption thing.)

Could you recheck with current staging?  It would appear that you are in
possession of the most comprehensive test suite available...

>> The above file works fine with current staging.  Since you, as
>> opposed to the Lilypond code base, appear to make extensive use of
>> ly:parser-include-string, you might want to consider contributing a
>> few regression tests capturing the essence of your usage patterns.
> That's what I wanted to know: since parser-include-string was
> originally implemented upon a request of mine, I wasn't sure it was
> considered vanilla LilyPond syntax and supported as such.

I don't throw out functionality as a rule.  ly:export was an exception
to that rule because its presence was fundamentally incompatible with
maintaining predictable timing for #.  But I backed up this step with a
set of convert-ly rules of rather high quality and coverage (including
the entire Lilypond code base).

> Do you think this warrants a regtest of its own, or should it rather
> be added to include-string.ly?

I think extending include-string.ly is ok.  I am somewhat surprised that
it did not trigger, actually.

David Kastrup

reply via email to

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