Re: Progress indicator

2009-09-26 Thread Neil Puttock
2009/9/26 Michael Käppler :

> I can confirm this for most cases. But I've had other experiences too AFAIK;

So far every file I've checked takes a fraction of a second for stages
one - four.

> Could you please do a batch run with some files in --verbose mode,
> using the attached patch and output all to a logfile?

Sure, see the attached logfile.

Regards,
Neil


test.log.tar.gz
Description: GNU Zip compressed data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Progress indicator

2009-09-26 Thread Michael Käppler



If my test runs are indicative of the average timings, then you might
as well junk all the stages apart from the last, since they only take
up a few seconds of the preprocessing time.  Of course, that then
  
I can confirm this for most cases. But I've had other experiences too 
AFAIK; Could you please do a batch run with some files in --verbose mode,

using the attached patch and output all to a logfile?

leaves the issue with the last stage stalling at 81%: it's not much
use as a progress indicator if 82 - 100% only takes a few seconds.
  

That is about the font loading, I think; I'll take a look on it later.

Regards,
Michael

>From 9e8766b370e907b9ebb1a626dcc386104680c29e Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Michael=20K=C3=A4ppler?= 
Date: Thu, 24 Sep 2009 18:26:32 +0200
Subject: [PATCH] Implement a progress indicator for the grob-preprocessing stages.

---
 lily/include/misc.hh |2 +
 lily/misc.cc |   18 ++--
 lily/system.cc   |  115 +++--
 scm/lily.scm |6 +++
 4 files changed, 122 insertions(+), 19 deletions(-)

diff --git a/lily/include/misc.hh b/lily/include/misc.hh
index 12392c0..45af373 100644
--- a/lily/include/misc.hh
+++ b/lily/include/misc.hh
@@ -48,5 +48,7 @@ Real peak_around (Real epsilon,  Real threshold, Real x);
 Real convex_amplifier (Real standard_x, Real increase_factor, Real x);
 string camel_case_to_lisp_identifier (string in);
 
+int array_sum (const int values[], int max);
+
 #endif
 
diff --git a/lily/misc.cc b/lily/misc.cc
index ee55a00..792a4db 100644
--- a/lily/misc.cc
+++ b/lily/misc.cc
@@ -57,32 +57,40 @@ peak_around (Real epsilon,  Real threshold, Real x)
 }
 
 /*
-  0 at 0,  1 at standard_x, and increasing thereafter. 
+  0 at 0,  1 at standard_x, and increasing thereafter.
  */
 Real
 convex_amplifier (Real standard_x, Real increase_factor, Real x)
 {
-  return (exp (increase_factor * x / standard_x) - 1.0) / (exp (increase_factor) - 1.0); 
+  return (exp (increase_factor * x / standard_x) - 1.0) / (exp (increase_factor) - 1.0);
 }
 
 string
 camel_case_to_lisp_identifier (string in)
 {
   vector out;
-  
+
   /* don't add '-' before first character */
   out.push_back (char (tolower (in[0])));
-
+
   for (size_t inpos = 1; inpos < in.size (); inpos++)
 {
   if (isupper (in[inpos]))
 	out.push_back ('-');
   out.push_back ( char(tolower (in[inpos])));
 }
-  
+
   string result (&out[0], out.size ());
   replace_all (&result, '_', '-');
 
   return result;
 }
 
+int
+array_sum (const int values[], const int max)
+{
+  int sum = 0;
+  for (int i = 0; i < max; i++)
+sum += values[i];
+  return sum;
+}
diff --git a/lily/system.cc b/lily/system.cc
index a43c1b4..0635601 100644
--- a/lily/system.cc
+++ b/lily/system.cc
@@ -11,20 +11,24 @@
 #include "align-interface.hh"
 #include "all-font-metrics.hh"
 #include "axis-group-interface.hh"
+#include "cpu-timer.hh"
 #include "grob-array.hh"
 #include "hara-kiri-group-spanner.hh"
 #include "international.hh"
 #include "lookup.hh"
 #include "main.hh"
