Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-08 Thread m...@mikesolomon.org
On 8 mars 2013, at 14:10, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly
> File input/regression/minimum-length-end-line.ly (right):
> 
> https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly#newcode10
> input/regression/minimum-length-end-line.ly:10: \override
> TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
> Why is this override needed for the regtest?  The other overrides are
> obvious user-accessible overrides for triggering the tested
> functionality.
> 
> But should _this_ override not be the default?
> 
> https://codereview.appspot.com/7453046/

Perhaps open a tracker issue for this?
The question is not only valid for text spanners but also hairpins, glissandos, 
etc.

Cheers,
MS


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


Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

2013-03-08 Thread mtsolo

Thanks for the review!


https://codereview.appspot.com/7310075/diff/53001/input/regression/skyline-point-extent.ly
File input/regression/skyline-point-extent.ly (right):

https://codereview.appspot.com/7310075/diff/53001/input/regression/skyline-point-extent.ly#newcode5
input/regression/skyline-point-extent.ly:5: even though the
@code{NoteHead} stencils are empty. The @code{Stem_engraver}
On 2013/03/08 14:24:11, dak wrote:

This talks about the NoteHead stencil being empty, but the actual code

uses a

point-stencil (which is _not_ empty).


Done.

https://codereview.appspot.com/7310075/diff/53001/lily/separation-item.cc
File lily/separation-item.cc (right):

https://codereview.appspot.com/7310075/diff/53001/lily/separation-item.cc#newcode148
lily/separation-item.cc:148: Interval extra_width = robust_scm2interval
(elts[i]->get_property ("extra-spacing-width"),
On 2013/03/08 14:24:11, dak wrote:

This is not related to this patch, but isn't it complete nonsense to

use an

Interval here rather than a Drul_array or other form of offset pair?



The LEFT and RIGHT values don't form an interval as far as I can see.


you're right

https://codereview.appspot.com/7310075/diff/53001/lily/skyline.cc
File lily/skyline.cc (right):

https://codereview.appspot.com/7310075/diff/53001/lily/skyline.cc#newcode649
lily/skyline.cc:649: return ret;
On 2013/03/08 14:24:11, dak wrote:

Why not just
return *this;
here?  The function does not return a reference, so a copy is

constructed

anyway.  There is no point in doing yet another copy, is there?


Done.

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm#newcode472
scm/output-lib.scm:472: 1000))
On 2013/03/08 14:24:11, dak wrote:

Don't we have some constants for the full range START and END values?


