Re: Some fixes to musicxml2ly

2006-09-16 Thread Tuukka Verho
On Fri, 2006-09-15 at 22:11 +0300, Tuukka Verho wrote:

> The attached diff for musicxml.py now has an explanatory comment.

Oops, sent a diff without the comment. Here comes the correnct version.

Tuukka
--- lilypond/python/musicxml.py	2006-08-26 01:04:08.0 +0300
+++ musicxml.py	2006-09-16 10:12:27.0 +0300
@@ -1,4 +1,5 @@
 import new
+import math
 from rational import *
 
 class Xml_node:
@@ -193,7 +194,22 @@
 'long': -2,
 'whole': 0} [log]
 	else:
-	return 0
+	# Using floating point arithmetic here to calculate logarithm
+	# the term 2**tolerance_exp ensures that borderline cases are
+	# rounded to the next whole duration
+	
+	tolerance_exp = -4  # means that notes that are 1/32 or less 
+	# shorter than 1/4 will be quarter notes etc.
+	return int (math.ceil 
+	   (-math.log (self._duration) / math.log (2)  - 2**tolerance_exp))
+
+def get_num_dots(self):
+if self.get_maybe_exist_typed_child (class_dict['type']):
+return len (self.get_typed_children (Dot))
+
+else:
+factor = self._duration / 2**(-self.get_duration_log())
+return int (round (-math.log(2 - factor) / math.log(2)))
 
 def get_factor (self):
 	return 1
@@ -351,27 +367,26 @@
 	elements.extend (m.get_all_children ())
 
 	start_attr = None
-	for n in elements:
-	voice_id = n.get_maybe_exist_typed_child (class_dict['voice'])
-
-	if not (voice_id or isinstance (n, Attributes)):
-		continue
-
-	if isinstance (n, Attributes) and not start_attr:
-		start_attr = n
-		continue
-
-	if isinstance (n, Attributes):
-		for v in voices.values ():
+	for n in elements:	
+	if (isinstance (n, Note)):
+	   voice_id = n.get_maybe_exist_typed_child (get_class('voice'))		
+	   if voice_id:
+	  id = voice_id.get_text ()  
+	   else:
+	  id = '1'
+	 	   
+	   if not voices.has_key (id):
+	 voices[id] = Musicxml_voice()
+		   
+	   voices[id].add_element (n)
+
+	elif isinstance (n, Attributes):
+	   if not start_attr:
+	  start_attr = n
+	  
+	   for v in voices.values ():
 		v.add_element (n)
-		continue
-
-	id = voice_id.get_text ()
-	if not voices.has_key (id):
-		voices[id] = Musicxml_voice()
-
-	voices[id].add_element (n)
-
+	 
 	if start_attr:
 	for (k,v) in voices.items ():
 		v.insert (0, start_attr)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: Some fixes to musicxml2ly

2006-09-16 Thread Karl Hammar

[EMAIL PROTECTED]:
> On Fri, 2006-09-15 at 19:33 +0200, Han-Wen Nienhuys wrote:
> > 
> > > else:
> > > -   return 0
> > > +   tolerance_exp = -4  # means that notes that are 1/32 or less 
> > > shorter
> > > than 1/4 are quarter notes etc.
> > > +   return int (math.ceil (-math.log(self._duration) / 
> > > math.log(2)  -
> > > 2**tolerance_exp))
> > 
> > Since music notation uses exact rational numbers, using math.log () is 
> > usually forbidden, and it's better to use exact arithmetic.  Can you 
> > doublecheck whether or not exact arithmetic applies to your case, please 
> > add an explanation comment why you're using floating point numbers?
> 
> In this case inexactness doesn't matter. The term 2**tolerance_exp makes
> sure that notes that are slightly shorter than the next whole duration
> are rounded to the whole duration instead of somethin like "c8.". In
> some cases floating point arithmetic can cause some randomness regarding
> whether the note becomes c8... or c4 (if the duration is exactly 1/32
> from the next whole duration), but I don't think that matters -- such
> note length are weird enough to start with.
> 
> When determining the number of dots the use of floating point arithmetic
> doesn't obviously harm, because the result is rounded anyway.
> 
> I can't think of any simple way to achieve the same result without using
> math.log().
> 
> The attached diff for musicxml.py now has an explanatory comment.
> 

