Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[mtsolo]

On 2011/07/24 13:50:53, MikeSol wrote:

New patchset uploaded with minor tweaks.
I still need to think about a better way to implement the change in

score_edges.

  The idea is that if there is a large jump right at the beginning or

end of the

stem, we should favor attachments points that are closer to the

Y-position of

the second note-column and not the first.  Currently, my code is too

extreme: it

pulls certain attachment points up too high (I'm thinking of

slur-rest.ly).

Hey all,

I was able to get rid of the change in score_edges with another
parameter.
I think this does the trick and fixes every example in issue 163 save
the one in comment 4 from Werner.  I'm not sure if this example is
undesirable - on IMSLP there are a few Brahms intermezzi (op. 118 119)
that make comparable engraving decisions.

Three regtests are added with relatively extreme situations that now
behave nicely.

Cheers,
MS

http://codereview.appspot.com/4817048/

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

Adds epsilon to Bezier range calculations. (issue4820048)

[mtsolo]

Reviewers: ,

Message:
This passes regtests and adds a regtest to show it in action.

As I know nothing about rounding error in C++, I'd like others who are
more familiar with this to comment on the way I handle it.

Cheers,
MS

Description:
Adds epsilon to Bezier range calculations.

Please review this at http://codereview.appspot.com/4820048/

Affected files:
  A input/regression/bezier-rounding-error.ly
  M lily/bezier.cc


Index: input/regression/bezier-rounding-error.ly
diff --git a/input/regression/bezier-rounding-error.ly  
b/input/regression/bezier-rounding-error.ly

new file mode 100644
index  
..0fe656e705756f45414e0192c01633af1a49f523

--- /dev/null
+++ b/input/regression/bezier-rounding-error.ly
@@ -0,0 +1,11 @@
+\version "2.15.7"
+
+\header {
+  texidoc = "Floating point rounding errors in the Bezier solver
+are encompassed by a small epsilon value to allow for solvable
+Bezier intersections.
+"
+}
+{
+  \slurUp \times 2/3 { a'8( a') a' }
+}
Index: lily/bezier.cc
diff --git a/lily/bezier.cc b/lily/bezier.cc
index  
e15b04827abd3ba39aa09fe2b1ee4eaea35524b9..078323f803cf6adf4faab23316de47f89d51e4b7  
100644

--- a/lily/bezier.cc
+++ b/lily/bezier.cc
@@ -165,8 +165,9 @@ Bezier::polynomial (Axis a) const
 vector
 filter_solutions (vector sol)
 {
+  Real epsilon = 1e-10;
   for (vsize i = sol.size (); i--;)
-if (sol[i] < 0 || sol[i] > 1)
+if (sol[i] < 0 - epsilon || sol[i] > 1 + epsilon)
   sol.erase (sol.begin () + i);
   return sol;
 }



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

Re: Fixes note column skylines by adding a stem tremolo pure height function. (issue4754054)

[mtsolo]

On 2011/07/24 11:06:43, J_lowe wrote:

Passes make and reg tests show some differences - nothing

significantly wrong


see
http://code.google.com/p/lilypond/issues/detail?id=1768#c6



for screenshots



(couldn't see where mikes attached differences were - so redid them

again myself

for the tracker in case people were not seeing what had changed).


Pushed as 922d59a242646c2488738d77263580427bd7764b.

Cheers,
MS

http://codereview.appspot.com/4754054/

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

Re: Fixes note column skylines by adding a stem tremolo pure height function. (issue4754054)

[mtsolo]

On 2011/07/27 08:40:04, MikeSol wrote:

On 2011/07/24 11:06:43, J_lowe wrote:
> Passes make and reg tests show some differences - nothing

significantly wrong

>
> see
> http://code.google.com/p/lilypond/issues/detail?id=1768#c6
>
> for screenshots
>
> (couldn't see where mikes attached differences were - so redid them

again

myself
> for the tracker in case people were not seeing what had changed).



Pushed as 922d59a242646c2488738d77263580427bd7764b.



Cheers,
MS


ERRATA
Pushed as def419dfd961fee6fd0bf49321ae130143b618af.

Cheers,
MS

http://codereview.appspot.com/4754054/

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

Re: Produces better error messages when programmers forget to document a property. (issue4801045)

[mtsolo]

On 2011/07/25 11:18:28, James.Lowe_datacore.com wrote:

Hello,



)-Original Message-
)From: mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of mailto:m...@apollinemike.com
)Sent: 24 July 2011 09:41
)To: mts...@gmail.com; n.putt...@gmail.com;
)lemniskata.bernoull...@gmail.com; pkx1...@gmail.com; lilypond-
)de...@gnu.org; mailto:re...@codereview.appspotmail.com
)Subject: Re: Produces better error messages when programmers forget
)to document a property. (issue4801045)
)
)On Jul 24, 2011, at 12:05 AM, mailto:pkx1...@gmail.com wrote:
)
)> Can you give me an idea what his does and how to test this or what

I

)> am going to see as someone who runs a lot of make/reg tests?
)>
)
)Try adding an undocumented property to an interface (i.e. add "foo"

to

)the Stem interface) and then run make.  Before, make would throw an
)error about procedure-name when building internals.texi.  Now, it

will still

)throw that error, but before that, it'll explicitly mention that

"foo" is

)undocumented, allowing for one to then document it.
)
)Cheers,
)MS



Thanks, for this information. I'll try to run the test tonight - I ran

out of

time yesterday - so I can see what it looks like when it does what it

is

supposed to do, using Neil's 'broken' patch.



James


Pushed as 922d59a242646c2488738d77263580427bd7764b.

Cheers,
MS

http://codereview.appspot.com/4801045/

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

Re: Makes parameters for hairpin rotation available in Scheme (issue4809051)

[mtsolo]

On 2011/07/25 22:22:05, graham_percival-music.ca wrote:

On Mon, Jul 25, 2011 at 09:17:53AM +0200, mailto:m...@apollinemike.com
wrote:
>
> We may want to just fix issue 36 via something in the docs-
...
>  but as there is no clear way to
> deal with these collisions, perhaps a section in the
> documentation "Dealing with collisions" that says something to
> the effect of "LilyPond does its best to avoid collisions
> between objects.  However, often there is more than one solution
> available to collision avoidance - white out, moving, rotating,
> etc..



sounds good to me.  That's in Learning 4.5 Collisions of objects,
right?



Cheers,
- Graham


Yup.
I'm gonna close this Rietveld issue.  Could you downgrade the priority
of the issue on the tracker to either medium or low (depending on what
you think would be appropriate) and add the right tags that show this
needs to be a documentation suggestion (not a code base fix).

Cheers,
MS

http://codereview.appspot.com/4809051/

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

some comments do not appear in the tracker page

[Janek Warchoł]

Hi,

there is a problem with comments in the tracker.  At least 2 comments
didn't make it to the "changing G clef" issue page:
- Trevor's comment from July 26th, containing sentence "The G clef
font was changed 18 months or so ago by Carl without all this fuss"
- Carls comment, perhaps from July 25th, containing sentence "This
proposal was based on Graham's assertion that 2.16 is 10 days away
from release"

The problem is quite serious because i didn't get these messages at
all - even though i'm subscribed to bug-lilypond, where they seem to
land!  I see them now in bug- archives, but they are nowhere in my
lemniskata.bernoulli...@gmail.com account.  The most funny things is,
perhaps, that they appeared in another mail account which i've
subscribed to mailing lists (that's how i doscovered them).

I suppose that this happens when someone replies to e-mail
notification from tracker, which contains comment message.

Should/can we change how this works?

Also, i'd like to apologize to everyone whose comments weren't
answered by me because of this.

cheers,
Janek

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

Re: Treats multi measure rest staff position like rest staff position. (issue4822046)

[mtsolo]

On 2011/07/23 20:54:40, MikeSol wrote:

Should fix issue 1604.


Passes regtests.

http://codereview.appspot.com/4822046/

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

RE: some comments do not appear in the tracker page

[James Lowe]

Janek

)-Original Message-
)From: lilypond-devel-bounces+james.lowe=datacore@gnu.org
)[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org] On
)Behalf Of Janek Warchol
)Sent: 27 July 2011 09:55
)To: lilypond-devel@gnu.org; Lilypond Bugreports
)Subject: some comments do not appear in the tracker page
)
)Hi,
)
)there is a problem with comments in the tracker.  At least 2 comments
)didn't make it to the "changing G clef" issue page:
)- Trevor's comment from July 26th, containing sentence "The G clef font
)was changed 18 months or so ago by Carl without all this fuss"
)- Carls comment, perhaps from July 25th, containing sentence "This
)proposal was based on Graham's assertion that 2.16 is 10 days away from
)release"
)
)The problem is quite serious because i didn't get these messages at all -
)even though i'm subscribed to bug-lilypond, where they seem to land!  I
)see them now in bug- archives, but they are nowhere in my
)lemniskata.bernoulli...@gmail.com account.  The most funny things is,
)perhaps, that they appeared in another mail account which i've
)subscribed to mailing lists (that's how i doscovered them).

Are these messages you are missing on the tracker itself (as opposed to someone 
just replying to the email that the tracker generates)?

I've not noticed any missing emails myself - I am also now quite involved with 
the tracker with the reg tests and have found the main problem is either 
replying to the email than the tracker itself and also updating Rietveld but 
not the tracker (or vice versa) but we know that is not ideal.

But missing emails? not from my side.

james

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

RE: Produces better error messages when programmers forget to document a property. (issue4801045)

[James Lowe]

Hello,

)-Original Message-
)From: mts...@gmail.com [mailto:mts...@gmail.com]
)Sent: 27 July 2011 09:43
)To: n.putt...@gmail.com; lemniskata.bernoull...@gmail.com;
)pkx1...@gmail.com; gra...@percival-music.ca;
)m...@apollinemike.com; James Lowe
)Cc: lilypond-devel@gnu.org; re...@codereview.appspotmail.com
)Subject: Re: Produces better error messages when programmers forget
)to document a property. (issue4801045)
)
)On 2011/07/25 11:18:28, James.Lowe_datacore.com wrote:
)> Hello,
)
)> )-Original Message-
)> )From: mailto:lilypond-devel-
)bounces+james.lowe=datacore@gnu.org
)> )[mailto:lilypond-devel-bounces+james.lowe=datacore@gnu.org]
)On
)> )Behalf Of mailto:m...@apollinemike.com
)> )Sent: 24 July 2011 09:41
)> )To: mts...@gmail.com; n.putt...@gmail.com;
)> )lemniskata.bernoull...@gmail.com; pkx1...@gmail.com; lilypond-
)> )de...@gnu.org; mailto:re...@codereview.appspotmail.com
)> )Subject: Re: Produces better error messages when programmers
)forget
)> )to document a property. (issue4801045)
)> )
)> )On Jul 24, 2011, at 12:05 AM, mailto:pkx1...@gmail.com wrote:
)> )
)> )> Can you give me an idea what his does and how to test this or what
)I
)> )> am going to see as someone who runs a lot of make/reg tests?
)> )>
)> )
)> )Try adding an undocumented property to an interface (i.e. add "foo"
)to
)> )the Stem interface) and then run make.  Before, make would throw an
)> )error about procedure-name when building internals.texi.  Now, it
)will still
)> )throw that error, but before that, it'll explicitly mention that
)"foo" is
)> )undocumented, allowing for one to then document it.
)> )
)> )Cheers,
)> )MS
)
)> Thanks, for this information. I'll try to run the test tonight - I ran
)out of
)> time yesterday - so I can see what it looks like when it does what it
)is
)> supposed to do, using Neil's 'broken' patch.
)
)> James
)
)Pushed as 922d59a242646c2488738d77263580427bd7764b.
)
)Cheers,
)MS
)
)http://codereview.appspot.com/4801045/

Oh.. Didn't get a chance to test it yet :)

But I have Neil's broken patch so I can still test it tonight for my own 
personal point of view.

James

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

Lilypond pixel comparisons on a subset of the retests

[m...@apollinemike.com]

Hey all,

If I'm working on a patch that effects a specific set of ly files, is there 
anyway to do a select pixel comparison between a baseline and these files 
without running the whole regrets machine?

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

Removes closeness-factor from the Slur details list. (issue4825051)

[mtsolo]

Reviewers: ,

Message:
This passes regtests without any change in the visual output.

After wading through slur-configuration.cc, I would like to prune the
details list as much as possible so that subsequent wadings are easier
to understand for everyone.

In general, if the absence of a parameter does not change the regtests,
I think it should be scrubbed.  If people truly want a parameter to be
kept, then a regtest should be added showing how its presence is
essential.

Cheers,
MS

Description:
Removes closeness-factor from the Slur details list.

Please review this at http://codereview.appspot.com/4825051/

Affected files:
  M lily/include/slur-score-parameters.hh
  M lily/slur-configuration.cc
  M lily/slur-score-parameters.cc
  M lily/slur.cc
  M scm/layout-slur.scm


Index: lily/include/slur-score-parameters.hh
diff --git a/lily/include/slur-score-parameters.hh  
b/lily/include/slur-score-parameters.hh
index  
49d159b9390da0a2aebb9589e62d1947b1ea1bd2..5c50d6bfa0a05e1c9f4dc37adf38aabc13254ef6  
100644

--- a/lily/include/slur-score-parameters.hh
+++ b/lily/include/slur-score-parameters.hh
@@ -28,7 +28,6 @@ struct Slur_score_parameters

   Real head_encompass_penalty_;
   Real stem_encompass_penalty_;
-  Real closeness_factor_;
   Real edge_attraction_factor_;
   Real same_slope_penalty_;
   Real steeper_slope_factor_;
Index: lily/slur-configuration.cc
diff --git a/lily/slur-configuration.cc b/lily/slur-configuration.cc
index  
e83856364db6dbb3a4f2e111915d5a55f44fafdf..2c4a920ee998a290c84260a8a7d7d541008db844  
100644

--- a/lily/slur-configuration.cc
+++ b/lily/slur-configuration.cc
@@ -267,18 +267,6 @@ Slur_configuration::score_encompass (Slur_score_state  
const &state)


  demerit += stem_dem;
}
-  else if (!edge)
-   {
- Interval ext;
- ext.add_point (state.encompass_infos_[j].stem_);
- ext.add_point (state.encompass_infos_[j].head_);
-
- // ?
- demerit += -state.parameters_.closeness_factor_
-   * min (state.dir_
-		   * (y - (ext[state.dir_] + state.dir_ *  
state.parameters_.free_head_distance_)), 0.0)

-   / state.encompass_infos_.size ();
-   }
 }
   add_score (demerit, "encompass");

Index: lily/slur-score-parameters.cc
diff --git a/lily/slur-score-parameters.cc b/lily/slur-score-parameters.cc
index  
1683aeea2feace61a84496e7247cecb57fd81e6d..a1f58c4dba5cb4179b7b54de0edf15d7be54c71d  
100644

--- a/lily/slur-score-parameters.cc
+++ b/lily/slur-score-parameters.cc
@@ -44,8 +44,6 @@ Slur_score_parameters::fill (Grob *me)
 = get_detail (details, ly_symbol2scm ("head-encompass-penalty"));
   stem_encompass_penalty_
 = get_detail (details, ly_symbol2scm ("stem-encompass-penalty"));
-  closeness_factor_
-= get_detail (details, ly_symbol2scm ("closeness-factor"));
   edge_attraction_factor_
 = get_detail (details, ly_symbol2scm ("edge-attraction-factor"));
   same_slope_penalty_
Index: lily/slur.cc
diff --git a/lily/slur.cc b/lily/slur.cc
index  
433406c92a57d9471daab3524cf5c32091af7ebe..7de05c2ff3a07b3818a6a9cf312a0364cb4ea468  
100644

--- a/lily/slur.cc
+++ b/lily/slur.cc
@@ -427,8 +427,6 @@ ADD_INTERFACE (Slur,
   "Demerit to apply when note heads collide with a slur.\n"
   "@item stem-encompass-penalty\n"
   "Demerit to apply when stems collide with a slur.\n"
-  "@item closeness-factor\n"
-  "Additional demerit used when scoring encompasses.\n"
   "@item edge-attraction-factor\n"
   "Factor used to calculate the demerit for distances"
   " between slur endpoints and their corresponding base"
Index: scm/layout-slur.scm
diff --git a/scm/layout-slur.scm b/scm/layout-slur.scm
index  
8626e0114690e832872b4aaff9cf23ce797a5e30..0f9a98c6e9f847e850b8268f163e8a7e56c0e761  
100644

--- a/scm/layout-slur.scm
+++ b/scm/layout-slur.scm
@@ -20,7 +20,6 @@
   '((region-size . 4)
 (head-encompass-penalty . 1000.0)
 (stem-encompass-penalty . 30.0)
-(closeness-factor . 10)
 (edge-attraction-factor . 4)
 (same-slope-penalty . 20)
 (steeper-slope-factor . 50)



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

Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[tdanielsmusic]

http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh
File lily/include/slur-score-parameters.hh (right):

http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh#newcode32
lily/include/slur-score-parameters.hh:32: Real
max_distance_from_head_penalty_;
duplicated

http://codereview.appspot.com/4817048/

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

Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[m...@apollinemike.com]

On Jul 27, 2011, at 3:37 PM, tdanielsmu...@googlemail.com wrote:

> 
> http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh
> File lily/include/slur-score-parameters.hh (right):
> 
> http://codereview.appspot.com/4817048/diff/13001/lily/include/slur-score-parameters.hh#newcode32
> lily/include/slur-score-parameters.hh:32: Real
> max_distance_from_head_penalty_;
> duplicated
> 
> http://codereview.appspot.com/4817048/

Fixed - thanks!

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

Re: Lilypond-book: Implement musicxml support in lilypond-book (issue1659041)

[reinhold . kainhofer]

Of course, all comments for the docs apply to HTML/LaTeX/Texinfo as
well.


http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):

http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely#newcode206
Documentation/usage/lilypond-book.itely:206: @itemize @bullet
On 2011/07/26 21:38:00, J_lowe wrote:

We don't use @bullet with @itemize.


Okay, I don't know anything about docs formatting, so I usually copy
things from the same file. IN this case, the @bullet is copied from a
few lines down (line 275 in the unmodified file). I'll remove it.

http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely#newcode207
Documentation/usage/lilypond-book.itely:207: @item the
@code{\lilypond@{...@}} command, where you can directly enter short
lilypond code
On 2011/07/26 21:38:00, J_lowe wrote:

On 2011/07/26 15:49:50, lemzwerg wrote:
> Please stay within a width of 80 characters.



80?



72 (preferably 66 - see 5.3.5 Text formatting in CG - also see @item

in the

various sections)


Yes, sorry. Plus, I should add the blank lines between the @items

http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely#newcode226
Documentation/usage/lilypond-book.itely:226: @end example
On 2011/07/26 21:38:00, J_lowe wrote:

I did this
Myself a few days ago on another section and Graham, quite rightly,

said it was

unnecessary. Can we just use one single



@example
...
@end example for all of these?


I have just added one more to the already existing list of @examples.
How exactly should the doc look with 1 @example?

http://codereview.appspot.com/1659041/

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

Re: Lilypond pixel comparisons on a subset of the retests

[Phil Holmes]

- Original Message - 
From: 

To: 
Sent: Wednesday, July 27, 2011 11:38 AM
Subject: Lilypond pixel comparisons on a subset of the retests



Hey all,

If I'm working on a patch that effects a specific set of ly files, is 
there anyway to do a select pixel comparison between a baseline and these 
files without running the whole regrets machine?



I don't believe the "standard" regtests are a true pixel comparison, so the 
simple answer is no, not that I know of.  Except...


If you run windows and have a windows LP executable, then my regtest checker 
would do what you want.  If you just run Windows and could create the PNGs 
in an alternative machine, I could adapt it to just do the comparisons.


--
Phil Holmes



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

Re: Doc build error

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Wednesday, July 27, 2011 12:19 AM
Subject: Re: Doc build error



On Tue, Jul 26, 2011 at 09:58:14PM +0100, Phil Holmes wrote:

I'm _still_ running the older version of lilydev, but with all the
patches.


hmm.



Part way through making a new virtual machine with lilydev 1.1 on it.  This 
version does not have the lily-git.tcl script on the desktop - I had to grab 
it from my older VM.


--
Phil Holmes



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

Re: Doc build error

[Phil Holmes]

- Original Message - 
From: "James Lowe" 


@Phil you should use the out of tree 'build' dir method, it's really 
convenient - see the CG.



James



I do - I quite often nuke it and start from scratch.  My problem wasn't 
fixed by doing this.


--
Phil Holmes



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

Re: Lilypond pixel comparisons on a subset of the retests

[m...@apollinemike.com]

Hey Phil,

Thanks for the offer!  Unfortunately, I don't have Windows, and I'll be running 
this on several batches of PNGs.
I overstated my case when I said pixel comparison: I just need to be able to 
selectively run certain tests and see generally if they differ.  I'm sure that 
I could hack the makefile(s) to do this, but I'll wait to see if anyone else 
has a prefabbed hack that will spare me from making my own.

Cheers,
MS

On Jul 27, 2011, at 4:49 PM, Phil Holmes wrote:

> - Original Message - From: 
> To: 
> Sent: Wednesday, July 27, 2011 11:38 AM
> Subject: Lilypond pixel comparisons on a subset of the retests
> 
> 
>> Hey all,
>> 
>> If I'm working on a patch that effects a specific set of ly files, is there 
>> anyway to do a select pixel comparison between a baseline and these files 
>> without running the whole regrets machine?
> 
> 
> I don't believe the "standard" regtests are a true pixel comparison, so the 
> simple answer is no, not that I know of.  Except...
> 
> If you run windows and have a windows LP executable, then my regtest checker 
> would do what you want.  If you just run Windows and could create the PNGs in 
> an alternative machine, I could adapt it to just do the comparisons.
> 
> --
> Phil Holmes
> 
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


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

Re: Lilypond pixel comparisons on a subset of the retests

[Phil Holmes]

I've never run the regtests on my VM here, but I would guess this would work 
if you simply edit the number of files in the regtest directory?


--
Phil Holmes


- Original Message - 
From: 

To: "Phil Holmes" 
Cc: 
Sent: Wednesday, July 27, 2011 4:07 PM
Subject: Re: Lilypond pixel comparisons on a subset of the retests


Hey Phil,

Thanks for the offer!  Unfortunately, I don't have Windows, and I'll be 
running this on several batches of PNGs.
I overstated my case when I said pixel comparison: I just need to be able to 
selectively run certain tests and see generally if they differ.  I'm sure 
that I could hack the makefile(s) to do this, but I'll wait to see if anyone 
else has a prefabbed hack that will spare me from making my own.


Cheers,
MS

On Jul 27, 2011, at 4:49 PM, Phil Holmes wrote:


- Original Message - From: 
To: 
Sent: Wednesday, July 27, 2011 11:38 AM
Subject: Lilypond pixel comparisons on a subset of the retests



Hey all,

If I'm working on a patch that effects a specific set of ly files, is 
there anyway to do a select pixel comparison between a baseline and these 
files without running the whole regrets machine?



I don't believe the "standard" regtests are a true pixel comparison, so 
the simple answer is no, not that I know of.  Except...


If you run windows and have a windows LP executable, then my regtest 
checker would do what you want.  If you just run Windows and could create 
the PNGs in an alternative machine, I could adapt it to just do the 
comparisons.


--
Phil Holmes



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




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

2.15.6 regtests

[Phil Holmes]

Results from the official regtests:

event-listener-output.ly: output is spaced completely differently, albeit it 
looks better to me.
stem-tremolo.ly: changes are shown (and with many other tremolo-containing 
regtests).  The changes are small enough that it's not clear what they are.

rest-ledger.ly: re-written regtest.
event-listener-output.log: lots and lots more output.
display-lily-tests.log: lots of added lines:

+Test 125 unequal: NOT A BUG.
+in  = \oneVoice
+out = {
+  \revert Voice . DotColumn #'direction
+  \revert Voice . Dots #'direction
+  \revert Voice . Fingering #'direction
+  \revert Voice . LaissezVibrerTie #'direction
+  \revert Voice . PhrasingSlur #'direction
+  \revert Voice . RepeatTie #'direction
+  \revert Voice . Rest #'direction
+  \revert Voice . Script #'direction
+  \revert Voice . Slur #'direction
+  \revert Voice . Stem #'direction
+  \revert Voice . TextScript #'direction
+  \revert Voice . Tie #'direction
+  \unset Voice . graceSettings
+  \revert Voice . NoteColumn #'horizontal-shift
+  \revert Voice . MultiMeasureRest #'staff-position
+
+}

incompatible-stem-warning.log: lots of changed lines: a sample:
-/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/incompatible-stem-warning.ly:16:20: 
warning: adding note head to incompatible stem (type = 1/2)
+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/incompatible-stem-warning.ly:16:20: 
warning: adding note head to incompatible stem (type = 1/4)

  << c'2
e'1 >>

midi-volume-equaliser.log (and other midi regtests): warnings removed (I've 
lost track of whether these are supposed to be there)

-warning: MIDI channel wrapped around
-warning: remapping modulo 16
-warning: MIDI channel wrapped around
-warning: remapping modulo 16

Otherwise: OK.  I'd like to know whether all these are expected, but none 
looks like a bug to me so I won't be raising any issues unless someone 
shouts.


--
Phil Holmes
Bug Squad




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

Re: 2.15.6 regtests

[David Kastrup]

"Phil Holmes"  writes:

> incompatible-stem-warning.log: lots of changed lines: a sample:
> -/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/incompatible-stem-warning.ly:16:20:
> warning: adding note head to incompatible stem (type = 1/2)
> +/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/incompatible-stem-warning.ly:16:20:
> warning: adding note head to incompatible stem (type = 1/4)
>   << c'2
> e'1 >>

Those are mine (it was the less invasive of two accidental commits, so I
dit not revert it): the code unifies the stem types before deciding
whether to complain, so there should be fewer warnings all in all.

However, this results in a warning being called out for a type 1/4 stem
when there has been no 1/4 note (the 1/4 stem is the same as an 1/2
stem).

If people find that too confusing, I can offer to save the original
duration and use that for wording the complaint.

-- 
David Kastrup


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

2.14.2 regtests (vs 2.14.1)

[Phil Holmes]

accidental-placement.ly (and others): no naturals before other accidentals- 
expected change.

A number of regtests are places/spaced better; e.g. fingering-cross-staff.ly
midi-volume-equaliser.log (for example):
-warning: MIDI channel wrapped around
-warning: remapping modulo 16

BUT.
midi-grace.log (for example):
+warning: MIDI channel wrapped around
+warning: remapping modulo 16
(I've definitely lost the plot over this error message).

mozart-hrn-3.log: 
+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.14/input/regression/mozart-hrn3-allegro.ily:129:17: 
warning: already have slur

+   \longgrace d16

Known problem with the regtest now.

Otherwise, OK, I reckon.

--
Phil Holmes
Bug Squad 




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

Re: Fix for Issue 620. (issue4814041)

[mtsolo]

A new version of this patch is up w/ the name of the property changed to
bound-alignment-interfaces.

Cheers,
MS

http://codereview.appspot.com/4814041/

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[bordage . bertrand]

This is really dirty, but here's an update that does what you want (I
hope).
If you have ideas to clean a bit this mess...

Thanks,
Bertrand

http://codereview.appspot.com/4536068/

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

Re: 2.15.6 regtests

[Graham Percival]

On Wed, Jul 27, 2011 at 04:47:42PM +0100, Phil Holmes wrote:
> event-listener-output.ly: output is spaced completely differently,
> albeit it looks better to me.

Yes, there was a rhythm problem in the old version.

> event-listener-output.log: lots and lots more output.

The format of the rest events changed.

Cheers,
- Graham

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

Re: Doc build error

[Graham Percival]

On Wed, Jul 27, 2011 at 03:57:11PM +0100, Phil Holmes wrote:
> Part way through making a new virtual machine with lilydev 1.1 on
> it.  This version does not have the lily-git.tcl script on the
> desktop - I had to grab it from my older VM.

These instructions:
http://lilypond.org/doc/v2.15/Documentation/contributor/using-lily_002dgit
tell users to run the command in the Terminal.  We therefore
removed it from the desktop.

Cheers,
- Graham

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[dak]

http://codereview.appspot.com/4536068/diff/30001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):

http://codereview.appspot.com/4536068/diff/30001/lily/multi-measure-rest.cc#newcode131
lily/multi-measure-rest.cc:131: int measure_duration_log = int (ceil
(duration_log));
On 2011/07/27 04:13:48, Keith wrote:

To me, having done numerical work, the chain of functions you use,

