[Caml-list] Do you use a debugger with OCaml? If not, why not?

[Caml-list] Do you use a debugger with OCaml? If not, why not?

[John Whitington]

Hi,

Like, I suspect, many people, my method has always been to insert 
Printfs, and stare at code until I find the problem. In fact, the 
ocaml.org page on ocamldebug says:

"In fact, for complex programs, it is likely the case that the 
programmer will use explicit printing to find the bugs, since this 
methodology allows the reduction of the trace material: only useful data 
are printed and special purpose formats are more suited to get the 
relevant information, than what can be output automatically by the 
generic pretty-printer used by the trace mechanism."

So, I ask: What do you use for debugging small and large OCaml programs? 
If not a debugger, why not? What problems prevent it? How does your 
debugging process differ when writing OCaml compared with other 
languages you use?

John

-- 
John Whitington
Director, Coherent Graphics Ltd
http://www.coherentpdf.com/

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Francois Berenger]

On 11/25/2015 01:49 PM, John Whitington wrote:
 > [...] How does your
> debugging process differ when writing OCaml compared with other
> languages you use?

In my experience, you fire the debugger much less often.

And when you do need to fire it once, you realize that
ocamldebug can back step ! :)

-- 
Regards,
Francois.
"When in doubt, use more types"

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Ivan Gotovchits]

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

The use of a debugger usually indicates that a programmer lost a control of
its own program and has no idea whats going on.
If a programmer doesn't own a program, and tries to understand existing
program, written by someone else, then it means to me,
that the program is written so poorly, that it is too hard to recover its
semantics by reading its source code representation.

OCaml, as well as any other functional programming language, encourages to
compose big programs from small and understandable
pieces. Due to unique properties of functional programming paradigm this
composition is usually linear (lack of mutable state and side-effects).
Also,
OCaml has a reach type system, that allows a programmer to specify his
assumptions and program invariants, so that any violation
will be caught on compile time.

So, if properly applied, OCaml allows one to write big programs without
need for debugging at all. Of course, it is possible to write Fortran 77 in
OCaml, in that case you will soon find yourself in the debugger prompt.

Sometimes, though, especially when you heavily interact with outside world,
like user interface, networking, etc, you find yourself on a loose ground,
since your assumptions cannot be defined in terms of OCaml typesystem (no
dependent typing, no linear typing). In that case you need to study
the dynamics of a program. Usually, in this cases the debugger is not
useful, since the program interacts in real-time with some external agent,
that is
not going to wait for you.

My personal approach to debugging is to start from static analysis of the
code and try to limit the search space. I also try to extract all possible
assumptions
that was made by a programmer. Once I have a list of possible suspects, I
instrument the code and insert some tests. Sometimes the instrumentation is
just
a printf, sometime it is just an assert. Quite often, this is just `assert
false`. I continue this operation, until only one suspect is left. In most
use cases, the
initial stage of reading code, will already leave me with only one or two
suspects, as if the code is written properly it is usually easy to find a
proof (an alibi) for
most cases. Of course this require some programming discipline:

1. limit the use of mutual state
2. limit the use of exceptions in favor of returning variant types (option,
result, or_error)

This two rules ensures linearity, due to the lack of side effects. And
usually, this is side effects, that we're trying to debug with a debugger
or printfing.


On Wed, Nov 25, 2015 at 7:49 AM, John Whitington <
john@coherentgraphics.co.uk> wrote:

> Hi,
>
> Like, I suspect, many people, my method has always been to insert Printfs,
> and stare at code until I find the problem. In fact, the ocaml.org page
> on ocamldebug says:
>
> "In fact, for complex programs, it is likely the case that the programmer
> will use explicit printing to find the bugs, since this methodology allows
> the reduction of the trace material: only useful data are printed and
> special purpose formats are more suited to get the relevant information,
> than what can be output automatically by the generic pretty-printer used by
> the trace mechanism."
>
> So, I ask: What do you use for debugging small and large OCaml programs?
> If not a debugger, why not? What problems prevent it? How does your
> debugging process differ when writing OCaml compared with other languages
> you use?
>
> John
>
> --
> John Whitington
> Director, Coherent Graphics Ltd
> http://www.coherentpdf.com/
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 4922 bytes --]

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]

Am Mittwoch, den 25.11.2015, 08:23 -0500 schrieb Ivan Gotovchits:
> The use of a debugger usually indicates that a programmer lost a
> control of its own program and has no idea whats going on. 
> If a programmer doesn't own a program, and tries to understand
> existing program, written by someone else, then it means to me, 
> that the program is written so poorly, that it is too hard to recover
> its semantics by reading its source code representation.

That's a little bit too hard. Actually, I like one aspect of the
debugger, namely that you can easily print deeply nested values. This is
also very helpful for exploring a well-written existing program. (And it
would even be more helpful if the debugger could look through
abstractions.)

Actually, I recently used that for writing unit tests for a complex
algebraic transformation (developed by myself). Just create some input
for the transformation, run it, fire up the debugger, and stop the test
at the point where the transformation call returns. Then check whether
you like the result by printing it in the debugger, and if so, develop a
check that matches against the expected pattern. (You could also do this
with the toploop, but using the debugger is easier when you have a
closed executable.)

That said, I also prefer the printf method for debugging program flow
issues.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Chan Ngo]

On 11/25/2015 04:27 PM, Gerd Stolpmann wrote:
> Am Mittwoch, den 25.11.2015, 08:23 -0500 schrieb Ivan Gotovchits:
>> The use of a debugger usually indicates that a programmer lost a
>> control of its own program and has no idea whats going on.
>> If a programmer doesn't own a program, and tries to understand
>> existing program, written by someone else, then it means to me,
>> that the program is written so poorly, that it is too hard to recover
>> its semantics by reading its source code representation.
> That's a little bit too hard. Actually, I like one aspect of the
> debugger, namely that you can easily print deeply nested values. This is
> also very helpful for exploring a well-written existing program. (And it
> would even be more helpful if the debugger could look through
> abstractions.)
>
> Actually, I recently used that for writing unit tests for a complex
> algebraic transformation (developed by myself). Just create some input
> for the transformation, run it, fire up the debugger, and stop the test
> at the point where the transformation call returns. Then check whether
> you like the result by printing it in the debugger, and if so, develop a
> check that matches against the expected pattern. (You could also do this
> with the toploop, but using the debugger is easier when you have a
> closed executable.)
>
> That said, I also prefer the printf method for debugging program flow
> issues.
Now, for OCaml development, I often use the printing method than 
ocamldebuger.

I hope that some IDE can support debugging OCaml programs in near future.

Chan
>
> Gerd

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Matthieu Dubuget]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I recently had to understand a bug. I tried to use OCaml debugger, but
soon gave up with this approach, because I was not able to reach the
time location where the bug occured (even after I had solved the
install_printer step that is necessary to output structured values).

One reason why it was difficult to narrow the problem was because of a
shifting of the hilighted code fragments in emacs (yes: I used
ocamldebug from emacs). I suppose (but I was too lazy to check this
assumption) that this is due to my comments: in this program they are
full of UTF-8 mathematical characters.

And I came back to the traditionnal printf debugging method.

For sure, a simpler and more robust way to visualize/follow the
execution of a program would be a great help to debug ocaml programs.

I have no idea how multi-threaded programs are supposed to be debugged,
thought?

Salutations
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlZVtyEACgkQCBfXUPYKuPWNdACfRX09FkwVbcrB6IiPiFGTuptL
4PUAn3OXNqvMaio0KOI8IPie7DyTxiGA
=Lb6/
-----END PGP SIGNATURE-----

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Matthieu Dubuget]

Le 25/11/2015 14:26, Matthieu Dubuget a écrit :
>  I suppose (but I was too lazy to check this
> assumption) that this is due to my comments: in this program they are
> full of UTF-8 mathematical characters.

Confirmed: getting rid of those chars in comments helped a lot

-- 
Matthieu Dubuget
Guide d’autodéfense numérique : http://guide.boum.org

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Markus Weißmann]

Hi John,

