[m-rev.] for review: accurately calculate depth to build subtrees to

[Ian MacLarty]

On Fri, 20 May 2005, Julien Fischer wrote:

>
> > diff -bu trace/mercury_trace_declarative.c trace/mercury_trace_declarative.c
> > --- trace/mercury_trace_declarative.c	13 May 2005 02:40:38 -0000
> > +++ trace/mercury_trace_declarative.c	19 May 2005 10:26:21 -0000
> > @@ -1,4 +1,7 @@
> >  /*
> > +** vim: ts=4 sw=4 expandtab
> > +*/
> > +/*
> >  ** Copyright (C) 1998-2005 The University of Melbourne.
> >  ** This file may only be copied under the terms of the GNU Library General
> >  ** Public License - see the file COPYING.LIB in the Mercury distribution.
> > @@ -27,16 +30,84 @@
> >  ** 	  than analyzing them for bugs.
> >  **
> >  ** The backend decides which events should be included in the annotated trace.
> > -** Given a final event the backend can either build the
> > -** annotated trace for the subtree rooted at the final event down to a specified
> > -** depth limit, or can build the tree a specified number of ancestors above the
> > -** given event, with the given event as an implicit root of the existing trace.
> > +** Given a final event the backend can either build the annotated trace for the
> > +** subtree rooted at the final event down to a specified depth limit, or can
> > +** build the tree a specified number of ancestors above the given event.
> s/a/to a/
>

I've removed this bit (from Given...) as pretty much the same thing is stated
in clearer terms below.

> > +**
> > +** Overview of the declarative debugger backend
> > +** --------------------------------------------
> > +**
> > +** Building of a new portion of the annotated trace is started when either the
> > +** user issues a `dd' command from the procedural debugger, or the
> > +** frontend requests that a new explicit subtree or supertree be built.
> > +**
> > +** Initially the trace is materialized down to a predefined depth, given
> > +** by the value of MR_edt_default_depth_limit.  We retry to the CALL event
> > +** corresponding to the EXIT, FAIL or EXCP event where the `dd' command was
> > +** issued and rerun the program, collecting all events above the depth limit.
> > +** Once we get to the EXIT, FAIL or EXCP event where the `dd' command was
> > +** issued, we call the front end (in browser/declarative_debugger.m) and
>
> s/front end/frontend/ since that's what you've used elsewhere.
> (You also swap between the two below.)
>

Have changed to "front end" and "back end" throughout.

> > +** ask it to analyse the generated trace.  The frontend then returns with one
> > +** of three possible responses:
> > +**
> > +**    1.  The front end wants control to return to the procedural debugger.
> > +**        This could be because the bug has been found, or the user has
> > +**        exited the declarative debugging session.
> > +**    2.  The front end wants the subtree of a specific node in the annotated
> > +**        trace.  Here the frontend will tell the backend to what depth it
> > +**        wants the new subtree built to.
>
> I suggest:
>
> 	... wants to build the new subtree to.
>

That sounds like the front end is doing the building.

>
> > +**    3.  The front end wants nodes generated above the currently materialized
> > +**        portion of the annotated trace (refered to here as a supertree).
> > +**
> s/refered/referred/
>

Fixed.

> > +** In case 1 the frontend may want control returned to the procedural debugger
> may want control returned or will want control returned?   If the
> former, what happens when it doesn't want control returned to the
> procedural debugger.
>

The front end may want control returned to the procedural debugger *at an event
other than the event where the `dd' command was issued*.

> > +** at an event other than the event where the `dd' command was issued.  If this
> > +** is the case then we perform a retry to get to an event before the desired
> > +** event and then simulate a `goto' command, so that mdb prompts the user
> > +** at the desired event.
> > +**
> > +** In case 2 the frontend will supply the event number and call sequence
> > +** number of the EXIT, FAIL or EXCP event at the root of the required subtree.
> > +** The backend will then retry to a CALL event before or equal to the CALL
> > +** with the given sequence number.  The program is then reexecuted and nodes
> > +** are added to the annotated trace to the depth limit specified by the
> > +** frontend.
> > +**
> > +** If, while the program is being reexecuted, the call depth exceeds the
> > +** depth limit, then we record, in an array, how many events are at each
>
> It's probably worth including some sort of link to the array here.
>

It's now:
** limit, then we record (in the array MR_edt_implicit_subtree_counters) how

> > +** depth below the depth limit.  The data collected is used to populate
> > +** a field at each CALL event which is the root of an implicit (unmaterialized)
> s/which/that/
>

Fixed.

> > +** subtree in the annotated trace.  The field (called the ideal depth) gives
> > +** the maximum depth the implicit subtree needs to be built to so that no more
>
> I suggest:
>
> 	The field (...) gives the maximum depth to build the subtree to
> 	so that ...
>

Done.

> > +** than MR_edt_desired_nodes_in_subtree nodes are materialized.  The frontend
> > +** passes the ideal depth to the backend when requesting a new subtree.
> > +**
> > +** In case 3 the frontend will supply the event number and call sequence
> > +** number of the EXIT, FAIL or EXCP event at the root of the currently
> > +** materialized tree.  As with case 2 the backend will retry to a CALL before
> > +** the given call sequence number and start rexecuting the program, however
> s/rexecuting/reexecuting/
>

Done.

> > +** no events are added to the annotated trace yet.  When execution reaches the
> > +** CALL event with the sequence number given by the frontend, another retry is
> s/with/matching/
>

Okay.

> >  				}
> >  			}
> > +        } else {
> > +            /*
> > +            ** If we are building a supertree we don't know what the
> > +            ** final event will be, so we just show a tick every
> > +            ** MR_DECL_DISPLAY_PROGRESS_DELAY miliseconds, so at least
> > +            ** the user knows something is happening.
> s/miliseconds/milliseconds/
>

Fixed.  That means MR_get_user_cpu_miliseconds is misspelt though.

> > +	Do not materialize the children of nodes at the depth limit, since
> > +	this is no longer necessary.
> > +
> >  trace/mercury_trace_internal.c:
> >  	Add and handle the --nodes dd option.  Rename the --depth-step-size
> >  	option to --depth.
> >
> The log message should also mention the addtion of the overview to
> mercury_trace_declarative.c.
>

Done.

Thanks,

Ian.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------