Here is the latest Caml Weekly News, for the week of May 07 to 14, 2013.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00026.htmlygrek announced:
New release of extlib is out - fixing installation problems only. Get it as usual at http://code.google.com/p/ocaml-extlib/
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00024.htmlFrancois 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. https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.mli?view=markup&revision=94&root=glmlite https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.mli?view=markup&root=glmlite https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.ml?view=markup&revision=94&root=glmlite https://forge.ocamlcore.org/scm/viewvc.php/trunk/TEST3/ogl_matrix.ml?view=markup&root=glmlite 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. http://www.linux-nantes.org/%7Efmonnier/ocaml/GL/fc/code/ogl_matrix.ml.xhtml http://www.linux-nantes.org/%7Efmonnier/ocaml/GL/fc/code/ 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 change. The current documentation of gg can be found here , the code can be browsed here . It can also be installed via the erratique-unstable opam repo: opam repo add erratique-unstable http://erratique.ch/software/opam-unstable opam update opam install gg But I'd advise you not to that until the next release of opam because of this bug  which while harmless makes your `opam update` experience become unpleasant (you have to do a `opam remove gg`, before being able to `opam update`). Comments are welcome. Best, Daniel  http://erratique.ch/software/gg/doc/Gg.html  https://github.com/dbuenzli/gg/  https://github.com/OCamlPro/opam/issues/552rixed also replied:
For what it's worth, I also did a small 2d vector library 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). : http://gitorious.org/ocalme/geomFrancois Berenger added:
By the way, I just saw in OPAM that there are bindings to cairo, which looks quite nice for 2D vector graphics.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00027.htmlGoswin 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 (Core.Std.Linux_ext.Epoll).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: https://github.com/pmundkur/sonet/blob/master/eventloop/epoll_stubs.cGerd Stolpmann also replied:
There is also some support in Ocamlnet: http://projects.camlcity.org/projects/dl/ocamlnet-3.6.3/doc/html-main/Netsys_posix.html#1_Eventaggregation
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00033.htmlMilan 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: http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc76 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);;
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00037.htmlDmitrii Kosarev announced:
I'm ready to share y experience about this topic. To build it you can use './configure' from https://github.com/Kakadu/lablqt/tree/qml-dev/qml . 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 : http://www.typerex.org/ocplib-wxOCaml.htmlDmitrii Kosarev then said:
I've added small introduction to OCaml+QtQuick https://github.com/Kakadu/lablqt/wiki/Using-mocml-with-QtQuick
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00040.htmlTom 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: https://github.com/mirage/ocaml-cstructLater 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. Lwt_bytes: http://ocsigen.org/lwt/api/Lwt_bytes Bigstring: https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Bigstring.html 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 - http://extunix.forge.ocamlcore.org/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: http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=libaio-ocaml/libaio-ocaml.git;a=summary pkg-ocaml-maint/packages/libaio-ocaml.git on git.debian.org Bindings for Linux async IO library (libaio) - libfuse-ocaml: http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=libfuse-ocaml/libfuse-ocaml.git;a=summary pkg-ocaml-maint/packages/libfuse-ocaml.git on git.debian.org 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.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00065.htmlFrancois Berenger asked:
Was this integrated in the subversion trunk? I mean the #load "toto.ml";; 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 "foo.ml" 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 foo.ml -- I think they even are silently dropped. It behaves exactly as if you entered "module Foo = <content of foo.ml (minus toplevel directives)> end;;" directly in the toplevel.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00074.htmlFabrice 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: http://www.meetup.com/ocaml-paris/ If you want to use the event for some announcements, we can schedule flash talks at the end of the meeting, just tell me !
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2013-05/msg00077.htmlFrancois 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 main.ml (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 PreBuildCommand http://oasis.forge.ocamlcore.org/MANUAL.html#package This is a toplevel field and you can surround it with conditional: if flag(tests) PreBuildCommand: foo-bar --output main.ml Is this what you want ?
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the recent posts from the ocamlcore planet blog at http://planet.ocaml.org/. OCaml MySQL Protocol 0.7 available: https://forge.ocamlcore.org/forum/forum.php?forum_id=876
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.