> So, I ask: What do you use for debugging small and large OCaml
> programs? If not a debugger, why not? What problems prevent it? How
> does your debugging process differ when writing OCaml compared with
> other languages you use?

I'm one of those printf-tracers, too; I guess its because its _the_
platform independent way of debugging and it works the same in every 
language.
I fire up the debugger when writing C, but only if I get a segmentation 
fault.

regards
-Markus

-- 
Markus Weißmann, M.Sc.
Technische Universität München
Institut für Informatik
Boltzmannstr. 3
D-85748 Garching
Germany
http://wwwknoll.in.tum.de/

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Nils Becker]

hi,

> The use of a debugger usually indicates that a programmer lost a
> control of its own program and has no idea whats going on.

this is one reason, but it is also completely valid to debug algorithms
i.e. find bugs in the logic of an algorithm, not the implementation.
these are not caught by the type system. in simulation code for example,
mutable state is often the most natural representation, and it is
sometimes necessary to follow a mutable value through the algorithm to
verify.

> debugging process differ when writing OCaml compared with other
> languages you use? 

when comparing with python, i often use the python debugger as integral
part of checking the correctness of the algorithm, and i have full
access to all values, and even evaluation of code, which makes that
easy. i feel in control. that said, often i need to use it to find nasty
bugs due to type-unsafety.

in ocamldebug, i find it great that i can back-step. however, the need
to work so much to install printers for my types is a severe drawback;
what's worse is that it seems to be even impossible to install printers
for types defined inside functor bodies. so, i sometimes hit a brick
wall with ocamldebug, which is frustrating, and i feel like i'm fighting
the system rather than using a productive tool.

for me, some way to auto-print some crude representation of _all_ types
in the debugger would help a lot.

n.

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Daniel Bünzli]

Le mercredi, 25 novembre 2015 à 12:49, John Whitington a écrit :
> If not a debugger, why not?

For UI reasons.  

When I was doing ios work you could just set a break point in the ide by clicking in the margin, hit the run button and you'd simply stop there and be able to inspect the state of your program. It was quick and easy so I would use it — note however that sometimes it was easier to get exactly what you wanted through a printf statement.

Lacking such a trivial setup, printf is quicker.

Best,

Daniel  

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Leonardo Laguna Ruiz]

I use oqamldebug. In general works very well.

Ocamldebug is good but I agree that the UI needs improvements. When I 
was programming F# I practically never used print debugging since the 
debugger was very accessible and installing custom printers for your 
data structures was trivial.

Leonardo

On 2015-11-25 16:55, Daniel Bünzli wrote:
> Le mercredi, 25 novembre 2015 à 12:49, John Whitington a écrit :
>> If not a debugger, why not?
> For UI reasons.
>
> When I was doing ios work you could just set a break point in the ide by clicking in the margin, hit the run button and you'd simply stop there and be able to inspect the state of your program. It was quick and easy so I would use it — note however that sometimes it was easier to get exactly what you wanted through a printf statement.
>
> Lacking such a trivial setup, printf is quicker.
>
> Best,
>
> Daniel
>
>
>
>
>
>
>
>

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Tom Ridge]

[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]

I haven't used oqamldebug - perhaps it should be more widely publicized?
Perhaps linked to from the ocamldebug doc?

That said, println is my tool of choice, although I hear good things about
printf :)

I think that, because of lack of resources, we probably have to accept
that, as far as debuggers and IDEs are concerned, we are going to be stuck
where we are for the forseeable future (emacs+speedbar in my case).

Recently I have been programming in scala. It is an interesting language. I
wouldn't say it is better than OCaml, but the tooling and IDE support is
much better (and the libraries... wow!), and as a consequence the
programming experience is more enjoyable (for me personally, YMMV). Not
having to write a make file is already a big win.


On 26 November 2015 at 09:14, Leonardo Laguna Ruiz <modlfo@gmail.com> wrote:

