Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-24 Thread Thomas Morley 
2017-10-23 21:28 GMT+02:00 David Kastrup :
> Thomas Morley  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 
> 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 
> 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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup 
Thomas Morley  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.

> 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 
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 
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

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread Thomas Morley 
2017-10-23 15:29 GMT+02:00 David Kastrup :
> David Kastrup  writes:
>
>>> Is this appropiate?
>>
>> "cause" here is the actual tie event triggering the column.  I think
>> that it should rather be the first tie, making the
>> LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
>> a directly caused grob.  Then it should be ignored by the
>> Parenthesis_engraver.  This would involve changing
>>
>>   SCM cause = tie_ev->self_scm ();
>>
>>   if (!lv_column_)
>> lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>>
>>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>>
>> into
>>
>>   SCM cause = tie_ev->self_scm ();
>>
>>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>>
>>   if (!lv_column_)
>> lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());
>>
>> I don't think that it would be a problem to have the tie created before
>> its column.
>
> Tracker issue: 5222 (https://sourceforge.net/p/testlilyissues/issues/5222/)
> Rietveld issue: 331080043 (https://codereview.appspot.com/331080043)
> Issue description:
>   Stop \parenthesize\laissezVibrer causing programming errors
>
> I don't think I'd have an issue with fast-tracking this one once it
> passed the regtests.
>
> --
> David Kastrup

So how to proceed with 5220?
I'm confident I could adapt your change once it is in master 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.


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)?


Cheers,
  Harm

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup 
David Kastrup  writes:

>> Is this appropiate?
>
> "cause" here is the actual tie event triggering the column.  I think
> that it should rather be the first tie, making the
> LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
> a directly caused grob.  Then it should be ignored by the
> Parenthesis_engraver.  This would involve changing
>
>   SCM cause = tie_ev->self_scm ();
>
>   if (!lv_column_)
> lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>
>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>
> into
>
>   SCM cause = tie_ev->self_scm ();
>
>   Grob *lv_tie = make_item ("LaissezVibrerTie", cause);
>
>   if (!lv_column_)
> lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());
>
> I don't think that it would be a problem to have the tie created before
> its column.

Tracker issue: 5222 (https://sourceforge.net/p/testlilyissues/issues/5222/)
Rietveld issue: 331080043 (https://codereview.appspot.com/331080043)
Issue description:
  Stop \parenthesize\laissezVibrer causing programming errors

I don't think I'd have an issue with fast-tracking this one once it
passed the regtests.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: LaissezVibrerTie and LaissezVibrerTieColumn

2017-10-23 Thread David Kastrup 
Thomas Morley  writes:

> Hi all,
>
> here:
> https://sourceforge.net/p/testlilyissues/issues/5220/#f5aa/ed76
> I wrote that \parenthesize\laissezVibrer does not work because
> LilyPond tries to parenthesize LaissezVibrerTieColumn as well.
>
> And indeed, with the code below _two_ grobs are affected:
> LaissezVibrerTieColumn and LaissezVibrerTie
>
> {
>   c'1
>  -\tweak after-line-breaking #(lambda (grob) (write grob))
>  -\laissezVibrer
> }
>
> This looks fishy.
> While the proposed check for interval-sane? at the tracker may be a
> good thing at its own, I found changing laissez-vibrer-engraver.cc
>
> -  if (!lv_column_)
> -lv_column_ = make_item ("LaissezVibrerTieColumn", cause);
>
> +  if (!lv_column_)
> +{
> +  lv_column_ = make_item ("LaissezVibrerTieColumn", SCM_EOL);
> +}
>
> seems to cure it.
> Though, I'm hardly knowing what I'm doing here...
>
> Is this appropiate?

"cause" here is the actual tie event triggering the column.  I think
that it should rather be the first tie, making the
LaissezVibrerTieColumn a grob with ultimately identifiable cause but not
a directly caused grob.  Then it should be ignored by the
Parenthesis_engraver.  This would involve changing

  SCM cause = tie_ev->self_scm ();

  if (!lv_column_)
lv_column_ = make_item ("LaissezVibrerTieColumn", cause);

  Grob *lv_tie = make_item ("LaissezVibrerTie", cause);

into

  SCM cause = tie_ev->self_scm ();

  Grob *lv_tie = make_item ("LaissezVibrerTie", cause);

  if (!lv_column_)
lv_column_ = make_item ("LaissezVibrerTieColumn", lv_tie->self_scm ());

I don't think that it would be a problem to have the tie created before
its column.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel