[m-dev.] for review: the new debugger command set (part 2 of 5)

[Mark Anthony BROWN]

Hi,

I didn't see any inconsistencies in the documentation
re the box model.  NB: one potential problem was that the
term "port", which originally referred to an entry or exit
point of a box, is not (IMO) a very good term for something
which the tracer reports.  The term "event" is much better.

Here's some _actual_ problems:


> Index: doc/mdb_categories
> ===================================================================

...

> +document_category 400 browsing
> +browse     - The commands that let users explore the state of the computation.
> +             The browse commands are vars, print, stack, up, down, level,
> +	     and event.

s/browse/browsing/
or vice-versa

> +document_category 600 parameter
> +parameter  - The commands that let users access debugger parameters.
> +             The params commands are printlevel, echo, scroll, alias and
> +	     unalias.

Likewise,
s/params/parameter/
or vice-versa

> +document_category 1000 misc
> +misc       - The commands that do not fit into other categories.
> +             The misc commands are alias, source and quit.

alias is also listed as a "parameter" command.


> Index: doc/user_guide.texi
> ===================================================================

...

> + at table @var
> + at item trace level none
> +A procedure compiled with trace level none
> +will never generate any events.
> + at item trace level deep
> +A procedure compiled with trace level deep
> +will always generate all the events requested by the user.
> + at item trace level shallow
> +A procedure compiled with trace level shallow
> +will generate interface events
> +if it is called from a procedure compiled with trace level deep,
> +while it will generate no events
> +if it is called from a procedure compiled with trace level shallow.
> +Which way it will behave
> +if it is called from a procedure compiled with trace level none
> +depends on whether its nearest anscestor whose trace level is not none

s/anscestor/ancestor/

> + at c XXX interrupts:
> + at c If the debugger recieves an interrupt, it will stop at the next event

s/recieves/receives/

> +The debugger can perform a retry only from an exit or fail port;
> +only at these ports does the debugger have enough information
> +to figure out how to reset the stacks.
> +If the debugger is not at such a port when a retry command is given,
> +the debugger will continue forward execution
> +until it reaches an exit or fail port of the call to be retries

s/retries/retried/


-- 
Mark Brown  (dougl at cs.mu.oz.au)           |  Let's talk about tax, baby
MEngSc student,                     )O+   |  Let's talk about GST
Dept of Computer Science                  |  Let's make a wider gap twixt
University of Melbourne                   |  Affluence and po-ver-ty ...