|
From: | Han-Wen Nienhuys |
Subject: | Re: The life of a Grob |
Date: | Sat, 16 Sep 2006 16:29:18 +0200 |
User-agent: | Thunderbird 1.5.0.7 (X11/20060913) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |