Previous week Up Next week


Here is the latest Caml Weekly News, for the week of May 07 to 14, 2013.

  1. extlib 1.5.4
  2. standard 3d vector library in OCaml
  3. Linux epoll bindings
  4. an issue with coercing private types
  5. Interfacing with QtQuick 2.0 from Qt5, RFC
  6. String, Array, Bigarray.char
  7. smarter #load directive
  8. New OCaml-Paris meetup on May 21, 19h30, IRILL
  9. oasis help: support for qtest in oasis
  10. Other Caml News

extlib 1.5.4


ygrek announced:
New release of extlib is out - fixing installation problems only.
Get it as usual at

standard 3d vector library in OCaml


Francois Berenger asked:
Is there a standard library for this purpose?

Maybe I should relase mine, I have a small one.
Francois Berenger replied:
I would enjoy to see your library.

Especially if some functions are usable for OpenGL.
Here is bellow what I'm using for OpenGL.
This is not a vector lib but a matrix lib tailored for use with
forward compatible OpenGL.
It only contains 2 or 3 (not-optimised) functions for vectors computations.

But this current revision 94 in the svn is not my more advanced version.
The more recent version is not in the svn because it's C code rewriten
in OCaml and the original code was provided under a more restrictive
license than the one of glMLite (MIT), and I don't want to downgrade
to (L)GPL.

Someone told me that I should not bother about this issue and that
this kind of code should be considered as only math.

If your lib contains things useful for OpenGL I would be pleased to
integrate these parts in my module Ogl_matrix, or maybe even create a
new one Ogl_vector.
(But only if your license is MIT or similar)
Daniel Bünzli also replied:
It's not standard, unreleased and I hate to pre-announce but in the following
months I plan to release Gg, a module that gives you basic types for 2D and
3D computer graphics; vectors, matrices, quaternions, axis-aligned boxes,
colors and raster data.

Vectors and matrices are abstract but represented internally as records of
floats. This allows to pass them directly to C functions that take double
arrays and avoids bounds checking in OCaml code. The memory layout of
matrices is also the one expected by OpenGL.

Except for the Raster module --- metadata for bigarrays to allow libraries to
share raster data without depending on each other e.g. an OpenCV or image
loading library and an OpenGL library --- the module is pretty stable now, it
still needs a final code review though and one or two function names may

The current documentation of gg can be found here [1], the code can be
browsed here [2]. It can also be installed via the erratique-unstable opam

opam repo add erratique-unstable
opam update
opam install gg

