This section describes the particular commands that are available when the system prompts you after printing out a debugging message. All the commands are one or two letter mnemonics, some of which can be optionally followed by an argument. They are read from the standard input stream with any blanks being completely ignored up to the end of the line (<RET>).
The only command which you really have to remember is h
(followed
by <RET>). This provides help in the form of the following list of
available commands.
<cr> creep c creep l leap z zip s skip s <i> skip i o out o <n> out n q q-skip q <i> q-skip i r retry r <i> retry i f fail f <i> fail i j<p> jump to port j<p><i>jump to port i d display w write p print p <i> print partial g ancestors g <n> ancestors n t backtrace t <n> backtrace n & blocked goals & <n> nth blocked goal n nodebug = debugging + spy this * spy conditionally - nospy this \ <i> remove brkpoint D <i> disable brkpoint E <i> enable brkpoint a abort b break @ command u unify e raise exception . find this < reset printdepth < <n> set printdepth ^ reset subterm ^ <n> set subterm ? help h help
If you supply an integer argument, then this should denote an
invocation number of an ancestral goal. The system tries to get you
to the Exit or Fail port of the invocation box you have specified.
An integer argument can be supplied as for skip.
If you supply an integer argument, then this should denote an
invocation number of an ancestral goal.
The system tries to get you to the Call port of the box you have
specified. It does this by continuously failing until it reaches the
right place. Unfortunately this process cannot be guaranteed: it may be
the case that the invocation you are looking for has been cut out of the
search space by cuts (!
) in your program. In this case the
system fails to the latest surviving Call port before the correct one.
If you supply an integer after the command, then this is taken as
specifying an invocation number and the system tries to get you to the
Fail port of the invocation box you have specified. It does this by
continuously failing until it reaches the right place. Unfortunately
this process cannot be guaranteed: it may be the case that the
invocation you are looking for has been cut out of the search space by
cuts (!
) in your program. In this case the system fails to the
latest surviving Fail port before the correct one.
c
, e
, r
,
f
, standing for Call, Exit, Redo and Fail ports. Takes an
optional integer argument, an invocation number.
Jumping to a Call port is the same as retrying it, i.e. jc
is the same as the r
debugger command; and similarly jf
is
the same as f
.
The je
jump to Exit port command transfers control back to
the Exit port of the box. It can be used at a Redo or an Exit port
(although at the latter it has no effect). This allows you to restart a
computation following an Exit port, which you first leapt over, but
because of its unexpected failure you arrived at the Redo port. When you
supply an integer argument, then this should denote an exact
invocation number of an exited invocation present in the backtrace, and
then the system will get you to the specified Exit port. The debugger
requires here an exact invocation number so that it does not jump too
far back in the execution (if an Exit port is not present in the
backtrace, it may be be a better choice to jump to the preceding Call port,
rather than to continue looking for another Exit port).
The jr
jump to Redo port command transfers control back to
the Redo port of the box. It can be used at an Exit or a Redo port
(although at the latter it has no effect). This allows you to force the
goal in question to try to deliver another solution. When you supply an
integer argument, then this should denote an exact invocation
number of an exited invocation present in the backtrace, and then the
system will get you to the specified Redo port.
display/1
.
See Write (below).
print/1
.
An argument will override the default printdepth, treating 0 as infinity.
writeq/1
.
Ancestors to the current goal are annotated with the Call:
port,
as they have not yet exited, whereas goals that have exited are
annotated with the Exit:
port. You can always be sure of jumping to the
Exit or Redo port of any goal shown to be exited in the backtrace listing.
The backtrace is a tree rather than a stack: to find the parent of a
given goal with depth indicator d, look for the closest goal above
it with depth indicator d-1.
debugging/0
.
spy(Func, Conditions)goal, where Func is the predicate spec of the current invocation. For
spy/2
, see Breakpoint Predicates.
nospy
Func
, where Func is the
predicate spec of the current invocation.
remove_breakpoints(
BID)
, where BID is the
current breakpoint identifier, or the supplied argument
(see Breakpoint Predicates).
disable_breakpoints(
BID)
, where BID is the
current breakpoint identifier, or the supplied argument
(see Breakpoint Predicates).
enable_breakpoints(
BID)
, where BID is the
breakpoint identifiers for the current predicate, or the supplied argument
(see Breakpoint Predicates).
abort/0
.)
break/0
, thus putting you
at a recursive top-level with the execution so far sitting underneath you.
When you end the break (^D) you will be reprompted at the port at
which you broke. The new execution is completely separate from the
suspended one; the invocation numbers will start again from 1 during the
break. The debugger is temporarily switched off as you call the break and
will be re-switched on when you finish the break and go back to the old
execution. However, any changes to the leashing or to spypoints will
remain in effect.
| :-
will be output on the standard error stream, and a command is then read
from the standard input stream and executed as if you were at top-level.
If the term read is of form
Pattern ^
Body
, then
Pattern is unified with the current goal and Body is
executed.
Head :-
Body
, then Head will
be unified with the current goal, and Body will be executed in its
place.
debugger_print_options
Prolog flag (see State Info).
The user can define new debugger commands or modify the behavior of the
above ones using the debugger_command_hook
hook predicate,
see Breakpoint Predicates.