Re: Fix #1507: Inconsistent \festival output in regression testing. (issue4693046)

2011-07-15 Thread k-ohara5a5a 

Works good for me.


http://codereview.appspot.com/4693046/diff/1/scm/song.scm
File scm/song.scm (right):

http://codereview.appspot.com/4693046/diff/1/scm/song.scm#newcode222
scm/song.scm:222: #:unfinished (and (not (*syllabify*))
(find-child-named music 'HyphenEvent))
On 2011/07/16 04:59:50, Keith wrote:

The regtest that caused the initial trouble
song-basic-nonenglish.ly
fails, maybe here-ish


Oops. Somehow I had failed to apply the patch to festivaly.ly, so
*syllabify* was being set the old way.

http://codereview.appspot.com/4693046/

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

Re: Fix #1507: Inconsistent \festival output in regression testing. (issue4693046)

2011-07-15 Thread k-ohara5a5a 


http://codereview.appspot.com/4693046/diff/1/scm/song.scm
File scm/song.scm (right):

http://codereview.appspot.com/4693046/diff/1/scm/song.scm#newcode222
scm/song.scm:222: #:unfinished (and (not (*syllabify*))
(find-child-named music 'HyphenEvent))
The regtest that caused the initial trouble
   song-basic-nonenglish.ly
fails, maybe here-ish

http://codereview.appspot.com/4693046/

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

Re: Fix 1563: System start bars interpreted collapse-height as absolute length. (issue4693043)

2011-07-15 Thread k-ohara5a5a 

Looks good to me.

The differences in beam-skip.ly were not due to this patch.

On 2011/07/12 23:40:54, J_lowe wrote:

Pass Make but I get a difference in one reg test



http://codereview.appspot.com/4693043/

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

Re: Fixes error for tuplet bracket direction calculation when tuplets contain rests. (issue4668045)

2011-07-15 Thread k-ohara5a5a 

Looks good and works good for me.

On 2011/06/29 16:32:33, mike_apollinemike.com wrote:


The only issue with this may be one of sight reading.  If I am reading

at

quaver=200 and I see \relative c''' { \times 2/3 { c4 b,, b } } , I'm

likely

going to want to see the tuplet above the staff so that I don't

accidentally

play the first note as a quarter.


People read ahead of where they are playing (by quite a lot; remember
how early you turn pages for a piano player) and keeping the tuplet
bracket near the staff makes it easier to see what *group* of notes it
applies to.  I like it.

http://codereview.appspot.com/4668045/

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

PATCH: Bonus 72-hour countdown

2011-07-15 Thread Colin Campbell 

21:00 MST Monday July 18

As I'm taking the World's Finest Grand-nipper to see the Badlands 
Passion Play in Drumheller this weekend, here is an extended list with 
extended time:


Issue 1563 : 
strange vertical line at staff begin using StaffSymbol #'staff-space - 
Rietveld - 4693043 : Fix 1563: 
System start bars interpreted collapse-height as absolute length.


Issue 1507 : 
weird linebreaks in song output - Rietveld - 4693046 
: Fix #1507: Inconsistent 
\festival output in regression testing. (no discussion of patch yet, is 
it acceptable?)


Issue 1695 : 
Clef change placed outside score - Rietveld - 4683043 
: Fix #1695: Clef change placed 
outside score.


Issue 1720 : 
Incorrect tuplet bracket direction calculation when tuplets contain 
rests - Rietveld Issue 4668045 : 
Fixes error for tuplet bracket direction calculation when tuplets 
contain rests

  No comments in 2 weeks on this one!

I'm also marking the tracker issues with "CD-110718" indicating their 
countdown expires that day.  Thanks to those who follow up by pushing 
their patches and closing issues; the tag will help remind the rest of us!


Good weekend, all

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: Checks for grobs with circular parentage in the regtests. (issue4747045)

2011-07-15 Thread hanwenn 


http://codereview.appspot.com/4747045/diff/2001/lily/grob.cc
File lily/grob.cc (right):

http://codereview.appspot.com/4747045/diff/2001/lily/grob.cc#newcode528
lily/grob.cc:528: Grob::in_own_family_tree (Grob *g, Grob *orig)
I think this should take an axis argument, and check only one axis.

http://codereview.appspot.com/4747045/diff/2001/lily/include/grob.hh
File lily/include/grob.hh (right):

http://codereview.appspot.com/4747045/diff/2001/lily/include/grob.hh#newcode140
lily/include/grob.hh:140: static bool in_own_family_tree(Grob *g, Grob
*orig);
this needs a small comment; could probably be normal method as well.

I think

  a->has_ancestor(b)

would be more clear.

http://codereview.appspot.com/4747045/diff/2001/lily/pitched-trill-engraver.cc
File lily/pitched-trill-engraver.cc (right):

http://codereview.appspot.com/4747045/diff/2001/lily/pitched-trill-engraver.cc#newcode124
lily/pitched-trill-engraver.cc:124: trill_group_->translate_axis
((unsmob_pitch (scm_pitch)->steps () + c0 ) * 0.5,
you can't do typography (positioning) in any engraver.  This wil mess up
positioning with modified staff sizes.

http://codereview.appspot.com/4747045/

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

Re: change in treble clef - do you accept?

2011-07-15 Thread Han-Wen Nienhuys 
2011/7/15 Janek Warchoł :
> Surprisingly, CueClef currently uses regular clef glyph scaled down
> 1.5874 times (font-size -4), not a scaled down change clef.  Maybe we

Almost; IIRC the -4 will end up in another font, so it will be the
normal clef from feta13 (?).

-- 
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: Fix 1390: slashedGrace function (graces with slashed stems but no slur, e.g. when grace is tied) (issue4670056)

2011-07-15 Thread k-ohara5a5a 

Looks good and works well for me.

http://codereview.appspot.com/4670056/

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

Re: Grobs that are their own ancestors.

2011-07-15 Thread Neil Puttock 
On 15 July 2011 23:00, Neil Puttock  wrote:

> Axis_group_interface::add_element () sets the DynamicLineSpanner as
> X-parent (depends on 'axes setting).

This should read `as Y-parent'.

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

Re: Grobs that are their own ancestors.

2011-07-15 Thread Neil Puttock 
On 15 July 2011 18:28,   wrote:
> I've now gone on a quest for parental loops in the source, and I've found 
> some:
>
> chord-repetition.ly
> chord-tremolo-articulations.ly
> dynamics-alignment-breaker.ly
> dynamics-alignment-no-line.ly
> dynamics-glyphs.ly
> dynamics-line.ly
> dynamics-rest-positioning.ly
> dynamics-text-right-padding.ly
> dynamics-text-spanner-abs-dynamic.ly
>
> After this I stopped checking, but in all of these, the DynamicLineSpanner is 
> its own parent if you trace back its ancestry.

Surely these are harmless though?  We'd only be concerned if the
parentage loop is in the same axis.

> The culprit is line 179 of dynamic-align-engraver - if anyone has any 
> intuition as to why this is the case, lemme know!

set_bound () also sets the X-parent if _this_ doesn't already have one
and we're setting the left bound.

Axis_group_interface::add_element () sets the DynamicLineSpanner as
X-parent (depends on 'axes setting).

So we get the following situation:

If we acknowledge a DynamicText, set DynamicLineSpanner as Y-parent.
If the DynamicText starts a new alignment spanner, set as X-parent of
DynamicLineSpanner.

Cheers,
Neil

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

Checks for grobs with circular parentage in the regtests. (issue4747045)

2011-07-15 Thread mtsolo 

Reviewers: ,

Message:
This gets rid of all circular parentage in LilyPond (at least all that's
in the regtests...).

Description:
Checks for grobs with circular parentage in the regtests.

Eliminates all circular parenting cases from the code base, allowing
for null pointers to be parents but issuing a programming error (this
should only happen for staves that will never see the light of day due
to bad code).

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

Affected files:
  M lily/dynamic-align-engraver.cc
  M lily/grob.cc
  M lily/include/grob.hh
  M lily/include/main.hh
  M lily/pitched-trill-engraver.cc
  M lily/program-option-scheme.cc
  M make/lilypond-vars.make
  M make/lysdoc-targets.make
  M scm/lily.scm


Index: lily/dynamic-align-engraver.cc
diff --git a/lily/dynamic-align-engraver.cc b/lily/dynamic-align-engraver.cc
index  
f62c45f0dc6d3adec09cccf6e700fa1722806a24..cd57b480b8858834d755cd2ef99e64bff7a05337  
100644

--- a/lily/dynamic-align-engraver.cc
+++ b/lily/dynamic-align-engraver.cc
@@ -166,16 +166,26 @@ Dynamic_align_engraver::stop_translation_timestep ()

  Grob *bound = 0;
  if (scripts_.size ())
-   bound = scripts_[0];
- else if (spanners.size ())
-   bound = spanners[0]->get_bound (d);
- else
-   {
- bound = unsmob_grob (get_property ("currentMusicalColumn"));
- if (!early_end_)
-   programming_error ("started DynamicLineSpanner but have no left 
bound");
-   }
-
+for (vsize i = 0; i < scripts_.size (); i++)
+  if (!Grob::in_own_family_tree (scripts_[i], line_))
+  {
+   bound = scripts_[i];
+   break;
+  }
+ if (!bound)
+if (spanners.size ())
+  for (vsize i = 0; i < spanners.size (); i++)
+if (!Grob::in_own_family_tree (spanners[i]->get_bound (d),  
line_))

+{
+  bound = spanners[i]->get_bound (d);
+  break;
+}
+  if (!bound)
+{
+  bound = unsmob_grob (get_property ("currentMusicalColumn"));
+  if (!early_end_ && !spanners.size () && !scripts_.size ())
+programming_error ("started DynamicLineSpanner but have no  
left bound");

+}
  line_->set_bound (d, bound);
}
 }
Index: lily/grob.cc
diff --git a/lily/grob.cc b/lily/grob.cc
index  
c613effccc65fd6be001aad742e41a1ed29b15a4..43c0cdbd4339307df676117d576c4346a39b23a6  
100644

--- a/lily/grob.cc
+++ b/lily/grob.cc
@@ -524,9 +524,31 @@ Grob::common_refpoint (Grob const *s, Axis a) const
   return 0;
 }

+bool
+Grob::in_own_family_tree (Grob *g, Grob *orig)
+{
+  if (!g)
+{
+  orig->programming_error ("Setting grob parent to a null pointer.");
+  return false;
+}
+  if (g == orig)
+return true;
+  Grob *x_parent = g->get_parent (X_AXIS);
+  Grob *y_parent = g->get_parent (Y_AXIS);
+  bool in_tree = false;
+  if (x_parent)
+in_tree = in_tree || in_own_family_tree (x_parent, orig);
+  if (y_parent)
+in_tree = in_tree || in_own_family_tree (y_parent, orig);
+  return in_tree;
+}
+
 void
 Grob::set_parent (Grob *g, Axis a)
 {
+  if (do_internal_grob_family_tree_checking_global)
+assert (!in_own_family_tree (g, this));
   dim_cache_[a].parent_ = g;
 }

Index: lily/include/grob.hh
diff --git a/lily/include/grob.hh b/lily/include/grob.hh
index  
eda94b6d5888b1778897658c683c7c20c5c57944..36c0fda8cf0b29a3e03de3dd554915273945c5de  
100644

--- a/lily/include/grob.hh
+++ b/lily/include/grob.hh
@@ -137,6 +137,7 @@ public:

   /* refpoints */
   Grob *common_refpoint (Grob const *s, Axis a) const;
+  static bool in_own_family_tree(Grob *g, Grob *orig);
   void set_parent (Grob *e, Axis);
   Grob *get_parent (Axis a) const;
   void fixup_refpoint ();
Index: lily/include/main.hh
diff --git a/lily/include/main.hh b/lily/include/main.hh
index  
7fa0905c83dc559bf0dc5c49950b263d58617d99..c512cc97c3a306c22482e84bd94bfa9f6ef52034  
100644

--- a/lily/include/main.hh
+++ b/lily/include/main.hh
@@ -44,6 +44,7 @@ extern string output_name_global;
 extern bool be_safe_global;
 extern bool be_verbose_global;
 extern bool do_internal_type_checking_global;
+extern bool do_internal_grob_family_tree_checking_global;
 extern bool point_and_click_global;
 extern string lilypond_datadir;
 extern bool use_object_keys;
Index: lily/pitched-trill-engraver.cc
diff --git a/lily/pitched-trill-engraver.cc b/lily/pitched-trill-engraver.cc
index  
6960d3e2dd1883d390daff87f982aefa7483da2f..8d2d599c5953f20596a25c2b29c640215c5ad7d6  
100644

--- a/lily/pitched-trill-engraver.cc
+++ b/lily/pitched-trill-engraver.cc
@@ -114,17 +114,17 @@ Pitched_trill_engraver::make_trill (Stream_event *ev)
   trill_head_ = 0;
 }

+  trill_group_ = make_item ("TrillPitchGroup", ev->self_scm ());
   trill_head_ = make_item ("TrillPitchHead", ev->self_scm ());
   SCM c0scm = g

Grobs that are their own ancestors.

2011-07-15 Thread mike 
I've now gone on a quest for parental loops in the source, and I've found some:

chord-repetition.ly
chord-tremolo-articulations.ly
dynamics-alignment-breaker.ly
dynamics-alignment-no-line.ly
dynamics-glyphs.ly
dynamics-line.ly
dynamics-rest-positioning.ly
dynamics-text-right-padding.ly
dynamics-text-spanner-abs-dynamic.ly

After this I stopped checking, but in all of these, the DynamicLineSpanner is 
its own parent if you trace back its ancestry.  The culprit is line 179 of 
dynamic-align-engraver - if anyone has any intuition as to why this is the 
case, lemme know!  Otherwise, I'll be able to look into it next week.

Then, in context-die-staff.ly, in fixup_refpoint, a grob is passed a null 
pointer as its parent (the variable newparent).  Any ideas as to where this 
error may be coming from?

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

Re: 2.15.5 regtests

2011-07-15 Thread Phil Holmes 
- Original Message - 
From: "Reinhold Kainhofer" 

To: "Phil Holmes" ; 
Sent: Friday, July 15, 2011 5:36 PM
Subject: Re: 2.15.5 regtests


On Fr., 15. Jul. 2011 15:35:37 CEST, Phil Holmes  
wrote:



Looks pretty clean.   Continuing midi warnings from
http://code.google.com/p/lilypond/issues/detail?id=1678

An interesting change from mozart-hrn-3.log

"+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/mozart-hrn3-allegro.ily:129:17:
warning: already have slur
+   \longgrace d16
+   ( \endlonggrace "

This was also noted by James in
http://code.google.com/p/lilypond/issues/detail?id=75.   Reinhold said:

"That warning is okay (it was a bug that the warning wasn't shown so
far),   it really uses two nested slurs (one normal and another one for
the grace) However, that whole code is really strange:"

I'm tempted to report this as a bug in the regtest?


Yaeh, that example should really be cleaned up!

Cheers,
Reinhold

==

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



--
Phil Holmes



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

Re: 2.15.5 regtests

2011-07-15 Thread Reinhold Kainhofer 
On Fr., 15. Jul. 2011 15:35:37 CEST, Phil Holmes  wrote:

> Looks pretty clean.   Continuing midi warnings from 
> http://code.google.com/p/lilypond/issues/detail?id=1678
> 
> An interesting change from mozart-hrn-3.log
> 
> "+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/mozart-hrn3-allegro.ily:129:17:
>  
> warning: already have slur
> +     \longgrace d16
> +                                 ( \endlonggrace "
> 
> This was also noted by James in 
> http://code.google.com/p/lilypond/issues/detail?id=75.   Reinhold said:
> 
> "That warning is okay (it was a bug that the warning wasn't shown so
> far),   it really uses two nested slurs (one normal and another one for
> the grace) However, that whole code is really strange:"
> 
> I'm tempted to report this as a bug in the regtest?

Yaeh, that example should really be cleaned up!

Cheers,
Reinhold

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

Re: Allows for rider grobs in outside-staff-priority. (issue4639075)

2011-07-15 Thread mtsolo 

On 2011/07/14 20:23:03, Neil Puttock wrote:

On 14 July 2011 21:01, mailto:m...@apollinemike.com

 wrote:


> I'll run the regtests tonight or tomorrow and report back.



I've just tried this and I think you've got an infinite loop somewhere
(I had to kill the process and reboot).



Edit: it's from tie-pitched-trill.ly; segfaults due to stack overflow.



Cheers,
Neil


I just ran regtests with this new patch and that fixes it.
There must be some type of loop in the grobs' family trees...

Cheers,
MS

http://codereview.appspot.com/4639075/

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

Re: Does type checking for all context property sets. (issue4654090)

2011-07-15 Thread mtsolo 

On 2011/07/14 14:56:00, Carl wrote:

LGTM.



With Neil's approval I think we can go ahead and push.


Thanks.
Pushed as a811a3c91c05f33474c1d447bedaa1e089522532.

Cheers,
MS

http://codereview.appspot.com/4654090/

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

Re: GOP-PROP 5: build system output (update)

2011-07-15 Thread Phil Holmes 
- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Friday, July 15, 2011 4:43 PM
Subject: Re: GOP-PROP 5: build system output (update)



On Fri, Jul 15, 2011 at 02:20:51PM +0100, Phil Holmes wrote:

- Original Message - From: "Graham Percival"
>   * All output will be saved to various log files. (including
> output from make(1))
>   * We will still display the output of make(1) on the console.

I read these as mutually exclusive.  Are you saying we'll send the
output of make both to a console and a log file?  Why?


Yes.  (well, "proposing" rather than "saying that we will")

- package maintainers (evidently) want to see the normal output of
 make(1).  Also, it anybody doesn't want to see that, they can
 trivially avoid it by doing make --silent.
- we'll still have tons of output, and some terminals only save
 1000 lines (for example).  If something goes wrong and I want
 to see exactly what commands were run, it'll be much easier to
 look at those commands if they were dumped verbatim into a
 test file.

I'm not certain if it's possible to cause make(1) to automatically
put its output into a logfile in addition to the console.  If not,
or if it looks really finicky to do this, then I'm quite willing
to withdraw this aspect of the proposal.  But if we're discussing
our ideal for the build system, mine would include this.


From my reading of the manual, there is no option to redirect make output to 
a logfile.  I always do this with a command line redirect.  AFAICS the only 
other way to do this would be to wrap make in another program that captures 
its output to log and console - Kili wrote something like this.  However, 
I'm personally rather loathe to do such wrapping.



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

I think there should be an option to turn it all back on if you want
- a sort of inverse of QUIET_BUILD.  We should also get rid of the
QUIET_BUILD variable completely.


Agreed.  Maybe using the V=1 thing that Jan was talking about?


That sort of thing.  I'd propose a variable called VERBOSE that would have 
to be set to get the output on screen.



>   * Both stderr and stdout will be saved in *.log. The order of
> lines from these streams must be preserved.

I do not believe this is possible, given the buffered nature of
stdout.  See the font of all Unix knowledge, Wikipedia, when
discussing sending both streams to the same file:

"Messages appear in the same order as the program writes them,
unless buffering is involved. (For example, a common situation is
when the standard error stream is unbuffered but the standard output
stream is line-buffered; in this case, text written to standard
error later may appear on the terminal earlier, if the standard
output stream's buffer is not yet full.)"


Hmm.  I've heard people talking about this, but I can't recall
ever running into this problem in lilypond development.  That
said, I almost always do multi-cpu builds, so I'm never surprised
when I see error messages apparently out of order -- but the
errors always make sense when I try a second make(1) call without
multi-threading.

Can we change the buffering on streams?  I wouldn't be surprised
if we could do that.  Or maybe this is an argument in favor of
always using stderr, since that (apparently) guarantees unbuffered
output?

At the moment, I'm thinking that we should acknowledge this as a
theoretical possibility, leave it in the policy as an "intended
behavior", and then go on with life.  If we have a bug report
about the actual behavior not following the intended behavior,
then we'll look at the technical issues in that bug, and if the
technical issues are unsurmountable, we can modify the policy.


Agreed.  I honestly don't think the slight possiblity of out-of-order 
messages should stop this.



>   * Ideally, a failing build should provide hints about the
> reason why it failed, or at least hints about which log
> file(s) to examine.

Seems a repeat of bullet point 3?


I think there's miscommunication here.  I see bullet point 3 as "
Logfiles from calling lilypond... all other logfiles will go
in..."
That bullet point is talking about informing the user of *which*
logfile to examine (we'll have a lot of logfiles, so guesswork
wouldn't be fun!), and possibly even output to console a portion
of the relevant logfile.

How could I clarify the language in those bullet points, or did
you mean a different bullet point?


I read the 2 bullets about indicating log files to examine as being similar. 
You're right - they're somewhat different.


--
Phil Holmes



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

Re: GOP-PROP 5: build system output (update)

2011-07-15 Thread Graham Percival 
On Fri, Jul 15, 2011 at 02:20:51PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> >   * All output will be saved to various log files. (including
> > output from make(1))
> >   * We will still display the output of make(1) on the console.
> 
> I read these as mutually exclusive.  Are you saying we'll send the
> output of make both to a console and a log file?  Why?

Yes.  (well, "proposing" rather than "saying that we will")

- package maintainers (evidently) want to see the normal output of
  make(1).  Also, it anybody doesn't want to see that, they can
  trivially avoid it by doing make --silent.
- we'll still have tons of output, and some terminals only save
  1000 lines (for example).  If something goes wrong and I want
  to see exactly what commands were run, it'll be much easier to
  look at those commands if they were dumped verbatim into a
  test file.

I'm not certain if it's possible to cause make(1) to automatically
put its output into a logfile in addition to the console.  If not,
or if it looks really finicky to do this, then I'm quite willing
to withdraw this aspect of the proposal.  But if we're discussing
our ideal for the build system, mine would include this.

> >   * 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.
> 
> I think there should be an option to turn it all back on if you want
> - a sort of inverse of QUIET_BUILD.  We should also get rid of the
> QUIET_BUILD variable completely.

Agreed.  Maybe using the V=1 thing that Jan was talking about?

> >   * Both stderr and stdout will be saved in *.log. The order of
> > lines from these streams must be preserved.
> 
> I do not believe this is possible, given the buffered nature of
> stdout.  See the font of all Unix knowledge, Wikipedia, when
> discussing sending both streams to the same file:
> 
> "Messages appear in the same order as the program writes them,
> unless buffering is involved. (For example, a common situation is
> when the standard error stream is unbuffered but the standard output
> stream is line-buffered; in this case, text written to standard
> error later may appear on the terminal earlier, if the standard
> output stream's buffer is not yet full.)"

Hmm.  I've heard people talking about this, but I can't recall
ever running into this problem in lilypond development.  That
said, I almost always do multi-cpu builds, so I'm never surprised
when I see error messages apparently out of order -- but the
errors always make sense when I try a second make(1) call without
multi-threading.

Can we change the buffering on streams?  I wouldn't be surprised
if we could do that.  Or maybe this is an argument in favor of
always using stderr, since that (apparently) guarantees unbuffered
output?

At the moment, I'm thinking that we should acknowledge this as a
theoretical possibility, leave it in the policy as an "intended
behavior", and then go on with life.  If we have a bug report
about the actual behavior not following the intended behavior,
then we'll look at the technical issues in that bug, and if the
technical issues are unsurmountable, we can modify the policy.

> >   * Ideally, a failing build should provide hints about the
> > reason why it failed, or at least hints about which log
> > file(s) to examine.
> 
> Seems a repeat of bullet point 3?

I think there's miscommunication here.  I see bullet point 3 as "
Logfiles from calling lilypond... all other logfiles will go
in..."

That bullet point is talking about informing the user of *which*
logfile to examine (we'll have a lot of logfiles, so guesswork
wouldn't be fun!), and possibly even output to console a portion
of the relevant logfile.

How could I clarify the language in those bullet points, or did
you mean a different bullet point?


Cheers,
- Graham

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

Re: 2.15.5 regtests

2011-07-15 Thread Phil Holmes 
"Phil Holmes"  wrote in message 
news:ivpfnb$n5p$1...@dough.gmane.org...
Looks pretty clean.  Continuing midi warnings from 
http://code.google.com/p/lilypond/issues/detail?id=1678


An interesting change from mozart-hrn-3.log

"+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/mozart-hrn3-allegro.ily:129:17: 
warning: already have slur

+   \longgrace d16
+ ( \endlonggrace "

This was also noted by James in 
http://code.google.com/p/lilypond/issues/detail?id=75.  Reinhold said:


"That warning is okay (it was a bug that the warning wasn't shown so far), 
it really uses two nested slurs (one normal and another one for the grace)

However, that whole code is really strange:"

I'm tempted to report this as a bug in the regtest?

--
Phil Holmes
Bug Squad


Two major changes revealed in the pixel-comparison.  1.  Different brace 
shape.  This looks like 
http://code.google.com/p/lilypond/issues/detail?id=1712.  2. 
lyric-hyphen-grace.ly now has nested slurs with the grace note.  I assume 
this is issue 75 again, but the regtest now looks wrong - it would seem that 
the slur should end earlier.  See attached.


--
Phil Holmes
Bug Squad

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

Re: Adds redirect-lilypond-output option tolilypond-book(issue4664060)

2011-07-15 Thread Graham Percival 
On Fri, Jul 15, 2011 at 02:04:56PM +0100, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> 
> >
> >Perhaps, in yet another stunning example of mis-management, this
> 
> As it stands, this patch does nothing unless you turn on the
> redirect-lilypond-output for lilypond book, so it's zero impact
> unless anyone deliberately uses it.

> Given that this patch has zero effect unless it's deliberately used,
> and has zero effect of mixing, let's go with it now.

Ok.  Could you send me the final patch for pushing?  IIRC we've
finished the countdown.

Cheers,
- Graham

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

2.15.5 regtests

2011-07-15 Thread Phil Holmes 
Looks pretty clean.  Continuing midi warnings from 
http://code.google.com/p/lilypond/issues/detail?id=1678


An interesting change from mozart-hrn-3.log

"+/main/src/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression/mozart-hrn3-allegro.ily:129:17: 
warning: already have slur

+   \longgrace d16
+ ( \endlonggrace "

This was also noted by James in 
http://code.google.com/p/lilypond/issues/detail?id=75.  Reinhold said:


"That warning is okay (it was a bug that the warning wasn't shown so far), 
it really uses two nested slurs (one normal and another one for the grace)

However, that whole code is really strange:"

I'm tempted to report this as a bug in the regtest?

--
Phil Holmes
Bug Squad




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

Re: GOP-PROP 5: build system output (update)

2011-07-15 Thread Phil Holmes 
- Original Message - 
From: "Graham Percival" 

To: 
Sent: Thursday, July 14, 2011 5:09 PM
Subject: GOP-PROP 5: build system output (update)



Update on this; I'm not ready to call it a "probable decision"
yet.
http://lilypond.org/~graham/gop/gop_5.html

(proposal written by Phil Holmes, modified by Graham)


** Proposal summary

When you run make or make doc,

   * All output will be saved to various log files. (including
 output from make(1))
   * We will still display the output of make(1) on the console.


I read these as mutually exclusive.  Are you saying we'll send the output of 
make both to a console and a log file?  Why?



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


I think there should be an option to turn it all back on if you want - a 
sort of inverse of QUIET_BUILD.  We should also get rid of the QUIET_BUILD 
variable completely.



   * 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 must be preserved.


I do not believe this is possible, given the buffered nature of stdout.  See 
the font of all Unix knowledge, Wikipedia, when discussing sending both 
streams to the same file:


"Messages appear in the same order as the program writes them, unless 
buffering is involved. (For example, a common situation is when the standard 
error stream is unbuffered but the standard output stream is line-buffered; 
in this case, text written to standard error later may appear on the 
terminal earlier, if the standard output stream's buffer is not yet full.)"



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


Seems a repeat of bullet point 3?



** Rationale

Before any of the current work on reducing output from make, the
result of a "make doc" was over 500,000 lines of text. Finding
errors or warnings in that volume of output is always going to be
hard. 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. 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.

A variable, QUIET_BUILD, can be set and this will reduce the
clutter but not eliminate it. (see
http://lilypond.org/doc/v2.15/Documentation/contributor/useful-make-variables
) This variable currently does things like adding a -q flag to the
TEXI2PDF call ("quiet") and getting rid of the –verbose flag in
some calls to LilyPond. However, it could be used more widely, as
proposed below.


** Implementation notes

none yet


Cheers,
- Graham

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




--
Phil Holmes



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

Re: Adds redirect-lilypond-output option tolilypond-book(issue4664060)

2011-07-15 Thread Phil Holmes 
- Original Message - 
From: "Graham Percival" 


Perhaps, in yet another stunning example of mis-management, this
entire patch should be withdrawn pending the GOP stdout/stderr
discussion.  The introduction of that discussion is pending us
finally finishing the C++ question, which itself is pending
another policy update, which itself was delayed due to my
travelling.



As it stands, this patch does nothing unless you turn on the 
redirect-lilypond-output for lilypond book, so it's zero impact unless 
anyone deliberately uses it.  It then sends a null stream (lilypond's stdout 
output) to one file and an output stream (lilypond's stderr output) to 
another.  So there's a 0% possibility of output being mixed, since you can't 
mix something with nothing and get a different result.


In the event that some of lilypond's output were sent to stdout, this would 
have to be done such that the 2 streams (stdout and stderr) are usable on 
their own.  Otherwise the buffering idiosyncrasies of the OS are always 
going to cause problems.


Given that this patch has zero effect unless it's deliberately used, and has 
zero effect of mixing, let's go with it now.


--
Phil Holmes



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

Re: Adds redirect-lilypond-output option to lilypond-book(issue4664060)

2011-07-15 Thread Phil Holmes 
- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: ; "David Kastrup" 
Sent: Wednesday, July 13, 2011 5:57 PM
Subject: Re: Adds redirect-lilypond-output option to 
lilypond-book(issue4664060)




On Wed, Jul 13, 2011 at 03:26:18PM +0100, Phil Holmes wrote:

- Original Message - From: "David Kastrup" 
To: 
>percival.music...@gmail.com writes:
>
>>in light of the growing consensus for "combined" logfiles for the build
>>system -- and given that lilypond only produces stuff on stderr and
>>apparently this isn't going to change -- I wonder if it might be better
>>to redirect both stdout and sterr to a single .log file.
>
>Redirecting two file pointers to the same file has a tendency to wreak
>havoc with buffering.
>
>So it is not something I am overly comfortable with.


ok, if/when we add this, we'd use a different way of recording
output.  I'm certain that python's subprocess module has some way
of doing this.


My understanding (which is certainly not perfect) is that one of the
stream is buffered (stdout from memory, without checking) and the
other isn't, so that the worst that happens is that the lines are
not quite in the order that might be expected.


That "worst that happens" is beyond what's acceptable.  Seeing an
error message before the command that causes the error?  That
could easily chew up 10 hours of fruitless debugging while
somebody investigates a perfectly good command.


Do you know that the order is _always_ correct when sent to terminal?  If 
what I said about buffering is true, you could easily get the same problem 
to the terminal.


If it's vitally important that the order of output to stdout and stderr are 
in a specific fixed order then programs that use both must ensure the order, 
not rely on quicks of the buffering of the OS.  Furthermore, if it's 
possible for a program to write something like "processing line z" to stdout 
and then "error in processing line" to stderr, then that's a bug in the 
error handling of the program.


TBH, it's my considered view that, since this possibility doesn't even occur 
in the issue we're talking about (since we're only affecting output from 
Lilypond, and that _only_ goes to stderr) then we're effectivly debating how 
many angels can fit on the head of a pin.



In light of this, let's go ahead with the separate log files for
now.

Cheers,
- Graham



Agreed.

--
Phil Holmes



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

Re: Adapt fixcc.py to use Astyle and/or emacs (issue4662074)

2011-07-15 Thread Trevor Daniels 


Keith OHara wrote Friday, July 15, 2011 4:50 AM


On Thu, 14 Jul 2011 00:47:58 -0700, Trevor Daniels 
 wrote:




I was hoping to recommend going with this, so we could
wrap up this issue, but then I found

- new_context->event_source ()->
-   add_listener (GET_LISTENER
(new_context->create_context_from_event),
+ new_context->event_source ()->
+ add_listener (GET_LISTENER
(new_context->create_context_from_event),

which looks wrong to me (by any measure of code clarity).



I commented on this in Patch Set 3,


Ah, sorry, I didn't follow all the twists and turns in
this carefully enough.


but it doesn't bother me too badly.


Well, no.  Overall the proposed change is a definite
improvement.

I put in an enhancement request for Astyle to indent multi-line 
statements.


Good.  So I would be happy to see your patch applied
as it is now, with this change being implemented whenever
it appears.  I don't see that causing much difficulty with
broken patches.

GNU style, interpreted literally, would put the binary operator -> 
on the second line.  I could easily make fixcc.py enforce this, if 
you think it helps:


new_context->event_source ()
->add_listener (GET_LISTENER 
(new_context->create_context_from_event),

ly_symbol2scm ("CreateContext"));


I'm not sure it does.  It's the indentation that immediately
shows the line is a continuation.

Trevor



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

Re: GOP-PROP 5: build system output (update)

2011-07-15 Thread Jan Warchoł 
2011/7/14 Graham Percival :
> ** Proposal summary
>
> When you run make or make doc,
>
>    * All output will be saved to various log files. (including
>      output from make(1))
>    * We will still display the output of make(1) on the console.
>    * 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.
>    * 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 must 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.

LGTM.

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