lilypond-devel
[Top][All Lists]
Advanced

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

Re: anyone notice speed of 2.17.95 on Windows ?


From: Mike Solomon
Subject: Re: anyone notice speed of 2.17.95 on Windows ?
Date: Sat, 14 Dec 2013 10:49:43 +0200

On Dec 14, 2013, at 9:35 AM, David Kastrup <address@hidden> wrote:

"Keith OHara" <address@hidden> writes:

On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup <address@hidden> wrote:

That does not make sense.  If you want call-once behavior, you can just
use a callback.

At the moment, the decision on whether to preserve the callback
pointer in the grob property, or fill the property with the returned
value, depends on the method used to request the property,
get_pure_property() versus get_property().  A callback would be called
multiple times (and it would have to support the unpure-pure calling
convention).

The information of whether the callback is providing a value that
/should/ be kept as final is better stored in the Grob itself, so I am
thinking of ways to reorganize.

The way stencil callbacks are evaluated now is interesting.  The
stencil callback itself is a simple callback, but when the layout
engine wants to know the size of a stencil it does
get_pure_property("Y-extent").  Y-extent property is set to either
execute the stencil callback, or estimate a height without building
the final stencil, as appropriate for each Grob.

If you are thinking of reorganizing: the current state is a mess.
I still have not figured out what ly:make-simple-closure is supposed to
do.

ly:make-simple-closure delays evaluation of its parts until looked up.
It is exactly the same as a lambda function.
I don’t think anyone actually uses them anymore - probably can be retired.


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.

Cheers,
MS

reply via email to

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