I don't understand this:

  tolerance_exp = -4
  a = - math.log(self._duration) / math.log(2)
  b = 2**tolerance_exp
  c = a - b

1:
 if tolerance_exp is a constant, why don't you simply say b = 1/16
 (another constant), which is clearly a duration(?) value.

2:
 why are you taking the difference between the log of a duration and a
 duration?

 In physics there is something which is called a dimension test: you
 simply cannot do 1 meter - 1 second. In math, you don't easily agree to
 do log(entity) - entity. And in this case I read your code as
 -2log( seconds ) - seconds which is clearly wrong.

 Now b seems to be an implementation detail caused by using floating
 point values, the same with math.ceil, is it so?

 If you simply want to map a duration to its -2log, why don't you use
 something like arr = [ 1, 2, 4, ...]; f(x) = arr[x]; which is a clear
 statement about what you are doing (although incomplete, I sense that
 self._duration is a rational number).

3:
 I don't understand what you are trying to do and your comment does not
 match the code

4:
 using floating point values for exact things usually open up enough
 nasty bugs and is very hard to verify due to rounding errors. Unless
 you have VERY good reason, just don't do it, it is not worth the
 trouble.

===

Later in your patch:

+factor = self._duration / 2**(-self.get_duration_log())
+return int (round (-math.log(2 - factor) / math.log(2)))

If:

 a = 1/2**(-self.get_duration_log())

then:

 a = 2**self.get_duration_log()

assuming that get_duration_log() returns a 2log and
that get_duration() exists, then

 a = self.get_duration()

get_duration() look suspiciously like _duration(), so my guess is that

 factor = self._duration ** 2

by quickly reading the code as a math guy.

Now, if duration usually is less than 1 (we don't see many breves and
longas today), then

 -math.log(2 - factor) / math.log(2)

more or less reduces to a near constant -1.

Is that your intention, or am I reading your code false?
I assume that duration is the lenght of a note, like whole note is 1,
a quater note is 1/4, ...

Regards,
/Karl

---
Karl HammarAspö Data   [EMAIL PROTECTED]
Lilla Aspö 2340Networks
S-742 94 Östhammar  +46  173 140 57   Computers
Sweden +46  70 511 97 84 Consulting
---


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


[patch] export functions from layout-page-layout.scm

2006-09-16 Thread Nicolas Sceaux
Hi,

The attached patch exports some of the utility function names in
scm/layout-page-layout.scm, so that they should be called by user
defined page breaking functions.

Make web runs fine, and the page breaking regression tests seem to look
as expected. May I commit?

nicolas

Index: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5299
diff -u -r1.5299 ChangeLog
--- ChangeLog	15 Sep 2006 18:04:16 -	1.5299
+++ ChangeLog	16 Sep 2006 11:15:25 -
@@ -1,3 +1,18 @@
+2006-09-16  Nicolas Sceaux  <[EMAIL PROTECTED]>
+
+	* scm/layout-page-layout.scm: export utility function names to
+	enable custom page breaking function writing. Tabify.
+	(line-next-space): use ?-suffix only for predicates
+	(page-maximum-space-to-fill): new function. Return the space
+	between first and bottom system of a page, to give to
+	space-systems.
+	(space-systems): use a space-to-fill argument (for instance as
+	computed by page-maximum-space-to-fill) instead of computing
+	internaly this space with the page height. That way, the caller
+	can adjust the space to use.
+	(make-page-from-systems, walk-paths): compute space to fill before
+	calling space-systems.
+
 2006-09-15  Mats Bengtsson  <[EMAIL PROTECTED]>
 
 	* ly/engraver-init.ly: Make FiguredBass accepted in GrandStaff and
