Joe Neeman wrote:
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.
that's an option. I'm worrying a bit about performance though.
get_property() and friends take a lot of time (10 to 20% of overall
execution time).
please apply after successful "make web".
--
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
