[m-rev.] for review: making user events more useful

Julien Fischer juliensf at csse.unimelb.edu.au
Mon Dec 4 18:52:05 AEDT 2006


On Mon, 4 Dec 2006, Zoltan Somogyi wrote:

> Implement some of Mark's wish list for making user events more useful.
>
> 1. When executing "print *" in mdb, we used to print both the values of all
>   attributes and the values of all live variables. Since some attributes'
>   values were given directly by live variables, this lead to some things being
>   printed twice. This diff eliminates this duplication.
>
> 2. At user events, we now print the name of the event. Whether we print the
>   other stuff we also print at events (the predicate containing the event,
>   and its source location) is now controlled by a new mdb command,
>   "user_event_context".
>
> 3. We would like different solvers to be compilable independently of one
>   another. This means that neither solver's event set should depend on the
>   existence of the events needed by the other solvers. This diff therefore
>   eliminates the requirement that all modules of the program be compiled with
>   the same event set specification. Instead, a program may contain modules
>   that were compiled with different event sets. Each event set is named;
>   the new requirement is that different named event sets may coexist in the
>   program (each being used to compile some modules), but two event sets with
>   the same name must be identical in all other respects as well (we need this
>   requirement to prevent inconsistencies arising between different versions of
>   the same event set).
>
> 4. We now generate user events even from modules compiled with --trace shallow.
>   The problem here is that user events can occur in procedures that do not
>   get caller events and whose ancestors may not get caller events either.
>   Yet these procedures must still pass on debugger information such as call
>   sequence numbers and the call depth to the predicate with the user event.
>   This diff therefore decouples the generation of code for this basic debugger
>   infrastructure information from the generation of call events by inventing
>   two new trace levels, settable by the compiler only (i.e. not from the
>   command line). The trace level "basic_user" is for procedures containing a
>   user event whose trace level (in a shallow traced module) would otherwise be
>   "none". The trace level "basic" is for procedures not containing a user
>   event but which nevertheless may need to transmit information (e.g. depth)
>   to a user event. For the foreseeable future, this means that shallow traced
>   modules containing user events will have some debugging overhead compiled
>   into *all* their procedures.

...


> tests/debugger/user_event_shallow.{m,inp,exp}:
> 	New test case to test the new functionality. This test case is the same
> 	as the user_event test case, but it is compiled with shallow tracing,
> 	and its mdb input exercises the user_event_context mdb command.
>
> tests/debugger/user_event_spec:
> tests/invalid/invalid_event_spec:
> 	Update these event set spec files by adding an event set name.
>
> tests/debugger/Mmakefile:
> tests/debugger/Mercury.options:
> 	Enable the new test case.
>
> tests/debugger/user_event.exp:
> 	Update the expected output of the old user event test case, which now
> 	prints event names, but doesn't print attribute values twice.
>
> tests/debugger/completion.exp:
> 	Expect the new "user_event_context" mdb command in the command list.
>
> tests/debugger/mdb_command_test.inp:
> 	Test the existence of the documentation for the new mdb command.
>
> tests/invalid/Mercury.options:
> 	Conform to the name change of the --event-spec-file-name option.

You should also run the test suite in  a .decldebug grade and check if 
any of the expected outputs there need updating.


...

> %---------------------------------------------------------------------------%
> Index: compiler/code_info.m
> ===================================================================
> RCS file: /home/mercury/mercury1/repository/mercury/compiler/code_info.m,v
> retrieving revision 1.335
> diff -u -b -r1.335 code_info.m
> --- compiler/code_info.m	1 Dec 2006 15:03:51 -0000	1.335
> +++ compiler/code_info.m	4 Dec 2006 03:40:45 -0000
> @@ -182,6 +182,10 @@
>     %
> :- pred get_layout_info(code_info::in, proc_label_layout_info::out) is det.
>
> +:- pred get_proc_trace_events(code_info::in, bool::out) is det.
> +
> +:- pred set_proc_trace_events(bool::in, code_info::in, code_info::out) is det.
> +
>     % Get the global static data structures that have
>     % been created during code generation for closure layouts.
>     %
> @@ -394,6 +398,9 @@
>                                     % are live and where at which labels,
>                                     % for tracing and/or accurate gc.
>
> +                proc_trace_events   :: bool,
> +                                    % Did the procedure have any trace events?
> +

s/trace events/user trace events/ in the comment.

The rest looks okay to me.  I'm happy for you to commit it (Mark may
wish to comment further when he gets back.)

Julien.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list