Bruce Stephens napisaĆ(a):
> Nicolas Castagne <castagne@imag.fr> writes:
>
>
>>gwl wrote:
>
>
> [...]
>
>
>>>man puts
>>
>>MMhh, sorry but I don't get it.
>>Do you mean the user should use puts to build its own debug-tool ?
>
>
> Almost all debugging problems end up with you wanting to know the
> value of some variables in a few places, and you can find that out by
> inserting a few puts statements in the code.
True. But then again, why not writing (heck, even a pure Tcl) Tcl parser
that just splits code into lines and inserts ::something::setLine 1234
(where 1234 is the line number in the source) before every invocation. I
think this is what TclPro/TDK does, but they do it integrated with an IDE.
I think it would be enough for most users who want to debug their stuff,
but do not want the overhead of some debugger - if anyone tried to code
VB for MS Office, then he/she knows how annoying it even is to see "Do
you wish to debug?" question 100 times.
I for example wrote a small audit library (quite cool, because the proc
you call is dynamically created so if one turns level to 0, then it's):
(zoro) 52 % audit::configure -level 0
(zoro) 53 % time {
audit::audit someStuff 1 "Some stuff I just wanted to check out"
} 1000
1.61 microseconds per iteration
(zoro) 54 % time {
audit::audit someStuff 1 "Some stuff I just wanted to check out"
} 100000
1.63275 microseconds per iteration
With just storing the audit data:
% time {audit::audit someStuff 1 "Some stuff I just wanted to check
out"} 10000
121.4237 microseconds per iteration
And now ... when doing a sync (async in this meaning is dumping the log
and/or audit data every 5 seconds) logging to a file:
% time {audit::audit someStuff 1 "Some stuff I just wanted to check
out"} 10000
1854.6912 microseconds per iteration
When I clean the audit lib up, I'll probably put it somewhere, even if
it clones tcllib/log's functionality. Well, mine also copies variables
and stores data useful for 'core'-like debugging, but I didn't get to
write any interface for browsing the damn audit data (and it isn't
readable at all :-).
> (It's not always true, of course, but very often that's the case: you
> speculate what the problem might be, and adding a few puts statements
> tells you whether you were right or not. And since Tcl is
> interpreted, doing that's often no slower overall than using a
> debugger would be.)
Yep. I found my audit just great for that, and I added printing the
clock so I can use it as a simple profiler as well. And when I turn it
off, noone is really annoyed.
--
WK
Received on Sat Oct 15 03:53:41 2005