Previous week Up Next week


Here is the latest Caml Weekly News, for the week of September 11 to 18, 2007.

  1. Making OS X universal binaries
  2. XenSource seeking OCaml hackers
  3. Paper on asynchronous exceptions
  4. XmlRpc-Light 0.5
  5. coThreads 0.10

Making OS X universal binaries


Richard Bornat said:
I have a need to build a OS X universal binary of an OCaml program. I   
found out how to do it (apologies if this is already posted, but I   
couldn't find a solution in the archives). 

1. Install the PowerPC version of OCaml. Squirrel away /usr/local/bin/ 
ocamlopt and /usr/local/lib/ocaml (I just added ppc to their names). 

2. Install the Intel version of OCaml. 

3. To make a ppc version of the program, compile with /usr/local/bin/ 
ocamloptppc (no need to add any extra arguments), and link with /usr/ 
local/bin/ocamloptppc -ccopt "-arch ppc" -nostdlib -I /usr/local/lib/ 

That's it. When you've made both versions, merge them with lipo. ppc   
compilation and loading is a bit slow, but that's the only drawback   
I've found.

XenSource seeking OCaml hackers


Anil Madhavapeddy announced:
XenSource is a dynamic, fast-growing software company that develops 
Linux/Windows virtualisation products on top of the open-source 
Xen hypervisor. Our most recent product, XenEnterprise v4, sports a 
high-performance, fully-featured virtualisation control plane implemented 
in OCaml. To help us achieve our goal of delivering high-quality, 
exciting features and supporting an ever-growing customer base, we are 
looking to hire black-belt OCaml programmers to join our established 
team of talented and motivated engineers. 

Our code base is significant: over 100,000 lines of OCaml which solves 
problems ranging from the low-level (Xen hypercalls), to the high-level 
(resource pool management), to the compiler-driven (generating language 
bindings for our Xen datamodel). 

Our ideal candidate will have: 

* significant experience of OCaml programming 

* an aptitude for implementing (and reasoning about) complex concurrent, 
distributed systems 

* the skills required to contribute to both the architectural design 
and day-to-day development of a large code-base 

* strong communication skills and problem solving ability 

* a determination to deliver great products that perform brilliantly 
and meet our customers' needs 

So if you want to hack OCaml professionally, tackle interesting and 
challenging programming problems and contribute to an innovative product 
that is already used by thousands of customers across the world, please 
don't hesitate to contact us. We are interested in applicants from both 
research and industrial backgrounds. 

XenSource has also joined the Caml Consortium to underline our committment 
to using state-of-the-art languages such as OCaml in a wider industrial 

For more information on XenSource and to play with our products, 
check out: 

Drop me a line off-list at: Anil Madhavapeddy
if you would like to have a chat and get more information.

Paper on asynchronous exceptions


Daniel Bünzli:
For the sake of completeness. After the discussion on thread   
cancellation a friend of mine pointed me to this [1] paper. It   
describes the design, semantics and implementation of a raise_in   
operation in Haskell. 

The paper does a good job in describing the problems of this   
operation. It also shows how to solve them by introducing two   
combinators to unconditionally block or unblock asynchronous   
exceptions in a given scope. 



  author = {Simon Marlow and Simon Peyton Jones and Andrew Moran and   
John Reppy}, 
  title = {Asynchronous exceptions in Haskell}, 
  booktitle = {PLDI '01: Proceedings of the ACM SIGPLAN 2001   
conference on Programming language design and implementation}, 
  year = {2001}, 
  isbn = {1-58113-414-2}, 
  pages = {274--285}, 
  location = {Snowbird, Utah, United States}, 
  doi = {}, 
  publisher = {ACM Press}, 
  address = {New York, NY, USA}, 

XmlRpc-Light 0.5


Dave Benjamin announced:
I'm happy to announce the release of version 0.5 of XmlRpc-Light. 
XmlRpc-Light is an XmlRpc library written in OCaml. It requires 
Xml-Light and Ocamlnet 2. 

New in version 0.5 

     * client: configurable socket timeouts 
     * client: basic authentication 
     * client: custom HTTP headers 
     * client: SSL support (requires command-line "curl" program) 
     * client: multicall class with optional lazy call behavior 
     * client: better interoperability with Apache XMLRPC 
     * client: code generation tool based on introspection functions 
     * server: methodHelp and methodSignature introspection functions 
     * server: shallow type checking of method signatures 
     * server: multiple signatures per method (overloading) 
     * both: proper text/xml Content-Type header and xml preamble 
     * both: 32-bit integer support 

This version features a convenience class for "multicall", a de-facto 
standard protocol for packaging multiple method calls together into a 
single request. It uses OCaml's lazy type to keep the interface very 
similar to regular method calls. Use of the lazy behavior is optional. 

Instances take an XmlRpc.client as an argument: 

         # let mc = new XmlRpc.multicall client;; 
         val mc : XmlRpc.multicall = <obj> 

The "call" method works like client#call, but it returns a lazy value: 

         # let a = mc#call "demo.addTwoNumbers" [`Int 3; `Int 4];; 
         val a : XmlRpc.value Lazy.t = <lazy> 
         # let b = mc#call "demo.addTwoNumbers" [`Int 42; `String "oh 
         val b : XmlRpc.value Lazy.t = <lazy> 
         # let c = mc#call "demo.addTwoNumbers" [`Double 3.0; `Double 4.0];; 
         val c : XmlRpc.value Lazy.t = <lazy> 

At this point, the call has not been executed yet: 

         # mc#executed;; 
         - : bool = false 

As soon as one of the return values is forced, the call is executed: 

         # Lazy.force a;; 
         -- : XmlRpc.value = `Int 7 
         # mc#executed;; 
         - : bool = true 

Once a call has been executed, this instance cannot be used to make any 
further calls; instead, a new multicall instance must be created: 

         # mc#call "demo.addTwoNumbers" [`Int 2; `Int 2];; 
         Exception: Failure "multicall#call: already executed". 

If an XmlRpc fault occurred, the exception will be thrown when the lazy 
value is forced: # Lazy.force b;; Exception: XmlRpc.Error (-32602, 
"server error. invalid method parameters"). ]} This will not prevent 
further methods from executing successfully: 

         # Lazy.force c;; 
         - : XmlRpc.value = `Double 7. 

It is possible for a multicall to be executed but not completed, for 
example if a transport occurs. Aside from catching the exception, the 
completed property indicates if the call actually went through or not: 

         # mc#completed;; 
         - : bool = true 

It is not necessary to use lazy values. Instead, the call can be 
executed explicitly, and the results can be retrieved by number: 

         # let mc = new XmlRpc.multicall client;; 
         val mc : XmlRpc.multicall = <obj> 
         # ignore (mc#call "demo.addTwoNumbers" [`Int 2; `Int 2]);; 
         -- : unit = () 
         # ignore (mc#call "demo.addTwoNumbers" [`Int 3; `Int 3]);; 
         -- : unit = () 
         # mc#result 1;; 
         -- : XmlRpc.value = `Int 6 

This release also includes a fix to the WordPress example code, thanks 
to Janne Hellsten. It has been tested with Ocamlnet 2.2.7 and 2.2.8, 
though the use of 2.2.8 or newer is recommended for correct behavior of 
the Netplex server.

coThreads 0.10


Zheng Li announced:
I'd like to announce the first public release of coThreads, a concurrent 
programming library for OCaml. 

It originated as STMlib [1], and was accepted as a Google Summer of Code 2007 
project [2] mentored by Yoriyuki Yamagata from the Free Software Initiative of 
Japan [3]. 

The official website of coThreads is where 
you can find the source code and some preliminary documents. It's a wiki-based 
website, so feel free to register and contribute. 

A byproduct of the project, the Vprint [4] module, was already announced 
independently a few weeks ago on this list.   



>From the README: 

=========================================================================== === 

= Description =   

coThreads is a concurrent programming library for OCaml. It enhances the 
Threads library of the standard OCaml distribution in two dimensions: 

* coThreads implements the same API of the standard Threads library on 
  different execution engines (process, netwoker(todo)), so that a single copy 
  of source code can be compiled and deployed to different environments without 
* coThreads is also a super set of the standard Threads library, with extra 
  components (STM etc.), functions (spawn etc.) and features (object-level 
  compatibility etc.) 

= Features = 

The design of coThreads brings several advantages: 

== Powerfulness ==   

* The process engine can give you real speedup on multi-core and 
  multi-processor machines, the networker engine (todo) will give you both 
  speedup and scalability. 
* Combining the original components from the Threads library and the newly 
  added ones, coThreads is a full-fledged toolbox covering two main concurrent 
  programming paradigms, namely shared-memory and message passing, with both 
  high-level and low-level constructors. 
* All constructors (e.g. thread, mutex, condition, event, channel, tvar, stm 
  etc.) are first class values that can be communicated and shared between 
  independent threads. 

== Compatibility ==   

* Full compatibility with the original Threads library (systhreads and 
  vmthreads), so that you can now deploy your legacy code to new environment 
  for free — without modifying source code, without learning something new. 
* Both source-level and object-level compatibility among different execution 
  engines, so that you can keep a single copy of source code as well as a 
  single copy of objects files. 

== Convenience ==   

* The full library is implemented in user-space, no modification to the OCaml 
compiler and runtime, so that you can use it as a set of plain modules. 
* Switching engines is as easy as changing the include paths of compilation, 
and it's quite easy to automate the building process over a set of engines 
(e.g. with lines of pattern rules in your Makefile)
Skaller asked and Zheng Li answered:
> > * The process engine can give you real speedup on multi-core and 
> >   multi-processor machines, the networker engine (todo) will give you both 
> >   speedup and scalability. 
> I'm curious how this can be possible**.. is this only with the message 
> passing model? 
> ** Since Ocaml can't multi-process and neither the compiler 
> nor library are modified .. 

Well, in order to have semantic consistency among different engines without 
modifying standard OCaml itself, shard-memory style concurrency should only be 
achieved through the STM module. It's documented in the pitfall pages:
Skaller then asked and Zheng Li answered:
> Yes but what I'm getting at is the claim of multi-processing, 
> which Ocaml 3.10 at least cannot do. If you run Ocaml on a multi-core 
> machine, even if you have 8 cores and 8 threads, one on each core, 
> only one will ever run at once, so there is no performance gain. 
> In fact, it will be slower than a single core. 

> If you are *enforcing* message passing and using separate processes 
> instead of threads, then 8 processes will run in parallel on 8 cores, 
> and you'll get roughly 8 times speedup. 

Yes, you are right. The process engine is implemented with process. That's how 
it can speedup and that's why it's called ``process engine''.   

> So I'm not asking about how to ensure the code is consistent 
> over the various models, but rather how you can get ANY genuine 
> concurrency WITHOUT using message passing and processes 
> (in which case the networking model should be easy to implement) 

I'm sorry if the document misleadingly made you think it get speedup without 
using process and message passing. Threads and related tools is just the 
abstract interface on which all engines agree, they implement it with various 
facilities from VM threads, system threads to  process or independent programs. 

> Whether you explicitly send messages or use transactional memory 
> or whatever to wrap the message passing isn't the question: 
> I can see how that can work. However note, the message passing 
> has to be used for immutable values too, if the threads are 
> represented by processes in separate address spaces. 

For immutable value, it's not different from the traditional threads, at least 
from the library users' point of view: if a variable is already inside the 
scope of a threads (i.e. it's global and created before launching the thread), 
there is no necessity to message passing it; if not, you should anyway do it 
explicitly even with the traditional threads.

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}$'?'&lt;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