| Hi there!
Yes, due to a slip-up it didn't make it into the V3.0 documentation
but I beleive this has been rectified for the future.
I've taken the liberty of re-posting my "documentation" from the
old conference.
Regards,
Paul
The debugger is very lightweight with very few commands, but it
has still proven invaluable with many of the engineers cursing
when they have to work on a vanilla V2.4 system again without
the debugger!
At the API level, you say <DEBUG ON to turn on the debugger, or
<DEBUG OFF to turn it off again. Once enabled, the debugger traps
execution of each script statement before it is executed and
displays it on the screen:
DEBUG[3]: GET #a = "FOO"
A1DEBUG>
At the A1DEBUG prompt, you can say STEP (or press return or KP0)
to step to the next statement or STEP n to step "n" statements.
The statements are listed on the screen unless you issue the
<debug nosource command, <debug source turns listing back on.
You can also say <func to execute an ALL-IN-1 function "func".
With <func you can examine symbol values and set symbol values or
even execute a script if you want.
The GO command continues execution and is the same as <DEBUG OFF.
There is also the concept of a script depth (the [3] printed in the
example above). Certain statements like DO script or .IF increase
the script depth. You can STEP/OVER a statement that increases the
script depth, and the debugger will only break when the script
depth comes back down to the current level or less, ie it has the
effect with a DO script of allowing the entire DO script to execute
before trapping at the next statement. Also you can STEP/INTO to
see all the intermediate script lines. This is the default. You
can change the default by saying SET STEP OVER, and reset it back
with SET STEP INTO.
That is about it! The script debugger is particulariliy useful for
finding out how a menu option works as it traces all the named
data for you and allows you to halt execution and step slowly
through interesting bits, unlike trace which races on.
There's a couple of things I don't like, which I will change if
I get chance (I've been saying that for ages). Comments are
compressed to a just a .REMARK statement so you can't see your
comments, I would like the debugger to just skip past .REMARK
statements and only break on "real" statements. It would be nice
if you could say "GO func" which would continue execution until
the next "func" statement, for example "GO .IF" would skip to the
next .IF statement. You can already sort of set breakpoints by
modifying your script to include DEBUG ON statements, and I can't
think of an easy way to implement breakpoint stting.
Another wishlist item that probably won't get done because it
would take too long to implement is stepping through the source
listing (ie the whole script on-screen with a pointer at where
you are in the script). This implies having a separate window
for debugger I/O.
Hope you like it!
Regards,
Paul
|