Re: The life of a Grob

[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 - address@hidden - http://www.xs4all.nl/~hanwen

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