[Top][All Lists]

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

Re: Creates pure closures (issue 4894052)

From: Mike Solomon
Subject: Re: Creates pure closures (issue 4894052)
Date: Thu, 18 Aug 2011 14:31:55 +0200

On Aug 18, 2011, at 1:06 PM, Reinhold Kainhofer wrote:

> Am Thursday, 18. August 2011, 11:21:59 schrieb address@hidden:
>> This is a more extensible way to deal with pure properties.  I'd like
>> this patch to be the first step, with the second step being rewriting
>> define-grob-properties.scm such that it uses pure closures as much as
>> possible.  First, create a procedure:
>> #(define-public (pure-wrapper proc)
>>   (lambda (grob start end) (proc grob)))
>> Then, for example:
>> (stencil . ,ly:clef::print)
>> becomes
>> (stencil . ,(ly:pure-closure ly:clef::print (pure-wrapper
>> ly:clef::print)))
> Wow, that would be VERY user-unfriendly. Just imagine explaining that to 
> someone on -user... 
> (or even to the average lilypond developer... I still haven't understood what 
> closures are).

I think it is rather easy (and necessary) to explain this to a user, especially 
if there are helper functions.


in output-lib.scm, write

#(define-public (pure-wrapper proc)
  (lambda (grob start end) (proc grob)))

#(define-public (simple-pure proc)
  (ly:pure-closure proc (pure-wrapper proc))

#(define-public (simple-pure-height proc)
  (ly:pure-closure ly:grob::stencil-height (pure-wrapper proc))

The, in the documentations on overrides:

Sometimes, you will want to override a stencil and will want this stencil to be 
taken into account when LilyPond does horizontal spacing.  For LilyPond to know 
that a stencil will not lead to things going bad (i.e. triggering a calculation 
that should happen at the end of a series of calculations at the beginning), it 
needs what are called "pure" approximations of grobs.  If you know that your 
grob's height will be pure (meaning it can be calculated without triggering 
lots of other calculations in other grobs), you can help the horizontal spacing 
engine by adding the following override:

\override Clef #'stencil = #my-stencil-proc
\override Clef #'Y-extent = #(simple-pure-height my-stencil-proc)

Of course, if you think that your stencil function will wreak havoc on other 
grobs, don't use simple-pure-height.  Some suggestions:

1)  If your stencil does not use the grob at all and just draws shapes, you can 
use simple-pure-height.
2)  If you are positive that your stencil does not trigger a VerticalAlignment 
grob, you can use simple-pure-height.

A good way to know if your stencil is pure or not is to run it through LilyPond.

#(define (my-good-unpure-property grob) (ly:stem::height grob))
#(define (my-bad-pure-property grob start end) (ly:stem::height grob))
#(define (my-good-pure-property grob start end) (ly:stem::pure-height grob 
start end))

First, try:

\relative c' {
  \override Stem #'Y-extent =
    #(ly:make-pure-closure my-good-unpure-property my-bad-pure-property)
  \repeat unfold 10 { d8 fis e gis }

Then, try:

\relative c' {
  \override Stem #'Y-extent =
    #(ly:make-pure-closure my-good-unpure-property my-good-pure-property)
  \repeat unfold 10 { d8 fis e gis }

The first will issue a series of warning messages, whereas the second will not.

You get the idea.

I think that, even with this introduced, the average user can keep on doing 
exactly what she was doing before this patch - this just gives her the ability 
to introduce her stencils into skyline calculations.


reply via email to

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