[m-rev.] for review: include label layouts in annotated trace

[Ian MacLarty]

On Sun, Feb 20, 2005 at 11:22:29PM +1100, Julien Fischer wrote:
> 
> On Sun, 20 Feb 2005, Ian MacLarty wrote:
> 
> > For review by anyone.
> >
> > Estimated hours taken: 7
> > Branches: main
> >
> > Record label layouts in the annotated trace.  This does away with the need
> > to store goal path strings and proc_layouts in the annotated trace, since
> > both can be obtained from the label layout (we still however need to store the
> > goal path of a call in its parent for subterm dependency tracking).
> >
> > The label layouts will be used for displaying more detailed information
> > in the declarative debugging session (such as line numbers) and also for
> in declarative debugging sessions
> 

Okay.

> > for slicing and dicing in the declarative debugger.
> >
> > browser/declarative_execution.m
> > 	Add label_layout foreign types and some useful functions on this type.
> >
> > 	Add label_layout field to each event in an annotated trace.
> >
> > 	Record just the arguments of an atom for call and exit events in the
> > 	annotated trace.  The complete atom can be constructed from the
> > 	label_layout and the arguments.
> >
> > 	When recording argument values add them to the front of the
> > 	argument list instead of inserting them in a specified position in the
> > 	argument list.  This means the arguments must be added in reverse order
> > 	in trace/mercury_trace_declarative.c.  This should, however be a bit
> > 	more efficient than the previous method where the arguments were
> > 	effectively being appended to the end of the argument list each time.
> >
> I wouldn't think that the argument lists are large enough most of the
> time for it to matter.
> 

Since the arguments must be added for every CALL and EXIT event (which could be
quite a few), I think there should be a slight gain, though I haven't actually
tested this.  I'll remove the comment anyway.

> > 	Adjust the predicates for building the annotated trace to also accept
> > 	a label_layout.
> >
> > browser/declarative_debugger.m
> > 	Get the proc_layout from the label_layout.
> >
> > browser/declarative_tree.m
> > 	Make adjustments for the extra field.
> >
> > trace/mercury_trace_declarative.c
> > 	Pass the label_layout when constructing pieces of the annotated trace.
> >
> > 	Construct only the atoms arguments.  Also when adding the arguments
> Is that atoms plural or should that be atom's?
> 

Should be atom's.

> > 	add them in reverse order, because of the change in
> > 	browser/declarative_execution mentioned above.
> >
> ...
> 
> > @@ -579,10 +598,40 @@
> >
> >  %-----------------------------------------------------------------------------%
> >
> > -step_left_in_contour(Store, exit(_, Call, _, _, _, _)) = Prec :-
> > +:- pragma foreign_type("C", label_layout, "const MR_Label_Layout *",
> > +	[can_pass_as_mercury_type, stable]).
> > +:- pragma foreign_type("Java", label_layout, "Object", []). % stub only
> > +
> s/Object/java.lang.Object/ there.
> 

Okay.  Also changed it in another part of the file.

> > +:- pragma foreign_proc("C", get_proc_layout_from_label_layout(Label::in)
> > +	= (ProcLayout::out),
> > +	[will_not_call_mercury, thread_safe, terminates, promise_pure],
> 
> `will_not_call_mercury' implies `terminates' in the absence of a
> `does_not_terminate' attribute so the terminates attribute is not
> strictly necessary there (although there is no harm in leaving it
> there).  Likewise below.

Okay.  I've taken them out so the foreign_proc declaration is consistent with the
other ones in the file.

Cheers,

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