Dan Sugalski wrote:
I'm considering adding in some new ops and a command-line switch to help debug parrot code, but before I did I figured I'd better throw it out to the list for some debugging. (This seems like something which could be of good general use, and as such I'd like to hash it out, do it once, and do it right)
I'd suggest looking at log4j [1] or the python logging [2] packages. The problem is that unless thera are separate switches, any debugging output placed deep inside parrot is likely to drown out any application level debugging output.
Overview: every named unit (perhaps a source file, or a namespace) has a single (constant?) PMC associated with a logger. By default, each logger is dormant, so all calls will return without doing anything. But either at startup or dynamically, individual loggers can be enabled to start (or stop) outputing messages that exceed a given threshhold (debug, info, warn, error, fatal). Loggers can also be arranged hierarchically, so that enabling everything to do with garbage collection, for example, could be done with one call.
Where the output goes, and how it is formatted is configurable. One of the appenders for log4j is a wraparound array so that the point of failure you can retrieve the last "n" log messages.
You can also query a given logger to see whether a given log level is active or not. This enables you to skip over code that might create a moderately complicated message that will simply be ignored.
If all this seems too abstract or complicated, remember that it can be implemented incrementally, and as needed.
If logger methods map to a vtable, performance when logging is disabled should not be a significant concern.
I'm willing to help.
- Sam Ruby
[1] http://logging.apache.org/log4j/docs/manual.html [2] http://docs.python.org/lib/module-logging.html
