Home  Download  Install  Demo  Programming VoiceXML Speech Interfaces Technical

Brainhat - Debug


Contact Us
Kevin Dowd
111 Founders Plaza
13th Floor
East Hartford, CT 06108
(860) 291-0851

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


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
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.
  Dump recursively.
LIST label
  Show all symbols matching label.
  Dump pre-prepared word list.
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 optional argument concept (if concept).
  Speak optional conchain (if conchain).
  Speak nth context entry.
  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.

©2001 Brainhat, Inc. All rights reserved.