[m-dev.] For review: implementation of collect for Opium-M

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Nov 3 01:47:40 AEDT 1999


On 02-Nov-1999, Erwan Jahier <Erwan.Jahier at irisa.fr> wrote:
> | (Another difference with foldl/4 is that it stops when the filter returns `no'.
> | In fact it's a bit more like `std_util__do_while', the only difference is that
> | it operators on a sequence of debugger events rather than a sequence of solutions.
> 
> But I am not sure that std_util__do_while is as famous as fold/4. Is it?

No.

> If it is not the case, I prefer to explain the collect in terms of fold/4.

OK.  But perhaps s/fold/foldl/ ?  At least in Mercury and Haskell,
the function is known as `foldl' rather than `fold'.

> | > browser/debugger_interface.m:
> | ...
> | > 	Define a new function get_collecting_variable_type/2 that retrieves
> | > 	the type of a variable. This type is needed in MR_trace_event_external()
> | > 	to be able to call MR_make_permanent() on MR_collecting_variable; we
> | > 	need to do that to ensure that the memory allocated for it won't be 
> | > 	deallocated on backtracking.
> | 
> | I think that function should not be needed anymore.
> 
> Why? I introduced it in my last change to be able to use MR_make_permanent()!
> Do you mean ML_DI_link_collect() should link with the collecting variable type 
> rather than a function that is able to retrieve its type?

I meant that that function should not be needed in browser/debugger_interface.m,
since it is now in collect.in instead.  The log message seems to be out of date.

> Index: 0.6/debugger_interface.m
> --- 0.6/debugger_interface.m Tue, 02 Nov 1999 08:31:18 +0100 jahier (collect/1_debugger_i 1.4 640)
> +++ 0.6(w)/debugger_interface.m Tue, 02 Nov 1999 11:13:01 +0100 jahier (collect/1_debugger_i 1.4 640)
> @@ -283,6 +283,9 @@
>  	;	grade(string)
>  	% responses to collect
>  	%;	collected(collected_type)
> +		% It is commented because collected_type is unknow at compile 
> +		% time since it is defined by by users in the dynamically 
> +		% linked collect module.

s/It is/This is/
s/commented/commented out/
s/unknow/unknown/
s/by by/by/

> Index: 0.6/mercury_trace_external.c
> -				collect_linked = (result =  'y');
> +				collect_linked = (result = 'y');

That's a bug: the second `=' should be `=='!

> +:- module collect_lib.
> +:- interface.
> +:- import_module io, char, dl.
> +
> +% dynamically link the collect module; 
> +:- pred link_collect(string, c_pointer, c_pointer, c_pointer, c_pointer, 
> +	dl__result(handle), char, io__state, io__state).
> +:- mode link_collect(in, out, out, out, out, out, out, di, uo) is det.

According to our Mercury coding guidelines, the comments in the interface
should be sufficient for someone to understand how to call a procedure
without having to look at the implementation.
So the comment here should explain the meaning of the parameters.

> +% interface to the C function dlclose()
> +:- pred close_collect(dl__result(handle), io__state, io__state).
> +:- mode close_collect(in, di, uo) is det.

I suggest that you change the comment for that one to

	% Dynamically unlink a module that was dynamically linked in
	% using `link_collect'.

and change the name from `close_collect' to `unlink_collect'.

The point of the name change is that `link_collect' and `close_collect'
are a pair of related routines that should always be called together,
so they should be given corresponding names, e.g. `link' and `unlink'
or `open' and `close'.

> --- mercury_trace_external.c	1999/10/28 20:15:02	1.27
> +++ mercury_trace_external.c	1999/11/02 10:14:12
>  /*
> +** Type of a local variable that indicates in which mode the external 
> +** debugger is. When the external debugger is in mode:
> +** (1) `MR_searching', it tries to find an event that matches a forward 
> +**      move request,
> +** (2) `MR_reading_request', it reads a new request on the socket,
> +** (3) `MR_collecting', it is collecting information (after a `collect' request).
> +*/
> +typedef enum {
> +	MR_searching, MR_reading_request, MR_collecting
> +} MR_external_debugger_mode_type;
> +
> +static	MR_external_debugger_mode_type 
> +	external_debugger_mode = MR_reading_request;

s/local variable/static variable/

("local" in "local variable" normally means "local to a function"
rather than "local to a translation unit".)

> +		case MR_collecting:
> +			(*send_collect_result_ptr)(
> +				MR_collecting_variable, 
> +				(Word) &MR_debugger_socket_out);

I think that is a bug: shouldn't that call be enclosed inside
MR_TRACE_CALL_MERCURY()?

When you've addressed those comments, I'd like to see another diff,
again in both relative and full versions.  Thanks.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list