> I use oqamldebug. In general works very well.
>
> Ocamldebug is good but I agree that the UI needs improvements. When I was
> programming F# I practically never used print debugging since the debugger
> was very accessible and installing custom printers for your data structures
> was trivial.
>
> Leonardo
>
>
> On 2015-11-25 16:55, Daniel Bünzli wrote:
>
>> Le mercredi, 25 novembre 2015 à 12:49, John Whitington a écrit :
>>
>>> If not a debugger, why not?
>>>
>> For UI reasons.
>>
>> When I was doing ios work you could just set a break point in the ide by
>> clicking in the margin, hit the run button and you'd simply stop there and
>> be able to inspect the state of your program. It was quick and easy so I
>> would use it — note however that sometimes it was easier to get exactly
>> what you wanted through a printf statement.
>>
>> Lacking such a trivial setup, printf is quicker.
>>
>> Best,
>>
>> Daniel
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3060 bytes --]

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Xavier Van de Woestyne]

[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]

I started implementing a small debugger using PPX. Actually the tool
provide only "logs" but if I have more time,
I will write more features (like loop/recursion log/breakpoint, watch etc).

https://github.com/xvw/ppx_debugger

The code was writted fast, It'll open to improvement.

2015-11-26 11:59 GMT+01:00 Tom Ridge <tom.j.ridge+list@googlemail.com>:

> I haven't used oqamldebug - perhaps it should be more widely publicized?
> Perhaps linked to from the ocamldebug doc?
>
> That said, println is my tool of choice, although I hear good things about
> printf :)
>
> I think that, because of lack of resources, we probably have to accept
> that, as far as debuggers and IDEs are concerned, we are going to be stuck
> where we are for the forseeable future (emacs+speedbar in my case).
>
> Recently I have been programming in scala. It is an interesting language.
> I wouldn't say it is better than OCaml, but the tooling and IDE support is
> much better (and the libraries... wow!), and as a consequence the
> programming experience is more enjoyable (for me personally, YMMV). Not
> having to write a make file is already a big win.
>
>
> On 26 November 2015 at 09:14, Leonardo Laguna Ruiz <modlfo@gmail.com>
> wrote:
>
>> I use oqamldebug. In general works very well.
>>
>> Ocamldebug is good but I agree that the UI needs improvements. When I was
>> programming F# I practically never used print debugging since the debugger
>> was very accessible and installing custom printers for your data structures
>> was trivial.
>>
>> Leonardo
>>
>>
>> On 2015-11-25 16:55, Daniel Bünzli wrote:
>>
>>> Le mercredi, 25 novembre 2015 à 12:49, John Whitington a écrit :
>>>
>>>> If not a debugger, why not?
>>>>
>>> For UI reasons.
>>>
>>> When I was doing ios work you could just set a break point in the ide by
>>> clicking in the margin, hit the run button and you'd simply stop there and
>>> be able to inspect the state of your program. It was quick and easy so I
>>> would use it — note however that sometimes it was easier to get exactly
>>> what you wanted through a printf statement.
>>>
>>> Lacking such a trivial setup, printf is quicker.
>>>
>>> Best,
>>>
>>> Daniel
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>
>


-- 
Xavier Van de Woestyne
xavier.vdw@gmail.com - TEL BE : 0474 49 53 83 | TEL FR : 06 73 38 72 84

[-- Attachment #2: Type: text/html, Size: 4335 bytes --]

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Maverick Woo]

Hi,

The first moment I detect I need a printf in a program for debugging, I put in a
logging framework instead because I find it saves me time in the long run. This
is true regardless of the language I am using. I essentially never use an
interactive debugger for normal programming projects, even if I am using C++ on
Windows, which has an excellent debugger in Visual Studio.

For OCaml projects, I use Lwt_log even if the program itself does not use Lwt.
Previously I have also tried Bolt (and Volt), but I switched to Lwt_log because
some of my programs do use Lwt and I like uniformity across my projects.

Maverick

On 11/25/15 07:49, John Whitington wrote:
> Hi,
> 
> Like, I suspect, many people, my method has always been to insert Printfs, and
> stare at code until I find the problem. In fact, the ocaml.org page on
> ocamldebug says:
> 
> "In fact, for complex programs, it is likely the case that the programmer will
> use explicit printing to find the bugs, since this methodology allows the
> reduction of the trace material: only useful data are printed and special
> purpose formats are more suited to get the relevant information, than what can
> be output automatically by the generic pretty-printer used by the trace mechanism."
> 
> So, I ask: What do you use for debugging small and large OCaml programs? If not
> a debugger, why not? What problems prevent it? How does your debugging process
> differ when writing OCaml compared with other languages you use?
> 
> John
> 

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Anton Bachin]