int( ceil(

-log2(x))), is easily recognizable as "find the smallest n so that 1 /

2^n <=

x".



While log2 is inexact, the results when x is a power of 2 are exact
(IEEE-compliant floating-point represents integers and integer powers

of 2

exactly) so reliably 3/4 and 2/4 both come out 1 (half/minim rest).


log2 is a transcedental operation, it is not guaranteed to be exact.
logb would be (it just returns the exponent from the floating point
representation).

Anyway, it seems like log2 is not universally available, so we should
avoid it.  The same is likely true for logb.

http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):

http://codereview.appspot.com/4536068/diff/37002/lily/multi-measure-rest.cc#newcode241
lily/multi-measure-rest.cc:241: length = (2 << -i) / 2;
The division by 2 changes the result.  Not that I understand too well
what it is supposed to be doing.

http://codereview.appspot.com/4536068/

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[mtsolo]

http://codereview.appspot.com/4536068/diff/30001/lily/multi-measure-rest.cc
File lily/multi-measure-rest.cc (right):

http://codereview.appspot.com/4536068/diff/30001/lily/multi-measure-rest.cc#newcode131
lily/multi-measure-rest.cc:131: int measure_duration_log = int (ceil
(duration_log));
On 2011/07/27 17:25:59, dak wrote:

On 2011/07/27 04:13:48, Keith wrote:
> To me, having done numerical work, the chain of functions you use,

int( ceil(

> -log2(x))), is easily recognizable as "find the smallest n so that 1

/ 2^n <=

> x".
>
> While log2 is inexact, the results when x is a power of 2 are exact
> (IEEE-compliant floating-point represents integers and integer

powers of 2

> exactly) so reliably 3/4 and 2/4 both come out 1 (half/minim rest).



log2 is a transcedental operation, it is not guaranteed to be exact.

logb would

be (it just returns the exponent from the floating point

representation).


Anyway, it seems like log2 is not universally available, so we should

avoid it.

The same is likely true for logb.


Why not just an array that acts as a log table?

int foo[10] = {1,2,4,8,16,32,64,128,256,512};

Or however long you need it to be, with a check to make sure we're in
bounds.  Then, a binary search will find the index you want.

http://codereview.appspot.com/4536068/

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

Re: printed bars thickness inconsistencies

[Janek Warchoł]

2011/7/26 Jean-Alexis Montignies :
> It looks much better on screen (Preview.app: MacOS X system renderer) and on 
> Xerox Phaser 5400!
>
> Remains a little bit of smearing on the top of the staff, but this is much 
> less than before and could be some rounding/smoothing issue in the renderers. 
> More specifically, on screen, the horizontal edge of the barline rect looks 
> not smoothed, while the vertical edge is. Don't know enough about PS if this 
> can be controlled, or if it's really an issue (in any case minor).
>
> Thickness looks consistent now.

Good, thanks for reporting!
I hope that current output could be improved even more - if Finale can
handle these things perfectly, then we should be able too :)
See "Postscript printer errors with rounded barlines" thread on devel.

> (extreme zoom, notice the round edge of the stall line on the right :) )

:P

cheers,
Janek

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

Re: Postscript printer errors with rounded barlines?

[Jan Warchoł]

2011/7/26 Han-Wen Nienhuys :
> On Sat, Jul 23, 2011 at 7:45 PM, Jan Warchoł
>  wrote:
>
>> I'm not experienced with PostScript, but i have an impression that
>> this may be related to an issue discussed earlier - see here
>> http://lists.gnu.org/archive/html/lilypond-user/2007-07/msg00485.html
>> and here
>> http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00072.html
>> I see that something about draw_round_box was said there...
>
> I think this is an other issue.  Due to rounding, PDF viewers can err
> the placement of the barline by a pixel. This is insolvable, as there
> is no way to hint that the barline should coincide with the staffline,
> yet we need to go the end of the barline to get the correct effect in
> the corners in staves.

I'd accept this if it were not for the fact that Finale seems to
handle this perfectly.  I've never experienced any sticking out
barlines in Finale pdfs, neither on screen nor in print (i can send
you some if you want).  Also, the thickness of the stems and barlines
is consistent in Finale pdfs (i.e. it looks like second image from
here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html
while Lily output looks like first one).
I'd say that the fact that Finale does something this basic better
than LilyPond is a serious insult to us, given how much Finale sucks
in these matters (for example in flag attachment, see attached).

> The one-pixel error is very noticeable on-screen due to
> low-resolution, but on a 1200dpi printer,  a single dot error is about
> 0.02 mm, ie. not noticeable.

I'm not sure whether you are referring to how it looked before your
patch or how it looks after it.
Before your patch it was certainly noticeable enough - even my friend
Luke, who doesn't care that much about the details, said it irked him.
As for how it looks after your patch - I hoped to be able to do some
prints on my choir's printer to see how things looks like now, but it
ran out of toner - new cartridge should be available in next week.
Besides, many printers have resolutions lower than 1200dpi.

cheers,
Janek
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

GOP-PROP 5: build system output (probable 2?)

[Graham Percival]

I still don't feel that we have any kind of consensus on this.
Here's an updated proposal.

http://lilypond.org/~graham/gop/gop_5.html


** Proposal summary

When you run make or make doc,

* All output will be saved to various log files, with the
  exception of output directly from make(1).
* By default, no other output will be displayed on the
  console, with one exception: if a build fails, we might
  display some portion(s) of log file(s) which give useful
  clues about the reason for the failure.

  The user may optionally request additional output to be
printed; this is controlled with the VERBOSE=x flag. In such
cases, all output will still be written to log files; the console
output is strictly additional to the log files.

* Logfiles from calling lilypond (as part of lilypond-book)
  will go in the relevant
  ‘build/out/lybook-db/12/lily-123456.log’ file. All other
  logfiles will go in the ‘build/logfiles/’ directory.
* Both stderr and stdout will be saved in *.log. The order of
  lines from these streams should be preserved.
* There will be no additional “progress messages” during the
  build process. If you run make --silent, a non-failing build
  should print absolutely nothing to the screen.
* Ideally, a failing build should provide hints about the
  reason why it failed, or at least hints about which log
  file(s) to examine. 


** Rationale

When the lilypond build breaks, it’s too hard to figure out why it
broke.

We see emails to lilypond-devel approximately once every two
months about broken builds. On a subjective note, Graham has been
the documentation editor since 2003, but even he cannot reliably
pinpoint the cause of a failing doc build within 10 minutes. We
waste a ridiculous amount of time, effort, and patience on build
problems.


** Sea of output

Before any of the current work on reducing output from make, the
result of a "make doc" was over 500,000 lines of text. The prime
reason for the output being so verbose is that all the processes
that run as a result of the call to make echo their output to the
screen, often in verbose mode. Lilypond itself produces around
370,000 lines of output as a result of lilypond-book building all
the snippets.

Much of this output can be redirected to logfiles and so the
impossible-to-read clutter on the screen is cut out and could be
referred to later.


** Don’t cause more build problems

However, there is a danger in this approach, that vital error
messages can also be lost, thus preventing the cause of the
failure of a make being found. We therefore need to be
exceptionally careful to move cautiously, include plenty of tests,
and give time for people to experiment/find problems in each stage
before proceeding to the next stage.


** Implementation notes

There is an existing make variable QUIET_BUILD, which alter the
amount of output being displayed
(http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables
). We are not planning on keeping this make variable.

