[m-dev.] Mercury's "Time to Hello World"

Julien Fischer jfischer at opturion.com
Mon Mar 25 23:13:38 AEDT 2013

On Mon, Mar 25, 2013 at 11:10 PM, Julien Fischer <jfischer at opturion.com> wrote:
> On Mon, Mar 25, 2013 at 10:32 PM, Paul Bone <paul at bone.id.au> wrote:
>>> The rationale for the default set of grades is this: it is the set of grades in
>>> most of the useful features and tools that make up Mercury are available, i.e.
>>>     -- support for trailing
>>>     -- support for parallelism and threads
>>>     -- support for debugging
>>>     -- support for declarative debugging
>>>     -- support for profiling
>>>     -- support for memory profiling
>>>     -- support for deep profiling
>>>     -- optionally, support for the Java, C# and Erlang backends
>> I also disagree with this.  If you have declative debugging you don't need
>> regular debugging as the former is a feature super-set without additional
>> cost.
> Wrong.  There *is* an additional cost, although off the top of my head I can't
> remember whether it's program runtime, executable size or both.  How much
> that matters to you depend on what you are trying to debug of course.
> (We have discussed merging the decldebug  and debug grades in the past
> and the long term intention is that should happen, but I don't think it's
> quite there yet.)
>> And I'm pretty sure that deep profiling superseeds the other
>> profiling grades.
> The design of deep profiling certainly better, but the implementation
> is not quite there yet.  For example,
> (1) the deep profiler still aborts if a program throws and then catches
> an exception.  (You may be familiar with the problem of things not
> handling exceptions properly ;-) )
> (2) merging of profiling runs is not currently supported -- it is in mprof.
> (3) run the deep profiler as a web service, makes setting it up quite fiddly.

Actually, and (4) deep profiling doesn't support memory retention profiling like
the memprof grades.


More information about the developers mailing list