I don't think we have one for integers. I made one in lily-library.scm

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm#newcode478
scm/output-lib.scm:478: (define-public
pure-from-neighbor-interface::unobtrusive-height
On 2013/03/08 14:24:11, dak wrote:

"unobtrusive" is a bit obscure: I suspected the only-a-bit-empty

interval at

first.  "height-if-pure" would be quite more descriptive.


Done.

https://codereview.appspot.com/7310075/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-08 Thread mtsolo


https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7615043/diff/1/scm/output-lib.scm#newcode929
scm/output-lib.scm:929: form. @code{x} is the portion of the width
consumed for a given line
On 2013/03/08 06:26:29, lemzwerg wrote:

Please use two spaces after a full stop.


Done.

https://codereview.appspot.com/7615043/

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


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-08 Thread m...@mikesolomon.org

On 9 mars 2013, at 00:15, thomasmorle...@googlemail.com wrote:

> Hi Mike,
> 
> one thought.
> 
> The image Trevor Bača posted
> http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png
> shows that the left ends of a decrecsendo-hairpin are vertical aligned
> even if the hairpin isn't extended horizontal but ascending.
> Currently the vertical alignment is gone if the hairpin is rotated, and,
> afaik, this is the only way an ascending hairpin is available (apart
> from constructing a new one from scratch).
> 
> (Similiar for cresc-hairpins.)
> 
> Is it possible to extend your code to achieve this?
> Might be an interesting feature for common hairpins as well.
> 
> Since I don't know of I explained myself well enough, here some
> markup-code which mimics it:
> 
> #(define drag-hairpin 5) % try different values
> 
> \markup
>  \postscript
>  #(string-append
>  "
>0 1.5 moveto
>0.5 -0.75 rlineto
>15
>"
>(number->string (+ -0.75 drag-hairpin))
>"
>rlineto
> 
>0 -1.5 moveto
>0.5 0.75 rlineto
>15
>"
>(number->string (+ 0.75 drag-hairpin))
>"
>rlineto
>stroke
> 
>% a red line to show vertical alignment:
> 
>gsave
>0 3 moveto
>1 0 0 setrgbcolor
>0 -6 rlineto
>stroke
>grestore
>   ")
> 
> 
> 
> 
> 
> 
> https://codereview.appspot.com/7615043/

 Hey Harm,

I think it's worth adding an issue to the tracker for this. You can make a 
minimal example with the hairpins in current master.

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


PATCHES: Countdown to 11 March 2013 - 19:00 GMT

2013-03-08 Thread James
Hello,

*Countdown – March 8th 2013 – 19:00 GMT* *
* *
* *
* *
*




 
3212
Enhancement
David Kastrup Push Patch: Make test-output-distance regtest contain span
bars  
2689
Enhancement
Mike Solomon Push Patch: Avoid duplication between slur and phrasing slur
engravers.  
1334
Enhancement
David Kastrup Push Enhancement: a \score-lines markup command for
multi-lines embedded scores   markup
3187
Ugly
David Kastrup Push Ugly alignment of text and score within a markup
3225
Enhancement
David Kastrup Push Patch: Decouple \defaultchild from \accepts list in
contexts




 
3134
Enhancement
Mike Solomon Countdown Patch: Removes the translate_axis call from
axis-group-interface outside-staff positioning.
3204
Crash
David Kastrup Countdown articulate: can't compile music containing
alternatives




 
3231
Enhancement
David Kastrup review Patch: Make reference pitch for \relative non-optional
3230
Enhancement
Mike Solomon review Patch: Adds Ferneyhough hairpins to LilyPond.
3229
Enhancement
David Kastrup review Patch: Make \relative { ... } interpret the first
pitch as an absolute one
3228
Documentation
Aleksandr Andreev review Patch: Change \transpose to \relative in
ancient.itely   Frog




 *Patches moved to 'Needs_work' this countdown*



 
1698
Defect
Mike Solomon Needs Work Slurs and ties are not correct over repeats
2785
Ugly
Mike Solomon Needs Work Hairpin minimum-length has not effect at end of
line
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

2013-03-08 Thread thomasmorley65

Hi Mike,

one thought.

The image Trevor Bača posted
http://lists.gnu.org/archive/html/lilypond-user/2013-03/pngIGBdggySyh.png
shows that the left ends of a decrecsendo-hairpin are vertical aligned
even if the hairpin isn't extended horizontal but ascending.
Currently the vertical alignment is gone if the hairpin is rotated, and,
afaik, this is the only way an ascending hairpin is available (apart
from constructing a new one from scratch).

(Similiar for cresc-hairpins.)

Is it possible to extend your code to achieve this?
Might be an interesting feature for common hairpins as well.

Since I don't know of I explained myself well enough, here some
markup-code which mimics it:

#(define drag-hairpin 5) % try different values

\markup
  \postscript
  #(string-append
  "
0 1.5 moveto
0.5 -0.75 rlineto
15
"
(number->string (+ -0.75 drag-hairpin))
"
rlineto

0 -1.5 moveto
0.5 0.75 rlineto
15
"
(number->string (+ 0.75 drag-hairpin))
"
rlineto
stroke

% a red line to show vertical alignment:

gsave
0 3 moveto
1 0 0 setrgbcolor
0 -6 rlineto
stroke
grestore
   ")






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


GUB usage

2013-03-08 Thread Jordi Gutiérrez Hermoso
For Octave, I'm trying to update GUB to use a newer gcc, and I'm
running across a few problems.

I haven't done much, but here is my clone of the repo:

http://hg.octave.org/gub

So now I need to patch the gcc sources because they have a small bug
that prevents building, and here I am puzzled about the overall GUB
architecture. Why is the patching logic spread out between actual
patch files and Python spec files? For my current issue, I need to
figure out this problem:

http://gcc.gnu.org/ml/libstdc++/2013-03/msg00041.html

so for this I would write a patch file, right? Or should I put the
patch logic in Python source code and use the file_sub() function?

Is there a simple mechanism in GUB for writing these patch files?
Reading them, it looks like they were somehow automated, so I would
like to know how they were generated.

Finally, if I update the style of the Python to follow PEP 8 (e.g. no
long lines), would you accept back those patches?

- Jordi G. H.

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


Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

2013-03-08 Thread dak


https://codereview.appspot.com/7310075/diff/53001/input/regression/skyline-point-extent.ly
File input/regression/skyline-point-extent.ly (right):

https://codereview.appspot.com/7310075/diff/53001/input/regression/skyline-point-extent.ly#newcode5
input/regression/skyline-point-extent.ly:5: even though the
@code{NoteHead} stencils are empty. The @code{Stem_engraver}
This talks about the NoteHead stencil being empty, but the actual code
uses a point-stencil (which is _not_ empty).

https://codereview.appspot.com/7310075/diff/53001/lily/separation-item.cc
File lily/separation-item.cc (right):

https://codereview.appspot.com/7310075/diff/53001/lily/separation-item.cc#newcode148
lily/separation-item.cc:148: Interval extra_width = robust_scm2interval
(elts[i]->get_property ("extra-spacing-width"),
This is not related to this patch, but isn't it complete nonsense to use
an Interval here rather than a Drul_array or other form of offset pair?

The LEFT and RIGHT values don't form an interval as far as I can see.

https://codereview.appspot.com/7310075/diff/53001/lily/skyline.cc
File lily/skyline.cc (right):

https://codereview.appspot.com/7310075/diff/53001/lily/skyline.cc#newcode649
lily/skyline.cc:649: return ret;
Why not just
return *this;
here?  The function does not return a reference, so a copy is
constructed anyway.  There is no point in doing yet another copy, is
there?

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm
File scm/output-lib.scm (right):

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm#newcode472
scm/output-lib.scm:472: 1000))
Don't we have some constants for the full range START and END values?

