caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Julien Signoles <julien.signoles@gmail.com>
To: Alexey Rodriguez <mrchebas@gmail.com>
Cc: Mathias Kende <mathias.kende@ens.fr>, caml users <caml-list@inria.fr>
Subject: Re: [Caml-list] Marshalling question
Date: Tue, 12 Oct 2010 11:25:32 +0200	[thread overview]
Message-ID: <AANLkTi=mLh5rZWcuFR6zRB9HZuyYupYJL5bVf5YdXgif@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikgu+qy26vQaQ+K7st04wUgq=EvUkf0VOyfwKPj@mail.gmail.com>

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

Hello,

2010/10/12 Alexey Rodriguez <mrchebas@gmail.com>

> On Fri, Oct 8, 2010 at 3:48 PM, Mathias Kende <mathias.kende@ens.fr>
> wrote:
>
> > Exception are some complex datastructure which may require additional
> > care when marshalled. An example of which are the graphs of the
> > ocamlgraph library (even the functional one), but there is none in the
> > standard library.
>
> Mathias, can you elaborate on "additional care"? We are using the
> functional graphs from ocamlgraph, so I am very interested in your
> experiences with it.
>

To my knowledge, issues come with the so-called "abstract" graphs from
OcamlGraph in which vertices have unique ids.
1) if there are abstract vertices in RAM while unmarshalling some others,
you have to be sure that RAM vertices do not share ids with unmarshalled
ones (except if you really want that).
2) Before creating new abstract vertices, you have to set the global id
counter Graph.Blocks.cpt_vertex in the right way (by marshalling it and by
calling Graph.Blocks.after_unserialization after unmarshalling).
I'm not aware of any other (un)marshalling issue with OcamlGraph
datastructures.

Beyond OcamlGraph, similar issues potentially exist for any datastructure
which uses unique ids as keys and/or hashconsing techniques. For instance, a
quite big job is done for solving this issue in Frama-C (http://frama-c.com)
which uses many hashconsed datastructures (included abstract ocamlgraph
vertices, but only the above-mentioned issue 2 applies in the Frama-C
context)

Hope this helps,
Julien Signoles

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

  reply	other threads:[~2010-10-12  9:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 13:37 Jean Krivine
2010-10-08 13:39 ` [Caml-list] " David Allsopp
2010-10-08 13:48 ` Mathias Kende
2010-10-12  8:42   ` Alexey Rodriguez
2010-10-12  9:25     ` Julien Signoles [this message]
2010-10-12  9:26     ` Mathias Kende
2010-10-12  9:42       ` Julien Signoles
2010-10-12  9:48         ` Alexey Rodriguez
2010-10-09  7:58 ` forum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTi=mLh5rZWcuFR6zRB9HZuyYupYJL5bVf5YdXgif@mail.gmail.com' \
    --to=julien.signoles@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=mathias.kende@ens.fr \
    --cc=mrchebas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).