[m-rev.] For review: changes to declarative debugger (Part 1)
maclarty at cs.mu.OZ.AU
Mon Nov 8 16:46:49 AEDT 2004
On Mon, Nov 08, 2004 at 02:11:14PM +1100, Zoltan Somogyi wrote:
> > > > 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.
I changed the log message to the following (used the term "child" instead of
Made changes so that all the interface events of child calls of a call
are included in the annotated trace, so that contours are built
> > > 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?
Changed the name.
> > % 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.
I changed the comment above pick_implicit_root to:
% pick_implicit_root(Store, SearchSpace, ImplicitRoot)
% Picks a suspect in SearchSpace who's EDT node is the root of an
% implicit subtree. Only suspects with a status of unknown, skipped or
% ignored will be considered. If there are multiple such suspects then
% one is committed to. ImplicitRoot will always be a descendent of the
% root of the search space. XXX currently ImplicitRoot is chosen
% naively, but in future better methods could be used to pick an
% implicit root (such as the implicit root whos subtree is most lightly
% to contain a bug according to some heuristic(s)).
> > 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*
If first_unknown_descendent needs an explicit subtree to be generated,
then there must be a node in the search space which is the root of an implicit
subtree. The exception is thrown when pick_implicit_root can't find such an
implicit root to use to generated the required explicit subtree.
I've changed the exception to:
"first_unknown_descendent requires an explicit"
++" subtree to be generated, but "++
"pick_implicit_root couldn't find an implicit"
++" root to generate an explicit subtree from"
Is that better?
> > > 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 this fact.
Okay. I added the following comment to the primitive_op case:
% XXX 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.
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