Re: anyone notice speed of 2.17.95 on Windows ?

[David Kastrup]

Mike Solomon <address@hidden> writes:

> On Dec 15, 2013, at 12:58 AM, Keith OHara <address@hidden> wrote:
>
>> On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon <address@hidden> wrote:
>> 
>>> On Dec 14, 2013, at 9:35 AM, David Kastrup <address@hidden> wrote:
>>> 
>>>> Most of the contortions seem focused about when or when not and how to
>>>> pass begin/end columns.  It would seem to make sense to turn them into
>>>> dynamic parameters *begin* *end* that you can then query with (*begin*)
>>>> and (*end*).  If (*begin*) returns ##f, we can assume being in a pure
>>>> calculation.
>>>> 
>>>> That would seem to get rid of most of the current interface
>>>> complications.
>>> 
>>> I can see the utility of having one function instead of two for these 
>>> things.
>>> 
>>> The current pure and non-pure functions are often wrappers around a
>>> single internal function that has a bool parameter called “pure”,
>>> so this would eliminate the need for the wrapper functions.
>>> 
>> 
>> The word 'pure' might have too much a connotation as 'good'.  Maybe
>> we should rename 'pure' ->
>> ‘shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me'
>> 
>
> I prefer the second name,

Too verbose.  raw/final would be shorter than pure/unpure.

> with the corollary that pure heights and
> pure anythings are the largest implementation of a basic strategy all
> over the code base, which is:
> elaborate several options
> score them
> pick the one with the highest score
>
> This happens for slurs, beams, ties, and line breaking.  In the case
> of line breaking, the elaboration of the options entails making
> estimates, which is why we calculate pure heights.

>> --
>> The most transparent reorganization might be to have all properties
>> that can hold data use the usual callback mechanism: where the
>> callback function is used just once, and the data it returns takes
>> the place of the callback.
>
> This is indeed transparent, but given that a single object can return
> many pure heights based on the begin/end values being used or based on

Huh? "pure" and "based on the begin/end values being used" seems like a
contradiction.

> how far downstream we are, it’s not clear what this property would
> look like.

For the standard caching, Scheme has "futures", stuff that is evaluated
when forced and then memoized.

What we need here is more like a conditional future, where we memoize
based on met or unmet dependencies.  The only dependency we currently
deal with is "post-break, given start and end columns".

>> The layout engine could use get_property_data() freely, but before it
>> has set line-breaks the layout engine would refrain from calling any
>> callback functions directly.  Instead of a callback for height',
>> layout functions would look up the grob property
>> tentative-height-estimator' where tentative-*-estimators are always
>> functions that take the start-end columns as parameters.
>
> This seems not too far from what we’re doing now, but it adds a lot
> more properties.

I was of the opinion that the tentative estimators (pure) were for the
situation _before_ the line breaking.

>> The tentative-height-estimator for something like a Slur or
>> VerticalAxisGroup would return its best guess for the height, while
>> the estimator for a Clef would simply get_property("height") causing
>> its stencil to be formed and leaving the resulting data in the
>> stencil' and 'height' properties for further use.
>
> This seems to get the same result we have now while adding a lot of
> extra properties.

Yup.  It would seem like we'd need more some nicer construct for
providing a number of behaviors in a single callback/property, with
caching for each set of _relevant_ preconditions.

> I like the idea of their being a single property that is honed in on
> with successive estimates until we get the perfect value.  This is how
> I do a Sudoku - I pencil the guesses in the squares

Blasphemy!

> until I get the actual value and then erase all the estimates and
> write the good value.  Something about using the container (the
> property) as a holder of the estimates and the final item itself feels
> sound design-wise.

-- 
David Kastrup