[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jean Abou Samra
Subject: Re: C++ question on wrapper API for setting Guile fluids
Date: Thu, 21 Apr 2022 10:51:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]