The standard way for GNU packages to give more output is with a
V=x option. Presumably this is done by increasing x? If we support
this option, we should still write log files; we would simply
print more of the info in those log files to screen.


** Bottom line

If there are no build problems, there should be no change to
people’s workflow.

If there are build problems, then it should be easier to find out
why it’s failing. 


Cheers,
- Graham

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

Re: Lilypond-book: Implement musicxml support in lilypond-book (issue1659041)

[pkx166h]

http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely
File Documentation/usage/lilypond-book.itely (right):

http://codereview.appspot.com/1659041/diff/5001/Documentation/usage/lilypond-book.itely#newcode226
Documentation/usage/lilypond-book.itely:226: @end example
On 2011/07/27 14:20:57, Reinhold wrote:

On 2011/07/26 21:38:00, J_lowe wrote:
> I did this
> Myself a few days ago on another section and Graham, quite rightly,

said it

was
> unnecessary. Can we just use one single
>
> @example
> ...
> @end example for all of these?



I have just added one more to the already existing list of @examples.

How

exactly should the doc look with 1 @example?


Oh, sorry Reinhold. I got carried away :)

Well if it were me...I'd probably have edited them 'while I was about
it' but then again Doc is all I do.

So in that case.

LGTM

http://codereview.appspot.com/1659041/

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

Re: Fix for Issue 620. (issue4814041)

[pkx166h]

Passes Make and reg tests

http://codereview.appspot.com/4814041/

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

Re: 2.15.6 regtests

[Reinhold Kainhofer]

On Mi., 27. Jul. 2011 17:47:42 CEST, Phil Holmes  wrote:
> display-lily-tests.log: lots of added lines:
> 
> +Test 125 unequal: NOT A BUG.
> +in   = \oneVoice
...

That's expected.
Cheers,
Reinhold

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

Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[pkx166h]

Passes Make and reg tests.

http://codereview.appspot.com/4817048/

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

Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[pkx166h]

On 2011/07/27 19:30:41, J_lowe wrote:

Passes Make and reg tests.


Sorry I updated the wrong Rietveld issue. This does pass make but there
are reg test differences - see

http://code.google.com/p/lilypond/issues/detail?id=163#c17

http://codereview.appspot.com/4817048/

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

Re: Adds epsilon to Bezier range calculations. (issue4820048)

[pkx166h]

On 2011/07/27 08:37:06, MikeSol wrote:

This passes regtests


It does indeed :)

James


http://codereview.appspot.com/4820048/

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

Re: Adds epsilon to Bezier range calculations. (issue4820048)

[pkx166h]

Added as

http://code.google.com/p/lilypond/issues/detail?id=1784

Just in case (some people use tracker more than Rietveld or their inbox
so this may get more eyes).

http://codereview.appspot.com/4820048/

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

Re: Adds epsilon to Bezier range calculations. (issue4820048)

[hanwenn]

this just moves the rounding error an epsilon away.

can you post an image of the problem you're solvnig ?

http://codereview.appspot.com/4820048/

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

Re: Postscript printer errors with rounded barlines?

[Han-Wen Nienhuys]

On Wed, Jul 27, 2011 at 3:23 PM, Jan Warchoł
 wrote:

>> I think this is an other issue.  Due to rounding, PDF viewers can err
>> the placement of the barline by a pixel. This is insolvable, as there
>> is no way to hint that the barline should coincide with the staffline,
>> yet we need to go the end of the barline to get the correct effect in
>> the corners in staves.
>
> I'd accept this if it were not for the fact that Finale seems to
> handle this perfectly.  I've never experienced any sticking out
> barlines in Finale pdfs, neither on screen nor in print (i can send
> you some if you want).  Also, the thickness of the stems and barlines
> is consistent in Finale pdfs (i.e. it looks like second image from
> here http://lists.gnu.org/archive/html/lilypond-devel/2007-07/msg00076.html
> while Lily output looks like first one).
> I'd say that the fact that Finale does something this basic better
> than LilyPond is a serious insult to us, given how much Finale sucks
> in these matters (for example in flag attachment, see attached).

You can make the problem disappear by

- hard coding the output to a certain resolution
- making the bar go to the middle of the staffline, rather than the outside.

both have disadvantages. (what does finale's barline at the end of a
staff look like?)

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: changing shape of the G clef (issue4664070)

[lemniskata . bernoullego]

Going back to replacing the clef only.  Old glyph is no longer in the
patch, we may discuss it separately.

http://codereview.appspot.com/4664070/

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

Re: Adds epsilon to Bezier range calculations. (issue4820048)

[m...@apollinemike.com]

On Jul 27, 2011, at 10:59 PM, hanw...@gmail.com wrote:this just moves the rounding error an epsilon away.can you post an image of the problem you're solvnig ?http://codereview.appspot.com/4820048/With my new patch, the tuplet collision right at the end of the slur is avoided (lily finds a Bezier intersection).  Without the patch, there is a slur/tuplet-number collision.

PastedGraphic-1.pdf
Description: Adobe PDF document
Cheers,MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.15.6 regtests

[Carl Sorensen]

On 7/27/11 9:53 AM, "David Kastrup"  wrote:

> "Phil Holmes"  writes:
> 
>> incompatible-stem-warning.log: lots of changed lines: a sample:
>> -/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-rel
>> ease-unstable/input/regression/incompatible-stem-warning.ly:16:20:
>> warning: adding note head to incompatible stem (type = 1/2)
>> +/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-rel
>> ease-unstable/input/regression/incompatible-stem-warning.ly:16:20:
>> warning: adding note head to incompatible stem (type = 1/4)
>>   << c'2
>> e'1 >>
> 
> Those are mine (it was the less invasive of two accidental commits, so I
> dit not revert it): the code unifies the stem types before deciding
> whether to complain, so there should be fewer warnings all in all.
> 
> However, this results in a warning being called out for a type 1/4 stem
> when there has been no 1/4 note (the 1/4 stem is the same as an 1/2
> stem).
> 
> If people find that too confusing, I can offer to save the original
> duration and use that for wording the complaint.

I would prefer that alternative, unless the overhead is significant.  This
error message is more confusing than it should be.

Thanks,

Carl


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

Re: 2.15.6 regtests

[David Kastrup]

Carl Sorensen  writes:

> On 7/27/11 9:53 AM, "David Kastrup"  wrote:
>
>> "Phil Holmes"  writes:
>> 
>>> incompatible-stem-warning.log: lots of changed lines: a sample:
>>> -/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-rel
>>> ease-unstable/input/regression/incompatible-stem-warning.ly:16:20:
>>> warning: adding note head to incompatible stem (type = 1/2)
>>> +/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-rel
>>> ease-unstable/input/regression/incompatible-stem-warning.ly:16:20:
>>> warning: adding note head to incompatible stem (type = 1/4)
>>>   << c'2
>>> e'1 >>
>> 
>> Those are mine (it was the less invasive of two accidental commits, so I
>> dit not revert it): the code unifies the stem types before deciding
>> whether to complain, so there should be fewer warnings all in all.
>> 
>> However, this results in a warning being called out for a type 1/4 stem
>> when there has been no 1/4 note (the 1/4 stem is the same as an 1/2
>> stem).
>> 
>> If people find that too confusing, I can offer to save the original
>> duration and use that for wording the complaint.
>
> I would prefer that alternative, unless the overhead is significant.  This
> error message is more confusing than it should be.

