Previous week Up Next week


Here is the latest Caml Weekly News, for the week of July 10 to 17, 2012.

  1. Returning an element computed with Toploop
  2. library/framework needed for distributed programming in OCaml
  3. Opportunité chez Esterel Technologies !
  4. Coherent Graphics Product Updates
  5. OUD - call for participation
  6. Other Caml News

Returning an element computed with Toploop


Jean-Baptiste asked and Jeannin Edgar Friendly replied:
> Thanks to Jonathan Kimmitt on this mailing list, I learned about the 
> existence of the Toploop module, that allows to execute OCaml code from a 
> string. For example, one can do:
> # Toploop.execute_phrase true Format.err_formatter
> ((!Toploop.parse_toplevel_phrase) (Lexing.from_string "355./.113.;;"));;
> - : float = 3.14159292035398252
> - : bool = true
> However I could not find any official documentation of the module on the 
> internet. In particular, the example above only prints out what was computed 
> and returns a boolean (true or false), depending on how the computation 
> terminated. I would like to compute an element and get the element back to be 
> able to use it later in the computation. Is that possible and how could I do 
> it?

The documentation for Toploop may not be on the net nicely anywhere;
here's the best link I have:

As far as your problem, you want the `Toploop.getvalue` function; for
an example, see specifically
the section "Referring to Packages Indirectly". Be warned that the
results are quite type unsafe.
Hongbo Zhang also replied:
The codebase for toplevel/ is pretty small, IMHO, reading the source
is best way to understand how toploop works.

There's another non-trivial example in camlp4/Camlp4Top which shows
you how to customize toplevel. If you understand how it works, feel
free to use it, it's pretty safe :-)
Kimmitt, Jonathan Richard Robert also replied:
If you have a complicated piece of code it might be better to use
Lexing.from_file instead of Lexing.from_string.

Also the evaluations made in the top-level will be cumulative:

you could do:

open "Jean";;

