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

[Julien Fischer]

On Thu, 12 May 2005, Ian MacLarty wrote:

> > >  /*
> > >  ** 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.
>
s/collecting/collection/, otherwise that's fine


> > > @@ -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.
Presumably that's the comment for the definitino of
MR_TRACE_EVENT_TOO_DEEP, so s/above/for/.

> > > +
> > > +		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?
>
Uhmmm ... I don't remember, so it can't have been that important.

> > > +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 think the fact that it will only happen rarely will make the difference in
behaviour look more like a bug; however I guess it isn't really all that
important.  I was just wondering if was (easily) possible to display
something when building the supertrees.

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