lilypond-devel
[Top][All Lists]
Advanced

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

Re: simple-spacer: inappropriate assert; issue 4448 (issue 249820043 by


From: David Kastrup
Subject: Re: simple-spacer: inappropriate assert; issue 4448 (issue 249820043 by address@hidden)
Date: Sun, 21 Jun 2015 07:07:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

"Keith OHara" <address@hidden> writes:

> On Fri, 19 Jun 2015 23:59:11 -0700, <address@hidden> wrote:
>
>>
>> https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc
>> File lily/simple-spacer.cc (right):
>>
>> https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc#newcode199
>> lily/simple-spacer.cc:199: programming_error ("misuse of expand_line");
>> Any sensible fallback behavior for this "misuse of expand_line"?  If we
>> can reliably guess what the intent of the "misuse" is (after all, it
>> would appear that the situation comes about from reasonably regular
>> input rather than explicit user error), one could just do that and
>> forget about the programming error.
>
> These two asserts cannot be triggered in current code, except maybe
> through roundoff error, because the only calls of the function are
> protected my matching conditionals in Simple_spacer::solve()
>
> The third assert is the one that trips (windows-only).
>
>
>> Is there something reasonably "continuous" one can do so that small
>> errors lead to small offsets?
>
> The following line obviously returns a quantity that changes
> continuously across the assert condition,
> so I am 90% sure you are defying national stereotypes and using irony.

I'll take the 10% option where I did not actually look at the code with
enough detail to see that.

> In that case, yes, I do think the behavior that was being protected
> against is so benign that there need be no traps at all for these
> conditions.

Even a slight aberration can ruin a subsequent loop relying on sorted
input.  I have not looked at the following code enough to see whether we
have that kind of situation relying on monotonicity here.

If we don't, ditching the warning seems like the easiest course.

-- 
David Kastrup



reply via email to

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