Re: How to debug Tcl procs

In article <%Ye4g.55772$IZ2.33520@dukeread07>,
Gerald W. Lester <Gerald.Lester@cox.net> wrote:
                        .
                        .
                        .
>Forget about using a GUI Debugger to help understand the code. With the mix
>of languages you have it will not work.
>
>One thing you can do is a static analysis of what Tcl calls what. But at
>some point you will need dynamic debugging.
>
>As to how to debug the code, that depends on if TCL_COMPILE_DEBUG was set
>when the Tcl library was compiled.
>
>If the variable tcl_traceExec exists, then I'd suggest starting by doing a:
> set tcl_traceExec 1
>at the top of mf.tcl and look at the trace results.
>
>If the variable tcl_traceExec does not exists, then put a:
> puts stdout "Entering [info level 0]"
>at the top of every procedure and at least:
> put stdout "Leaving [info level 0]"
>before each return point of a procedure. Even better would be to put:
> put stdout "Leaving [info level 0] - return #1 with {$result}"
>Where #1 is #2, #3, ..., #N inside of a proc and $result is whatever is
>being returned.
>
>Once you narrow down the routine that seems to be not doing what you expect,
> add put statements at the top of each branch.
>
>In other words, apply the same analysis techniques we were taught in physics
>labs to find out why a particular experiment is not working to the program
>-- put measurement points in then where the results are not expected put
>more probes in that piece of equipement (think of procs as pieces of equipment).
>
>Now if you can share the code and give detailed symptoms of what is wrong, I
>may be able to point out what needs to change.
                        .
                        .
                        .
I realized this morning what all this talk of debuggers sounds like
to me. I have a ten-year-old who's saving to buy a truck (if I
understand her correctly). When there's a spill in the kitchen, and
someone needs to haul out the trash, she appears to think, "If we
bought a truck, we could haul garbage with it." There's truth in
that, but my perspective is that someone still needs to get down on
the kitchen floor and pick up the junk.

My perspective counts for a lot, 'cause it's my kitchen.

Anyway, that's what I think of debuggers: they're largely a
distraction. Gerald, Maura had the problem localized several days
ago, thanks to Tcl's intelligent error reports (although her
unfamiliarity with the language required a tiny bit of hand-holding
to confirm what the pop-up was saying).

Everything you wrote is on-target, of course, and will be applicable
sooner or later; I'm just letting you know that, after looking over
the 7700+ lines of the source Maura's wrangling, I'm confident that
she has bigger issues than debugger techniques.

I REALLY like the idea of static analysis, though. Maura, plan to
learn nagelfar, or frink.

Good news: she's already done a crucial part of the analysis you
describe, and identified that the Tk part is only very loosely
coupled to the C and Fortran parts. In that sense, a Tcl debugger
*is* feasible ... I continue, of course, to advise that it would
be a waste of time.
Received on Sun Apr 30 03:30:34 2006