Minimal debug/rep functionality

[Delaney, Timothy]

> From: Peter Hansen [mailto:peter at engcorp.com]
> 
> Hmmm... I didn't see any implication that speed was even remotely
> a concern for the OP.  After all, he did ask to *print* each line
> as it executed.  What could possibly be slower than that?
> (I doubt he would care to deal with the volume of information
> generated when using this with a large program anyway... needs
> a way to turn it on and off, at least.)

Very true - hence my qualification. The speed comes into effect when tracing
a long-running process - for example, while using the "standard" two
coverage tools (trace.py and coverage.py) performance was unacceptably slow
for coverage of some unit tests here (well, once I'd hacked them to actually
allow unittest to determine what was a test case ...).

> My standard comments about Python speed and Knuth's comments about
> premature optimization apply...

Oh yeah. Unfortunately, tracing becomes a real bottleneck if done wrongly -
I've achieved two orders of magnitude improvement since I first started on
this tool - both in performance and memory use.

> I'm looking forward to seeing your tool though, Timothy. :)

I'd love it to eventually become part of the core - I *expect* I'll be able
to release it (but of course, it's up to my employer ...). It's doing
everything I want now except for determining exactly which zero-count lines
can be safely ignored (comments, multiline expressions). Oh - and I haven't
got an actual "trace as you go" mode (which is the topic of this thread ;)
but that will be easy to add. And I haven't got any path coverage analysis
yet - the data is captured, but no analysis is performed. And it currently
does a relatively primitive text-only coverage dump. And ... 

:)

Tim Delaney