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

[Jean Abou Samra]

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