[m-rev.] for review: Uncomment foreign code definition for clock/3.
Julien Fischer
jfischer at opturion.com
Wed May 25 10:27:55 AEST 2016
Hi,
On Tue, 24 May 2016, Sebastian Godelet wrote:
>> diff --git a/library/time.m b/library/time.m index bf4caad..ea9c569 100644
>> --- a/library/time.m
>> +++ b/library/time.m
>> @@ -264,16 +264,14 @@ time.clock(Result, !IO) :- "
>> Ret = (MR_Integer) clock();
>> ").
>> -/* XXX need to add System.dll to the references list.
>> :- pragma foreign_proc("C#",
>> time.c_clock(Ret::out, _IO0::di, _IO::uo),
>> [will_not_call_mercury, promise_pure, tabled_for_io], "{
>> // XXX Ticks is long in .NET!
>> - Ret = (int) System.Diagnostics.Process.GetCurrentProcess
>> - .UserProcessorTime.Ticks;
>> + Ret = (int) System.Diagnostics.Process.GetCurrentProcess().
>
> Well the XXX is not addressed in this issue, the reason why ticks is using 64-bit integers
> in .NET is that it is based on 100-nanosecond intervals, which get large pretty fast,
> but I guess there is a reason why clock_t is a public alias for int (IMHO it should be an abstract type
> depending on the backend).
I suspect the reason may simply be that that module predates the
addition of foreign_type pragmas to the language. (Indeed, it predates
the addition of the non-C backends as well.)
I agree that it should be an abstract type. (I'm present running a
check to see what actually depends on the definition of clock_t being
exported.)
Julien.
More information about the reviews
mailing list