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)
As I've been writing library code in pir, I'm finding I've got a *lot* of commented-out printerr sections, as well as a fair amount of intermediate code to generate the data to be printed. What would be useful would be a relatively fast and simple way to leave these in and just skip over them, or have them not execute. As such I'm thinking we could use:
dprinterr [PISN]x - Like printerr, but only when running in debug mode ifdebug label - If debug's on, branch to label unlessdebug label - branch to label unless debugging's on debugbsr label - do a bsr to the label if debugging's on
As well as making the current debug status part of the interpreter info section which can be queried and branched on as needed. I can certainly see skipping the if/unlessdebug stuff, though the print only if debugging would make the code a lot cleaner, such as it is. (I'm also thinking that a conditional bsr would be useful, but I'm not sure it'd be useful *enough*) If it'd make the JIT unhappy to have more branching ops they can be left out. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
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)
> As I've been writing library code in pir, I'm finding I've got a *lot* > of commented-out printerr sections, as well as a fair amount of > intermediate code to generate the data to be printed. What would be > useful would be a relatively fast and simple way to leave these in and > just skip over them, or have them not execute. As such I'm thinking we > could use:
> dprinterr [PISN]x - Like printerr, but only when running in debug mode > ifdebug label - If debug's on, branch to label > unlessdebug label - branch to label unless debugging's on > debugbsr label - do a bsr to the label if debugging's on
> As well as making the current debug status part of the interpreter > info section which can be queried and branched on as needed. I can > certainly see skipping the if/unlessdebug stuff, though the print only > if debugging would make the code a lot cleaner, such as it is. (I'm > also thinking that a conditional bsr would be useful, but I'm not sure > it'd be useful *enough*) If it'd make the JIT unhappy to have more > branching ops they can be left out.
Maybe a bit off-topic (as it concerns pir syntax), but wouldn't it be usefull if we had multi-line comments? I find myself commenting out line after line quite some time, so if that could be done by only inserting 2 tokens (start/end comment), that would be great.
On Monday 01 November 2004 10:17 am, Sam Ruby wrote:
> 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.
<snip>
There is a Perl-based version of log4j, which would fit into Parrot much better than Java would:
Dan Sugalski <d...@sidhe.org> wrote: > dprinterr [PISN]x - Like printerr, but only when running in debug mode > ifdebug label - If debug's on, branch to label > unlessdebug label - branch to label unless debugging's on > debugbsr label - do a bsr to the label if debugging's on
Ok.
> (I'm also thinking that a conditional bsr would be useful, but I'm > not sure it'd be useful *enough*) If it'd make the JIT unhappy to > have more branching ops they can be left out.
C<ifdebug label> and C<unlessdebug label> are JITtable with not much effort. The conditional bsr needs a bit more. What about:
>>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)
>>As I've been writing library code in pir, I'm finding I've got a >>*lot* of commented-out printerr sections, as well as a fair amount >>of intermediate code to generate the data to be printed. What would >>be useful would be a relatively fast and simple way to leave these >>in and just skip over them, or have them not execute. As such I'm >>thinking we could use:
>> dprinterr [PISN]x - Like printerr, but only when running in debug mode >> ifdebug label - If debug's on, branch to label >> unlessdebug label - branch to label unless debugging's on >> debugbsr label - do a bsr to the label if debugging's on
>>As well as making the current debug status part of the interpreter >>info section which can be queried and branched on as needed. I can >>certainly see skipping the if/unlessdebug stuff, though the print >>only if debugging would make the code a lot cleaner, such as it is. >>(I'm also thinking that a conditional bsr would be useful, but I'm >>not sure it'd be useful *enough*) If it'd make the JIT unhappy to >>have more branching ops they can be left out.
>Maybe a bit off-topic (as it concerns pir syntax), but wouldn't it >be usefull if we had multi-line comments? >I find myself commenting out line after line quite some time, so if that could >be done by only inserting 2 tokens (start/end comment), that would be great.
We could, certainly. I'd not given it a whole lot of thought -- I'm used to assembly languages having only single-line comments. (And, I admit, I tend to use emacs' comment-region feature to make life easier) I'm not sure it's worth much effort, but on the other hand I've nothing against it either. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
>>>>> "DS" == Dan Sugalski <d...@sidhe.org> writes:
DS> dprinterr [PISN]x - Like printerr, but only when running in debug mode DS> ifdebug label - If debug's on, branch to label DS> unlessdebug label - branch to label unless debugging's on DS> debugbsr label - do a bsr to the label if debugging's on
DS> As well as making the current debug status part of the interpreter DS> info section which can be queried and branched on as needed. I can DS> certainly see skipping the if/unlessdebug stuff, though the print DS> only if debugging would make the code a lot cleaner, such as it DS> is. (I'm also thinking that a conditional bsr would be useful, but DS> I'm not sure it'd be useful *enough*) If it'd make the JIT unhappy DS> to have more branching ops they can be left out.
some random comments:
it looks like you have only one debug flag/level. would multiple flags/levels be useful or hard to add? it would mean adding another arg to the debug ops. if given no arg, it would default to level 1/flag 1 or something like that.
what about a compile time (byte code generation? JIT?) option to optimize out debug code so it doesn't even get run if not enabled?
do we need JIT support for debugging? you can debug in bytecode and then JIT for speed. this assumes, of course, that the JITing is correct.
uri
-- Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
> >>>>> "DS" == Dan Sugalski <d...@sidhe.org> writes:
> DS> dprinterr [PISN]x - Like printerr, but only when running in debug mode > DS> ifdebug label - If debug's on, branch to label > DS> unlessdebug label - branch to label unless debugging's on > DS> debugbsr label - do a bsr to the label if debugging's on
> DS> As well as making the current debug status part of the interpreter > DS> info section which can be queried and branched on as needed. I can > DS> certainly see skipping the if/unlessdebug stuff, though the print > DS> only if debugging would make the code a lot cleaner, such as it > DS> is. (I'm also thinking that a conditional bsr would be useful, but > DS> I'm not sure it'd be useful *enough*) If it'd make the JIT unhappy > DS> to have more branching ops they can be left out.
>some random comments:
>it looks like you have only one debug flag/level. would multiple >flags/levels be useful or hard to add? it would mean adding another arg >to the debug ops. if given no arg, it would default to level 1/flag 1 or >something like that.
Dunno. I generally either want it on or off. The logging stuff that Sam noted looks interesting, though.
>what about a compile time (byte code generation? JIT?) option to >optimize out debug code so it doesn't even get run if not enabled?
That's not what I'm looking for, in part because at compile time I don't know if I need the debug stuff executed. Most of the code's in library modules which are precompiled and hanging around. I want their debug code in there, but only enabled when I need it. (Basically I run through a bunch of programs and when one or more fail I want to rerun and kick in debugging)
>do we need JIT support for debugging? you can debug in bytecode and then >JIT for speed. this assumes, of course, that the JITing is correct.
Leo says no problem, so that's fine. This stuff's not really for debugging parrot, more for debugging pasm/pir code. -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Where DO_WE_TRACE_THIS can use whatever heirachical naming convenctions one wants and DO_THE_TRACING can be anything from printf to kernel logging depending on what one wants.
We actually leave these in the release versions of our product, but one could easily filter them out with a different macro. I know that it doesn't allow you to change dynamically, but it does provide a fair amount of speed for the not tracing case, as the condition is only checked once.
<tmurray-pe...@wumpus-cave.net> wrote: > On Monday 01 November 2004 10:17 am, Sam Ruby wrote: > > 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. > <snip>
> There is a Perl-based version of log4j, which would fit into Parrot much > better than Java would:
>>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 d...@sidhe.org have teddy bears and even teddy bears get drunk
>On 04/11/01 11:17 -0500, Sam Ruby wrote: >> 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).
>One thing that I really miss in this kind of logging framework is to >switch *at any time* (ie, not only when creating the logging stuff) the >threshold.
>This allows for example to run all your code with fatal threshold and >then, when running into sub-that-is-supposed-to-be-all-bugged, you just >activate debug level, and return to fatal after leaving it. This way you >only get the traces you wanted - instead of getting lost in your debug >traces.
Sounds like a job for pre and post handlers for subs and methods.... -- Dan
--------------------------------------it's like this------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Dan Sugalski <d...@sidhe.org> wrote: >>This allows for example to run all your code with fatal threshold and >>then, when running into sub-that-is-supposed-to-be-all-bugged, you just >>activate debug level, and return to fatal after leaving it. This way you >>only get the traces you wanted - instead of getting lost in your debug >>traces. > Sounds like a job for pre and post handlers for subs and methods....
Pah. Sounds like a debug variable in the interpreter context (what we already have for errors and warnings - we might need a few more bits for level, though) and a bit more cleverness for the C<debug> opcode (which we have too).
Said buggy sub starts with:
debug 0 # turn off or - debug -1 ... reduce level
Returning from the sub restores automagically the old debug level, because it's in the interpreter context.
More advanced debugging stuff is library code IMHO, we should have all necessary hooks like asserts and tracebacks, though.
Ah and the Parrot debugger needs a lot of work still.
On Mon, Nov 01, 2004 at 08:24:34PM +0100, Leopold Toetsch wrote: > Dan Sugalski <d...@sidhe.org> wrote: > > Sounds like a job for pre and post handlers for subs and methods....
> Pah. Sounds like a debug variable in the interpreter context (what we > already have for errors and warnings - we might need a few more bits for > level, though) and a bit more cleverness for the C<debug> opcode (which > we have too).
> Said buggy sub starts with:
> debug 0 # turn off or - debug -1 ... reduce level
Faffing with $^D in Perl 5 can be really useful.
> Returning from the sub restores automagically the old debug level, > because it's in the interpreter context.
local $^D in Perl 5, which is also useful.
But we don't have pre and post handers in Perl 5, so I don't know if they'd make the job easier.
