[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