https://codereview.appspot.com/7310075/diff/53001/scm/output-lib.scm#newcode478
scm/output-lib.scm:478: (define-public
pure-from-neighbor-interface::unobtrusive-height
"unobtrusive" is a bit obscure: I suspected the only-a-bit-empty
interval at first.  "height-if-pure" would be quite more descriptive.

https://codereview.appspot.com/7310075/

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


Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

2013-03-08 Thread dak


https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly
File input/regression/minimum-length-end-line.ly (right):

https://codereview.appspot.com/7453046/diff/1/input/regression/minimum-length-end-line.ly#newcode10
input/regression/minimum-length-end-line.ly:10: \override
TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
Why is this override needed for the regtest?  The other overrides are
obvious user-accessible overrides for triggering the tested
functionality.

But should _this_ override not be the default?

https://codereview.appspot.com/7453046/

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


Re: Allows inheritence for slur engravers (issue 7437048)

2013-03-08 Thread dak

LGTM

https://codereview.appspot.com/7437048/

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


Re: Allows slurs to break at barlines. (issue 7424049)

2013-03-08 Thread dak


https://codereview.appspot.com/7424049/diff/19022/ly/spanners-init.ly
File ly/spanners-init.ly (right):

https://codereview.appspot.com/7424049/diff/19022/ly/spanners-init.ly#newcode114
ly/spanners-init.ly:114: breakSlur = #(make-music 'BreakSlurEvent)
I am not happy with a new event type here.  Can't this become an
additional property on the existing events?  That way, we could do make
with a single command \broken used like
c\broken(
and similar.

That's one new user interface rather than half a dozen and growing.

https://codereview.appspot.com/7424049/

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