Re: The life of a Grob

[Joe Neeman]

On Sat, 2006-09-16 at 16:29 +0200, Han-Wen Nienhuys wrote:
> 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__ .

This is done. I've removed all direct calls to internal_foo. I also
cleaned up make_{item,paper_column,spanner}.

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

I've done this, too but I'm not sure about it -- some of the ifndefs
start to inhibit readability.

What if I get rid of just the ifndef'ed prototypes? Ie. the line
numbers, etc will get passed around, but they won't get used when NDEBUG
is defined.

BTW, I removed the hooks from set_object because they weren't much use.
To get that information, I really need to hook into things like
Pointer_group_interface::add_grob.

tmp.patch
Description: Text Data