lilypond-devel
[Top][All Lists]
Advanced

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

Re: LaissezVibrerTie and LaissezVibrerTieColumn


From: Thomas Morley
Subject: Re: LaissezVibrerTie and LaissezVibrerTieColumn
Date: Tue, 24 Oct 2017 10:37:29 +0200

2017-10-23 21:28 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> So how to proceed with 5220?
>> I'm confident I could adapt your change once it is in master
>
> More like "use it".  I don't think you need to do anything with it.
>
>> and maybe even prepare the engravers so that a follow up could
>> implement the idea of https://codereview.appspot.com/335910043/#msg2
>> easily, though I'm not able to realize this idea myself.
>
> The main thing is listing just what the differences between the two
> engravers were.  All those need to be made overridable in whatever will
> serve as the base class.

I did what I could...

>
>> Btw, why do we redefine LaissezVibrerTie-stencil in output-lib.scm?
>> The comment says:
>>
>> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>> ;;  laissez-vibrer tie
>> ;;
>> ;;  needed so we can make laissez-vibrer a pure print
>> ;;
>> (define-public (laissez-vibrer::print grob)
>>   (ly:tie::print grob))
>>
>> Is this (still) true or could it be deleted (and define-grobs.scm
>> adjusted, ofcourse)?
>
> This looks like a remnant of
> commit 55d4389e74f830d759176867dae44ed0400c3b68
> Author: Carl Sorensen <address@hidden>
> Date:   Fri May 14 19:51:57 2010 -0600
>
>     Fix 881, with Neil's suggestion
>
>     Make laisser-vibrez::print a pure function
>
>     Add regression test for issue 881
>
> before
>
> commit 74e4d219b24ec6d6f28d663c0285418e6c8e122e
> Author: Mike Solomon <address@hidden>
> Date:   Tue Mar 5 21:03:55 2013 +0100
>
>     Uses only unpure-pure containers to articulate unpure-pure relationships 
> (issue 3199)
>
>     Previously, LilyPond used several different lists in define-grobs.scm
>     to define relationships between unpure and pure functions.  This patch
>     eliminates these lists, using unpure-pure containers to articulate
>     these relationships.
>
>     The modifications required to implement this change are described below:
>
>     -) axis-group-interface.cc
>     A Scheme function is no longer needed to determine pure relevant grobs.
>     All grobs can have their Y-extents meaningfully pure-evaluated now. The
>     worst-case scenario is that they evaluate to false. Dead grobs, on the
>     other hand, are never pure relevant. The calls to is_live are the only
>     holdovers from the old pure-relevant? scheme function.
>
>     -) grob-closure.cc
>     We allow unpure-pure containers in simple closures.
>
>     -) grob-property.cc
>     call_pure_function no longer looks up a Scheme module. Because there are
>     no hard-coded lists in Scheme any more, the function is smaller and
>     writing it in C++ gets slight efficiency gains.
>
>     -) grob.cc
>     pure_stencil_height used to be a Scheme function in define-grobs.scm.
>     Because it is much simpler (it no longer makes references to lists defined
>     in Scheme), it can be implemented in C++.
>
>     -) pure-from-neighbor-engraver.cc
>     Similar to axis-group-interface.cc, the pure-relevant distinction is
>     no longer important.
>
>     -) side-position-interface.cc
>     In order to avoid issues with alterBroken, we only check pure properties
>     before line breaking.
>
>     -) simple-closure.cc
>     Simple closures were incorrectly evaluated when containing unpure-pure
>     containers. This rectifies that.
>
>     -) stencil-integral.cc
>     Several pure equivalent functions needed to be written for skylines.
>
>     -) define-grobs.scm
>     Multiple overrides must be changed to unpure-pure containers. Previous
>     hard-coded lists are all deleted and several functions moved to C++ (see
>     above).
>
>     -) output-lib.scm
>     Several common unpure-pure containers used in define-grobs.scm are
>     defined here. Several functions from define-grobs.scm pertaining to
>     grob offsets are moved to this file.
>
>
> So I think that at the current point of time, this can likely be
> retired.  Or at least, the definition can be simplified to
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;  laissez-vibrer tie
> ;;
> ;;  Backward compatibility alias
> ;;
> (define-public laissez-vibrer::print ly:tie::print)
>
>
> --
> David Kastrup

Thanks for the info,
  Harm



reply via email to

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