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

[Julien Fischer]

On Thu, 19 May 2005, Ian MacLarty wrote:

> On Fri, 13 May 2005, Julien Fischer wrote:
>
> > >
> > > Okay, how about if I'm building a supertree I just print a dot every
> > > second?  That would be pretty easy to do.  I'll do that and also add a
> > > summary of how subtrees and supertrees are built to the top of
> > > mercury_trace_declarative.c and then I'll post the interdiff for
> > > review.
> > >
> > Yes, something like that.  I think that it is important that
> > the user experience here is consistent (or at least as consistent
> > as is easily possible.)
> >
>
> Here's the interdiff.  I have also put an overview of the backend in
> mercury_trace_declarative.c and removed some of the complexity around depth
> limits by making edt_dependency check if an explicit subtree is required,
> instead of relying on the backend to ensure that the children of nodes at the
> depth limit are materialized.
>

...

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

>  **
>  ** The backend can be called multiple times to materialize different portions
>  ** of the annotated trace.  It is the responsibility of the frontend to
>  ** connect the various portions of the annotated trace together into a
>  ** complete tree.  This is done in declarative_edt.m.
>  **
> +**
> +** 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.)

> +** 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.


> +**    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/

> +** 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.

> +** 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.

> +** 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/

> +** 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 ...

> +** 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/

> +** 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/

> +** performed to get MR_edt_default_depth_limit levels above the currently
> +** materialized tree.  Execution is then restarted from this point and
> +** collection of events begins.  Events are collected down to the depth of
> +** the root of the previously materialized tree as illustrated in the
> +** following diagram.
> +**
> +**                     /\     |
> +**                    /  \    |- Newly materialized supertree
> +**                   /    \   |
> +**                     /\       |
> +**                    /  \      |
> +**                   /    \     |- Previously materialized tree
> +**                  /      \    |
> +**                 /        \   |
> +**
>  */
>

...

> @@ -2325,26 +2378,56 @@
>  			** We count the initial progress message as the first
>  			** tick.
>  			*/
> -			last_tick = 1;
> -		} else if (last_tick > 0) {
> +                MR_edt_progress_last_tick = 1;
> +            } else if (MR_edt_progress_last_tick > 0) {
>  			current_tick = ((event_number - MR_edt_first_event)
>  					* MR_DECL_PROGRESS_TOTAL)
>  				/ (MR_edt_last_event - MR_edt_first_event);
> -			if (current_tick != last_tick) {
> -				for (; last_tick < current_tick; last_tick++) {
> +                if (current_tick != MR_edt_progress_last_tick) {
> +                    for (; MR_edt_progress_last_tick < current_tick;
> +                        MR_edt_progress_last_tick++)
> +                    {
>  					fprintf(MR_mdb_out,
>  						MR_DECL_PROGRESS_TICK_STRING);
>  					fflush(MR_mdb_out);
>  				}
> -				if (current_tick == MR_DECL_PROGRESS_TOTAL) {
> -					fprintf(MR_mdb_out, "\n");
> -					last_tick = 0;
>  				}
>  			}
> +        } 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/

...

> --- CVSLOG.old	2005-05-19 20:35:57.000000000 +1000
> +++ CVSLOG	2005-05-19 20:40:05.000000000 +1000
> @@ -31,6 +31,10 @@
>  browser/declarative_debugger.m:
>   	Pass the ideal depth of a subtree to the backend.
>
> +browser/declarative_edt.m:
> +	Handle the case where edt_dependency says an explicit subtree is
> +	required.
> +
>  browser/declarative_execution.m:
>  	Record the ideal depth at the CALL event corresponding to the root
>  	of an implicit subtree.
> @@ -41,6 +45,12 @@
>  	Export a new predicate, trace_implicit_tree_info, which is used to
>  	get the info stored at the root of an implicit root.
>
> +	Make trace_dependency respond that an explicit subtree is required
> +	if it needs to explore the children of an implicit subtree.  Previously
> +	we made this situation impossible by requiring the backend to
> +	always generate the children of nodes at the depth limit.  This,
> +	however, complicated the backend code unnecessarily.
> +
>  doc/user_guide.texi:
>  	Change the --depth-step-size dd option to just --depth which is now
>  	only used as the initial depth to build the subtree to.  Comment out
> @@ -76,6 +86,9 @@
>  	instead of using the value of the global MR_edt_depth_step_size
>  	(which no longer exists).
>
> +	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.

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