Interacting with the debugger¶
YAP includes a procedural debugger, based on Byrd's four port model.
In this model, execution is seen at the procedure level: each activation of a procedure is seen as a box with control flowing into and out of that box.
In the four port model control is caught at four key points: before entering the procedure, after exiting the procedure (meaning successful evaluation of all queries activated by the procedure), after backtracking but before trying new alternative to the procedure and after failing the procedure. Each one of these points is named a port:
*--------------------------------------*
Call | | Exit
---------> + descendant(X,Y) :- offspring(X,Y). + --------->
| |
| descendant(X,Z) :- |
<--------- + offspring(X,Y), descendant(Y,Z). + <---------
Fail | | Redo
*--------------------------------------*
Call
The call port is activated before initial invocation of procedure. Afterwards, execution will try to match the goal with the head of existing clauses for the procedure.
Exit
This port is activated if the procedure succeeds. Control will now leave the procedure and return to its ancestor.
Redo
If the goal, or goals, activated after the call port fail then backtracking will eventually return control to this procedure through the redo port.
Fail
If all clauses for this predicate fail, then the invocation fails, and control will try to redo the ancestor of this invocation.
To start debugging, the user will either call trace
or spy the relevant procedures, entering debug mode, and start execution of the program. When finding the first spy-point, YAP's debugger will take control and show a message of the form: v ```
(1) call: quicksort([1,2,3],_38) ? ```
The debugger message will be shown while creeping, or at spy-points, and it includes four or five fields:
-
The first three characters are used to point out special states of the debugger. If the port is exit and the first character is '?', the current call is non-deterministic, that is, it still has alternatives to be tried. If the second character is a
\*
, execution is at a spy-point. If the third character is a>
, execution has returned either from a skip, a fail or a redo command. -
The second field is the activation number, and uniquely identifies the activation. The number will start from 1 and will be incremented for each activation found by the debugger.
-
In the third field, the debugger shows the active port.
-
The fourth field is the goal. The goal is written by
write_term//33
on the standard error stream, using the options given by debugger_print_options.
If the active port is leashed, the debugger will prompt the user with a ?
, and wait for a command. A debugger command is just a character, followed by a return. By default, only the call and redo entries are leashed, but the leash//11 predicate can be used in order to make the debugger stop where needed.
There are several commands available, but the user only needs to remember the help command, which is h
. This command shows all the available options, which are:
c
- creep
this command makes YAP continue execution and stop at the next leashed port.
return
- creep
the same as c
l
- leap
YAP will execute until it meets a port for a spied predicate; this mode keeps all computation history for debugging purposes, so it is more expensive than standard execution. Use k
or z
for fast execution.
k
- quasi-leap
similar to leap but faster since the computation history is not kept; useful when leap becomes too slow.
z
- zip
same as <tt>k</tt>
``s
- skip
YAP will continue execution without showing any messages until returning to the current activation. Spy-points will be ignored in this mode. Note that this command keeps all debugging history, use t
for fast execution. This command is meaningless, and therefore illegal, in the fail and exit ports.
t
- fast-skip
similar to skip but faster since computation history is not kept; useful if skip becomes slow.
f [ _GoalId_]
- fail
If given no argument, forces YAP to fail the goal, skipping the fail port and backtracking to the parent. If f
receives a goal number as the argument, the command fails all the way to the goal. If goal GoalId has completed execution, YAP fails until meeting the first active ancestor.
r
[ GoalId] - retry
This command forces YAP to jump back call to the port. Note that any side effects of the goal cannot be undone. This command is not available at the call port. If f
receives a goal number as the argument, the command retries goal GoalId instead. If goal GoalId has vcompleted execution, YAP fails until meeting the first active ancestor.
q+ a
- abort execution will be aborted, and the interpreter will return to the
top-level. YAP disactivates debug mode, but spypoints are not removed.
n
- nodebug
stop debugging and continue execution. The command will not clear active §spy-points.
e
- exit
leave YAP.
h
- help
show the debugger commands.
!
Query
execute a query. YAP will not show the result of the query.
b
- break
break active execution and launch a break level. This is the same as !break
.
+
- spy this goal
start spying the active goal. The same as ! spy G
where G is the active goal.
-
- nospy this goal
stop spying the active goal. The same as ! nospy G
where G is
the active goal.
p
- print
shows the active goal using print//11
d
- display
shows the active goal using display//11
<Depth
- debugger write depth
sets the maximum write depth, both for composite terms and lists, that will be used by the debugger. For more information about write_depth//22
( (see Input/Output Control)).
<
- full term
resets to the default of ten the debugger's maximum write depth. For more information about write_depth//22
( (see Input/Output Control)).
A
- alternatives
show the list of backtrack points in the current execution.
g [ _N_]
show the list of ancestors in the current debugging environment. If it receives N, show the first N ancestors.
The debugging information, when fast-skip quasi-leap
is used, will be lost.