Calculate wordwrapped/justified lines using the stencil stacking primitives

Calculate wordwrapped/justified lines using the stencil stacking primitives

In that manner, the spacing decisions are sure to be correct.

[janek, 2013-09-24 07:46:17]

could you give an example of how it was failing before?

[dak, 2013-09-24 08:53:07]

On 2013/09/24 07:46:17, janek wrote:
> could you give an example of how it was failing before?

Regtests change, and the new regtests seem pretty consistent.  I was not going
to measure this out in detail.  The comments of the old code also spell out a
failure case.  Check out
\markuplist
#(map (lambda (n)
       #{ \markup
            \override #'(line-width . 60)
            \column {
              \override #`(text-direction . ,(if (zero? (remainder n 2)) RIGHT
LEFT))
              \justify { $@(map number->string (iota (quotient n 2))) }
              \draw-hline
            }
       #})
  (iota 160 60))

and you'll see that the old code has problems in the patterns ending on 85 and
104.  Do you have an actual problem with how the new code is written in
comparison to the old code?  I sometimes have a hard time understanding why
people object against refactoring code even when the old code has been prodded
until it happens to turn out the correct thing most of the time without anybody
exactly knowing why.

In this case, it happens to fail sometimes.  The failure case _has_ actually
been described in comments, but the old design of the code made it probably too
cumbersome for anybody to cater for that case.

But assuming that this code would not actually fix anything but lead to
equivalent results: would you object to it?  Can you point out what part in
particular you object to?  Because if there is stuff you don't want to have in
the code base unless it actually fixes something, chances are that you don't
want to have it in the code base either way, and it should be done differently.

"It works" is not the ultimate excuse for everything.  Because if no-one can
understand _why_ it works, then even in the case that it works in 100% of all
cases now, future changes might break it unintentionally when nobody can
understand the reason it works.

Issue 3552 is such a case where I changed code not because of any known
breakage, but because the risk of future breakage in connection with
superficially unrelated and/or user code.

[janek, 2013-09-24 22:01:17]

Hi David,

2013/9/24  <dak@gnu.org>:
> Do you have an actual problem with how the new code is
> written in comparison to the old code?

No, not at all!  I apologize for not making my intentions clearer.  I
asked for an example not because i doubted your patch - i just wanted
to have some output to look at, so that i would understand the patch
better.  I actually haven't read the code yet - as you know, i'm not
fluent with Scheme, and i expected that i wouldn't manage to
understand the patch without having some example.  I'm sorry that my
question made you anxious.

> I sometimes have a hard time
> understanding why people object against refactoring code even when the
> old code has been prodded until it happens to turn out the correct thing
> most of the time without anybody exactly knowing why.

This situation occasionally happens to me as well, and i don't
understand it either.

> But assuming that this code would not actually fix anything but lead to
> equivalent results: would you object to it?

No, absolutely not!  I know that you're a much better programmer that
i am, so unless i'd find something explicitely suspicious (which is
unlikely) i would never object to code refactoring.

> "It works" is not the ultimate excuse for everything.  Because if no-one
> can understand _why_ it works, then even in the case that it works in
> 100% of all cases now, future changes might break it unintentionally
> when nobody can understand the reason it works.

Absolutely!

> Issue 3552 is such a case where I changed code not because of any known
> breakage, but because the risk of future breakage in connection with
> superficially unrelated and/or user code.

That's a good reason to change things.

> On 2013/09/24 07:46:17, janek wrote:
>> could you give an example of how it was failing before?
>
> Regtests change, and the new regtests seem pretty consistent.  I was not
> going to measure this out in detail.  The comments of the old code also
> spell out a failure case.  Check out
> \markuplist
> #(map (lambda (n)
>        #{ \markup
>             \override #'(line-width . 60)
>             \column {
>               \override #`(text-direction . ,(if (zero? (remainder n 2))
> RIGHT LEFT))
>               \justify { $@(map number->string (iota (quotient n 2))) }
>               \draw-hline
>             }
>        #})
>   (iota 160 60))
>
> and you'll see that the old code has problems in the patterns ending on
> 85 and 104.

Thanks, this should help me understand what's going on.
Interestingly, with current master (bfdebcb93bebe820c2d5fd6c1bed) the
pattern ending with 104 appears to be fine.

best,
Janek

[dak, 2013-09-24 22:25:46]

On 2013/09/24 22:01:17, janek wrote:

> > and you'll see that the old code has problems in the patterns ending on
> > 85 and 104.
> 
> Thanks, this should help me understand what's going on.

Without looking at the code, that's not all that likely.

> Interestingly, with current master (bfdebcb93bebe820c2d5fd6c1bed) the
> pattern ending with 104 appears to be fine.

My current "fresh" installed LilyPond at /usr/local/bin/lilypond from which I
reported the behavior is 2.17.23, the main spacing changes were 2.17.19.  There
might have been some fixes to linewrapping after 2.17.23, and/or this might be
related to font metrics.

commit 6e8698dcb9a9b9a98d8b1a644c84fcb737f99bdc
Author: David Kastrup <dak@gnu.org>
Date:   Thu Aug 1 12:20:24 2013 +0200

    Issue 3483: Pango font size should be calculated using rounding

could be relevant here, and it's 2.17.24, indeed later.  Of course, numerical
accuracy can _always_ come into play here and make things differ on different
compilers/libraries/optimization levels, but the probability is rather low.

[janek, 2013-09-24 22:43:24]

2013/9/25  <dak@gnu.org>:
> On 2013/09/24 22:01:17, janek wrote:
>> Thanks, this should help me understand what's going on.
>
> Without looking at the code, that's not all that likely.

uh, my point was that i wanted to see the example before reading the
code so that i can understand the code in the context of the example.
If you've read the autobiography of Richard Feynman, you may notice
that he was doing a similar thing when discussing physical models etc.

I hope to look at the code tomorrow.

>> Interestingly, with current master (bfdebcb93bebe820c2d5fd6c1bed) the
>> pattern ending with 104 appears to be fine.
>
>
> My current "fresh" installed LilyPond at /usr/local/bin/lilypond from
> which I reported the behavior is 2.17.23, the main spacing changes were
> 2.17.19.  There might have been some fixes to linewrapping after
> 2.17.23, and/or this might be related to font metrics.

FWIW, pattern ending with 104 seems ok on 2.17.23
(1ce025d8e1bf93e820270d7ed74fccc48fa4fc64) (output attached)

Janek