1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
|
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="application/xml+xhtml; charset=utf-8" />
<title>Logtalk user manual: running and debugging Logtalk programs</title>
<link rel="stylesheet" href="../screen.css" type="text/css" media="screen"/>
<link rel="stylesheet" href="../print.css" type="text/css" media="print"/>
</head>
<body>
<div class="top-left">Logtalk user manual</div>
<div class="top-right">Running and debugging Logtalk programs</div>
<div class="bottom-left"><span class="page"/></div>
<div class="bottom-right"><span class="page"/></div>
<div class="navtop"><a href="../index.html">contents</a> > <a href="index.html">user manual</a></div>
<h1>Running and debugging Logtalk programs</h1>
<h2>Running a Logtalk session<a id="running"></a></h2>
<p>
We run Logtalk inside a normal Prolog session, after loading the necessary files. Logtalk extends but does not modify your Prolog compiler. We can freely mix Prolog queries with the sending of messages and our programs can be made of both normal Prolog clauses and object definitions.
</p>
<h3>Starting Logtalk<a id="starting"></a></h3>
<p>
Depending on your Logtalk installation, you may use a script or a shortcut to start Logtalk with your chosen Prolog compiler. On POSIX operating systems, the scripts should be available from the command-line; scripts are named upon the used Prolog compilers. On Windows, the shortcuts should be available from the Start Menu. If no scripts or shortcuts are available for your installation, operating-system, or Prolog compiler, you can start a Logtalk session by performing the following steps:
</p>
<ol>
<li>Start your Prolog compiler.</li>
<li>Load the appropriate configuration file for your compiler. Configuration files for most common Prolog compilers can be found in the <code>configs</code> subdirectory.</li>
<li>Load the Logtalk compiler/runtime files contained in the <code>compiler</code> subdirectory.</li>
<li>Load the library paths configuration file corresponding to your Logtalk installation contained in the <code>libpaths</code> subdirectory.</li>
</ol>
<p>
Note that the configuration files, compiler/runtime files, and library paths file are Prolog source files. The predicate called to load (and compile) them depends on your Prolog compiler. In case of doubt, consult your Prolog compiler reference manual or take a look at the definition of the predicate <code>'$lgt_load_prolog_code'/1</code> in the corresponding configuration file.
</p>
<p>
Most Prolog compilers support automatic loading of an initialization file, which can include the necessary directives to load both the Prolog configuration file and the Logtalk compiler. This feature, when available, allows automatic loading of Logtalk when you start your Prolog compiler.
</p>
<h3>Compiling and loading your programs<a id="compiling"></a></h3>
<p>
Your programs will be made of source files containing your objects, protocols, and categories. After changing the Prolog working directory to the one containing your files, you can compile them to disk by calling the Logtalk built-in predicate
<a title="Consult reference manual" href="../refman/builtins/logtalk_compile1.html"><code>logtalk_compile/1</code></a>:
</p>
<pre>| ?- logtalk_compile([source_file1, source_file2, ...]).</pre>
<p>
This predicate runs the preprocessor on each argument file and, if no fatal errors are found, outputs Prolog source files that can then be consulted or compiled in the usual way by your Prolog compiler. Note that the predicate argument must be either an entity name or a list of entity names.
</p>
<p>
To compile to disk and also load into memory the source files we can use the Logtalk built-in predicate <a title="Consult reference manual" href="../refman/builtins/logtalk_load1.html"><code>logtalk_load/1</code></a>:
</p>
<pre>| ?- logtalk_load([source_file1, source_file2, ...]).</pre>
<p>
This predicate works in the same way of the predicate <code>logtalk_compile/1</code> but also loads the compiled files to memory.
</p>
<p>
Both predicates expect a source name name or a list of source name names as an argument. The Logtalk source file name extension, as defined in the configuration file, must be omitted.
</p>
<p>
If you have more than a few source files then you may want to use a loader helper file containing the calls to the <code>logtalk_load/1</code> predicate. Consulting or compiling the loader file will then compile and load all your Logtalk entities into memory (see the <a href="programming.html#loaders">next</a> section for details).
</p>
<h3>Compiler flags<a id="flags"></a></h3>
<p>
The <a title="Consult reference manual" href="../refman/builtins/logtalk_load1.html"><code>logtalk_load/1</code></a> and <a title="Consult reference manual" href="../refman/builtins/logtalk_compile1.html"><code>logtalk_compile/1</code></a> always use the current set of default compiler flags as specified in the Logtalk configuration files or changed for the current session using the built-in predicate <a title="Consult reference manual" href="../refman/builtins/set_logtalk_flag2.html"><code>set_logtalk_flag/2</code></a>. Although the default flag values cover the usual cases, you may want to use a different set of flag values while compiling or loading some of your Logtalk source files. This can be accomplished by using the <a title="Consult reference manual" href="../refman/builtins/logtalk_load2.html"><code>logtalk_load/2</code></a> or the <a title="Consult reference manual" href="../refman/builtins/logtalk_compile2.html"><code>logtalk_compile/2</code></a> built-in predicates. These two predicates accept a list of flag values affecting how a Logtalk source file is compiled and loaded:
</p>
<pre>| ?- logtalk_compile(Files, Flags).</pre>
<p>
or:
</p>
<pre>| ?- logtalk_load(Files, Flags).</pre>
<p>
In fact, the <code>logtalk_load/1</code> and <code>logtalk_compile/1</code> predicates are just shortcuts to the extended versions called with the default compiler flag values.
</p>
<p>
You can use the following flags:
</p>
<blockquote>
<dl>
<dt><code>events(Option)</code></dt>
<dd>Allows Logtalk event-driven programming support to be turned off when not needed in order to improve message sending performance. Possible option values are <code>on</code> (the usual default) and <code>off</code>. Objects (and categories) compiled with this option set to <code>off</code> use optimized code for message-sending that does not trigger events. As such, this option can be used on a per-object (or per-category) basis. Note that turning off this option is of no consequence for objects and categories already compiled and loaded.</dd>
</dl>
<dl>
<dt><code>unknown(Option)</code></dt>
<dd>Controls the unknown entity warnings, resulting from loading an entity that references some other entity that is not currently loaded. Possible option values are <code>warning</code> (the usual default) and <code>silent</code>. Note that these warnings are not always avoidable, specially when using reflective designs of class-based hierarchies.</dd>
</dl>
<dl>
<dt><code>singletons(Option)</code></dt>
<dd>Controls the singleton variable warnings. Possible option values are <code>warning</code> (the usual default) and <code>silent</code> (not recommended).</dd>
</dl>
<dl>
<dt><code>underscore_vars(Option)</code></dt>
<dd>Controls the interpretation of variables that start with an underscore (excluding the anonymous variable) that occur once in a term as either don't care variables or singleton variables. Possible option values are <code>dont_care</code> and <code>singletons</code> (the usual default). Note that, depending on your Prolog compiler, the <code>read_term/3</code> built-in predicate may report variables that start with an underscore as singleton variables. There is no standard behavior, hence this option.</dd>
</dl>
<dl>
<dt><code>misspelt(Option)</code></dt>
<dd>Controls the misspelt predicate call warnings. A misspelt call is a call to a predicate which is not defined in the object or category containing the call, is not declared as dynamic, and is not a Logtalk/Prolog built-in predicate. Possible option values are <code>warning</code> (the usual default) and <code>silent</code> (not recommended).</dd>
</dl>
<dl>
<dt><code>lgtredef(Option)</code></dt>
<dd>Controls the Logtalk built-in predicate redefinition warnings. Possible option values are <code>warning</code> (the usual default) and <code>silent</code>. These warnings are almost always programming errors.</dd>
</dl>
<dl>
<dt><code>plredef(Option)</code></dt>
<dd>Controls the Prolog built-in predicate redefinition warnings. Possible option values are <code>warning</code> (can be very verbose if your code redefines a lot of Prolog built-in predicates) and <code>silent</code> (the usual default). When running a Logtalk application on several Prolog compilers, is possible to get different sets of warnings due to different sets of built-in predicates implemented by each Prolog compiler.</dd>
</dl>
<dl>
<dt><code>portability(Option)</code></dt>
<dd>Controls the non-ISO specified built-in predicate calls warnings. Possible option values are <code>warning</code> and <code>silent</code> (the usual default).</dd>
</dl>
<dl>
<dt><code>xmldocs(Option)</code></dt>
<dd>Controls the automatic generation of documenting files in XML format. Possible option values are <code>on</code> (the usual default) and <code>off</code>.</dd>
</dl>
<dl>
<dt><code>xmlspec(Option)</code></dt>
<dd>Defines the XML documenting files specification format. Possible option values are <code>dtd</code> (for the DTD specification; the usual default) and <code>xsd</code> (for the XML Schema specification). Most XSL processors support DTDs but only some of them support XML Schemas.</dd>
</dl>
<dl>
<dt><code>xmlsref(Option)</code></dt>
<dd>Sets the reference to the XML specification file in the automatically generated XML documenting files. The default value is <code>local</code>, that is, the reference points to a local DTD or XSD file (respectively, <code>logtalk.dtd</code> or <code>logtalk.xsd</code>), residing in the same directory as the XML file. Other possible values are <code>web</code> (the reference points to an web location, either <code>http://www.logtalk.org/xml/1.3/logtalk.dtd</code> or <code>http://www.logtalk.org/xml/1.3/logtalk.xsd</code>), and <code>standalone</code> (no reference to specification files in the XML documenting files). The most appropriated option value depends on the XSL processor you intend to use. Some of them are buggy an may not work with the default option value.</dd>
</dl>
<dl>
<dt><code>xslfile(File)</code></dt>
<dd>Sets the XSLT file to be used with the automatically generated XML documenting files. The default value is <code>lgtxml.xsl</code>, which allows the XML files to be viewed by simply opening them with recent versions of web navigators which support XSLT transformations (after copying the <code>lgtxml.xsl</code> and of the <code>logtalk.css</code> files to the directory containing the XML files).</dd>
</dl>
<dl>
<dt><code>report(Option)</code></dt>
<dd>Controls reporting of each compiled or loaded object, category, or protocol (including compilation and loading warnings). Possible option values are <code>on</code> (the usual default) and <code>off</code> (silent compilation and loading).</dd>
</dl>
<dl>
<dt><code>smart_compilation(Option)</code></dt>
<dd>Controls the use of smart compilation of source files to avoid recompiling files that are unchanged since the last time they are compiled. Possible option values are <code>on</code> and <code>off</code> (the usual default). This option is only supported in some Prolog compilers. It must not be used when compiling source files in debug mode (see <code>debug/1</code> option below).</dd>
</dl>
<dl>
<dt><code>code_prefix(Option)</code></dt>
<dd>Enables the definition of prefix for all functors of Prolog code generated by the Logtalk compiler. The option value must be an atom; the default value is the empty atom (<code>''</code>). Specifying a code prefix provides a way to solve possible conflicts between Logtalk compiled code and other Prolog code. In addition, some Prolog compilers automatically hide predicates whose functor start with a specific prefix such as the character <code>$</code>.</dd>
</dl>
<dl>
<dt><code>debug(Option)</code></dt>
<dd>Controls the compilation of source files in debug mode (the Logtalk built-in debugger can only be used with files compiled in this mode). Possible option values are <code>on</code> and <code>off</code> (the usual default).</dd>
</dl>
<dl>
<dt><code>hook(Object::Functor)</code></dt>
<dd>Allows the definition of a compiler hook that is called for each term read form a source file. This option specifies both an object (which can be the pseudo-object <code>user</code>) and the functor of a public predicate with two arguments, the first one receiving the term read form the source file and the second one returning a list of terms corresponding to the expansion of the first argument.</dd>
</dl>
</blockquote>
<p>
We may also change the default flag values from the ones loaded from the config file by using the <a title="Consult reference manual" href="../refman/builtins/set_logtalk_flag2.html"><code>set_logtalk_flag/2</code></a> built-in predicate. For example:
</p>
<pre>| ?- set_logtalk_flag(xmldocs, off).</pre>
<p>
The current default flags values can be enumerated using the <a title="Consult reference manual" href="../refman/builtins/current_logtalk_flag2.html"><code>current_logtalk_flag/2</code></a> built-in predicate:
</p>
<pre>| ?- current_logtalk_flag(xmldocs, Value).
Value = off
yes</pre>
<h3>Smart compilation of source files<a id="smart"></a></h3>
<p>
If the Prolog compiler that you are using supports retrieving of file modification dates, then you can turn on smart compilation of source files to avoid recompiling files that have not been modified since last compilation.
</p>
<p>
Smart compilation of source files is usually off by default. You can turn it on by changing the default flag value in the configuration file, by using the corresponding compiler flag with the compiling and loading built-in predicates, or, for the remaining of a working session, by using the call:
</p>
<pre>| ?- set_logtalk_flag(smart_compilation, on).</pre>
<p>
Some caveats that you should be aware. First, some warnings that might be produced when compiling a source file will not show up if the corresponding object file is up-to-date because the source file is not being (re)compiled. Second, if you are using several Prolog compilers with Logtalk, be sure to perform the first compilation of your source files with smart compilation turned off: the intermediate Prolog files generated by the Logtalk preprocessor may be not compatible across Prolog compilers or even for the same Prolog compiler across operating systems (due to the use of different end-of-line characters).
</p>
<h2>Using Logtalk for batch processing<a id="batch"></a></h2>
<p>
If you use Logtalk for batch processing, you probably want to suppress most, if not all, banners, messages, and warnings that are normally printed by the system. To suppress printing of the Logtalk startup banner and default flags, set the option <code>startup_message</code> in the config file that you are using to <code>none</code>. To suppress printing of compiling and loading messages (including compiling warnings but not compiling error messages), turn off the option <code>report</code>.
</p>
<h2>Debugging Logtalk programs<a id="debugging"></a></h2>
<p>
Logtalk defines a built-in pseudo-object named <code>debugger</code>, which implements debugging features similar to those found on most Prolog compilers. However, there are some differences between the usual implementation of Prolog debuggers and the current implementation of the Logtalk debugger that you should be aware. First, unlike some Prolog debuggers, the Logtalk debugger is not implemented as a meta-interpreter. This translates to a different, although similar, set of debugging features with some limitations when compared with some Prolog debuggers. Second, debugging is only possible for objects compiled in debug mode. When compiling an object in debug mode, Logtalk keeps each clause goal in both source form and compiled form in order to allow tracing of the goal execution. Third, implementation of spy points allows the user to specify the execution context for entering the debugger. This feature is a consequence of the encapsulation of predicates inside objects.
</p>
<h3>Compiling entities in debug mode<a id="debugmode"></a></h3>
<p>
Compilation of source files in debug mode is controlled by the compiler flag <code>debug</code>. The default value for this flag, usually <code>off</code>, is defined in the config files. Its value may be changed at runtime by writing:
</p>
<pre>| ?- set_logtalk_flag(debug, on).
yes</pre>
<p>
In alternative, if we want to compile only some entities in debug mode, we may instead write:
</p>
<pre>| ?- logtalk_load([file1, file2, ...], [debug(on)]).</pre>
<p>
The compiler flag <code>smart_compilation</code> is automatically turned off whenever the debug flag is turned on at runtime. This is necessary because debug code would not be generated for files previously compiled in normal mode if there is no changes to the source files. However, note that you should be careful to not turn both flags on at the same time in a config file.
</p>
<p>We may check or enumerate, by backtracking, all loaded entities compiled in debug mode as follows:
</p>
<pre>| ?- debugger::debugging(Entity).</pre>
<h3>Logtalk Procedure Box model<a id="boxmodel"></a></h3>
<p>
Logtalk uses a <em>Procedure Box model</em> similar to those found on most Prolog compilers. The traditional Prolog procedure box model uses four ports (<em>call</em>, <em>exit</em>, <em>redo</em>, and <em>fail</em>) for describing control flow when a predicate clause is used during program execution:
</p>
<blockquote>
<dl>
<dt><code>call</code></dt>
<dd>predicate call</dd>
<dt><code>exit</code></dt>
<dd>success of a predicate call</dd>
<dt><code>redo</code></dt>
<dd>backtracking into a predicate</dd>
<dt><code>fail</code></dt>
<dd>failure of a predicate call</dd>
</dl>
</blockquote>
<p>
Logtalk, as found on some recent Prolog compilers, adds a port for dealing with exceptions thrown when calling a predicate:
</p>
<blockquote>
<dl>
<dt><code>exception</code></dt>
<dd>predicate call throws an exception</dd>
</dl>
</blockquote>
<p>
In addition to the ports described above, Logtalk adds two more ports, <em>fact</em> and <em>rule</em>, which show the result of the unification of a goal with, respectively, a fact and a rule head:
</p>
<blockquote>
<dl>
<dt><code>fact</code></dt>
<dd>unification success between a goal and a fact</dd>
<dt><code>rule</code></dt>
<dd>unification success between a goal and a rule head</dd>
</dl>
</blockquote>
<p>
The user may define for which ports the debugger should pause for user interaction by specifying a list of leashed ports. For example:
</p>
<pre>| ?- debugger::leash([call, exit, fail]).</pre>
<p>
Alternatively, the user may use an atom abbreviation for a pre-defined set of ports. For example:
</p>
<pre>| ?- debugger::leash(loose).</pre>
<p>
The abbreviations defined in Logtalk are similar to those defined on some Prolog compilers:
</p>
<blockquote>
<dl>
<dt><code>none</code></dt>
<dd><code>[]</code></dd>
<dt><code>loose</code></dt>
<dd><code>[fact, rule, call]</code></dd>
<dt><code>half</code></dt>
<dd><code>[fact, rule, call, redo]</code></dd>
<dt><code>tight</code></dt>
<dd><code>[fact, rule, call, redo, fail, exception]</code></dd>
<dt><code>full</code></dt>
<dd><code>[fact, rule, call, exit, redo, fail, exception]</code></dd>
</dl>
</blockquote>
<h3>Defining spy points<a id="spypoints"></a></h3>
<p>
Logtalk spy points can be defined by simply stating which predicates should be spied, as in most Prolog debuggers, or by fully specifying the context for activating a spy point.
</p>
<h4>Defining predicate spy points<a id="pspypoints"></a></h4>
<p>
Predicate spy points are specified using the method <code>spy/1</code>. The argument can be either a predicate indicator (<code>Functor/Arity</code>) or a list of predicate indicators. For example:
</p>
<pre>| ?- debugger::spy(foo/2).
Spy points set.
yes
| ?- debugger::spy([foo/4, bar/1]).
Spy points set.
yes</pre>
<p>
Predicate spy points can be removed by using the method <code>nospy/1</code>. The argument can be a predicate indicator, a list of predicate indicators, or a non-instantiated variable in which case all predicate spy points will be removed. For example:
</p>
<pre>| ?- debugger::nospy(_).
All matching predicate spy points removed.
yes</pre>
<h4>Defining context spy points<a id="cspypoints"></a></h4>
<p>
A context spy point is a term describing a message execution context and a goal:
</p>
<pre>(Sender, This, Self, Goal)</pre>
<p>
The debugger is evoked whenever the execution context is true and when the spy point goal unifies with the goal currently being executed. Variable bindings resulting from the unification between the current goal and the goal argument are discarded. The user may establish any number of context spy points as necessary. For example, in order to call the debugger whenever a predicate defined on an object named <code>foo</code> is called we may define the following spy point:
</p>
<pre>| ?- debugger::spy(_, foo, _, _).
Spy point set.
yes</pre>
<p>
For example, we can spy all calls to a <code>foo/2</code> predicate by setting the condition:
</p>
<pre>| ?- debugger::spy(_, _, _, foo(_, _)).
Spy point set.
yes</pre>
<p>
The method <code>nospy/4</code> may be used to remove all matching spy points. For example, the call:
</p>
<pre>| ?- debugger::nospy(_, _, foo, _).
All matching context spy points removed.
yes</pre>
<p>
will remove all context spy points where the value of <em>Self</em> matches the name <code>foo</code>.
</p>
<h4>Removing all spy points<a id="nospyall"></a></h4>
<p>
We may remove all predicate spy points and all context spy points by using the method <code>nospyall/0</code>:
</p>
<pre>| ?- debugger::nospyall.
All predicate spy points removed.
All context spy points removed.
yes</pre>
<h3>Tracing program execution<a id="trace"></a></h3>
<p>
Logtalk allows tracing of execution for all objects compiled in debug mode. To start the debugger in trace mode, write:
</p>
<pre>| ?- debugger::trace.
yes</pre>
<p>
Note that, when tracing, spy points will be ignored. While tracing, the debugger will pause for user input at each leashed port.
</p>
<p>
To stop tracing and turning off the debugger, write:
</p>
<pre>| ?- debugger::notrace.
yes</pre>
<h3>Debugging using spy points<a id="debug"></a></h3>
<p>
Tracing a program execution may generate large amounts of debugging data. Debugging using spy points allows the user to concentrate its attention in specific points of its code. To start a debugging session using spy points, write:
</p>
<pre>| ?- debugger::debug.
yes</pre>
<p>
At the beginning of a port description, the debugger will print a <code>+</code> or a <code>*</code> before the current goal if there is, respectively, a predicate spy point or a context spy point defined.
</p>
<p>
To stop the debugger, write:
</p>
<pre>| ?- debugger::nodebug.
yes</pre>
<p>
Note that stopping the debugger does not remove any defined spy points.
</p>
<h3>Debugging commands<a id="commands"></a></h3>
<p>
The debugger pauses at leashed posts when tracing or when finding a spy point for user interaction. The commands available are as follows:
</p>
<blockquote>
<dl>
<dt><code>c</code> — creep</dt>
<dd>go on; you may use the spacebar in alternative (but not the return or enter keys)</dd>
<dt><code>l</code> — leap</dt>
<dd>continues execution until the next spy point is found</dd>
<dt><code>s</code> — skip</dt>
<dd>skips debugging for the current goal; only valid at call and redo ports</dd>
<dt><code>f</code> — fail</dt>
<dd>forces backtracking</dd>
<dt><code>n</code> — nodebug</dt>
<dd>turns off debugging</dd>
<dt><code>@</code> — command</dt>
<dd>reads and executes a query</dd>
<dt><code>b</code> — break</dt>
<dd>suspends execution and starts new interpreter; type <code>end_of_file</code> to terminate</dd>
<dt><code>a</code> — abort</dt>
<dd>returns to top level interpreter</dd>
<dt><code>d</code> — display</dt>
<dd>writes current goal without using operator notation</dd>
<dt><code>x</code> — context</dt>
<dd>prints execution context</dd>
<dt><code>e</code> — exception</dt>
<dd>prints exception term thrown by the current goal</dd>
<dt><code>=</code> — debugging</dt>
<dd>prints debugging information</dd>
<dt><code>*</code> — add</dt>
<dd>adds a context spy point for the current goal</dd>
<dt><code>+</code> — add</dt>
<dd>adds a predicate spy point for the current goal</dd>
<dt><code>-</code> — remove</dt>
<dd>removes a predicate spy point for the current goal</dd>
<dt><code>h</code> — help</dt>
<dd>prints list of command options; <code>?</code> can be used in alternative</dd>
</dl>
</blockquote>
<div class="footer">
<div class="navbottom"><a href="installing.html">previous</a> | <a href="../glossary.html">glossary</a> | <a href="programming.html">next</a></div>
<div class="copyright">Copyright © <a href="mailto:pmoura@logtalk.org">Paulo Moura</a> — <a href="http://www.logtalk.org">Logtalk.org</a></div>
<div class="footnote">
<span class="validators"><a href="http://validator.w3.org/check/referer">XHTML</a> + <a href="http://jigsaw.w3.org/css-validator/check/referer">CSS</a></span>
<span class="date">Last updated on: January 29, 2006</span>
</div>
</div>
</body>
</html>
|
