Previous week Up Next week


Here is the latest Caml Weekly News, for the week of November 27 to December 04, 2007.

  1. Camlp5 release 5.04 - yet another release of camlp5...
  2. Python and Caml
  3. Wink releases Hydro - an ICE implementation
  4. Disabling the OCaml garbage collector
  5. Is there a way to statically link an ocaml app compiled to native code against glibc?
  6. Doctoral and Post-doctoral openings at Rice
  7. LLVM: A native-code compiler for MiniML in ~100LOC

Camlp5 release 5.04 - yet another release of camlp5...


Daniel de Rauglaudre announced:
Yet another release of Camlp5: 5.04 

A new feature is added: full backtracking 

  1/ new syntax to create backtracking parsers introduced by "bparser". 
  2/ ability to change the parsing algorithm of extensible grammars. 

Also, some bug fixes in installation, improvements of documentation pages, 
other small bug fixes. 

See the Camlp5 documentation and the file CHANGES. 

Download the sources and the documentation at:

Python and Caml


Deep in this thread, Thomas Fischbacher announced:
Acknowledging that there is a number of people interested in interfacing 
python and caml, I just put up a website from which our bugfixed and 
extended variant of Art Yerkes' "pycaml" module can be downloaded: 

(Note ad Debian developers: this fixes some major memory management bugs 
that can cause crashes in the original pycaml module which is in Debian, 
so, ideally, our variant should eventually supersede the code that is at 
present in that Debian package. Interface-wise, our module provides more 
than the original one, but I think I also had to remove two or three 
very obscure functions.)

Wink releases Hydro - an ICE implementation


Gerd Stolpmann announced:
Wink Technologies, Inc., the makers of the soon-to-be-famous people 
search engine (, have just released another OCaml 
library, this time for using the ICE protocol. 

This is really an exciting contribution, as it directly addresses the 
problem of language interoperability. Hydro opens the door to use O'Caml 
besides other languages in the same company! We at Wink use Hydro 
already for communication between O'Caml, C++, and Java. 

Note that we don't have any relationship with ZeroC, the inventors of 


From the README: 


Hydro is an independent implementation of ICE, the object-oriented RPC 
protocol by ZeroC, for the O'Caml programming language. This is an 
early, not yet complete release, but the code is already stable and 
usable. For the restrictions of this release, see below. 

Hydro (like ICE) allows you to bridge language barriers by letting 
components written in different programming languages communicate with 
each other. ZeroC's ICE product currently includes implementations for C 
++, Java, C#, Python, Ruby, VB, and PHP.  Hydro adds support for O'Caml. 
The ICE protocol is rich enough to make the representation of the data 
to communicate easy and convenient to use, and adopts an object-oriented 
type system. ZeroC sees ICE as a superior successor to CORBA. 

Hydro includes a runtime, and a generator called hydrogen. The runtime 
is fully asynchronous, based on Ocamlnet's event queues. The generator 
is used to create a thin layer on top of the runtime that maps abstract 
Hydro types to specific O'Caml types.  The Hydro engine therefore 
appears to the programmer as if it was typed using the input IDL file. 
Unlike the generators shipped by ZeroC, hydrogen does not create 
marshalling code -- we see this as the task of the runtime and not of 
the language mapping layer. Because of this design decision we have high 
confidence in the correctness of the generator. 

Although we want Hydro to be an implementation whose protocol is fully 
compatible with ICE and that can process all its IDL files, we take some 
freedom to deviate from what is described in ZeroC's "ICE manual". ICE 
was designed with mainstream object-oriented languages in mind, and 
therefore lacks many of the advanced constructs available in O'Caml 
(variants, for example).  Conversely, ICE includes constructs such as 
hierarchical exceptions and downcasts which do not exist in O'Caml (and 
for good reason!).  To deal with the "impedance mismatch," we 
implemented emulations for these concepts.  On the other hand, O'Caml 
offers advanced features which ought to be exploited by a good 
implementation.  For example, in O'Caml, asynchronous networking code is 
quite natural, so we have chosen to make this the default style. So 
while Hydro is quite straightforward, the O'Caml programmer should not 
expect a design which is a perfect one-to-one translation of what ZeroC 

