Been there, done that...

Been there, done that...

Post by NewbieDre » Sun, 07 Oct 2007 01:48:13


I faced a similar problem some time ago. For starters, grep is your
friend for finding places that look like they are setting a value into
the variable in question. I wasted a great deal of time looking for
ways that the variable I was referencing could be in a different scope
than the variable that was getting the value that wasn't there when I
needed it. I eventually had a test case where the global variable
had a value on one pass through the function with the problem, but on
a later visit, the variable had become uninitialized. TCL has a
statement that can delete a variable, so a variable can go from having
a value to being without one. More confusing still, the name of the
variable to delete can be a glob expression, so grepping for the
specific variable name that has lost its value didn't turn up the
delete statement that was making the value go away. Grepping for
all the delete statements and contemplating them finally provided the
enlightenment that I sought. A routine had been added to the program
that was attempting to reset it so another "run" could be made without
exiting and restarting the program. That was where the bug was
lurking.

I pass along this tale in hopes that it helps you with your problem.

On my way to resolving that problem, I pushed the code through a
pretty-printer program that gave me paginated listings and an index to
the pages. The first try, the humongous program crashed the pretty
printer. Fortunately, the fellow who supported the pretty printer
program was happy to have a new test case. Turned out there were
files with unbalanced brackets and that flumoxed his parser. Finding
and fixing those certainly helped things along in my effort to get the
bugs out of the program I'd inherited. The experience certainly
drove home that debugging TCL is different than debugging C. Unless
you have test cases that specifically drive execution into the various
corners, there can be glaring syntax errors that the "compiler" didn't
flag when it ingested the files. (That was likely TCL 8.3.something
and maybe has changed in more recent editions? I've been away from
the language for a while now, so I can't really say what has changed
in recent years)

R.Drew Davis
(retired from Bell Labs)
 
 
 

Been there, done that...

Post by clair » Sun, 07 Oct 2007 10:23:07

In article < XXXX@XXXXX.COM >,

.
.
.
I'm a bit touchy about this characterization.

I recognize it; I know there are plenty of other people
who talk this way--"that debugging TCL is different than
debugging C".

I see far more similarities than differences. Perhaps
it's just a peculiarity of my own thoughts to regard so
many distinctions as mere convention. When I'm working
with C, I often think, "My, how can these coders commit
such glaring parasyntactic errors as to leave dangling
pointers, or memory bounds violations, or ...; I guess
their 'compiler' didn't flag them, and clearly they don't
use appropriate test cases ..."

To answer your question: Tcl's nature in these regards
has changed little in over a decade.

I have analogous comments about, for example, "the name
of the variable to delete can be a glob expression". I
sincerely can't relate that any more definitely to Tcl
than I can to C.