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

[Ian MacLarty]

On Wed, 11 May 2005, Julien Fischer wrote:

> >  @sp 1
> >  The @samp{-s at var{search-mode}} or @samp{--search-mode @var{search-mode}}
> >  option tells the declarative debugger which
> > @@ -3340,9 +3346,9 @@
> >  declarative debugging session.  If the @samp{--resume} option is given and
> >  there were no previous declarative debugging sessions then the option will be
> >  ignored.  A @samp{dd --resume} command can be issued at any event.  The
> > - at samp{--search-mode} or @samp{--depth-step-size} options can be used in
> > -conjunction with the @samp{--resume} option to change the search mode or depth
> > -step size of a previously started declarative debugging session.
> > + at samp{--search-mode} option can be used in
> > +conjunction with the @samp{--resume} option to change the search mode
>
> I suggest:
>
> 	The --search-mode option may be used with the --resume option
> 	to change the search mode.
>

It's now:
The @samp{--search-mode} option may be used with the @samp{--resume} option
to change the search mode of a previously started declarative debugging
session.

> The comment should (briefly) mention what the statistics are.
>

** If this macro is defined then some statistics, such as how many nodes were
** added to the annotated trace in the current run and the amount of memory
** consumed so far,  will be printed to stderr whenever a new subtree or
** supertree is built.

> >  /*
> >  ** The declarative debugger back end is controlled by the
> > @@ -196,6 +209,28 @@
> >  static	MR_Unsigned	MR_edt_max_depth;
> >
> >  /*
> > +** The time, in milliseconds since the start of the program, when collecting of
> > +** events for the current portion of the annotated trace being materialized
> > +** started.
> > +*/
> That doesn't make a great deal of sense.
>

What part don't you understand?

What about:
The time (in milliseconds since the start of the program) when collecting of
events, for the current portion of the annotated trace being materialized,
started.

> > @@ -1688,6 +1785,16 @@
> >  	MR_edt_max_depth = maxdepth;
> >  	MR_edt_inside = MR_FALSE;
> >  	MR_edt_building_supertree = create_supertree;
> > +	MR_edt_start_time = MR_get_user_cpu_miliseconds();
> > +	MR_edt_first_event = event_details->MR_event_number;
> > +
> > +	/*
> > +	** The deepest we will build any implicit subtree to will be
> s/deepest we will/maximum depth to which we will/
>

What's wrong with deepest?

>
> > @@ -1861,20 +1970,25 @@
> >  		/*
> >  		** Front end requires a subtree to be made explicit.  Restart
> >  		** the declarative debugger with the appropriate depth limit.
> > +		** We subtract 1 from the depth limit, since nodes will be
> > +		** materialized one level below the depth limit for the
> > +		** reason described in the comment above the
> > +		** MR_TRACE_EVENT_TOO_DEEP macro above.
> >  		*/
> There are too many "aboves" above ;-)  Simplify this.
>
		** The front end requires a subtree to be made explicit.
		** Restart the declarative debugger with the appropriate depth
		** limit.  We subtract 1 from the depth limit, since nodes will
		** be materialized one level below the depth limit.  This is
		** done so that the correct contour can be built at the depth
		** limit.  See the comment above the definition of
		** MR_TRACE_EVENT_TOO_DEEP.
>
> > +
> > +		if (total > MR_edt_desired_nodes_in_subtree) {
> > +			/*
> > +			** Since we have gone over the desired number of nodes,
> > +			** the ideal depth is depth - 1.  We want the depth to
> > +			** be at least 2 because if it is 1, the root of the
> > +			** new tree will have its at-depth-limit flag set.
> > +			*/
> We discussed this one in person.
>

I forget - what did you say about it again?

> > +static	void
> > +MR_trace_maybe_show_progress(MR_Unsigned event_number)
> > +{
> > +	static MR_Unsigned	last_tick = 0;
> > +	MR_Unsigned		current_tick;
> > +
> > +	/*
> > +	** We can't show progress when building a supertree since we don't
> > +	** know what the final event will be.
> Isn't that behaviour potentially confusing?  If it takes a long time
> to build the supertree, might a user not just assume that something
> has gone wrong with the debugger.  Is it possible to get it to display
> some sort of progress indicator, even if it's not like the other one?

Yes it's possible, but building of supertrees will happen much less often than
building of subtrees (since once a node has been asserted erroneous, no more
supertrees need be built).

I've followed all your other suggestions.

Cheers for that.

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