Hi,

I always use prints and never debuggers when I have access to the
source, in any language. I use debuggers when reverse-engineering
binaries, however. As for why – setting up breakpoints, trying to
examine values usually takes more time for me than adding some
prints and reading and understanding the resulting trace. Perhaps
it only seems that way, but that has been my habit for a very long
time.

Best,
Anton

> On Nov 25, 2015, at 06:49, John Whitington <john@coherentgraphics.co.uk> wrote:
> 
> Hi,
> 
> Like, I suspect, many people, my method has always been to insert Printfs, and stare at code until I find the problem. In fact, the ocaml.org page on ocamldebug says:
> 
> "In fact, for complex programs, it is likely the case that the programmer will use explicit printing to find the bugs, since this methodology allows the reduction of the trace material: only useful data are printed and special purpose formats are more suited to get the relevant information, than what can be output automatically by the generic pretty-printer used by the trace mechanism."
> 
> So, I ask: What do you use for debugging small and large OCaml programs? If not a debugger, why not? What problems prevent it? How does your debugging process differ when writing OCaml compared with other languages you use?
> 
> John
> 
> -- 
> John Whitington
> Director, Coherent Graphics Ltd
> http://www.coherentpdf.com/
> 
> 
> -- 
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Michael Grünewald]

> On 25 Nov 2015, at 17:16, Anton Bachin <antonbachin@yahoo.com> wrote:
> 
> I always use prints and never debuggers when I have access to the
> source, in any language. I use debuggers when reverse-engineering
> binaries, however. As for why – setting up breakpoints, trying to
> examine values usually takes more time for me than adding some
> prints and reading and understanding the resulting trace. Perhaps
> it only seems that way, but that has been my habit for a very long
> time.

While OCaml has an incredibly powerful debugger, I rarely use it. In
most situation, I can analyse code to make an hypothesis that I can
turn into an automatic test case.  Time spent writing tests is in
my opinion much better invested than time spent debugging, because
the investment is reflected by a code artefact that adds value to
the project, in the form of confidence about results.

Sometimes, problems observed do not have any obvious plausible cause,
so that stepping through the code is one of the best options.

Instead of print-peppering, I prefer to use structured failures
(like the success monad https://github.com/michipili/lemonade)
giving context for the failure, or improved logging capacities.

This is not really related to debugging, but let me add that I tend
to use the toplevel loop, either for experimenting or to interactively
solve complex (to me) typing problems that I cannot do right away.

Best,
Michael

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Török Edwin]

