Inspect and dump values on the OCaml heap

Inspect and dump values on the OCaml heap

[Kaspar Rohrer]

Hello everybody

I've written a little library to inspect and dump values on the OCaml heap, as S-expressions or in the Graphiz dot-format.
It's as simple as

open Inspect

dump ();;
dump 3;;
dump (1,2);;
dump (test_data ();
dot (test_data ());

If anybody is interested, I will put up the code somewhere. Any opinions on a good place to post it? I'm using git, so I'm thinking maybe git-hub?
I'm also unsure as to what license I should use. I'm favoring some kind of BSD-license, to keep it simple?

Best regards
	Kaspar Rohrer

Re: [Caml-list] Inspect and dump values on the OCaml heap

[Richard Jones]

On Wed, Apr 14, 2010 at 05:02:30PM +0200, Kaspar Rohrer wrote:
> Hello everybody
> 
> I've written a little library to inspect and dump values on the OCaml heap, as S-expressions or in the Graphiz dot-format.
> It's as simple as
> 
> open Inspect
> 
> dump ();;
> dump 3;;
> dump (1,2);;
> dump (test_data ();
> dot (test_data ());
> 
> If anybody is interested, I will put up the code somewhere. Any opinions on a good place to post it? I'm using git, so I'm thinking maybe git-hub?

Graphviz output is interesting, but I would add that such a thing
exists as the 'Std.dump' function in extlib.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Inspect and dump values on the OCaml heap

[Kaspar Rohrer]

On Apr 15, 2010, at 12:45 AM, Richard Jones wrote:
> Graphviz output is interesting, but I would add that such a thing
> exists as the 'Std.dump' function in extlib.

The last time I've checked, Std.dump had several shortcomings. It did not handle cycles in the object graph that well (that's probably an understatement, it did not print much information about some value types (e.g. custom, closure).
I tried to remedy that in my library. I also do not try to interpret the values (e.g. lists are printed as either 0 or (BL0#2 hd tl) ). The library simply dumps the object graph, with references or links where appropriate or needed.

I will go into more detail if anybody is interested, but right now I just want to get the code out there.

In the meantime, there are two sample pictures of graphviz dumps on my personal blog: http://lambdamuesli.blogspot.com/ (I apologize for the shameless plug)

Re: [Caml-list] Inspect and dump values on the OCaml heap

[Martin Jambon]

Kaspar Rohrer wrote:
> On Apr 15, 2010, at 12:45 AM, Richard Jones wrote:
>> Graphviz output is interesting, but I would add that such a thing
>> exists as the 'Std.dump' function in extlib.
> 
> The last time I've checked, Std.dump had several shortcomings. It did not handle cycles in the object graph that well (that's probably an understatement, it did not print much information about some value types (e.g. custom, closure).
> I tried to remedy that in my library. I also do not try to interpret the values (e.g. lists are printed as either 0 or (BL0#2 hd tl) ). The library simply dumps the object graph, with references or links where appropriate or needed.
> 
> I will go into more detail if anybody is interested, but right now I just want to get the code out there.
> 
> In the meantime, there are two sample pictures of graphviz dumps on my personal blog: http://lambdamuesli.blogspot.com/ (I apologize for the shameless plug)

By the way, there is also Dum, which takes care of cycles. No graphviz/dot
output though:

  http://oss.wink.com/dum/


Martin

-- 
http://mjambon.com/

Re: [Caml-list] Inspect and dump values on the OCaml heap

[Kaustuv Chaudhuri]

On Wed, Apr 14, 2010 at 5:02 PM, Kaspar Rohrer <kaspar.rohrer@gmail.com> wrote:
> [...]

Implementing dumpers seems like a teething procedure for
OCaml hackers. Here's my own attempt from a couple of years ago.
It handles cycles, renders SVGs (via Graphviz), and can accept
data structure "descriptions" to produce better names for the
internal nodes. It is almost 100% OCaml.

  http://www.lix.polytechnique.fr/~kaustuv/misc/ocaml_show.html

I am convinced that such things have *no* usefulness. If you
are trying to debug your data structure, state its global
invariants, prove (at whatever level of formality you are most
comfortable with) that all API functions preserve the invariants,
and use the module system to hide functions that do not
preserve them. You will be done faster than trying to make
sense of graphs and your code will be better.

-- Kaustuv

Re: [Caml-list] Inspect and dump values on the OCaml heap

[rixed]

I think this kind of dot output can be very informative if accurate
enough, for instance as a pedagogical or debug purpose.

That, and the fact that large graphs are beautiful.
Large graphs are like to nightly skies : it's always nice to stare at
them even if you are not knowledgeable in the field :)

May I suggest gitorious instead of github for hosting this ?

Re: [Caml-list] Inspect and dump values on the OCaml heap

[rixed]

> I am convinced that such things have *no* usefulness. If you
> are trying to debug your data structure, state its global
> invariants, prove (at whatever level of formality you are most
> comfortable with) that all API functions preserve the invariants,
> and use the module system to hide functions that do not
> preserve them. You will be done faster than trying to make
> sense of graphs and your code will be better.

Visualizing data structures does no prevent you from proving some
invariant and can give some other kind of informations, like spotting 
unexpected (ir)regularities, wrong proofs, etc...  Why oppose both ?

Re: [Caml-list] Inspect and dump values on the OCaml heap

[Martin Jambon]

Kaustuv Chaudhuri wrote:
> On Wed, Apr 14, 2010 at 5:02 PM, Kaspar Rohrer <kaspar.rohrer@gmail.com> wrote:
>> [...]
> 
> Implementing dumpers seems like a teething procedure for
> OCaml hackers. Here's my own attempt from a couple of years ago.
> It handles cycles, renders SVGs (via Graphviz), and can accept
> data structure "descriptions" to produce better names for the
> internal nodes. It is almost 100% OCaml.
> 
>   http://www.lix.polytechnique.fr/~kaustuv/misc/ocaml_show.html
> 
> I am convinced that such things have *no* usefulness. If you
> are trying to debug your data structure, state its global
> invariants, prove (at whatever level of formality you are most
> comfortable with) that all API functions preserve the invariants,
> and use the module system to hide functions that do not
> preserve them. You will be done faster than trying to make
> sense of graphs and your code will be better.

The only reason why I wrote Dum was to print exceptions deeper than
Printexc.to_string:

# exception Foo of [`Bar of string];;
exception Foo of [ `Bar of string ]

# Printexc.to_string (Foo (`Bar "abc"));;
- : string = "Foo(_)"

# Dum.to_string (Foo (`Bar "abc"));;
- : string = "((\"Foo\") (3303859 \"abc\"))"


Martin

-- 
http://mjambon.com/