[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: untangling the remaining regressions
From: |
Mike Solomon |
Subject: |
Re: untangling the remaining regressions |
Date: |
Thu, 22 Aug 2013 11:34:55 +0300 |
On 22 août 2013, at 11:19, "Keith OHara" <address@hidden> wrote:
> Positioning properties like 'Y-offset' are often linked to callback
> functions. When it is time to place a grob, LilyPond calls that function and
> stores the result in the property 'Y-offset', overwriting the link to the
> callback function.
>
Yup.
> Sometimes, most notably during line/page-breaking, we want *hypothetical*
> positions: where a grob would be placed *if* line-breaking put paper-columns
> 'start' through 'end' on one line. We do not want to evaluate every
> positioning callback, and even if we did there is no mechanism to restore all
> the links to the original callback functions, so we use estimates of
> positions through 'pure' functions. 'Pure' functions can look up a
> 'Y-offset' if it is data, but are not usually permitted to use a callback
> function. There are utility functions named maybe_pure_*() that look up
> properties that are data, but refrain from using most callbacks. The
> exceptions, callbacks that may be evaluated, were previously enumerated in
> lists; now they are simply those functions wrapped in an
> unpure-pure-container. When such a container is accessed through a 'pure'
> function-call, its return value is *not* stored in the grob property, so the
> link to the unpure-pure-container remains in place for the next use.
>
Yup, with the notable sort-of-exception of Items' pure height, which is cached
and reused to speed up computation time.
> 'pure' could now mean simply: this function promises to change no grob data.
> It may cache data, and perform output, and other procedural things, so long
> we retain our ability to evaluate more hypothetical layouts.
>
Agreed in the big picture and I think it'd be good to come up with rules to
test for this during debugging.
In LilyPond terms, we do not want "set_property", "set_object", "suicide" or
"translate_axis" ever called as the result of the evaluation of a pure
function. set_property, set_object, suicide and translate_axis are evil
expedients, as they often break the LilyPond callback model. Whenever
something goes wrong with the new skyline code, they are called somewhere.
> The various functions labeled pure do not all keep this promise. (My
> struggle today was using pure_vertical_stencil_from_extents on a
> note-column, and finding it set the cross-staff beam position, through
> various paths.) The code before Mike's two big commits does not seem perfect
> in this regard either.
Yup, this has been a problem for a while but has been hidden.
>
> 'cross-staff' marks grobs whose positioning (relative to their parent)
> depends on the spacing of staves on the page.
Yup.
> These grobs have to be positioned last, after all grobs moving with their
> parent Staff are positioned relative to him, and staves are spaced. There is
> not an overarching mechanism to enforce this timing.
Nope.
> Positions of cross-staff grobs could be estimated (and sometime are through
> 'pure' function calls) but they are most often ignored.
This is the basis of all my stub work (SlurStub, etc.).
>
> All non-cross-staff grobs must find their positions while the positions of
> cross-staff grobs remain hypothetical.
Yup.
> That is, any positions callbacks for a non-cross-staff grob may use only
> 'pure' functions to access properties of cross-staff grobs.
Yup.
Excellent e-mail! Worth archiving and reading for future developers.
~Mike
- Re: untangling the remaining regressions, (continued)
Re: untangling the remaining regressions, David Kastrup, 2013/08/13
Re: untangling the remaining regressions, Keith OHara, 2013/08/22
- Re: untangling the remaining regressions,
Mike Solomon <=
Re: untangling the remaining regressions, David Kastrup, 2013/08/22