Will do.

-- 
David Kastrup


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

Re: Adds epsilon to Bezier range calculations. (issue4820048)

[Han-Wen Nienhuys]

That's weird - the overlap looks way more than 1e-10. Are you sure it is
taking the correct extent of the number into account?

(I am surprised that we do tuplet number/slur collisions at all.)


2011/7/27 m...@apollinemike.com 

> On Jul 27, 2011, at 10:59 PM, hanw...@gmail.com wrote:
>
> this just moves the rounding error an epsilon away.
>
> can you post an image of the problem you're solvnig ?
>
> http://codereview.appspot.com/4820048/
>
>
> With my new patch, the tuplet collision right at the end of the slur is
> avoided (lily finds a Bezier intersection).  Without the patch, there is a
> slur/tuplet-number collision.
>
>
> Cheers,
> MS
>
>


-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.15.6 regtests

[Keith OHara]

> midi-volume-equaliser.log (and other midi regtests): warnings removed (I've 
> lost track of whether these are supposed to be there)
> -warning: MIDI channel wrapped around

They are not, and their appearances in regression test comparisons will 
disappear soon, as the patch spreads through the builds.





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

Re: Remove special case in staff-spacing (issue4188051)

[k-ohara5a5a]

http://codereview.appspot.com/4188051/diff/4001/lily/include/spacing-spanner.hh#newcode45

lily/include/spacing-spanner.hh:45: static Real cushion_;
I think this should be a grob property rather than a static variable.


New patch set up, simpler, no longer involves any static variable.

http://codereview.appspot.com/4188051/

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

PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Colin Campbell]

New today, for Friday:

Issue 621 : 
Dynamics should avoid cross-staff BarLines (e.g. GrandStaff, PianoStaff 
etc) - Rietveld



Countdown done, but still open/not marked fixed:
From Wednesday July 27

Issue 732 : 
Alignment problems when vertically stacking horizontally centered 
stencils. - Rietveld Issue 4798050 
: Fix 732: center-column ignored 
left half of stencil extent -> collision with previous stencil
Issue  : 
Allow manual directions on dynamics to break alignment spanner 
automatically - Rietveld Issue 4810048 
: Fix : Break dynamic line 
spanner if different direction is explicitly given
Issue 1730 : 
Documentation for lilypond-windows.exe and -dgui option - Rietveld Issue 
4806050 : Doc: Usage - new 
option for lilypond-book



And a couple of Rietveld-only patches:
  Issue 4668045 : Fixes error 
for tuplet bracket direction calculation when tuplets contain rests.
Issue 4639075 : Moves tuplet 
numbers outside staff with their brackets.
  Issue 4580041 : Current state 
of automatic footnotes.




  Issue 1433 
: 
\breakDynamicSpan breaks with \break ("bounds of spanner are invalid") - 
Rietveld Issue 4630070 : Fix 
issues 1259 and 1433 (\breakDynamicSpan and a spanner's style=#'none 
over a line break)
  Issue 1259 : 
DynamicTextSpanner #'style = #'none doesn't work over \break


The list of patches still not dealt with is rather alarming: is it 
because devels are on holiday, am I missing the closed or fixed tags in 
Rietveld and Google Code?  How can I help you folk keep this moving?



I still owe Graham a proposal on patch management, but this seems to 
call for more immediate attention.


cheers,

Colin

--
The human race has one really effective weapon, and that is laughter.
-- Mark Twain

 

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

Re: First pass at avoiding very high slurs (fixes issue 163). (issue4817048)

[hanwenn]

as an overall comment; I would try to look at the buggy examples in more
detail to understand exactly what is going wrong.  It is easy to add an
extra demerit, but (as you can see) hard to make it work with all the
other cases that we handle.


http://codereview.appspot.com/4817048/diff/15002/lily/slur-configuration.cc
File lily/slur-configuration.cc (right):

http://codereview.appspot.com/4817048/diff/15002/lily/slur-configuration.cc#newcode249
lily/slur-configuration.cc:249: Real encompass_refpoint = minmax
(state.dir_, state.encompass_infos_[j].head_,
state.encompass_infos_[j].stem_);
refpoint usually has another meaning within lilypond.

