Re: C++ question on wrapper API for setting Guile fluids

[Jean Abou Samra]

Not sure why my message got mangled? Resending, properly formatted.


Le 21/04/2022 à 10:51, Jean Abou Samra a écrit :
> Le 21/04/2022 à 10:38, Han-Wen Nienhuys a écrit :
> > On Thu, Apr 21, 2022 at 12:04 AM Jean Abou Samra <jean@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