On 11/25/2015 06:52 PM, Michael Grünewald wrote:
> 
>> On 25 Nov 2015, at 17:16, Anton Bachin <antonbachin@yahoo.com> wrote:
>>
>> I always use prints and never debuggers when I have access to the
>> source, in any language. I use debuggers when reverse-engineering
>> binaries, however. As for why – setting up breakpoints, trying to
>> examine values usually takes more time for me than adding some
>> prints and reading and understanding the resulting trace. Perhaps
>> it only seems that way, but that has been my habit for a very long
>> time.
> 
> [ ... ]
> 
> Instead of print-peppering, I prefer to use structured failures
> (like the success monad https://github.com/michipili/lemonade)
> giving context for the failure, or improved logging capacities.

I use tools that I am familiar with when debugging because I don't want to focus on two things (learning a new tool and tracking down/fixing a bug).

For Lwt what helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception
will have some context and helps towards creating a reproducible testcase.

I'd love to be able to use ocamldebug's functionality, but all my OCaml programs are compiled to native code which rules ocamldebug out for the moment.
Ideally I'd like to have something like http://rr-project.org/, unfortunately that doesn't work on my CPU (yet).

Additional logging is my preferred method too: sometimes I just add a printf, but often it is Lwt.log hidden behind a --debug flag,
and I keep these even after the bug is fixed.
I also try to turn debug/verbose mode of libraries (OCamlNet, Ocsigen, ..) where possible.

Often all I know about a problem is a warning or exception logged long ago, and if its Lwt then the stacktrace usually stops at map or some other uninteresting function,
which makes it hard to find the real origin of a bug.
What helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception
will have some context and helps towards creating a reproducible testcase.
Once there is a testcase it is sometimes enough to observe the inputs/outputs using wireshark, sometimes more debugging has to be added.
The hardest ones to debug are probably bugs where timing matters (timeouts, intentional retry delays, etc.).

I would say this is exactly the way I'm debugging C multi-process/multi-threaded server applications too, not necessarily an efficient one though.
Some colleagues always use gdb on C code, but I find grepping logfiles more efficient.
For hard to reproduce bugs you can turn on debug mode - even on quasi-production servers for brief periods of time - , and analyze the logs later (quite likely few GB).

I haven't spent much time debugging single applications that are not networked, but when I'm writing new code/new module I usually just use utop (either directly or from (Spac)Emacs).

There is one case that requires a different debugging technique: SIGSEGV (quite rare, but quite time consuming to track down).
Then I use gdb to get a stacktrace, it is almost certainly a bug in C code.
Debugging it is similar to the approach I take when debugging incorrect code generated by C compilers (I had quite a few of these in C applications, more than bugs I had in C code linked with OCaml apps).
That is: build with debugging aids (in this case OCaml's debug runtime and Gc.compact called often), try to find a reproducible testcase, and then try to minimize the testcase
(either manually or via tools like delta.tigris.org). Often this means adding additional sanity checks to the C code being debugged.
Once there is a testcase of reasonable size then there is usually enough information to fix it or report to upstream bugtracker.
Unfortunately C debugging aids like address sanitizer or valgrind are not easily usable with OCaml C runtime/bindings, because they would only detect corruption at the C level,
and wouldn't always detect when C code corrupts OCaml's heap.

-- 
Edwin Török | Co-founder and Lead Developer

Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[David MENTRÉ]

Hello,

Le 2015-11-25 13:49, John Whitington a écrit :
> What do you use for debugging small and large OCaml programs?

Mostly Printf and exception backtraces.

> If not a debugger, why not? What problems prevent it? 

Mainly for following reasons:

 1. No support for native code;

 2. UI was unclear to me: difficult to see where I was and where was set
a breakpoint;

 3. Going in the past is a nice idea but does not interact well with I/O
code like networking;

 4. Inability to print immediately your own defined types;

 5. Lack of use vicious circle: when you really need a debugger, your
are not willing to learn a new tool. When your are willing to learn a
new tool, you don't really want to learn a debugger. ;-)

It's a long time that I haven't used the debugger so those reasons might
be not accurate or outdated. :-)


> How does your debugging
> process differ when writing OCaml compared with other languages you use?

I'm using a lot printfs and backtraces in other languages. Probably to
much. :-)

I systematically use the debugger for C language for segfault related
issues, you can hardly use another tool.

Best regards,
david

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Malcolm Matalka]

John Whitington <john@coherentgraphics.co.uk> writes:

> Hi,
>
> Like, I suspect, many people, my method has always been to insert Printfs, and stare at code until I find the problem. In fact, the
> ocaml.org page on ocamldebug says:
>
> "In fact, for complex programs, it is likely the case that the programmer will use explicit printing to find the bugs, since this
> methodology allows the reduction of the trace material: only useful data are printed and special purpose formats are more suited to get the
> relevant information, than what can be output automatically by the generic pretty-printer used by the trace mechanism."
>
> So, I ask: What do you use for debugging small and large OCaml programs? If not a debugger, why not? What problems prevent it? How does your
> debugging process differ when writing OCaml compared with other
> languages you use?

I do not use a debugger, but I think it's mostly due to ignorance.  I
just don't know how to use a debugger effectively in any language.

That being said, I write a lot of asynchronous code which I have found
difficult to use a debugger in pretty much any language other than
Erlang.

