Hello
Here is the latest Caml Weekly News, for the week of September 11 to 18, 2007.
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/ ocamlppc. 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 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 context. For more information on XenSource and to play with our products, check out: http://www.xensource.com/ Drop me a line off-list at: Anil Madhavapeddy anil@xensource.com if you would like to have a chat and get more information.
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.
Best,
Daniel
[1]
@inproceedings{378858,
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 = {http://doi.acm.org/10.1145/378795.378858},
publisher = {ACM Press},
address = {New York, NY, USA},
}
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.
http://code.google.com/p/xmlrpc-light/
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
noes!"];;
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.
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 http://cothreads.sourceforge.net 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. Enjoy. [1] http://www.pps.jussieu.fr/~li/software/index.html#stmlib [2] http://code.google.com/soc/2007/ [3] http://fsij.org [4] http://www.pps.jussieu.fr/~li/software/index.html#vprint >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 modification * 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: http://cothreads.sourceforge.net/doc/pitfallSkaller 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.
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
zM
If you know of a better way, please let me know.
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.