On 22 août 2013, at 11:19, "Keith OHara" <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