results := ["cats";"dogs";"fish];;

This assumes the module "" previously compiled has a "let result = ref 

By this means data can be exchanged between top-level and your own module.

If the last calculation in your parsed string/file has type unit, nothing 
will be printed, apart from status

I don't think there is anything type-unsafe about it, or any
difference with the normal top-level really, just you need to be aware
the expressions are not checked at compile time, so you need to be
careful to check for errors.

library/framework needed for distributed programming in OCaml


Francois Berenger asked:
Please forgive me to open this possibly re-occurring thread
but I need an up to date version of the answer.

I once wrote a parallel and distributed toy program in Python which
proved to be quite useful
(  It was quite simple and
easy to write because I used a "library that enables you to build
applications in which objects can talk to each other over the network"

So, I am looking for the gold standard to write
modules in OCaml that can talk to each other over the network
(not objects, I don't like them so much).

Here are some requirements, in a random order:

- the target execution environment is composed of
about 10 Linux workstations. It may switch to 1 or
2 interconnected clusters in the future (about 512 cores max).
So, not as large a scale as a company doing big data.
- the system will be used to transfer files of various sizes
(big files like a few Gb included, tiny ones also)
- pure OCaml code, so JoCaml and CamlP3l are out.
I don't like so much if there is some C part in the library
but this is not a show stopper.
- I really dislike syntax extensions (or things that force
me to do a lot of sysadmin strange configuration) so user-land only
would be great
- preserving type-safety and abstraction as mentioned
in the Quicksilver/OCaml paper would be cool (
) but not mandatory.
Ideally, encryption or compression of communications should
be a user-toggable feature.
- tolerance to partial failures would be nice but not
mandatory (because my target environment is not so error prone
and not so large)
- the project should be actively maintained and preferably used
in production somewhere ("je n'aime pas essuyer les platres")
- I don't like to use huge frameworks/libraries (j'essaye d'eviter "les
usines a gaz")

I would be satisfied with even just links to things that
satisfy most of my requirements.

For the moment, the few things that I could find that looks useful are:
- Client-server part of
- maybe the SunRPC part of
Lauri Alanko replied:
I also had need of such a library when I started working on a
distributed programming project, but as I couldn't find anything that
fulfilled my requirements, I wrote my own.

The library is Lwt-based, and provides pretty straightforward remotely
callable procedures:

type ('a, 'r) handle
val ($) : ('a, 'r) handle -> 'a -> 'r Lwt.t
val publish : ('a -> 'r Lwt.t) -> ('a, 'r) handle

The library is designed to work in a firewalled environment:
firewalled nodes can join the distributed network by connecting to any
accessible host of that network with an open listener. All messages
between nodes are routed through the network.

type connection
val connect :
?host:string -> ?port:int -> unit -> connection Lwt.t
val listen :
?port:int -> unit -> unit Lwt.t

Initial values are obtained with "roots". A root (usually a handle, or
a record or first-class module containing handles) is keyed to a
string, and once set by a node, it can be discovered by any node in
the network:

val get_root : string -> 'a Lwt.t
val set_root : string -> 'a -> unit Lwt.t

This is the only unsafe part of the interface: the getter and setter
_must_ agree on the type of the root or all hell breaks loose.

I haven't published the library yet, since I have wanted to feel free
to modify it as required by my application, but if you are interested,
and cannot find a more mature solution, I'd be happy to provide it for
your inspection.
Later on, Francois Berenger said:
For the moment, the best answer I got privately in my mailbox
is to combine Janestreet's bin_prot and async libraries
or Martin Jambon's biniou with Lwt.

I kind of like what I read on async and bin_prot.

Opportunité chez Esterel Technologies !


Amandine ROY announced:
Je recherche un ingénieur en Validation qui connaît la programmation
OCaml pour compléter notre équipe R&D.
Ce poste est à pourvoir sur notre site de Toulouse (31), de Villeneuve
Loubet (06) ou d'Elancourt (78) et est à pourvoir en CDD ( 9 mois)
avec la possibilité d’être reconduit en CDI.

Vous trouverez ci-après la description du poste : 

Ingénieur Validation
Description du Poste:
Au sein de l'équipe R&D en charge du développement et de la validation
de nos générateurs de code certifiés, vous avez pour missions:

- La spécification et le développement de tests de bas niveaux écrits

- La mise à jour du référentiel documentaire du projet et la
participation aux activités de vérification

Le poste est basé au sein de notre équipe de Toulouse, de Paris ou de
Villeneuve-Loubet et est à pourvoir en CDD (9 mois) avec la
possibilité d’être reconduit en CDI.

Profil du candidat:
- Formation en informatique : pas d'exigence sur la formation
initiale, le candidat sera jugé sur ses compétences en programmation

Compétences Requises:
- Bonne pratique de la programmation
- Connaissance du langage OCaml
- Bon niveau d’Anglais

Si vous êtes intéressé, contactez moi ! ou si vous connaissez une
personne susceptible de l'être, transférez-lui mon email.

Voici mes coordonnées : 

Amandine ROY 
Responsable R.H. 

Esterel Technologies 
8 rue blaise Pascal - Parc Euclide 
78990 Elancourt 

amandine.roy AT 

Tél: 01 30 68 61 60 

Coherent Graphics Product Updates


John Whitington announced:
1. A new version of our PDF editor for OS X (PDF manipulation in
OCaml, interface in Objective C):

Should be on the Apple App Store within the next couple of weeks.

2. The latest versions of our PDF command line tools from last year
(/almost/ pure OCaml):

3. Not really OCaml-related, but I wrote a book about PDF:

Also available in Portuguese!

There should be new releases of the command line tools and CamlPDF
later in the year. Our OCaml codebase just exceeded 100,000 lines -
not that that's necessarily a good sign :-)
David MENTRE asked and John Whitington replied:
> An architectural question: how your backend OCaml part and your
> Objective C GUI are communicating between each other?

It's entirely one-way. Objective C calls OCaml. OCaml never calls Objective C. 

Here's the makefile for the library - this method is straight out of the OCaml manual. 

ocamlc.opt cpdfstrftime.mli;
ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa; 
ocamlc.opt cpdf.mli;
ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa; 
ocamlc.opt cpdflib.mli;
ocamlopt.opt -c -I . unix.cmxa str.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdf.cmx; 
ocamlc.opt cpdflibwrapper.c;
ocamlopt.opt -output-obj -o cpdflib.o unix.cmxa bigarray.cmxa cgutil.cmxa camlpdf.cmxa cpdfstrftime.cmx cpdf.cmx cpdflib.cmx; 
cp /usr/local/lib/ocaml/libasmrun.a cpdflib.a;
ar r cpdflib.a cpdflib.o cpdflibwrapper.o

test: zlibstubs.o cpdflib.a cpdflibc-test.c
cc -c cpdflibc-test.c -o cpdflibc-test.o; \
cc -L'/usr/local/lib/ocaml' -lunix -lbigarray -lz -o test cpdflibc-test.o zlibstubs.o cpdflib.a 

For example, for a single function 'fromFile' to load a PDF from disc: (Wraps up functionality from our command line tools imperatively)

(* Read a file, no attempt at decryption, unless it's the blank user password. *) 
let fromFile filename =
new_pdf (Pdfread.pdf_of_file (Some "") None filename)
e -> handle_error "fromFile" e; err_int

let _ = Callback.register "fromFile" fromFile

cpdflibwrapper.c (the foreign function interface)

int fromFile(char* filename)
CAMLparam0 ();
CAMLlocal3(fromfile_v, filename_v, result_v);
fromfile_v = *caml_named_value("fromFile");
filename_v = caml_copy_string(filename);
result_v = caml_callback(fromfile_v, filename_v);
updateLastError ();
CAMLreturnT(int, Int_val(result_v));

PDFDocument.m (Objective C)

clearError ();
const char* in_c = [[[self fileURL] path] UTF8String];
int pdf = fromFile((char*) in_c);
if (lastError != 0) return NO;

Functions like handle_error, updateLastError(), clearError()
etc. provide a simple flat system for dealing with errors without
exceptions crossing the C/OCaml boundary. This is very old fashioned,
but seems to work. C code checks the error code after each callback to
Ocaml, and can extract extra information about the error.

Similarly, no complicated OCaml data structures cross the boundary -
it's all direct ints, floats, strings, and the occasional void*. The
possibility for programmer error in building big OCaml data structures
directly in C seems to outweigh the annoyance of a slightly flat
interface, at least for this particular application. FFI Masters may
disagree :-)

The multiple PDF files representing different undo/redo states of a
document are held in memory in OCaml (with most of the data shared
between them automatically, of course). When the PDF is updated or
undone/redone, it's flattened to disk, and the PDFKit component in
Cocoa picks it up and renders it - surprisingly, this is quick enough
- it's all in the memory cache rather than the actual disk usually, of

PDFKit (The cocoa PDF component) is only used for rendering - almost
every other piece of functionality is dealt with by CamlPDF via the

OUD - call for participation


Didier Remy announced:


Copenhagen, Denmark

Fri, Sep 14th, 2012

Co-located with ICFP

Sponsored by SIGPLAN and the OCaml Consortium

This year, the OCaml Meeting is renamed the OCaml Users and Developers
workshop (OUD), and is colocated with ICFP in Copenhagen, Denmark. It
will be held on Friday September 14, after the ML workshop (Thu 13)
and before the Commercial Users of Functional Programming (Sat 15).

The OCaml Users and Developers Workshop will bring together industrial
users of OCaml with academics and hackers who are working on extending the
language, type system and tools. Discussion will focus on the practical
aspects of OCaml programming and the nitty gritty of the tool-chain and
upcoming improvements and changes.

The program is available at


Please, register to OUD via the ICFP conference registration site at and don't miss the
early registration deadline on *August 1st*!

There is some support for students to travel to ICFP as well as specific
support for OUD. See

See the OUD homepage for more information.
If you have any other questions, please e-mail us:

Didier Remy 
<didier.remy AT>
Anil Madhavapeddy 
<avsm2 AT>

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at

OCaml MySQL Protocol 0.5 available:

A minor branch off Braun Trees:

HeVeA : a new Rope:

Release of OCaml-safepass 1.0:

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt