[m-rev.] For review: allow declarative debugger to search upward from initial symptom

[Julien Fischer]

On Sat, 4 Dec 2004, Ian MacLarty wrote:

> On Fri, Dec 03, 2004 at 12:48:34AM +1100, Julien Fischer wrote:
> > > Index: doc/user_guide.texi
> > > ===================================================================
> > > RCS file: /home/mercury1/repository/mercury/doc/user_guide.texi,v
> > > retrieving revision 1.398
> > > diff -u -r1.398 user_guide.texi
> > > --- doc/user_guide.texi	19 Nov 2004 11:54:21 -0000	1.398
> > > +++ doc/user_guide.texi	29 Nov 2004 09:30:27 -0000
> > > @@ -3215,8 +3215,17 @@
> > >  @c makes an assertion, and if the assertion is incorrect, the resulting
> > >  @c behaviour would be hard for non-developers to understand. The option is
> > >  @c therefore deliberately not documented.
> > > -Starts declarative debugging
> > > -using the current event as the initial symptom.
> > > +Starts declarative debugging using the current event as the initial symptom.
> > > + at sp 1
> > > +The declarative debugger searches for bugs in a debug tree.  Only a portion of
> >
> > Dropping in the term "debug tree" without any further explanation isn't so
> > good - the rest of the documentation for the declarative debugger
> > doesn't use the term.
> >
> > > +the debug tree is materialized at any time to save memory.  When a new portion
> > > +of the tree needs to be materialized the program being debugged is re-executed.
> >
> > I think the concept of the tree being "materialized" needs further
> > explanation.  Perhaps it would be better to say that the dd can only
> > consider parts of the program at once and that it is the size of these
> > parsts that the`--depth-step-size' option controls?
> >
> I didn't want to go into too much detail about how the declarative debugger
> works here.  I've changed the text to the following which avoids using the
> term "debug tree".  I think the concept of an "execution trace" should be
> familiar to someone using the debugger.
>
> When searching for bugs the declarative debugger needs to keep portions of the
> execution trace in memory.  If it requires a new portion of the trace then it
> needs to rerun the program.  The @samp{-d at var{depth}} and
> @samp{--depth-step-size @var{depth}} options tell the declarative debugger how
> much of the execution trace to gather when it reruns the program.  A higher
> @var{depth} will require more memory, but will improve the performance of the
> declarative debugger for long running programs since it will not have to rerun
> the program as much.
>
I think that is better.

> > > +to the call came from.  To find out you could first go to the final event by
> >
> > I'd change "could" to "would" there unless there is another way of doing
> > it.
> >
> Well you could just look for it manually...
>
True enough.

> > > The
> > > +next question should be about the call that bound the term at which point you
> > s/should/will/?
> > > +could issue a @samp{pd} command to return to the procedural debugger at the
> > > +final event of the call that bound the term.
> > >
> > It seems like two sentences have run into each other there.  I suggest
> > splitting that sentence up.
> >
> I've changes it to:
>
> The next question should be about the call that bound the term.  Issue a
> @samp{pd} command at this point to return to the procedural debugger at the
> final event of the call that bound the term.
>
I think the last sentence should be something like:

	Issue a @samp{pd} command to return to the procedural debugger.
	It will now show the final event of the call that bound the
	term.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------