[m-rev.] For review: changes to declarative debugger (Part 1)

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon Nov 8 14:11:14 AEDT 2004


On 29-Oct-2004, Ian MacLarty <maclarty at cs.mu.OZ.AU> wrote:
> I changed the log to:
> 
> 	The EDT depth is now calculated independently instead of using
> 	event_info->MR_call_depth (which is not always consistent with
> 	the EDT depth).
> 
> Is that clearer?

Yes.

> > > 	Made changes so that all the interface events for the sub-calls inside
> > > 	a call are included in the annotated trace, so that contours are built
> > > 	correctly.
> > 
> > This breaks the depth limit, so I suspect you don't mean that in all cases.
> > 
> It does break the depth limit, but only ever by 1 and is 
> necessary to build correct contours.  What do you mean "in all cases"?

That you don't include the interface events for ALL sub-calls inside
a call, only the ones one level down.

> > Since start_analysis with MaybeRequireExplicit = yes just continues an
> > existing analysis, you should rename the predicate.
> > 
> Do you think start_or_resume_analysis is a good name?

Yes.

> > > 		% An explicit subtree is required, so pick an implicit root
> > > 		% to make explicit.
> > > 		% 
> > > 		(
> > > 			pick_implicit_root(Store, !.SearchSpace, ImplicitRoot)
> > > 		->
> > > 			Response = require_explicit(ImplicitRoot),
> > > 			NewMode = breadth_first
> > 
> > Could this decide to materialize a node that is not a child of RootId? If yes,
> > why? If not, document why it can't.
> > 
> 
> 		% An explicit subtree is required, so pick an implicit root
> 		% to make explicit.  pick_implicit_root/3 will choose an
> 		% implicit root that is a descendent of the root id of the 
> 		% search space.  There is no point in making an implicit root
> 		% that is not a descendent of the root id explicit, since
> 		% all suspects above the root id have been excluded from the
> 		% bug search.  pick_implicit_root will also not choose an
> 		% implicit root that is a descendent of a correct or
> 		% inadmissible node, for the same reason.

Actually, I knew why you don't *want* to pick a node that not a child of
RootId, I was asking for an argument why the code of pick_implicit_root
*doesn't*. The comment at the declaration of pick_implicit_root doesn't say
that ImplicitRoot is inside SearchSpace.

> > > 			throw(internal_error("breadth_first_search",
> > > 				"first_unknown_descendent_breadth required "++
> > > 				"an explicit subtree, but pick_implicit_roo"++
> > > 				"t couldn't find an implicit root"))
> > 
> > The error message is contradictory.
> > 
> The two predicates are contradicting each other, so that's why I throw an
> exception, as this shouldn't happen.

Don't complain about not finding an *implicit* root if you need an *explicit*
subtree.

> > The code for primitive_op and not_found seem identical. Is this intentional,
> > and if so, why?
> > 
> For now the behaviour is the same: if the sub-term is bound by a primitive
> operation in the node, then the node is at the end of the dependency chain; if
> there is no more tracing information then the node is also at the end of the
> dependency chain.
> 
> In future the filename and line number of the primitive operation could be
> printed out if the node in which the primitive operation occured turned out
> to be a bug.

Then document that fact.

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



More information about the reviews mailing list