+#include "misc.hh"
 #include "output-def.hh"
 #include "page-layout-problem.hh"
 #include "paper-column.hh"
 #include "paper-score.hh"
 #include "paper-system.hh"
 #include "pointer-group-interface.hh"
+#include "program-option.hh"
 #include "skyline-pair.hh"
 #include "staff-symbol-referencer.hh"
 #include "warn.hh"
+#include 
 
 System::System (System const &src)
   : Spanner (src)
@@ -244,7 +248,7 @@ System::break_into_pieces (vector const &breaking)
 	system_labels = scm_append (scm_list_2 (col_labels, system_labels));
 	}
   system->set_property ("labels", system_labels);
-  
+
   set_loose_columns (system, &breaking[i]);
   broken_intos_.push_back (system);
 }
@@ -269,35 +273,118 @@ System::add_column (Paper_column *p)
 }
 
 void
+progress_output (int progress)
+{
+  string backspaces;
+  ostringstream poutput;
+  poutput << " (" << progress << " %)";
+  for (unsigned bs = 0; bs < poutput.str ().size (); bs++)
+backspaces+= "\b";
+  progress_indication (poutput.str () + backspaces);
+}
+
+void
 System::pre_processing ()
 {
-  for (vsize i = 0; i < all_elements_->size (); i++)
-all_elements_->grob (i)->discretionary_processing ();
+  const unsigned min_process_grobs = robust_scm2int (ly_get_option
+ (ly_symbol2scm ("min-grobs-indicator")), 0);
+
+  bool show_progress = (all_elements_->size () >= min_process_grobs);
+  SCM stages_weight_scm = ly_get_option (ly_symbol2scm ("preprocessing-stages-weight"));
+  int stages_weig

Re: Progress indicator

2009-09-26 Thread David Kastrup
Michael Käppler  writes:

>> Have you tested this using an editor?  I've tried a fairly long piece
>>   
> No, I haven't.
>> using Frescobaldi and LilyPondTool, and neither likes the backspaces:
>>
>> Preprocessing graphical objects... (1 %) (2 %) (3 %)
>> (4 %) (5 %) (6 %) (7 %) (8 %) (9
>> %) (10 %) (11
>>   
> Argh... I admit that it isn't a very clean way to do this. I'll try to
> find a better solution (never thought that it would be as tricky as it
> actually seems to be...)

An editor will not interpret control characters.  One solution is to
check whether output is sent to a tty and only then use progress
indicators.  Or at least overprinting.

-- 
David Kastrup



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


Re: Progress indicator

2009-09-25 Thread Graham Percival
On Sat, Sep 26, 2009 at 12:29:34AM +0200, Michael Käppler wrote:
>
>> Preprocessing graphical objects... (1 %) (2 %) (3 %)
>> (4 %) (5 %) (6 %) (7 %) (8 %) (9
>> %) (10 %) (11
>>   
> Argh... I admit that it isn't a very clean way to do this. I'll try to  
> find a better solution (never thought that it would be as tricky as it  
> actually seems to be...)

Why not just print the 10%s ?  I mean, the other lilypond "status
indicators" just print out bar numbers.

Cheers,
- Graham


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


Re: Progress indicator

2009-09-25 Thread Neil Puttock
2009/9/25 Michael Käppler :

> Hmm... I'll try to introduce a --verbose mode that prints the time needed
> for each stage, so we can run a test suite and hopefully get to considerable
> defaults.

If my test runs are indicative of the average timings, then you might
as well junk all the stages apart from the last, since they only take
up a few seconds of the preprocessing time.  Of course, that then
leaves the issue with the last stage stalling at 81%: it's not much
use as a progress indicator if 82 - 100% only takes a few seconds.

> Can you propose a good way how to set the constants in Lily or SCM code?

I suppose the easiest way is to introduce a program option which can
be set via -d (with a sensible default set in lily.scm).

Regards,
Neil


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


Re: Progress indicator

2009-09-25 Thread Michael Käppler



Have you tested this using an editor?  I've tried a fairly long piece
  

No, I haven't.

using Frescobaldi and LilyPondTool, and neither likes the backspaces:

Preprocessing graphical objects... (1 %) (2 %) (3 %)
(4 %) (5 %) (6 %) (7 %) (8 %) (9
%) (10 %) (11
  
Argh... I admit that it isn't a very clean way to do this. I'll try to 
find a better solution (never thought that it would be as tricky as it 
actually seems to be...)

The lion's share of the preprocessing time is taken up by
springs-and-rods (i.e., after 80%); when run via the command line, it
was difficult to see anything before 81% (and it sits around here for
a long time before zipping up to 100%).
  
Hmm... I'll try to introduce a --verbose mode that prints the time 
needed for each stage, so we can run a test suite and hopefully get to 
considerable defaults.

Can you propose a good way how to set the constants in Lily or SCM code?

Regards,
Michael



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


Re: Progress indicator

2009-09-25 Thread Neil Puttock
2009/9/24 Michael Käppler :

> I'd like to propose the following as a possibility to provide a simple
> progress indicator for the "Preprocessing graphical objects" stage.
> I'm happy to read your comments.

Have you tested this using an editor?  I've tried a fairly long piece
using Frescobaldi and LilyPondTool, and neither likes the backspaces:

Preprocessing graphical objects... (1 %) (2 %) (3 %)
(4 %) (5 %) (6 %) (7 %) (8 %) (9
%) (10 %) (11

The lion's share of the preprocessing time is taken up by
springs-and-rods (i.e., after 80%); when run via the command line, it
was difficult to see anything before 81% (and it sits around here for
a long time before zipping up to 100%).

Warning messages interrupt the progress indication, though there's
probably nothing you can do about this.

Regards,
Neil


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


Progress indicator

2009-09-24 Thread Michael Käppler

Hi all,
I'd like to propose the following as a possibility to provide a simple 
progress indicator for the "Preprocessing graphical objects" stage.

I'm happy to read your comments.

http://codereview.appspot.com/122051

Regards,
Michael



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


Re: progress indicator?

2009-08-03 Thread Werner LEMBERG

>> Any chance to add a progress indicator, for example, giving the
>> ratio between the total number of grobs and the grobs already
>> processed?
> 
> What could be done is having a progress indicator showing the number
> grob/property combinations that were computed.

OK.  Even a rotating dash would be a better than nothing...


Werner


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


Re: progress indicator?

2009-08-03 Thread Han-Wen Nienhuys
On Mon, Aug 3, 2009 at 6:22 AM, Werner LEMBERG wrote:
>
> For longer pieces, lilypond takes ages for the `preprocessing
> graphical elements' stage.  For the novice, it might appear that
> lilypond hangs.  Any chance to add a progress indicator, for example,
> giving the ratio between the total number of grobs and the grobs
> already processed?

That's less trivial than it sounds.  Because all computation is done
lazily, we don't know how many grobs there are to be processed.  What
could be done is having a progress indicator showing the number
grob/property combinations that were computed.

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


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


progress indicator?

2009-08-03 Thread Werner LEMBERG

For longer pieces, lilypond takes ages for the `preprocessing
graphical elements' stage.  For the novice, it might appear that
lilypond hangs.  Any chance to add a progress indicator, for example,
giving the ratio between the total number of grobs and the grobs
already processed?


Werner


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


Re: Progress indicator missing

2006-11-05 Thread Han-Wen Nienhuys

Werner LEMBERG escreveu:

The phases

  Preprocessing graphical objects...

and

  Layout output to `%s'...

can take a lng time with big scores.  What about a progress
indicator?  Ideally this should be a percentage, but any number will
do just to indicate that something is happening.



Most of the formatting backend is demand-driven, so it's not always 
clear how much time an operation takes,


  obj->get_property ("direction")

may return a number directly, or trigger a complete (re)formatting of 
the entire score.



The time is probably spent in

System::pre_processing ()
System::post_processing ()

please experiment a bit with what would be useful.



--

Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com



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


Progress indicator missing

2006-11-03 Thread Werner LEMBERG

The phases

  Preprocessing graphical objects...

and

  Layout output to `%s'...

can take a lng time with big scores.  What about a progress
indicator?  Ideally this should be a percentage, but any number will
do just to indicate that something is happening.


Werner


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