Index: scm/layout-page-dump.scm
===
RCS file: /cvsroot/lilypond/lilypond/scm/layout-page-dump.scm,v
retrieving revision 1.1
diff -u -r1.1 layout-page-dump.scm
--- scm/layout-page-dump.scm	15 Jul 2006 10:34:29 -	1.1
+++ scm/layout-page-dump.scm	16 Sep 2006 11:15:27 -
@@ -10,7 +10,9 @@
   #:use-module (scm paper-system)
   #:use-module (scm page)
   #:use-module (lily)
-  #:export (write-page-breaks))
+  #:export (write-page-breaks
+;; utilisties for writing other page dump functions
+record-tweaks dump-all-tweaks))
 
 
 (define (record-tweaks what property-pairs tweaks)
Index: scm/layout-page-layout.scm
===
RCS file: /cvsroot/lilypond/lilypond/scm/layout-page-layout.scm,v
retrieving revision 1.21
diff -u -r1.21 layout-page-layout.scm
--- scm/layout-page-layout.scm	4 Sep 2006 05:31:28 -	1.21
+++ scm/layout-page-layout.scm	16 Sep 2006 11:15:27 -
@@ -3,7 +3,7 @@
   source file of the GNU LilyPond music typesetter
 
  (c) 2004--2006 Jan Nieuwenhuizen <[EMAIL PROTECTED]>
-  Han-Wen Nienhuys <[EMAIL PROTECTED]>
+	  Han-Wen Nienhuys <[EMAIL PROTECTED]>
 
 (define-module (scm layout-page-layout)
   #:use-module (srfi srfi-1)
@@ -13,7 +13,13 @@
   #:use-module (scm page)
   #:use-module (scm layout-page-dump)
   #:use-module (lily)
-  #:export (post-process-pages optimal-page-breaks make-page-from-systems))
+  #:export (post-process-pages optimal-page-breaks make-page-from-systems
+	;; utilities for writing custom page breaking functions
+	line-next-space line-next-padding
+	line-minimum-distance line-ideal-distance
+	first-line-position
+	line-ideal-relative-position line-minimum-relative-position
+	page-maximum-space-to-fill space-systems))
 
 (define (post-process-pages layout pages)
   (if (ly:output-def-lookup layout 'write-page-layout #f)
@@ -25,18 +31,18 @@
 (define (line-next-space line next-line layout)
   "Return space to use between `line' and `next-line'.
   `next-line' can be #f, meaning that `line' is the last line."
-  (let* ((title? (paper-system-title? line))
- (next-title? (and next-line (paper-system-title? next-line
-(cond ((and title? next-title?)
-   (ly:output-def-lookup layout 'between-title-space))
-  (title?
-   (ly:output-def-lookup layout 'after-title-space))
-  (next-title?
-   (ly:output-def-lookup layout 'before-title-space))
-  (else
-   (ly:prob-property
-line 'next-space
-(ly:output-def-lookup layout 'between-system-space))
+  (let* ((title (paper-system-title? line))
+	 (next-title (and next-line (paper-system-title? next-line
+(cond ((and title next-title)
+	   (ly:output-def-lookup layout 'between-title-space))
+	  (title
+	   (ly:output-def-lookup layout 'after-title-space))
+	  (next-title
+	   (ly:output-def-lookup layout 'before-title-space))
+	  (else
+	   (ly:prob-property
+	line 'next-space
+	(ly:output-def-lookup layout 'between-system-space))
 
 (define (line-next-padding line next-line layout)
   "Return padding to use between `line' and `next-line'.
@@ -51,22 +57,22 @@
  reference position. If next-line is #f, return #f."
   (and next-line
(max 0 (- (+ (interval-end (paper-system-extent next-line Y))
-(if ignore-padding 0 (line-next-padding line next-line layout)))
- (interval-start (paper-system-extent line Y))
+		(if ignore-paddi

Re: [patch] export functions from layout-page-layout.scm

2006-09-16 Thread Han-Wen Nienhuys

Nicolas Sceaux wrote:

Hi,

The attached patch exports some of the utility function names in
scm/layout-page-layout.scm, so that they should be called by user
defined page breaking functions.

Make web runs fine, and the page breaking regression tests seem to look
as expected. May I commit?


please do.



--

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


Re: [patch] export functions from layout-page-layout.scm

2006-09-16 Thread Han-Wen Nienhuys

Nicolas Sceaux wrote:

Hi,

The attached patch exports some of the utility function names in
scm/layout-page-layout.scm, so that they should be called by user
defined page breaking functions.

Make web runs fine, and the page breaking regression tests seem to look
as expected. May I commit?


please do.



--

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


The life of a Grob

2006-09-16 Thread Joe Neeman
Understanding the LilyPond source often boils down to figuring out what
is happening to the Grobs. Where (and why) are they being created,
modified and destroyed? I've spent many hours tracing Lily through a
debugger and it is mind-blowingly tedious.

So I quickly hacked a few things together and came up with something a
bit better. I added hooks into internal_grob_set_property and
make_grob_from_properties. You can register a scheme callback which will
get called whenever a Grob is modified or created. The scheme callback
will receive the file and line numbers in the C++ source where the call
was made. This can help you to trace cause and effect through the C++
source.

This is very hackish right now (I only started this morning), but I
thought I'd share a quick application. The file test.ly produces a
graphviz output file, "graph.dot", that lets you visualise the changes
in Grobs throughout LilyPond execution. For now, you'll need to add a
closing brace to the end of graph.dot.

I attach a patch, an example input file and a sample output.
diff --git a/lily/accidental-engraver.cc b/lily/accidental-engraver.cc
index 39a66ba..20f0103 100644
--- a/lily/accidental-engraver.cc
+++ b/lily/accidental-engraver.cc
@@ -402,7 +402,7 @@ Accidental_engraver::make_standard_accid
 = make_grob_from_properties (trans,
  ly_symbol2scm ("Accidental"),
  note_head->self_scm (),
- "Accidental");
+ "Accidental", __FILE__, __LINE__);
 
   /*
 We add the accidentals to the support of the arpeggio,
@@ -442,7 +442,7 @@ Accidental_engraver::make_suggested_acci
 = make_grob_from_properties (trans,
  ly_symbol2scm ("AccidentalSuggestion"),
  note_head->self_scm (),
- "AccidentalSuggestion");
+ "AccidentalSuggestion", __FILE__, __LINE__);
 
   Side_position_interface::add_support (a, note_head);
   if (Grob *stem = unsmob_grob (a->get_object ("stem")))
diff --git a/lily/align-interface.cc b/lily/align-interface.cc
index afe4702..b2160d0 100644
--- a/lily/align-interface.cc
+++ b/lily/align-interface.cc
@@ -323,7 +323,7 @@ Align_interface::add_element (Grob *me, 
   SCM sym = axis_offset_symbol (a);
   SCM proc = axis_parent_positioning (a);
 
-  element->internal_set_property (sym, proc);
+  element->internal_set_property (sym, proc, __FILE__, __LINE__);
   Axis_group_interface::add_element (me, element);
 }
 
diff --git a/lily/axis-group-interface.cc b/lily/axis-group-interface.cc
index 1d509f0..2727751 100644
--- a/lily/axis-group-interface.cc
+++ b/lily/axis-group-interface.cc
@@ -37,7 +37,7 @@ Axis_group_interface::add_element (Grob 
   e->internal_set_object ((a == X_AXIS)
 			  ? ly_symbol2scm ("axis-group-parent-X")
 			  : ly_symbol2scm ("axis-group-parent-Y"),
-			  me->self_scm ());
+			  me->self_scm (), __FILE__, __LINE__);
 }
 
   /* must be ordered, because Align_interface also uses
diff --git a/lily/break-align-engraver.cc b/lily/break-align-engraver.cc
index e6a7935..7b4f4b7 100644
--- a/lily/break-align-engraver.cc
+++ b/lily/break-align-engraver.cc
@@ -85,7 +85,7 @@ Break_align_engraver::acknowledge_break_
 	  left_edge_ = make_item_from_properties (random_source,
 		  ly_symbol2scm ("LeftEdge"),
 		  SCM_EOL,
-		  "LeftEdge");
+		  "LeftEdge", __FILE__, __LINE__);
 	  add_to_group (left_edge_->get_property ("break-align-symbol"),
 			left_edge_);
 	}
diff --git a/lily/break-substitution.cc b/lily/break-substitution.cc
index 0c1e996..8d65f6b 100644
--- a/lily/break-substitution.cc
+++ b/lily/break-substitution.cc
@@ -397,7 +397,7 @@ Spanner::fast_substitute_grob_array (SCM
   if (!unsmob_grob_array (newval))
 	{
 	  newval = Grob_array::make_array ();
-	  sc->internal_set_object (sym, newval);
+	  sc->internal_set_object (sym, newval, __FILE__, __LINE__);
 	}
 
   Grob_array *new_array = unsmob_grob_array (newval);
@@ -500,14 +500,14 @@ Spanner::substitute_one_mutable_property
 	if (!unsmob_grob_array (newval))
 	  {
 		newval = Grob_array::make_array ();
-		sc->internal_set_object (sym, newval);
+		sc->internal_set_object (sym, newval, __FILE__, __LINE__);
 	  }
 	substitute_grob_array (grob_array, unsmob_grob_array (newval));
 	  }
 	else
 	  {
 	SCM newval = do_break_substitution (val);
-	sc->internal_set_object (sym, newval);
+	sc->internal_set_object (sym, newval, __FILE__, __LINE__);
 	  }
   }
 }
diff --git a/lily/context-property.cc b/lily/context-property.cc
index 502fc92..0f77cfd 100644
--- a/lily/context-property.cc
+++ b/lily/context-property.cc
@@ -118,7 +118,7 @@ execute_general_pushpop_property (Contex
 	{
 	  SCM base = updated_grob_properties (context, context_property);
 	  current_context_val = scm_cons (base, base);
-	  context->internal_set_property (context_property, current_context_val);
+	  context->internal_set_property (context_property, current_context_val, __FILE__, __LINE__);
 	}
 
   if (!scm_is_pair (current_context_val))
@@ -180,7 +180,7 @@ execute_general

Re: The life of a Grob

2006-09-16 Thread Han-Wen Nienhuys

Joe Neeman wrote:

Understanding the LilyPond source often boils down to figuring out what
is happening to the Grobs. Where (and why) are they being created,
modified and destroyed? I've spent many hours tracing Lily through a
debugger and it is mind-blowingly tedious.

So I quickly hacked a few things together and came up with something a
bit better. I added hooks into internal_grob_set_property and
make_grob_from_properties. You can register a scheme callback which will
get called whenever a Grob is modified or created. The scheme callback
will receive the file and line numbers in the C++ source where the call
was made. This can help you to trace cause and effect through the C++
source.


Of course, having written much of the code myself, I don't need it, but 
this is extremely cool!


Some comments:

* can you add another macro layer, so __LINE__ and __FILE__ aren't 
sprinkled around in the code? For good measure, you could also add 
__FUNCTION__ .


* similarly, can you add macro layering, so that passing around line 
numbers/file  names is entirely optional, and doesn't happen for a 
-DNDEBUG build?


* It might be possible to get some sort of causality in the diagram, by 
recursively tracing 'cause properties. Dunno if that helps understanding 
things, though.



+  protect ();
+  if (ly_is_procedure (modification_callback))
+  scm_apply_0 (modification_callback,
+  scm_list_n (self_scm (), scm_makfrom0str (file), 
scm_from_int (line),
+  sym, v, SCM_UNDEFINED));
+  unprotect ();


this protection should not be necessary: as self_scm is passed as Stack 
variable it will be GC protected.




--

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


Re: The life of a Grob

2006-09-16 Thread Werner LEMBERG

> The file test.ly produces a
> graphviz output file, "graph.dot", that lets you visualise the changes
> in Grobs throughout LilyPond execution. For now, you'll need to add a
> closing brace to the end of graph.dot.

Very nice!  A minor suggestion: Please add a counter to the boxes so
that they are enumerated.  Then the start of an arrow should be
labeled with the number of the target box, and the end of an arrow
should tagged with the number of the origin box.


Werner


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


Re: The life of a Grob

2006-09-16 Thread Joe Neeman
On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote:
> Some comments:
> 
> * can you add another macro layer, so __LINE__ and __FILE__ aren't 
> sprinkled around in the code? For good measure, you could also add 
> __FUNCTION__ .
How about something like the attached patch? I "overload" get_property
so that it can take a SCM directly. Then I can replace every
internal_get_property with get_property.

> 
> * similarly, can you add macro layering, so that passing around line 
> numbers/file  names is entirely optional, and doesn't happen for a 
> -DNDEBUG build?
Sure.

> 
> * It might be possible to get some sort of causality in the diagram, by 
> recursively tracing 'cause properties. Dunno if that helps understanding 
> things, though.
Probably. There are a bunch more hooks I want to add too... this was
just the start :)

> > +  protect ();
> > +  if (ly_is_procedure (modification_callback))
> > +  scm_apply_0 (modification_callback,
> > +  scm_list_n (self_scm (), scm_makfrom0str (file), 
> > scm_from_int (line),
> > +  sym, v, SCM_UNDEFINED));
> > +  unprotect ();
> 
> this protection should not be necessary: as self_scm is passed as Stack 
> variable it will be GC protected.

I was getting segfaults in scm_gc_mark and this magically solved it.
Being in dirty hack mode, I didn't investigate further. But you're
right.

diff --git a/lily/include/lily-guile-macros.hh b/lily/include/lily-guile-macros.hh
index 7002c0f..dcb0a13 100644
--- a/lily/include/lily-guile-macros.hh
+++ b/lily/include/lily-guile-macros.hh
@@ -29,6 +29,14 @@ #endif
 
 #ifdef CACHE_SYMBOLS
 
+/* this lets us "overload" macros such as get_property to take
+   symbols as well as strings */
+inline SCM
+scm_or_str2symbol (char const *c) { return scm_str2symbol (c); }
+
+inline SCM
+scm_or_str2symbol (SCM s) { return s; }
+
 /* Using this trick we cache the value of scm_str2symbol ("fooo") where
"fooo" is a constant string. This is done at the cost of one static
variable per ly_symbol2scm() use, and one boolean evaluation for
@@ -43,10 +51,10 @@ #define ly_symbol2scm(x)		\
 if (__builtin_constant_p ((x)))	\
   {	\
 	if (!cached)			\
-	  value = cached = scm_gc_protect_object (scm_str2symbol ((x))); \
+	  value = cached = scm_gc_protect_object (scm_or_str2symbol (x)); \
   }	\
 else\
-  value = scm_str2symbol ((char *) (x));\
+  value = scm_or_str2symbol (x);	\
 value;\
   })
 #else
diff --git a/lily/tweak-engraver.cc b/lily/tweak-engraver.cc
index a479935..1749228 100644
--- a/lily/tweak-engraver.cc
+++ b/lily/tweak-engraver.cc
@@ -33,7 +33,7 @@ Tweak_engraver::acknowledge_grob (Grob_i
   for (SCM s = music->get_property ("tweaks");
 	   scm_is_pair (s); s = scm_cdr (s))
 	{
-	  info.grob ()->internal_set_property (scm_caar (s), scm_cdar (s), __FILE__, __LINE__);
+	  info.grob ()->set_property (scm_caar (s), scm_cdar (s));
 	}
 }
 }
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


Re: The life of a Grob

2006-09-16 Thread Joe Neeman
On Sat, 2006-09-16 at 20:47 +0200, Werner LEMBERG wrote:
> > The file test.ly produces a
> > graphviz output file, "graph.dot", that lets you visualise the changes
> > in Grobs throughout LilyPond execution. For now, you'll need to add a
> > closing brace to the end of graph.dot.
> 
> Very nice!  A minor suggestion: Please add a counter to the boxes so
> that they are enumerated.  Then the start of an arrow should be
> labeled with the number of the target box, and the end of an arrow
> should tagged with the number of the origin box.

I don't suppose you'd know how to do this in graphviz? I'm quite new to
it.




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


Re: The life of a Grob

2006-09-16 Thread Han-Wen Nienhuys

Joe Neeman wrote:

On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote:

Some comments:

* can you add another macro layer, so __LINE__ and __FILE__ aren't 
sprinkled around in the code? For good measure, you could also add 
__FUNCTION__ .

How about something like the attached patch? I "overload" get_property
so that it can take a SCM directly. Then I can replace every
internal_get_property with get_property.


Clever! This means that we can do away with the whole internal_FOO 
business, right? (also for some other functions, I expect.)

Can you prepare a patch that removes all the internal_XXX  ?


+  protect ();
+  if (ly_is_procedure (modification_callback))
+  scm_apply_0 (modification_callback,
+  scm_list_n (self_scm (), scm_makfrom0str (file), 
scm_from_int (line),
+  sym, v, SCM_UNDEFINED));
+  unprotect ();
this protection should not be necessary: as self_scm is passed as Stack 
variable it will be GC protected.


I was getting segfaults in scm_gc_mark and this magically solved it.
Being in dirty hack mode, I didn't investigate further. But you're
right.


ok, but to get this in lily, we have to get it out of dirty hack mode.



--

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


Re: The life of a Grob

2006-09-16 Thread Joe Neeman
On Sun, 2006-09-17 at 01:20 +0200, Han-Wen Nienhuys wrote:
> Joe Neeman wrote:
> > On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote:
> >> Some comments:
> >>
> >> * can you add another macro layer, so __LINE__ and __FILE__ aren't 
> >> sprinkled around in the code? For good measure, you could also add 
> >> __FUNCTION__ .
> > How about something like the attached patch? I "overload" get_property
> > so that it can take a SCM directly. Then I can replace every
> > internal_get_property with get_property.
> 
> Clever! This means that we can do away with the whole internal_FOO 
> business, right? (also for some other functions, I expect.)
> Can you prepare a patch that removes all the internal_XXX  ?

Except that I will need internal_FOO for the scheme hooks. It will be
completely transparent to other parts of the code though (ie.
internal_FOO shouldn't be called directly by anything any more). I
should be able to do something similar for
make_{item,spanner,paper_column} too.




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


Re: The life of a Grob

2006-09-16 Thread Werner LEMBERG
> > Very nice!  A minor suggestion: Please add a counter to the boxes so
> > that they are enumerated.  Then the start of an arrow should be
> > labeled with the number of the target box, and the end of an arrow
> > should tagged with the number of the origin box.
> 
> I don't suppose you'd know how to do this in graphviz? I'm quite new to
> it.

Sorry, no.


Werner


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


page breaking and vector_sort cleanups

2006-09-16 Thread Joe Neeman
This patch STL-ifies vector_sort much like my previous patch for
binary_search. It also includes my patch for rewriting the
interpretation step for page turns.

These changes touch a lot of files, so I'd like to get them committed
before I mess up my working tree with grob graphing stuff.

2006-09-17  Joe Neeman  <[EMAIL PROTECTED]>

* scm/define-music-types.scm (music-descriptions): remove
BreakEvent and fix {Page,Line}{Break,Turn}Event so
Music::to_event doesn't complain.

* lily/accidental-placement.cc (ape_compare):
* lily/semi-tie.cc (compare): 
* lily/note-column.cc (shift_compare): replace by XXX_less

* lily/tie-formatting-problem.cc (set_chord_outline): 
* lily/tie-column.cc (calc_positioning_done): 
* lily/system.cc (post_processing)
(get_paper_system): 
* lily/stem.cc (note_head_positions)
(calc_positioning_done): 
* lily/spanner.cc (do_break_processing)
(find_broken_piece): 
* lily/span-bar.cc (print): 
* lily/semi-tie-column.cc (calc_positioning_done): 
* lily/rest-collision.cc (calc_positioning_done): 
* lily/program-option.cc (get_help_string): 
* lily/note-collision.cc (get_clash_groups):
* lily/new-fingering-engraver.cc (position_scripts):
* lily/keyword.cc (Keyword_table):
* lily/hara-kiri-group-spanner.cc (request_suicide):
* lily/grob-pq-engraver.cc (stop_translation_timestep):
* lily/accidental-placement.cc (calc_positioning_done):
(stagger_apes):
* lily/beam.cc (get_beam_segments):
* lily/grob-array.cc (remove_duplicates):
use new vector_sort

* input/mutopia/W.A.Mozart/mozart-hrn3-defs.ily:
ragged-last-bottom = ##f (test the new page breaker)

* flower/include/std-vector.hh (vector_sort): use STL sort stuff

* scm/define-context-properties.scm
(all-internal-translation-properties): remove properties that
were used to communicate page-turn stuff to the paper-column
engraver.

* lily/lily-guile.cc (robust_scm2string): new function

* lily/paper-column-engraver.cc: Clean up page turn stuff

* lily/page-turn-engraver.cc: Re-write the page turn logic here
instead of cluttering up paper-column-engraver.cc
Index: ChangeLog
===
RCS file: /sources/lilypond/lilypond/ChangeLog,v
retrieving revision 1.5304
diff -u -r1.5304 ChangeLog
--- ChangeLog	16 Sep 2006 22:34:51 -	1.5304
+++ ChangeLog	17 Sep 2006 06:14:52 -
@@ -1,3 +1,53 @@
+2006-09-17  Joe Neeman  <[EMAIL PROTECTED]>
+
+	* scm/define-music-types.scm (music-descriptions): remove
+	BreakEvent and fix {Page,Line}{Break,Turn}Event so
+	Music::to_event doesn't complain.
+
+	* lily/accidental-placement.cc (ape_compare):
+	* lily/semi-tie.cc (compare): 
+	* lily/note-column.cc (shift_compare): replace by XXX_less
+
+	* lily/tie-formatting-problem.cc (set_chord_outline): 
+	* lily/tie-column.cc (calc_positioning_done): 
+	* lily/system.cc (post_processing)
+	(get_paper_system): 
+	* lily/stem.cc (note_head_positions)
+	(calc_positioning_done): 
+	* lily/spanner.cc (do_break_processing)
+	(find_broken_piece): 
+	* lily/span-bar.cc (print): 
+	* lily/semi-tie-column.cc (calc_positioning_done): 
+	* lily/rest-collision.cc (calc_positioning_done): 
+	* lily/program-option.cc (get_help_string): 
+	* lily/note-collision.cc (get_clash_groups):
+	* lily/new-fingering-engraver.cc (position_scripts):
+	* lily/keyword.cc (Keyword_table):
+	* lily/hara-kiri-group-spanner.cc (request_suicide):
+	* lily/grob-pq-engraver.cc (stop_translation_timestep):
+	* lily/accidental-placement.cc (calc_positioning_done):
+	(stagger_apes):
+	* lily/beam.cc (get_beam_segments):
+	* lily/grob-array.cc (remove_duplicates):
+	use new vector_sort
+	
+	* input/mutopia/W.A.Mozart/mozart-hrn3-defs.ily:
+	ragged-last-bottom = ##f (test the new page breaker)
+
+	* flower/include/std-vector.hh (vector_sort): use STL sort stuff
+
+	* scm/define-context-properties.scm
+	(all-internal-translation-properties): remove properties that
+	were used to communicate page-turn stuff to the paper-column
+	engraver.
+
+	* lily/lily-guile.cc (robust_scm2string): new function
+
+	* lily/paper-column-engraver.cc: Clean up page turn stuff
+
+	* lily/page-turn-engraver.cc: Re-write the page turn logic here
+	instead of cluttering up paper-column-engraver.cc
+
 2006-09-17  Han-Wen Nienhuys  <[EMAIL PROTECTED]>
 
 	* scm/script.scm (default-script-alist): set paddings for every
Index: flower/include/interval.hh
===
RCS file: /sources/lilypond/lilypond/flower/include/interval.hh,v
retrieving revision 1.58
diff -u -r1.58 interval.hh
--- flower/include/interval.hh	11 Feb 2006 11:35:18 -	1.58
+++ flower/include/interval.hh	17 Sep 2006 06:14:52 -
@@ -128,9