Also, if something weird is happening in an place I don't expect, I
often try to hoist that up to the type system which can, with
discipline, inform me of when I was forgetting to handle a situation.


>
> John
>
> -- 
> John Whitington
> Director, Coherent Graphics Ltd
> http://www.coherentpdf.com/

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Romain Bardou]

On 25/11/2015 13:49, John Whitington wrote:
> Hi,
>
> Like, I suspect, many people, my method has always been to insert
> Printfs, and stare at code until I find the problem. In fact, the
> ocaml.org page on ocamldebug says:
>
> "In fact, for complex programs, it is likely the case that the
> programmer will use explicit printing to find the bugs, since this
> methodology allows the reduction of the trace material: only useful data
> are printed and special purpose formats are more suited to get the
> relevant information, than what can be output automatically by the
> generic pretty-printer used by the trace mechanism."
>
> So, I ask: What do you use for debugging small and large OCaml programs?
> If not a debugger, why not? What problems prevent it? How does your
> debugging process differ when writing OCaml compared with other
> languages you use?
>
> John
>

I used to program in Delphi, which is basically an IDE for Object 
Pascal. It had a debugger which I used, because it was easy:
- click in the margin of your program to set up a breakpoint;
- click on a button to run step-by-step;
- learn the keyboard shortcut for this button by putting the mouse 
cursor over it;
- view the value of a variable by putting the mouse cursor over it;
- add conditions to breakpoints easily, like "only stop after the 100th 
time" or "only stop if x > 100".

I did use the equivalent of printf sometimes though, because for some 
bugs it's just more convenient, even in a GUI such as Delphi.

I almost never used a debugger for OCaml. I tried once, but:
- the learning curve was really not as smooth;
- it was not integrated into my editor (Emacs) or if it did, it was not 
easy to discover;
- having to type debugger commands was actually slower than adding 
printf calls, maybe because I had to look up the commands first.

I'm impressed by the capacity to rewind, but it turns out this feature 
is not enough to counterbalance the above.

I would probably use a debugger for OCaml if it had the following features.

- It's an easy-to-use GUI.

- I can click to set up a breakpoint or just add something like 
Debug.breakpoint () in my code. I can run it step-by-step.

- I'm able to see the state of the stack and the heap with some kind of 
OCaml value browser. This browser should know the types of values to 
display them with constructor and field names. I should be able to click 
to open or close a value so that I can hide large subtrees. The roots 
could be the roots of the GC, or the set of variables which are 
currently in scope. I can click on a variable in my code and the browser 
jumps to it immediately.

- I can visualize the current backtrace, and use the value browser to 
explore function arguments in this backtrace.

- The state is saved at each breakpoint so I can explore the past using 
the value browser.

It would be an awesome challenge to program such a tool but it requires 
a lot of time! So I just use printf. Actually I think there has been 
work by OCamlPro which goes towards those goals.

Printf-debugging would be even easier with some kind of "typeof" 
construct, which would return a runtime representation of the type of 
its argument, so that one could easily write a generic printer without 
the need for a ppx. Even if it only worked for non-polymorphic parts of 
said type it would be useful, as long as it uses the type after 
inference has finished. For instance one could write "let print_t (x: t) 
= print_generic (typeof x) x" and get a generic printer for type t. One 
can already write a generic printer with Obj, but it misses the field 
and constructor names, that typeof could provide. The type 
representation could be from compiler-libs or something. I might try to 
patch the compiler to add that one day, just for fun because it's not 
general enough to be integrated, I guess.

Cheers

-- 
Romain

Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

[Richard W.M. Jones]

On Wed, Nov 25, 2015 at 12:49:42PM +0000, John Whitington wrote:
> So, I ask: What do you use for debugging small and large OCaml programs? If
> not a debugger, why not? What problems prevent it? How does your debugging
> process differ when writing OCaml compared with other languages you use?

No one seems to have mentioned gdb in this thread.  I use it on OCaml
programs quite often.  It's especially useful for finding bugs in my C
libraries :-)  In fact I missed gdb when we ported the tools to aarch64
because stack traces didn't work properly for quite a while [now fixed].

Rich.

-- 
Richard Jones
Red Hat