[m-users.] newbe tutorial on development workflow and debugging

[Julian Fondren]

On 2019-07-02 03:52, Daniel Gross wrote:
> Hi Sean,
> 
> Thanks.
> 
> So, how do you debug your code ... by adding inline writes ...

That's one way. You can have inline writes in declarative code with
trace goals. io.print/3 is handy in these for readable output of data
that you may not even have the definitions for:

https://mercurylang.org/information/doc-latest/mercury_ref/Trace-goals.html

You can also debug by writing tests. A related technique that I enjoy
is debugging by specifying: if your program doesn't behave as you
expect, then make your code more precise until it starts to fail in
more understandable ways. For example if you have a networking library
that treats all file descriptors the same, then by giving server
sockets and client sockets their own distinct types you might discover
that some code has them misused.

In Ada you can add pre/post assertions, which in my experience is
*amazing* for sussing out bugs.

   some_pred(In1, In2, Out1, Out2) :-
       assert1(In1, In2), assert2(In1, In2, Out1, Out2), % pre/post 
assertions
       normal_code.

there's just not as convenient a way to do it. What I'd like is an
assert goal that doesn't effect determinism and that can be disabled
with compile-time flags.

   some_pred(In1, In2, Out1, Out2) :-
       assert In1 < In2,
       assert ( In1 < Out1, In2 < Out2 ),
       assert probably_prime(Out2),
       normal_code.

Doable with trace goals. But how neatly?

> I see step by step tracing of a program / debugging as part of the
> learning opportunity during problem solving.
> 

The debugging documentation is in another manual:

https://mercurylang.org/information/doc-latest/mercury_user_guide/Debugging.html

And it includes single-stepping through programs, printing variables,
getting the call stack, listing surrounding source code, etc. The
usual stuff. A problem you might run into is that you lack a specific
debugging grade; in such cases you can run something like

   make LIBGRADES=asm_fast.par.gc.debug.stseg install

in your rotd source directory to fill the gap.

> Would emacs be the only way to get a good debugging view -- i
> understand that there also exists an eclipse plugin -- but it looks
> dated.

You can use mdb at a terminal, as in the example in Debugging.html's
Quick overview.

> thanks,
> 
> Daniel