Hi, > Friendly piece of advice: don't add debug-only codepaths in your > components.
I agree. Debug-only codepaths should not be part of any release worthy code. However the goal of this library is to help developers understand what is going on while debugging/developing new components. It is not meant to be part of release code, hence the compile time switch that removes all visualization code paths. In a sense this library is like a logging library. But instead of textual output it creates visual output. > If you need to visualize debug info, build data structures > that go on a port and visualize that. Which will allow you to do deep > debugging from log files, and will make sure that debugging codepaths > does not get in the way when you go headless. > That is what we did before. However building data structures for temporary stuff that you just want to take a look at while debugging is time consuming and cumbersome. Especially in early development phases I tend to use small binaries that just test the stuff I am working on. At that time there are neither tasks nor ports. Besides, creating and populating special data structures just for debugging creates debug-only code paths as well. In my experience going from hand-made debug visualizations to debug drawing macros has reduced the debug-only code paths to a bare minimum. Cheers, Arne _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
