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.
Fair enough. I've got to admit I tend to use really primitive tools -- gdb's nice, and DEC^WCompaq^WHP has a really nice GUI debugger... and I do most of my work with scattered print statements. :)
[Snipped description]
If all this seems too abstract or complicated, remember that it can be implemented incrementally, and as needed.
But, but, but... consider all the bikesheds that will remain unpainted if we do this?
Which, I suppose, is an *excellent* reason to do it, so lets. This also means we should hash out module building, installation paths, versioning, and generic module loading, which sounds like fun.
If logger methods map to a vtable, performance when logging is disabled should not be a significant concern.
I'm willing to help.
Cool. -- Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
