Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is it possible to stop and continue a script execution (break point)?

1,658 views
Skip to first unread message

Frank

unread,
Feb 28, 2017, 11:03:23 PM2/28/17
to
Hi,

I have an application that has a TCL console.

In the console the user runs TCL scripts to interact with the application.

The user scripts could contain several nested procedures and could be 5k lines or so.

Because sometimes it is hard to understand how the scripts are interacting with the application I would like to develop in the application a break_point and continue capability similar to the debuggers.

The idea is to somehow provide a TCL prompt where I can query some variables, check the application status, etc. and be able to continue the execution where I interrupted it.

At this time I just add (at the desired observation point) a line in the user TCL script to generate a TCL error. This takes me out of the user code and gives me back the application TCL console where I can query information in the application to understand its status. The problem is that once it breaks I can not continue the execution of the user script.


The approach I was thinking was to have an error handling procedure to handle the error generated and somehow create a simple interface "TCL shell" where I could type basic commands (ideally mini TCL scripts), get the application status and when done exit the TCL shell and have the application continue the execution of the user script right where it was interrupted.


Could I get some recommendations of the best approach to achieve this if at all possible? Any complications or limitations?

Thanks in advance.


Gerald W. Lester

unread,
Mar 1, 2017, 12:23:11 AM3/1/17
to
Talk to ActiveState about licensing the TDK (at least the debugger part of
it) to "embed" in your application.


--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Frank

unread,
Mar 1, 2017, 6:02:16 PM3/1/17
to
Is there a simpler way?
I do not need a full debugger, just the ability to stop the execution take a look around by doing some queries and continue.

Alexandre Ferrieux

unread,
Mar 1, 2017, 7:36:26 PM3/1/17
to
It depends on the flexibility you expect to offer regarding the position of the breakpoint(s): if you can afford to modify the code and insert a line wherever you want a breakpoint, you can simply write a procedure "breakpoint" and call it. The following one prints the call stack and enters a simple REPL where you can type Tcl commands to be evaluated in the context of the "breakpoint" statement (locals visible ; use upvar to see higher up). You can break out of the loop and continue to the next breakpoint by typing "cont" (like in gdb).

proc breakpoint {} {
puts "STACK:"
for {set n [info level];incr n -1} {$n>0} {incr n -1} {puts " [info level \
$n]"}
while {1} {
puts -nonewline "Eval: "
flush stdout
if {[gets stdin line]<0} break
if {$line=="cont"} break
if {[catch {uplevel 1 $line} res]} {
puts "ERROR: $res"
} else {
puts $res
}
}
}

-Alex

Robert Heller

unread,
Mar 1, 2017, 7:53:27 PM3/1/17
to
You could use trace and create a simple "shell" (read-eval-print-loop):

proc shell {args} {
puts $args
while {1} {
set line [gets stdin]
if {$line eq "exit"} {break}
catch {uplevel #1 $line} result
puts $result
}
}

trace add execution somefunction enter shell

>

--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

Michael Keith

unread,
Mar 1, 2017, 7:55:19 PM3/1/17
to
On Tue, 28 Feb 2017 15:03:14 -0800 (PST), Frank <kra...@gmail.com>
wrote:
Hi Frank,
if you can replace your 'Tcl console' with TkCON you can use its
integrated debugger:
- in TkCon you say 'idebug on' to enable debugging and
- in your script under test you add 'idebug break' at all the places
where you want to debug.
Once the program stops you have commands to show
- all local / global variables with or w/o their values
- the stack level
- etc.

If you say 'idebug off' you can even leave all the idebug statements
in your code ...

HTH
M'
0 new messages