Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit :
On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra <j...@abou-samra.fr> wrote:
I am working on code that pervasively utilizes Guile fluids. They should
be set in dynamic scopes.
That sounds scary. Care to tell more?
What is scary about it exactly?
I am trying to reimplement purity in terms of fluids, so the set of
parameters is not hardcoded to 'start, end' and all the code doesn't
have to be littered with functions working both as pure and impure and
forwarding start/end to the property callbacks they cause. Essentially,
this should look like { Dynwind_context dwc; dwc->make_assumption
(Lily::prebreak_estimate, SCM_BOOL_T); ... get_property (grob,
"property") ... } or in Scheme: (under-assumptions ((*prebreak-estimate*
#t)) ...) and by virtue of the dynamic context, the callback that
computes the grob property understands that it should do pure estimates.
The property then gets cached if it doesn't depend on assumptions, or if
it only depends on *prebreak-estimate* (in that case with two cached
value, prebreak and postbreak), but not if the callback uses
*prebreak-estimate-start* or *prebreak-estimate-end*. I'll have to
experiment with caching strategies, but this is the current idea. The
advantage is that 95% of code that needs to interact with purity (via
ly:make-unpure-pure-container, get_maybe_pure_property, etc.) no longer
needs to do so. Purity becomes a very localized thing and no longer
pervades the code base. It can also be worked on more easily; my work on
https://gitlab.com/lilypond/lilypond/-/merge_requests/744 involves
introducing pure widths, and I don't want to add maybe_pure_x_extent and
change hundreds of callbacks so they do maybe_pure_x_extent instead of
extent ( X_AXIS). There is the same need in order to properly implement
functionality demonstrated in a recent -user thread
https://lists.gnu.org/archive/html/lilypond-user/2022-04/msg00062.html
where LyricText.X-offset needs a pure/unpure distinction in order to
avoid after-line-breaking. Also, since whether callbacks access start
and end is now known, pure properties that depend on whether the call is
pure or not but not on start and end (namely the vast majority of them)
can start getting cached. Right now, we use a trick to cache item pure
heights, assuming that Y-extent/Y-offset does not depend on start/end
for items (Item::pure_y_extent). This can then be done for spanners as
well. I haven't gotten as far as a working proof of concept, but I
expect a speedup. This is essentially a remix of an idea from David:
https://lists.gnu.org/archive/html/lilypond-devel/2015-05/msg00397.html
Jean
