What tools are in your Tcl debugging toolbox?
Larry W. Virden
use TclDevKit's tclchecker, frink (even though it doesn't appear to
have been updated in the past 4 years), nagelfar, tkinspect, and
putting in a variety of puts statements, and the occasional use of
dbx.
I've tried a few of the single stepping debuggers - the one that works
with Komodo was pretty nice - but many times I feel so frustrated by
the lack of speed that I give up on them.
So, what additional tools do you find useful when debugging Tcl code?
Particularly if you are using Tk or some other binary extension?
Gerald W. Lester
puts & flush
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Alexandre Ferrieux
Debugging, reverse engineering: puts stderr, strace, /proc/$pid/fd
Optimization: ::tcl::unsupported::disassemble
In addition, for long-running event-driven server stuff that shouldn't
be stopped, I like to add a "live debugging backdoor": a server socket
with a read-eval-print loop, allowing to run arbitrary Tcl code.
-Alex
Ron Fox
gdb issuing the package require command to get my extension loaded,
hitting control-c to get back to (gdb) and setting break points
wherever appropriate.
I second Gerry's use of puts/flush but then we're both old school from
when that was the only way to debug anything...other than flipping
switches on computer front panel setting tight infinite loops as break
points...and watching the address lights settle in on the address; you
installed... putting the old opcode back and... hitting the single
step switch using the load map and so on and so forth
Gerry remember the opcode 0777 ?
RF.
(for you youngsters 0777 was/is the PDP-11 opcode for:
here: br here
see http://en.wikipedia.org/wiki/PDP-11
The pic shown was very much like one of the first systems I worked
with however that was a PDP-11/45 not the 11/40 shown.). I didn't
have those marvelous Dectapes. Just a pair of RK05's (Archaic old 5's
as we eventually called them). The 5 was the number of Megabytes of
storage on those disks (that's no typo Megabytes not gigabytes).
Other system I got to use back then:
mumble mumble grumble..now who hid my cane...kids these days...
--
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321
Gerald W. Lester
> Larry W. Virden wrote:
>> I was just thinking about this topic over the weekend. Right now, I
>> use TclDevKit's tclchecker, frink (even though it doesn't appear to
>> have been updated in the past 4 years), nagelfar, tkinspect, and
>> putting in a variety of puts statements, and the occasional use of
>> dbx.
>>
>> I've tried a few of the single stepping debuggers - the one that works
>> with Komodo was pretty nice - but many times I feel so frustrated by
>> the lack of speed that I give up on them.
>>
>> So, what additional tools do you find useful when debugging Tcl code?
>> Particularly if you are using Tk or some other binary extension?
> Debugging my binary extension: gdb... nothing like running tclsh under
> gdb issuing the package require command to get my extension loaded,
> hitting control-c to get back to (gdb) and setting break points wherever
> appropriate.
>
> I second Gerry's use of puts/flush but then we're both old school from
> when that was the only way to debug anything...other than flipping
> switches on computer front panel setting tight infinite loops as break
> points...and watching the address lights settle in on the address; you
> installed... putting the old opcode back and... hitting the single step
> switch using the load map and so on and so forth
>
> Gerry remember the opcode 0777 ?
Sorry, I used the big systems -- I was a PDP-10 person with front panel.
Used a debugger that could set "symbolic" breakpoints on the PDP-11
(RSX-11M) in the assembler code.
>
> RF.
>
> (for you youngsters 0777 was/is the PDP-11 opcode for:
>
> here: br here
>
> see http://en.wikipedia.org/wiki/PDP-11
>
> The pic shown was very much like one of the first systems I worked with
> however that was a PDP-11/45 not the 11/40 shown.). I didn't have those
> marvelous Dectapes. Just a pair of RK05's (Archaic old 5's as we
> eventually called them). The 5 was the number of Megabytes of storage on
> those disks (that's no typo Megabytes not gigabytes).
> Other system I got to use back then:
>
>
> mumble mumble grumble..now who hid my cane...kids these days...
>
>
>
--
Donal K. Fellows
> Larry W. Virden wrote:
>> Particularly if you are using Tk or some other binary extension?
>
> puts & flush
Don't forget logfiles, especially for server apps. Though they're really
just an upgraded form of [puts]... :-)
Donal.
Richard Owlett
If this is a trivia contest - recognize ML 5-5?
[relevant to everything from RX-01's to KL-10's ;]
Gerald W. Lester
Address of main office of DEC.
Jeff Hobbs
/me so sad tkcon didn't make the list. what other tool could one
need? ;)
suchenwi
> > So, what additional tools do you find useful when debugging Tcl code?
> > Particularly if you are using Tk or some other binary extension?
>
> puts & flush
In particular, puts [info level 0] as first command in procs under
study.
And this tiny little breakpointer:
proc bp args {
while 1 {
puts -nonewline "$args % "; flush stdout
gets stdin line
if {$line eq "c"} break
catch {uplevel 1 $line} res
if {$res ne ""} {puts $res}
}
}
Ron Fox
> Richard Owlett wrote:
>> If this is a trivia contest - recognize ML 5-5?
>> [relevant to everything from RX-01's to KL-10's ;]
>>
>
> Address of main office of DEC.
>
Known by the DECcies as 'the mill'
Ron Fox
I good bottle of alcohol... or rather a bottle of good alcohol
Christian Gollwitzer
In fact tkcon is my personal favorite debugging tool. Together with
nagelfar. One thing I don't like with tcl is, that a proc {} with
eroneous syntax does byte-compile without any problems, but raises a
syntax error on the first invocation. I'd like to have a --lint switch
or something like
set tcl::strict 1
so that the syntax errors raise already when the file is sourced.
Christian
suchenwi
bayreuth.de> wrote:
> In fact tkcon is my personal favorite debugging tool. Together with
> nagelfar. One thing I don't like with tcl is, that a proc {} with
> eroneous syntax does byte-compile without any problems, but raises a
> syntax error on the first invocation. I'd like to have a --lint switch
> or something like
> set tcl::strict 1
> so that the syntax errors raise already when the file is sourced.
The error is found and reported at byte-compilation, which happens at
the first invocation. The idea is to save time when you source library
files with many procs, of which only a few may be actually called.
What the [proc] command does is just save the arglist and the body
under the given name.
If your proc does not have side effects (like deleting files or
so :^), you could just call it once after definition, to get early
alert on syntax errors:
proc foo x {
...
}
foo 0
Alexandre Ferrieux
bauersa...@siemens.com> wrote:
>
> The error is found and reported at byte-compilation, which happens at
> the first invocation.
If you want an early compilation without risks of execution (like side-
effects), you can use Donal's disassembler:
foreach f [info proc] {::tcl::unsupported::disassemble proc $f}
Indeed, the disassembler requests the production of the bytecode if it
does not exist yet.
-Alex
Jeff Hobbs
wrote:
This is not actually the same as the OP wanted. The Tcl bytecode
engine is very conservative in reporting syntax errors (it almost
never does). If it finds something that doesn't appear correct, it
just reverts to "out of line compile". This allows for bytecompiling
procs that have "broken" ifs, but _maybe_ the real case if that some
other code you call will redefine [if] before that code is called (and
with some debugging tools, this can be the case with several core
commands).
Jeff
Alexandre Ferrieux
Of course. What I meant (and thought the OP meant too) by compilation
error was not "broken ifs" (which to some extent are merely a library
concern, since an out-of-line "if" is just a library function), but
broken Tcl *syntax* like characters after close-quote or close-brace:
proc foo {} {puts {yes sir}oops}
Now I admit that this limited coverage makes the trick less useful.
But that's the price to pay for a wonderfully reflective dynamic
language :-)
-Alex
Don Porter
> On 15 Okt., 15:55, Christian Gollwitzer <Christian.Gollwit...@uni-
> bayreuth.de> wrote:
>> In fact tkcon is my personal favorite debugging tool. Together with
>> nagelfar. One thing I don't like with tcl is, that a proc {} with
>> eroneous syntax does byte-compile without any problems, but raises a
>> syntax error on the first invocation. I'd like to have a --lint switch
>> or something like
>> set tcl::strict 1
>> so that the syntax errors raise already when the file is sourced.
>
> The error is found and reported at byte-compilation, which happens at
> the first invocation.
This is no longer true. The compile step never raises errors. Even
errors in basic Tcl syntax do not raise an error; they compile to
bytecode that will raise the error during execution.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Fredderic
Alexandre Ferrieux <alexandre...@gmail.com> wrote:
> In addition, for long-running event-driven server stuff that shouldn't
> be stopped, I like to add a "live debugging backdoor": a server socket
> with a read-eval-print loop, allowing to run arbitrary Tcl code.
The conn package is handy there...
--
Fredderic
Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 8 days, 13:16)
Alexandre Ferrieux
> On Tue, 14 Oct 2008 14:18:57 -0700 (PDT),
>
> > In addition, for long-running event-driven server stuff that shouldn't
> > be stopped, I like to add a "live debugging backdoor": a server socket
> > with a read-eval-print loop, allowing to run arbitrary Tcl code.
>
> The conn package is handy there...
I guess you mean 'comm' :-)
-Alex
Fredderic
Who swapped the 'm' and 'n' keys om ny keyboard...?!?
But yeah. It's a shame it doesn't lend itself a little better to being
positioned on a specific port, and more ready authentication. But it's
got most of the bits already for a nice quick hacky debugging console.
Even for other uses, those little issues are easy enough to work around,
and the eval hook allows you to fit it to a specific API. Quite neat.
--
Fredderic
Debian/unstable (LC#384816) on i686 2.6.23-z2 2007 (up 9 days, 4:13)