*** Features *** 

      * Support for clients and proxies 
      * The whole ICE type system is implemented, and can be marshalled. 
        This includes graphs of objects. 
      * The whole ICE type system can be mapped to O'Caml types. The 
        mapping is quite flexible and configurable, e.g. you can choose 
        whether you prefer arrays or lists as representations of ICE 
        sequences. Where necessary, the properties of the ICE type 
        system are emulated. For example, hydrogen generates special 
        code for downcasts of objects. 
      * IDL files are dynamically represented at runtime 
      * The runtime supports both asynchronous and synchronous method 
      * The runtime can be integrated with other libraries that also 
        base on Ocamlnet's event queues, e.g. with Ocamlnet's HTTP 
        clients, or SunRPC. 
      * Fully automatic connection management 
      * The generated code is properly indented 
      * Liberal license conditions 

*** Restrictions *** 

      * Hydro does not support servers for now (this will follow soon, 
        and is now priority #1). The support for clients is quite 
      * Hydro only supports twoway calls over TCP for now 
      * Hydro does not support separate compilation (i.e. you cannot 
        split an .ice file into several parts, hydrogen every part 
        alone, and then merge them later). This is a fundamental 
        restriction we'll never be able to improve. 
      * There is no support for Slice checksums 
      * There is no support for checked proxy casts (to will follow 
      * There is no support for configuration files 
      * There is no support for stringified proxies and endpoints 
      * The runtime and the generated language mapping layer are both 
        reentrant. However, there is no specific support for 
        multi-threaded programming beyond this 
      * There is no support for compression 
      * Except of calling the locator service of IceGrid, there is no 
        support for add-on technologies like IceGrid, Freeze, etc. We 
        have some interest in IceGrid, so this may also follow at some 

[... rest of README omitted...] 

Download, and documentation 

Download link: 


A GODI package godi-hydro exists. 

For general information about ICE, see ZeroC's homepage:

Disabling the OCaml garbage collector


Raj Bandyopadhyay said and Xavier Leroy answered:
> The issue for me is that I need to be able to modify mutable objects in 
> OCaml (eg. array-modification in-place) from both OCaml and C/Python. 
> However, the OCaml GC moves things around while the execution is in 
> C/Python and this crashes my program. 
> The Python GC is very simple, based on reference counts, hence (I think) 
> it suffices just to make sure that any object has a refcount > 0 to keep 
> the Python GC off. 
> Well, I decided to go ahead and hack some C code to build a custom OCaml 
> compiler. These are the steps I followed:

That's a classic bootstrapping issue, and "make bootstrap; make all" 
might solve it.  But you are on the wrong tracks anyway. 

What your C code does is disable the compactor, which runs from time 
to time to eliminate fragmentation in the major heap by moving objects 
around.  You can disable it by using Gc.set with the "max_overhead" 
field set to a suitably high value, as documented in the Gc module. 
There is no need to hack the run-time system. 

However, what you will never be able to disable is the minor 
collector, which moves blocks from the minor heap to the major heap. 
The reason it cannot be disabled is that the minor heap is of fixed 
size, so if it gets full and the minor GC isn't executed to empty it, 
your program cannot proceed. 

You see, the Caml garbage collector is like a god from ancient 
mythology: mighty, but very irritable.  If you mess with it, it'll 
make you suffer in surprising ways. 

The solution to your problem is to play nice with the Caml GC: on the 
C/Python side, handle Caml "values" through an indirection via a 
malloc-ed block, and register the Caml value contained within this 
block with the Caml GC using register_global_roots(), as Thomas 
Fischbacher outlined.  Members of this list can probably point you to 
some existing C/Caml bindings that does just this and that you could 
use as inspiration. 
Raj Bandyopadhyay then said and Thomas Fischbacher answered:
> I would highly appreciate any pointers to existing code that does the 
> 'register_global_roots()' thing.  Examples would definitely help me code 
> it correctly. 

I would suggest you download the nsim sources from: 

and study the nsim/mpi_petsc/ and petsc_stubs.c files. 

(Actually, the code quality of these functions varies a bit. 
Most of the module is reasonably good style, but not everything.) 

Basically, this is an OCaml interface to the PETSc "parallel sparse 
linear algebra" library. (It also assimilated Xavier's old MPI 
interface for OCaml. Had to do that, sorry.) 

Of particular interest should be the function 
with_petsc_vector_as_bigarray, which will take an opaque petsc vector 
and a function that takes a double-float bigarray and calls that 
function from C in such a way that it can address the Petsc vector as if 
it were a bigarray. 

Also, you might be interested in the "sundials" module, which interfaces 
the CVODE time integrator from libsundials to OCaml.

Is there a way to statically link an ocaml app compiled to native code against glibc?


Eric Merritt asked and Sylvain Le Gall answered:
>  I have spent quite a bit of time digging around for this on the net 
> with now luck. We have a pretty simple ocaml app for which we would 
> like to distribute an executable binary. For the most part this works. 
> However, we would like to minimize the number of binaries that we are 
> forced to distribute. We would also like to avoid any confusion on the 
> part of our users around figuring out which version of glibc they are 
> using. For example, we would like to avoid distributing a binary for 
> each version of glibc available. Its more work for us and has a chance 
> of confusing some of the folks using our work. Considering the 
> simplicity of our binary it seems like a good solution would be to be 
> to just statically link against glibc (our only non-ocaml dependency). 
> So it would be great if someone could give me pointers to docs that 
> describe how to do this. Extra points if I can easily do this with 
> OCamlMakefile.  If there is another way to accomplish our goals I am 
> more then willing to entertain them, as there are a lot of potential 
> problems involved with static linking against glibc. 

Other people had already give you some advices on how to achieve a static 
link against glibc. 

I would like to WARN you against this. I have some pretty bad 
experiences with using static glibc in my binaries. It seems to have 
something to do with the fact that: 
* top bugs of glibc (in BUGS in the orginal tarball 

[ **]  Closing shared objects in statically linked binaries most of the 
       times leads to crashes during the dlopen().  Hard to fix. 

** is medium severity. 

* whatever you will statically linked, you will always have to load -- which makes you fall into the top bug of glibc 

* you will have to include NSS into your code (so it won't be 
  possible to use system NSS). 

All in all, you could get really strange behavior by using a statically 
linked glibc into your code. Of course, this also should not happen...
Garrett Jones also suggested:
This setting works for me with OCamlMakefile: 

LDFLAGS = -Wl,-Bstatic

Doctoral and Post-doctoral openings at Rice


Walid Taha announced:
The Resource-Aware Programming (RAP) research group at Rice University 
is seeking qualified doctoral and post-doctoral students.  The openings will 
support work on a wide range of topics, including the Concoqtion programming 
language, physically safe computing, and device drivers.  The full descriptions 
of these positions can be found at: 

Funding for these positions is provided by the National Science Foundation 
(NSF) and by industrial partners including Intel, LogicBlox, and Schlumberger.

LLVM: A native-code compiler for MiniML in ~100LOC


Continuing the thread from last week, Xavier Leroy said:
Yes, LLVM is an impressive project and your example demonstrates that 
LLVM is very well suited to run-time code generation. 

However, I have a point of terminology to make: the language you 
implemented is not what is normally called Mini-ML in the literature. 

Your language has first-order, second-class functions, while Mini-ML 
has higher-order, first-class functions.  A runtime code generator for 
Mini-ML would be significantly more complex, since it has to deal with 
first-class functions either through closure conversion or 
defunctionalization, meaning in both cases dynamic allocation and 
garbage collection. 

Which brings us back to Basile's original question about LLVM and the 
Caml garbage collector.  The following page suggests that they can 
already work together: 

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1

If you know of a better way, please let me know.

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