[cwn] Attn: Development Editor, Latest Caml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Mon Sep 17 23:15:12 PDT 2007
Hello,
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
========================================================================
1) Making OS X universal binaries
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
a9cf100cb523b65a/c6c8a8424d7fcb90#c6c8a8424d7fcb90>
------------------------------------------------------------------------
** 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/
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.
========================================================================
2) XenSource seeking OCaml hackers
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
5b3755174580829e/7ea42655927e438e#7ea42655927e438e>
------------------------------------------------------------------------
** 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
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 at xensource.com
if you would like to have a chat and get more information.
========================================================================
3) Paper on asynchronous exceptions
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
af09dd4c4cc05af1/55c894fa55672c2f#55c894fa55672c2f>
------------------------------------------------------------------------
** 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.
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},
}
========================================================================
4) XmlRpc-Light 0.5
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
6925354babb284e8/89f06a2f738dcaae#89f06a2f738dcaae>
------------------------------------------------------------------------
** 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.
<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.
========================================================================
5) coThreads 0.10
Archive: <http://groups.google.com/group/fa.caml/browse_frm/thread/
c0bb621b9d3c91ad/34ffa30420633f18#34ffa30420633f18>
------------------------------------------------------------------------
** 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 <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/pitfall>
** 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}$'?'<1':1
zM
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
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take
a look at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
========================================================================
--
Alan Schmitt <http://alan.petitepomme.net/>
The hacker: someone who figured things out and made something cool
happen.
.O.
..O
OOO
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20070918/34c642a1/attachment.pgp
More information about the caml-news-weekly
mailing list