[m-users.] Debugging with foreign types

Peter Ross peter at emailross.com
Sat May 23 08:44:22 AEST 2015

On 23 May 2015 at 03:47, Zoltan Somogyi wrote:
> On Fri, 22 May 2015 18:12:29 +0100, Matthias G├╝demann wrote:
>> I imagined having a type class for foreign types that exports a
>> few functions to turn a value into a string. A simple case could be
>> having two functions, one to get a condensed version, e.g., printing
>> only the root of the tree, and a second one to get the full
>> representation.
> That would not require a type class, merely an optional attribute
> in foreign type pragmas. The problems outlined in my previous email
> would remain, of course.
>> How is debugging with foreign code usually done?
> When the foreign code is in C, *and* when you understand how the Mercury
> compiler works, you can do it by compiling Mercury to C as usual, invoking
> the C compiler and the linker with the flags required to enable debugging,
> and running the program inside gdb. That is how almost all parts of the
> Mercury system were debugged.
> As for how people outside the Mercury team debug foreign language code,
> unfortunately, the answer is "behind closed doors" :-(
> If anyone on the mailing list would like to open their doors, now would be
> a good time.
It has been awhile, but I think that this is what I used to do.

Register a handler for a type info with the pretty printer, then when
pretty printing a term in the debugger the correct code would be
called and you could see a representation of the type.

However I've just browsed the code and I can't find these entry points
anymore, so I might be deluded.


More information about the users mailing list