http://codereview.appspot.com/4817048/diff/15002/lily/slur-configuration.cc#newcode252
lily/slur-configuration.cc:252: if (fabs (encompass_refpoint) >
highest_point
is this reasonable for non-horizontal slurs? Why don't you check for the
maximum dy instead?

http://codereview.appspot.com/4817048/diff/15002/lily/slur-configuration.cc#newcode256
lily/slur-configuration.cc:256: * 2 is the max distance allowable from
the highest notehead before
2 ?

http://codereview.appspot.com/4817048/

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

Re: Adds longas, maximas and non-standard tweaks to MultiMeasureRest (issue4536068)

[k-ohara5a5a]

Works good for me.


On 2011/07/27 17:49:01, MikeSol wrote:


Why not just an array that acts as a log table?



int foo[10] = {1,2,4,8,16,32,64,128,256,512};


Bertrand already has something better, walking along the (very short)
list of usable-duration-logs.

http://codereview.appspot.com/4536068/

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

Re: PATCH: 48-Hour countdown to 20:00 MDT Friday July 29

[Graham Percival]

On Wed, Jul 27, 2011 at 08:04:21PM -0600, Colin Campbell wrote:
> The list of patches still not dealt with is rather alarming: is it because
> devels are on holiday, am I missing the closed or fixed tags in Rietveld and
> Google Code?  How can I help you folk keep this moving?

You could check the git changelog (either in gitk, or on the web)
to make sure that nobody pushed something without marking it
fixed.  Then send private emails to people reminding them to push,
or to send final patches to me if they don't have push ability.

Private emails always get more attention.  Yes, it adds another 30
minutes to your job, but with the looming Aug 1 deadline before
existing C++ patches get awkward, I think it's worth the effort.

Cheers,
- Graham

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

Re: GOP-PROP 5: build system output (probable 2?)

[Jan Nieuwenhuizen]

Graham Percival writes:

> I still don't feel that we have any kind of consensus on this.
> Here's an updated proposal.

Ah, great.

So what if we add a --log option to lilypond-book (and probably
to lilypond), that [always in verbose mode?] writes individual
.log files alongside the output.  Would this fix 90% of this
proposal?  Sure, we also have metafont/post, fontforge.

I can imagine also adding stepmake rules to handle V=0 for
c/c++ compilation.  Possibly not logging that would be OK,
because a new compile with V=1 would almost instantly show
the problem?

Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

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

Re: GOP-PROP 5: build system output (probable 2?)

[Graham Percival]

On Thu, Jul 28, 2011 at 07:33:04AM +0200, Jan Nieuwenhuizen wrote:
> Graham Percival writes:
> 
> > I still don't feel that we have any kind of consensus on this.
> > Here's an updated proposal.
> 
> So what if we add a --log option to lilypond-book (and probably
> to lilypond), that [always in verbose mode?] writes individual
> .log files alongside the output.  Would this fix 90% of this
> proposal?

You mean, like
  23cdda9506931d5b9a1e75ee8be8b74f9084a7c0
?

I'd call it 20% rather than 90%, but yes, Phil's work on
lilypond-book will certainly be valuable!

> I can imagine also adding stepmake rules to handle V=0 for
> c/c++ compilation.  Possibly not logging that would be OK,
> because a new compile with V=1 would almost instantly show
> the problem?

I don't agree.  Log files are cheap; I think we should always
write the logfiles -- but I'd be ok if we had a special option to
omit writing logfiles if the user really really wants that.

Cheers,
- Graham

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

Re: GOP-PROP 5: build system output (probable 2?)

[Jan Nieuwenhuizen]

Graham Percival writes:

> You mean, like
>   23cdda9506931d5b9a1e75ee8be8b74f9084a7c0
> ?

Yes (I would have called the option --log).

> I'd call it 20% rather than 90%, but yes, Phil's work on
> lilypond-book will certainly be valuable!

Assuming that --redirect-lilypond-output is used during build now, you
mention 500,000 and 370,000 lines of output for make doc.  Am I assuming
correctly that currently make doc prints 130,000 lines?  Which programs
are responsible for that?

>> I can imagine also adding stepmake rules to handle V=0 for
>> c/c++ compilation.  Possibly not logging that would be OK,
>> because a new compile with V=1 would almost instantly show
>> the problem?
>
> I don't agree.  Log files are cheap; I think we should always
> write the logfiles

I don't get this.  Any sort of complexity added is expensive.  It must
be written, it must be documented, it must be remembered, it must be
maintained.  One of the biggest responsibilities as a maintainer is to
deny most if not all `nice to have' features in favour of simplicity and
more important things.

Moreover, I figure that c/c++ compilation amounts to only a maximum of
about 0% to the sea of output burden.  What are you trying to fix?

Also, you are [should be] probably running c/c++ compilation in -j4
mode; how are you going to find/determine which compile failed and
what log file it is?  Then, you have to open the log file and tell
your editor to go to the right location.

It's just much smarter to hit compile [bound to make V=[ [-j1]] in your
editor and have it jump to the error location.

Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

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

Re: review process not working

[Jan Warchoł]

I agree with Graham that it's a matter of bad luck (i.e. "stuff
happens").  If i understand Graham correctly, the idea of countdown is
not to add some beaurocratic order, but to force us to "speak now, or
forever be silent" (tongue-in-cheek, of course).  In other words, a
patch without reviews is not put on countdown because it certainly
must be good, but precisely to *get* some reviews.

2011/7/26 Graham Percival :
> On Tue, Jul 26, 2011 at 07:36:43PM +0200, David Kastrup wrote:
>>
>> So it needs to tell its story in comments.  It doesn't.  There is a lot
>> of code in Lilypond that nonchalantly expects people to get along
>> without commenting what it does.  This is often a nuisance, but if the
>> code is written by a master, the pain of figuring out what it does is
>> usually tolerable.
>
> Very true; I think that almost all developers (if not all!) would
> like to see better comments in the code!

I'd like to see them for certain.

> Could you get into the
> habit of pointing out questionable / unclear parts of code in
> future patches, so that the author will explain them in comments?

I'll try.  This will probably be easy; as i won't understant anything
i'll ask for comments everywhere :)

cheers,
Janek

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

Re: GOP-PROP 5: build system output (probable 2?)

[Jan Nieuwenhuizen]

Graham Percival writes:

> You mean, like
>   23cdda9506931d5b9a1e75ee8be8b74f9084a7c0
> ?

Yes (I would have called the option --log).

> I'd call it 20% rather than 90%, but yes, Phil's work on
> lilypond-book will certainly be valuable!

Assuming that --redirect-lilypond-output is used during build now, you
mention 500,000 and 370,000 lines of output for make doc.  Am I assuming
correctly that currently make doc prints 130,000 lines?  Which programs
are responsible for that?

>> I can imagine also adding stepmake rules to handle V=0 for
>> c/c++ compilation.  Possibly not logging that would be OK,
>> because a new compile with V=1 would almost instantly show
>> the problem?
>
> I don't agree.  Log files are cheap; I think we should always
> write the logfiles

I don't get this.  Any sort of complexity added is expensive.  It must
be written, it must be documented, it must be remembered, it must be
maintained.  One of the biggest responsibilities as a maintainer is to
deny most if not all `nice to have' features in favour of simplicity and
more important things.

Moreover, I figure that c/c++ compilation amounts to only a maximum of
about 0% to the sea of output burden.  What are you trying to fix?

Also, you are [should be] probably running c/c++ compilation in -j4
mode; how are you going to find/determine which compile failed and
what log file it is?  Then, you have to open the log file and tell
your editor to go to the right location.

Isn't it smarter to hit compile [bound to make V=[ [-j1]] in your editor
and have it jump to the error location?

Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl

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

Re: GOP-PROP 5: build system output (probable 2?)

[Graham Percival]

On Thu, Jul 28, 2011 at 08:25:25AM +0200, Jan Nieuwenhuizen wrote:
> Graham Percival writes:
> 
> > You mean, like
> >   23cdda9506931d5b9a1e75ee8be8b74f9084a7c0
> > ?
> 
> Yes (I would have called the option --log).

IMO a long descriptive name is better than a short name that's
open to interpretation.  Note that --redirect-lilypond-output does
*not* save any output from lilypond-book (the python script) to a
file.  I'd expect a --log to do that.

We may well look at adding --log in the future, or else do that
redirection in the build system.

> > I'd call it 20% rather than 90%, but yes, Phil's work on
> > lilypond-book will certainly be valuable!
> 
> Assuming that --redirect-lilypond-output is used during build now,

It is not.  We are moving very slowly and cautiously to avoid
creating more problems.  --redirect-lilypond-output needs a lot
more testing, particularly stuff like .tely files including .itely
files including .ly files.

The build system has not been touched, in large part because we
have not yet decided on what the overall policy should be.

> > I don't agree.  Log files are cheap; I think we should always
> > write the logfiles
> 
> I don't get this.  Any sort of complexity added is expensive.  It must
> be written, it must be documented, it must be remembered, it must be
> maintained.  One of the biggest responsibilities as a maintainer is to
> deny most if not all `nice to have' features in favour of simplicity and
> more important things.

I submit to you that since we have 1 thread about broken builds
every 2 months, the current build system needs to change.  I think
this extra complexity is worth it.

BTW, do you consider the logging system in GUB to be unnecessary
added complexity?  I find it incredibly useful.

> Moreover, I figure that c/c++ compilation amounts to only a maximum of
> about 0% to the sea of output burden.  What are you trying to fix?

We're mostly trying to fix the doc output.  In case there is
ambiguity here, "build system output" refers to
  make doc
in addition to plain old
  make

We are trying to figure out general policies for the build system.

> Also, you are [should be] probably running c/c++ compilation in -j4
> mode; how are you going to find/determine which compile failed and
> what log file it is?  Then, you have to open the log file and tell
> your editor to go to the right location.

If we cannot clearly distinguish which log file (from -j4)
contains the error, then obviously we would simply redirect all
threads to the same log file.  I consider this a relatively minor
implementation detail; the relevant policy point is:
  "Ideally, a failing build should provide hints about the reason
why it failed, or at least hints about which log file(s) to
examine."

If a certain arrangement of log files (be that merging files,
splitting files, whatever) does a better job of bringing the error
to the user's attention, then we should use that arrangement.

Cheers,
- Graham

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