| This section is under
development. It will eventually describe how to debug Brainhat in
some detail. For now, I will provide a cursory overview of the
most important techniques. You will find that Brainhat has debug
capabilities throughout. You can enter debug mode at any time by
entering:
-
>> break
at the ">>"
prompt. You can return to processing by entering the
debug> cont
command.
Debug mode is useful for
examining Brainhat's context and discourse buffers, and for
looking at individual concept definitions from the context and
from the basic knowledge pool. The following is the output of the
help command within debug mode:
-
>> break
Break in debug at the start:
debug> help
Commands:
DEBUG routine-or-process[ location]
Enable debug type, and optionally stop at listed locations.
NODEBUG routine-or-process
Disable debug type.
DUMP [n]
Dump optional argument concept (if concept).
Dump optional conchain (if conchain).
"n" chooses conchain element.
RDUMP [n]
Dump recursively.
LIST label
Show all symbols matching label.
WORDS
Dump pre-prepared word list.
STOP
Stop.
S[R]DUMP label
Dump symbol from basic knowledge pool.
C[R]DUMP label
Dump symbol from context.
X[R]DUMP label
Dump CC from context.
D[R]DUMP label
Dump symbol from discourse buffer.
X[R]DUMP label
Dump CC from context.
SPEAK [n]
Speak optional argument concept (if concept).
Speak optional conchain (if conchain).
XSPEAK [n]
Speak nth context entry.
DSPEAK [n]
Speak nth discourse entry.
"n" chooses conchain element.
"location" is one of {start, loc[1-3], finish, all}
debug> cont
>>
Say that you want to examine what
Brainhat has recorded for definitions of "block". You
could step into debug mode and ask Brainhat to list all concepts
known as "block".
-
>> the block is red
the block is red.
>> break
Break in debug at the start:
debug> list block
block-1 (basic pool)
block-1-36d0 (context)
Two definitions appear--one from
the basic knowledge pool, and one from the context. To examine the
copy from basic knowledge pool, use the srdump command,
as described above. To examine a concept from the context, use the
crdump command, as below:
-
debug> crdump block-1-36d0
define block-1-36d0 [2210]
label block
attribute red-1-36cf
article the-1-3600
typically square-1
wants size-1
wants color-1
child toy-1
define red-1-36cf [2236]
label red
tense present
orthogonal color-1
child color-1
define present [7153]
child tense
define color-1 [2224]
label color
child attribute-1
define the-1-3600 [1888]
label the
child definite
child article-1
define square-1 [2350]
label square
orthogonal shape-1
child shape-1
define shape-1 [2339]
label shape
child attribute-1
define size-1 [2284]
label size
typically small-1
child attribute-1
define small-1 [2290]
label small
orthogonal size-1
child size-1
define color-1 [2224]
label color
child attribute-1
debug> cont
Debug also allows you to examine
the contents of concepts and chains of concepts as they proceed
through processing. You can select from the many breakpoints
embedded in the code. Most of the post processing routines, for
example, can be break-pointed at the entry, exit, and in the
middle, as appropriate. Futhermore, a breakpoint may have data
associated with it. A concept or a string of concepts (a "conchain")
may be available once the break occurs--it depends upon how the
breakpoint was coded.
As an example, the following sets
a breakpoint at the start of a routine called chooseone
that has the job of skinnying down a list of candidate complex
concepts into a single winner:
-
debug> break chooseone start
When the program runs and
processing passes to chooseone, the program will go into
debug mode. At that point, you may exercise an of the commands
listed above. A typical command to issue upon breaking at the
start of a post routine would be:
-
debug> dump
This will list the contents of
the conchain passed to chooseone, and thereby allow you
to see the field of candidates available to the routine before it
makes its selection.
In addition to routine
breakpoints, you may also set debug flags (coded to look like
breakpoints) that will reveal something about processing along the
way. One I often use is called input1. It will show which
rules in input-patterns are matching my input.
-
debug> break input1
debug> cont
There is much more to this
subject. I hope to return to documentation sometime soon.
|