But I'd advise you not to that until the next release of opam because of this
bug [3] which while harmless makes your `opam update` experience become
unpleasant (you have to do a `opam remove gg`, before being able to `opam

Comments are welcome.



rixed also replied:
For what it's worth, I also did a small 2d vector library[1] some time ago in
order to learn some OCaml while doing something fun. What might be of interest
is that it was able to read font outlines from truetype files, and some non
trivial triangulation algorithm was implemented. If someone is interrested it
could be a good thing to "port" this with this upcoming Gg lib (instead of my
own slower and certainly less elegant vector module).

Francois Berenger added:
By the way, I just saw in OPAM that there are bindings to cairo, which looks
quite nice for 2D vector graphics.

Linux epoll bindings


Goswin von Brederlow asked and Markus Mottl replied:
> does anyone have or know of bindings for linux epoll for ocaml?

the Jane Street Core library has epoll in its Linux extensions module
Goswin von Brederlow then asked and Gerd Stolpmann replied:
> I think the best feature of Linux epoll is that the struct epoll_event
> contains a epoll_data_t where one can store a pointer, int, uint32_t
> or uint64_t. Core.Std.Linux_ext.Epoll (and the other epoll bindings)
> seem to always store the Unix.file_descr there.
> In my case, and probably most cases, I have different FDs in the mix
> that need to do different things when their event is triggered. For
> example the server socket needs to call accpet() on POLLIN while
> client sockets need to (continue to) parse requests. So every FD has a
> bit of state associated with it that tells what to do with it. And I
> need a Hashtbl.t to lookup the state for each FD that gets an event.

Using a hashtbl or other external container is the right thing to do.  
You cannot put an OCaml pointer into a kernel structure, because the  
OCaml memory manager might want to move the OCaml block around, and  
there is no way to update the pointer when OCaml wants to do this. So  
you cannot get around this indirection here (which is also very cheap  
at runtime, so I also wonder where the runtime improvement would be).
Prashanth Mundkur also replied to the original post:
There are some in sonet too:
Gerd Stolpmann also replied:
There is also some support in Ocamlnet:

an issue with coercing private types


Milan Stanojević asked and Jacques Garrigue replied:
> I have this module
> module Foo : sig
>  type 'a t = private int
> end = struct
>  type 'a t = int
> end
> and then I want to coerce Foo.t into int
> let to_int (a : 'a Foo.t) = (a :> int)
> this fails to compile with
> Error: This expression cannot be coerced to type int; it has type 'a Foo.t
>       but is here used with type int
> but this compiles fine
> let to_int a = (a : 'a Foo.t :> int)
> 	and gives me the right type.

The reason one works and not the other is explained here:
Namely, when using single coercions from private type abbreviations,
the type of the expression should not contain type variables.

An interesting consequence is that the following is fine:

let to_int (type a) (a : a Foo.t) = (a :> int);;

Interfacing with QtQuick 2.0 from Qt5, RFC


Dmitrii Kosarev announced:
I'm ready to share y experience about this topic. To build it you can use
'./configure' from . In
'test' directory you will find demo ocamlbrowser-like application with
QtQuick GUI interface and logic in OCaml.

I have successfully built it on  Debian sid x64 with Qt5 from git and on
Ubuntu 13.04 with Qt5 from repository. Now it's time to ask what do u think
about all of this.
Fabrice Le Fessant replied:
   Is there any documentation in the examples, to understand how the 
code is structured ?

   I have also improved the wxWidgets binding, the code is now 
completely generated, no code shared with wxHaskell anymore. There is a 
screenshot of some examples on :
Dmitrii Kosarev then said:
I've added small introduction to OCaml+QtQuick

String, Array, Bigarray.char


Tom Ridge asked and Anil Madhavapeddy replied:
> Quick question: I am working a lot with arrays of byte, which at
> various points I want to view as strings, and at various points I want
> to view as arrays. The exact types involved should be discernible from
> the code below.
> I have some conversion functions e.g.:
>  type myfusebuffer = (char, Bigarray.int8_unsigned_elt,
> Bigarray.c_layout) Bigarray.Array1.t
>  module A = Bigarray.Array1
>  (* convenience only; don't use in production code *)
>  let array_of_string bs = (
>    let arr = (Array.init (String.length bs) (String.get bs)) in
>    let contents = A.of_array Bigarray.char Bigarray.c_layout arr in
>    contents)
>  let (_:string -> myfusebuffer) = array_of_string
> This presumably takes O(n) time (where n is the length of the string
> bs). My question is: is there functionality to move values between
> these types at cost O(1)? Basically, I'm hoping that String is
> implemented as A.of_array Bigarray.char Bigarray.c_layout or
> similar...

Strings are represented as normal OCaml values within the OCaml heap,
whereas Bigarrays are simply pointers to externally allocated memory
(via malloc).  You do therefore need to copy across them in most cases.
One quick solution is to define a subset of the String module that uses
the Bigarray accessor functions, but this isn't ideal (especially when
external libraries that use strings are involved).

Your fusebuffer type probably means that you're working with filesystem
data.  Can you just use Bigarrays for everything, with copies to strings
only when you absolutely need to?  We haven't released this out of beta
yet, but the cstruct camlp4 extension helps map C structures to OCaml:
Later on, Anil Madhavapeddy added:
You should look at either Lwt or Core/Async, which both provide wrappers
over Bigarray, and asynchronous alternatives to using Unix and threads.


The choice between them depends on your situation.  Lwt is an add-on
library that interops with existing code well, whereas Core is a more
complete stdlib replacement (with vastly more features/datastructures).
ygrek then added:
There are also write/pwrite wrappers with bigarray argument in extunix -
Markus Mottl also replied:
The Core.Std.Bigstring-module offers a large number of Unix-I/O
functions for bigstrings, even for vectorized I/O (e.g. writev). I am
sure you will find everything you need there.
Goswin von Brederlow also suggested:
A Bigarray is a ocaml block with the dimension, size, proxy object
(for sub arrays) and pointer to the data.

A string on the other hand is a ocaml block with bytes directly in it.

Now if you allocate the memory for a Bigarray you can add a bit extra
in front so you can also access the array as string. But you run into
problems with the GC. Because it might want to free the Bigarrays
while something still holds a reference to the string. So realy not a
good idea.

Since you seem to want to use fuse and bigarrays to implement a
filesystem you might want to take a look at:

- ExtUnix:
type buffer = (int, Bigarray.int8_unsigned_elt, Bigarray.c_layout) Bigarray.Array1.t

- ExtUnix.BA:
val pread : Unix.file_descr -> int -> ExtUnixSpecific.buffer -> int
val pwrite : Unix.file_descr -> int -> ExtUnixSpecific.buffer -> int
val read : Unix.file_descr -> ExtUnixSpecific.buffer -> int
val write : Unix.file_descr -> ExtUnixSpecific.buffer -> int
val get_substr : ExtUnixSpecific.buffer -> int -> int -> string
val set_substr : ExtUnixSpecific.buffer -> int -> string -> unit

- ExtUnix.BA.BigEndian
- ExtUnix.BA.LittleEndian
- ExtUnix.BA.HostEndian

- libaio-ocaml:;a=summary
	pkg-ocaml-maint/packages/libaio-ocaml.git on
	Bindings for Linux async IO library (libaio)

- libfuse-ocaml:;a=summary
	pkg-ocaml-maint/packages/libfuse-ocaml.git on
	Bindings for libfuse

The fuse bindings are for the lowlevel interface and geared towards
async IO. I already convert filenames to strings. Or the stat
structures to Bigarray on replies and so on. All of those are
comparatively small so copying seems OK. The read callback always uses
Bigarray and the write callback reply with string, string array,
Bigarray or Bigarray array.

I've managed to merge the Bigarray and endian stuff from libaio-ocaml
and libfuse-ocaml in extunix but I haven't yet updated libaio-ocaml
and libfuse-ocaml to make use of that. So if you plan to use either of
those for real let me know and I will find some time to update them. I
plan to do that soon and get them added to Debian proper now that
wheezy is released anyway.

Also if you want to add bindings for the high level fuse interface,
implement a high level interface in ocaml directly or add a
multithreaded main loop I wouldn't mind patches to that affect.

smarter #load directive


Francois Berenger asked:
Was this integrated in the subversion trunk?

I mean the
#load "";;
that creates a Toto module automatically.
Gabriel Scherer replied:
Following the caml-list discussion, and PR submission #5825 by
Grégoire Henry (with a patch!), the directive #mod_use "" was
added in trunk last November.

It does not correspond to "load" because the module is not compiled
using ocamlc (no .cmo is produced), but compiled by the toplevel in
the current toplevel environment. The current implementation is a bit
hackish, I think, and in particular toplevel directives are not
allowed inside -- I think they even are silently dropped. It
behaves exactly as if you entered "module Foo = <content of
(minus toplevel directives)> end;;" directly in the toplevel.

New OCaml-Paris meetup on May 21, 19h30, IRILL


Fabrice Le Fessant announced:
  We are happy to announce a new meetup of OCaml-Paris, next week, on May 21, at
IRILL (Paris 13th). Everybody is welcome of course, as long as you understand
some French...

Here is the current schedule of the meeting (in French):

19h30-19h40 : Intro et nouvelles
19h40-20h05 : Esther Baruk : LexiFi: usage d'OCaml pour décrire des contrats financiers
20h05-20h30 : Gabriel Scherer : comment mieux interagir avec l'équipe du noyau d'OCaml
20h30-20h55 : Benoît Vaugon : que peut-on faire avec le bytecode d'OCaml ?
20h55-21h20 : Frédéric Bour : Merlin, un IDE OCaml pour VIM
(reporté)  Pierre Chambart : les GADT dans la pratique
21h20-21h30 : Discussions ouvertes/démos flash
21h30 : Pizzas

You should register online so that we can order enough pizzas for everybody !
The Meetup site is here:

If you want to use the event for some announcements, we can schedule flash talks
at the end of the meeting, just tell me !

oasis help: support for qtest in oasis


Francois Berenger asked and Sylvain Le Gall replied:
> Is there some way to plug qtest into
> an oasis-managed project?
> My current problem is that qtest
> generates the (for example) file to run the tests
> and I don't want to add this file under VC
> so oasis should allow me to run a command
> to create this file before it is compiled.

I don't know how qtest works, but I would say, that you should use
This is a toplevel field and you can surround it with conditional:

if flag(tests)
PreBuildCommand: foo-bar --output

Is this what you want ?

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.7 available:

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