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

[Ian MacLarty]

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 
		"sub-call"):
	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
	correctly.

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

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*
> subtree.
> 

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:
                        throw(internal_error("top_down_search",
                                "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.
                %

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