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

[Julien Fischer]

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

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

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

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

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

> +"
> +	ProcLayout = Label->MR_sll_entry;
> +").
> +
> +:- pragma foreign_proc("C", get_goal_path_from_label_layout(Label::in)
> +	= (GoalPath::out),
> +	[will_not_call_mercury, thread_safe, terminates, promise_pure],
> +"
> +	GoalPath = (MR_String)MR_label_goal_path(Label);
> +").
> +

That looks okay otherwise.

Julien.

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