[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: anyone notice speed of 2.17.95 on Windows ?
From: |
David Kastrup |
Subject: |
Re: anyone notice speed of 2.17.95 on Windows ? |
Date: |
Sun, 15 Dec 2013 09:46:07 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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
- Re: anyone notice speed of 2.17.95 on Windows ?, (continued)
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/13
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/13
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/14
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?,
David Kastrup <=
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Werner LEMBERG, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Werner LEMBERG, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Trevor Daniels, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, David Kastrup, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Mike Solomon, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Keith OHara, 2013/12/15
- Re: anyone notice speed of 2.17.95 on Windows ?, Devon Schudy, 2013/12/15