lilypond-devel
[Top][All Lists]
Advanced

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

Re: untangling the remaining regressions


From: David Kastrup
Subject: Re: untangling the remaining regressions
Date: Tue, 13 Aug 2013 11:41:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Mike Solomon <address@hidden> writes:

> On 13 août 2013, at 11:59, David Kastrup <address@hidden> wrote:
>
>> It's window dressing on bugs if the design does actually work properly,
>
> That's exactly what this is, but it allows us to isolate the bug and
> put a big TODO.

I don't see that it allows us "to isolate the bug" and it puts yet
another layer of unfinished code in.

>>> I can do this tonight - does this sound like a reasonable
>>> middle-ground solution?
>> 
>> No.  Two half-solutions don't make a full one.
>> 
>
> Conceptually, in the previous code, Scheme functions combed through a
> slew of hard-coded lists in order to determine if a grob was pure
> relevant.  I am proposing making this one property, which allows us to
> keep the new system.

No, that is not what you propose.  You propose keeping the replacement
for the old scheme _and_ tacking _another_ replacement for it on top
that should not be there in the first place since it is _supposed_ to be
tackled completely by the first replacement.

I repeat: either the redesign is sound, and then we want to get it
fixed.  Or it is broken, then we want it taken out.  But we don't want a
mashup of two broken half-implementations.

> That seems more elegant than the previous implementation.

But we are not talking about replacing the previous implementation but
rather about fixing the current implementation.  And you propose that we
should not really fix the current implementation right now but rather
drag in the old implementation _additionally_, just in the disguise of
yet another implementation.

> Then, the only remaining task is improving pure-property calculations
> so that they don't trigger unpure calculations.

Mike, we have enough unfinished code around as it is.  We don't need a
whole reimplementation of old code for the sole purpose of temporarily
masking bugs with the new implementation by retro-fitting a distant
clone of the old implementation on top of the unfixed new
implementation.

And you propose that as a measure to _speed_ up getting a hold of
problems with the new implementation.

Software does not work like that.

-- 
David Kastrup



reply via email to

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