Previous week Up Next week


Here is the latest Caml Weekly News, for the week of April 29 to May 06, 2008.

  1. ocaml-gettext v0.3.0
  2. Core has landed

ocaml-gettext v0.3.0


Sylvain Le Gall announced:
ocaml-gettext is a library that enables string translation in OCaml.
The API is based on GNU gettext. It comes with a tool to extract
the string which needs to be translated from OCaml source file.

This enable OCaml program to output string in the native language of the
user (if you also provide a file containing the translation of the
english string contains in the program to the one in the native language
of the user).

The translation is based on string (this means that you need to provide a
string and not a unique identifier, like in some other catalog system).
This string is in english, and will be returned if the native language
of the user doesn't have translation catalog.

v 0.3.0 has been long awaited but is now ready. It fix a lot of bugs
concerning merging PO and POT file (multiline comments, UTF-8...). This
is also the first release that works with camlp4 3.10. 

This new version doesn't need camlidl and ocaml-ast-analyze anymore, in
order to simplify installation. When building, it is also possible to
not use Camomile in favor of a simple gettext C library.


Core has landed


Yaron Minsky announced, spawning a huge thread:
We are proud to announce the first public release of core, Jane
Street's own alternative to OCaml's standard library.  We use this
library as the base for our own development, and we hope people on the
outside will find some use for it as well.

People should be warned that core is still in flux: there are
interfaces that we have plans to change, so if you're not willing to
come along for the ride, you shouldn't use it.  Also, be warned that
conformance with the OCaml standard library is not a goal, and we have
already deviated from it in a number of ways.  It's also worth noting
that we have only used and tested this library on x86 and x86-64 on
Linux, and we make no claims about other platforms.

You can find the library here:

along with three other libraries that you will need to use along with
it: type-conv, sexplib and bin-prot.  These three libraries
provide macros for generating functions for serializing and
deserializing types. sexplib uses a human-readable s-expression
format, and bin-prot uses a high-performance binary protocol, and
type-conv is the common base of the other two libraries.  This is
also the first public release of bin-prot, and like sexplib, that
library can be used independently of core.

If you have any comments or patches, we'd love to hear about it.  Our
blog is a great place for comments:

and patches should be sent to

All of the released libraries are licensed under the
LGPL-plus-linking-exception that is used by the OCaml standard
Richard Jones added:
Thanks - I think this is an impressive contribution to OCaml & open
source.  For those not aware of the full extent of this library, I
went through and noted down this non-exhaustive list of features:

- Bag (set type with duplicates)
- Bigbuffer (unlimited Buffer type)
- Bigstring (unlimited String type)
- 8/16/32/64-bit signed/unsigned binary packing functions
- Bool type
- Safe finalization for reading/writing files
- Function composition operators
- Enhanced versions of stdlib modules such as Arg, Array, Printf, etc.
- Mutexes
- CRC functions
- Dequeue type
- Doubly-linked list type
- Enhanced exception module
- Fast hash table
- Force once (thunk that can be forced only once)
- Functional queue type
- Min-heap type
- Enhanced input/output channels
- Closed interval type
- Interval set type
- Read files as lines
- Linux-specific syscalls such as sendfile, get/set TCP options, epoll,
- Memoization
- Piece-wise linear interpolation of floats
- Polymorphic map and set
- Find size of OCaml structures
- Space-efficient tuples
- Synchronized queues
- Thread-safe queues
- Convenience functions for Unix times
- Timed events
- Tuple convenience functions
- Extended Unix module filling in some missing syscalls such as
  sync, getrusage, inigroups, etc.

There's a Fedora package here:

but note you will also need these dependencies:

It would be nice to have bin-prot working on all architectures ...
Markus Mottl replied:
>  It would be nice to have bin-prot working on all architectures ... 

The biggest obstacle to this is that the current implementation 
assumes little endian machines.  Both 64bit and 32bit are fully 
supported on these platforms.  It would certainly be possible to 
support other architectures, but good portability and performance are 
not easily combined here.  If performance does not matter, it would be 
easiest to just convert all data to the protocol already used by 
little endian machines.  This would noticably slow down communication 
with/among machines that are not little endians.  Since the vast 
majority of computers are little endians, this won't matter for most 
people.  OCaml takes a similar approach. 

Note that communication _among_ machines with different endianness, 
assuming that they all have the same byte layout, should work, too, 
with the current binary protocol.  At least if you do not mix 32/64bit 
machines there...
Stefano Zacchiroli then said and Markus Mottl replied:
>  Sounds like a reasonable solution indeed. Way better than not having 
>  bin-prot on some archs (this is particularly annoying in Debian, where 
>  we support several big endian machines; the status quo would mean no 
>  Core on them and in turn no application using Core on them. Currently we 
>  patched Core on that architecture to remove the bin-prot dependency, but 
>  is a rather hackish solution I would like to get rid off). 

>  Do you plan to implement such a solution in forthcoming releases? 

We currently do not have any immediate need and man power to fully 
support big-endian machines (we also don't have access to any), but 
we'll gladly accept patches.  This could be implemented using 
platform-specific macros as is the case with 32/64bit. 

This is what works / doesn't work as of now: 

  *) Big-endian and little-endian machines cannot communicate with 
each other for anything but very specific cases.  Don't use the binary 
protocol in such heterogeneous environments. 

  *) 32 and 64 bit, little-endian architectures can communicate 
freely, assuming, of course, that integers do not overflow on 32bit. 
This is tested at runtime to prevent hard to debug errors. 

  *) 32bit big-endian machines can communicate with each other freely. 
 64 bit big-endians can communicate with each other freely, too, but 
not necessarily with 32bit big-endians: values of type int64, etc., 
may not necessarily be communicated correctly.  Note, too, that you 
should exclusively use the automatically generated converters on 
big-endian machines.  The hand-written (slower) ones for the basic 
types are intended mostly for testing purposes only, and will not work 
when mixed with a different endianness (they assume little-endians). 

Thus, it certainly makes sense to package the binary protocol for 
big-endians, too, as long as people are informed of what works.  Since 
almost nobody uses big-endian machines, most users won't care.  But 
I'd surely be happy to see a patch to fully support all 
Following a comment on the absence of a Windows port, Yaron Minsky said:
Agreed.  We have a limited amount of energy to devote to a Windows port at 
this time, but we would be happy for core to work well on Windows.  Most of 
the library depends only on the version of OCaml, so it should be pretty 
easy to port.  We've done a bit of ifdef work to make it a tad more portable 
(it's known to compile so far on FC5, Centos/RHE 4 and 5, and OS X.)

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