How to debug Tcl procs
maura.m...@gmail.com
integers.
I've got a number of answers. A simple blind change of the data type
would possibly
solve that particular instantiation onf the proc but the same proc is
called from different branches.
that, from my understanding can be affected by the "on-the-spot"
change.
A further complication (for me) is due to the Tcl/Tk procs being called
by C routines, and the whole stuff making a big Monte Carlo package
which contains Fortran, C, and Tcl /Tk functions.
The good news is that al the Tcl/Tk routines (procs) are in a file
called "mf.tcl" and the problem I'm facing occurs after the Tcl/Tk GUI
has taken over.
Therefore I'd like to esclude the C and Fortran routine and work on the
"mf.tcl" file stand-alone.
The advantage is that I will be able to avail myself of a debugger
specially made for interpreted code, if necassary, for instance Komodo
from Activestate.
I do not know of any debugger that can handle (and debug) C and
Fortran compiled code as well as Tcl interpreted procedures.
If I use DDD I can step through the C anf Fortran code. But DDD will be
blind when the control is passed to the Tcl procedures. On the other
hand, if I use komodo all what is C and Fortran code will be a "black
hole" until the control is transferred to the first Tcl proc ... i
guess
To pursue the strategy I have in mind I'd like to know if there is a
standard Tcl/Tk proc that handles the mouse input. In fact the MC user
will use the mouse left buton to click on a point beloning to a 2-D
schematic representation of a beam collider zones, and get the
preselected physical quantity value, at the point pointed at, displayed
on a pop-up widget.
Therefore we have an input format (the format through the value is read
out of a C structure passed to the Tcl routines, and an output format
used to display the value.
I think I need to know what are the Tcl standard procs that handle the
mouse input (coordinates) and the standard output to the screen.
Please, can someone help me with that ?
If require I can append the "mf.tcl" file. It's no secret.
Thank you in advance for your help.
Maura
Uwe Klein
How do you display your 2-D representation
of a beam collider?
And will user selection be a piece of the collider
or any point in the colliders passway defined by some
x/y(/z) position?
For starters you could read the
manpages for [bind] and [canvas]
Then go to the tcl'ers wiki
http://wiki.tcl.tk/
start from here:
http://wiki.tcl.tk/canvas
uwe
Cameron Laird
.
.
You've got a LOT going on here.
What's your high-level goal? Do you want to understand Tcl well enough
to solve all these items on your own, or is it enough for you that we
give you small fixes that eliminate the misbehavior you've reported?
I don't know what "a big Monte Carlo package" means in this context;
are you saying that some of the algorithms are of stochastic nature?
Were you given packages that permit mf.tcl to operate stand-alone? I'm
skeptical, at least as to whether you and I mean the same thing by that.
Debuggers interest me little. I'll probably discourage you from their
use.
"I'd like to know if there is a standard Tcl/Tk proc that handles the
mouse input." Hmmmm. Does the application implement its GUI with
standard Tk? Is it built with canvases and texts and such? When you
write, "the MC user will use the mouse left buton to click on a point
beloning to a 2-D schematic representation of a beam collider zones,
and get the preselected physical quantity value, at the point pointed
at, displayed on a pop-up widget", is all that widgetry Tk-based, or
might it have been written in C or Fortran or one of the other languages
of this project?
I suspect a sufficiently knowledgeable Tcl person could look at your
application and recommend corrections essentially instantaneously.
I further suspect that trying to understand clearly what you have by
way of these posted descriptions might take weeks.
Donal K. Fellows
>I don't know what "a big Monte Carlo package" means in this context
Probably means a simulation where a major part of the behaviour is
controlled by a random number generator. But I've learned that you can
never really tell round here, Tcl's that widely used; it might instead
be part of the back-end of an online gambling site for all I know. :-)
Donal.
Cameron Laird
Ms. Monville is a physicist, involved in application of simulation
of atomic transport problems. MARS is a definite package which
uses Monte Carlo techniques; I've found little on it so far apart
from meager evidence that it's used at Oak Ridge. Someone wrote a
Tk-based GUI to visualize the numerical results, and Ms. Monville
is now trying to get the whole mess to do its job, so she can
return to thinking physicist thoughts, as opposed to computing-
language semantics.
I'll repeat, though, that few of us are equipped to give advice
about how to use a Tcl debugger to "understand GUI code". She
has Adrian's book, but found it "pretty useless".
She's Linux-oriented.
You'd think that Arjen or Gerald or I or one of the others with a
background in wrapping scientific Fortran code could help, but I'm
a bit stumped now. Maybe, instead of a book (I thought of Eric's
<URL: http://wiki.tcl.tk/113 >, 'cept it's out-of-print, and
slanted toward Windows), we should be recommending introductory
Tk tutorials, like <URL: http://wiki.tcl.tk/3999 >, <URL:
http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html >, and <URL:
http://www.msen.com/~clif/TclTutor.html >. Maybe we should just
advise her to create TkTutor ...
Gerald W. Lester
> In article <1146175761.9...@i39g2000cwa.googlegroups.com>,
>...
> Ms. Monville is a physicist, involved in application of simulation
> of atomic transport problems. MARS is a definite package which
> uses Monte Carlo techniques; I've found little on it so far apart
> from meager evidence that it's used at Oak Ridge. Someone wrote a
> Tk-based GUI to visualize the numerical results, and Ms. Monville
> is now trying to get the whole mess to do its job, so she can
> return to thinking physicist thoughts, as opposed to computing-
> language semantics.
>
> I'll repeat, though, that few of us are equipped to give advice
> about how to use a Tcl debugger to "understand GUI code". She
> has Adrian's book, but found it "pretty useless".
>
> She's Linux-oriented.
>
> You'd think that Arjen or Gerald or I or one of the others with a
> background in wrapping scientific Fortran code could help, but I'm
Ok, I can take a hint.
Being not only a CS but Physics major, I guess I should jump in. So...
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.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Cameron Laird
Gerald W. Lester <Gerald...@cox.net> wrote:
.
.
.
.
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.