Hello

Here is the latest Caml Weekly News, for the week of December 16 to 30, 2008.

OCaml Meeting 2009 in Grenoble -- subscription open

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/6ca934db724432fc#

For the second time, I am proud to invite all OCaml enthusiasts to join us at OCaml Meeting 2009 in Grenoble. This year event will be in Grenoble just after JFLA. We choose this location because a lot of OCaml enthusiasts will probably already been there and to avoid last year collision between the two events. The subscription is now open for participants. The fee are 32€ and cover the lunch. You should use the link provided on the wiki page to subscribe: http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009#Participants We are still looking for people wanting to give a talk around OCaml subjects and to volunteer to help to help before/during the event. The list of possible talks is actually: - OCamlCore.org news and projects - OCaml Batteries Included - Cameleon/Chamo - Delimited overloading Further information: http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009 You can also have a look at the other near-located event: http://jfla.inria.fr/2009 Regards, Sylvain Le Gall on behalf of the OCaml Meeting organization team

More cores

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/fb0c0fa0ca985555#

Is it time to start rethinking concurrency in OCaml? I have followed the argumentation of only using one native thread for the OCaml runtime. I can easily see how this can increase performance and simplify implementation. I can also see that spawning new processes makes sense, so you get a local heap for each task. However, as we move forward it seems that we will get more than a few cores on the same computational node according to the following article: Intel says to prepare for 'thousands of cores': http://news.cnet.com/8301-13924_3-9981760-64.html?part=rss&subj=news&tag=2547-1_3-0-20 As I see it, it is not feasible to spawn a new process with a local heap for each core, when the number of cores increases dramatically. I am not sure that a parallel GC is a sufficient solution either due to the high contention on memory, at least unless it provide some additional core affinity features. I believe some level of compiler support is needed in the not so distant future such that enough primitives are available to build powerful multi-core aware libraries. One approach could be micro heaps with core affinity and handle mutable memory specially.

That's a recurrent topic in this list. I'll summarise the arguments and save us all some time: i) Someone raises the issue that it's time for Ocaml to go multicore. ii) A few voices go "yeah!" and state that with a concurrent GC, Ocaml can take over the world. Their argument is as follows: 1) Ocaml gets a concurrent GC; 2) ... 3) Profit! iii) A voice of reason notes that the devil is in step 2) above. If your programming paradigm for concurrency is Threads+Mutexes, then you are exposing yourself to a world of pain in race conditions. At this point someone usually links to Xavier's standard speech on concurrency (which is a few years old, but as poignant now as it was then). iv) The voices from step ii) retort that they're über-programmers and that they can make perfectly scalable and race condition-free programmes with Threads+Mutexes if only they had a concurrent GC. v) The voice of reason remarks that one of the main reasons we all chose Ocaml is because the language ensures safe, resilient programmes. In a way it's the humble recognition that we are human, and that we make mistakes. Choosing the Threads+Mutexes path would be hubris and an abandonment of fundamental reasons why we chose Ocaml in the first place. While I tend to agree with viewpoints iii) and v), I do think a healthy discussion on the subject of multicore is in order. Though I suggest we focus the discussion on concurrency models that will allow us to take advantage of those multicores in a safe, sane manner: a) Could Jocaml be the future of Ocaml? b) How do we handle the global mutability issue?

Well, it's fun to join the old discussion in the new times. The fact that computers go multicore at a greater scale makes it recurrent. Erlang makes concurrency easy due to purity, and OCaml is famous for being eclectic. Why not embrace Erlang's model by imposing limitations on what can be in threads -- keeping them pure? Erlang model works and attracts people to functional programming in general. Even if some other model of concurrency prevails, it is interesting and useful to interop with Erlang easily. Here's what Erlang folks have started: http://code.google.com/p/erlocaml/ Doing this properly can solve a lot of needs out there, and bring lots of debugged, proven, high-quality concurrent server and communication code within reach.

Also worth reading is Ulrich Drepper's series on current and future system architectures. I've highlighted the important parts of this long series below, but you can find the complete list of links at the end of part 1. Part 1: http://lwn.net/Articles/250967/ Part 2, on CPU caches: http://lwn.net/Articles/252125/ Part 4, on NUMA: http://lwn.net/Articles/254445/ Part 8, on future technologies: http://lwn.net/Articles/258154/ Uli has recently been advocating languages like OCaml (+ fork, numactl and virtualization obviously) for future architectures which will involve massive numbers of cores and very long paths to main memory.

Not especially for multicore, but for parallel programming, this might be of interest: http://camlp3l.inria.fr/eng.htm (To mention this by me also is recurrent, as the thread we are in...) Ciao, Oliver P.S.: During the last multicore discussion, I found that link, but had not tried OCamlp3l. Now I think I will have more time and motivation and it could be compiled and installed without any problems with OCaml 3.10.2.

> Has anyone tried it with 3.11? > > I had an idea to try out some fork-based OCaml programming to exploit > the 4 & 8 core machines we have here, but maybe can try this instead. The prelude.ml project has some fork-based parallel functions for lists, arrays, strings and bigarrays: http://github.com/kig/preludeml/tree/master/prelude.ml While I have not tried OCamlp3l on 3.11 yet, my guess is that it would work. It is a pure-OCaml set of libraries along with some helper scripts/programs and as far as I know there is not any camlp4 involved. After speaking with the authors, the package does seem to be more focused on distributed computing than local parallelism. It is still possible to use it for local parallelism though. OCamlp3l is currently going through a rewrite as Camlp3l though the restructuring is not complete at this point. CVS repositories for both are here -- http://camlcvs.inria.fr/cgi-bin/cvsweb/bazar-ocaml/ Please let us know how it goes if you do try one or both of these out.

Here's a Fedora package: https://bugzilla.redhat.com/show_bug.cgi?id=477313 I don't think this is packaged in Debian yet, so I had to make a few decisions about packaging: - the ocamlfind name is 'preludeml' - the package name (in Fedora) is ocaml-preludeml - no upstream versions, so I packaged it as "version 0.1", dated 20080922

> OCaml is extremely bad at parallelism, even embarassingly parallel tasks > because OCaml still has to marshall all the data in a gather operation or > resort to manual memory management. Merjis implemented the Ancient module to handle this case, and we shared the code with an open source license so everyone can benefit: http://merjis.com/developers/ancient

camlp4 vs camlp5

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/23e0ce83a6f9598d#

OCaml 3.09 OCaml 3.10 OCaml 3.11 ..... + + + camlp4 -----+---> camlp4 was -----> camlp4 development --> "new" camlp4 \ rewritten continues \ \ \ not everyone agrees with the rewrite, so old camlp4 -----> camlp5 development continues as camlp5 All the distributions now ship OCaml, camlp4 and camlp5. This means you can continue to compile and use pre-3.10 software which relies on the old camlp4 (now called camlp5). Or you can use the new camlp4 which has some nice bits (like Reflective OCaml and the "scrap your boilerplate" stuff). The worst thing is the lack of good documentation for camlp4. The wiki is a good start (http://brion.inria.fr/gallium/index.php/Camlp4). I've said it before, there's a good book's worth of material in this subject. If you prefer looking at code, then take a look at: http://code.google.com/p/bitstring/ (camlp4) http://merjis.com/developers/pgocaml (camlp4) http://alain.frisch.fr/soft#openin (camlp4 & camlp5) http://martin.jambon.free.fr/micmatch.html (camlp5 & camlp4) http://martin.jambon.free.fr/extend-ocaml-syntax.html (camlp5) Actually, there's loads more projects here ... http://caml.inria.fr/cgi-bin/hump.en.cgi?sort=0&browse=92

OCamlSpotter: OCaml compiler extension for source browsing, version 1.0

Archive: http://groups.google.com/group/fa.caml/browse_thread/thread/fa755ee340f46ea5#

Here is your free holiday gift, OCamlSpotter version 1.0, a small patch for OCaml 3.11.0. OCamlSpotter : OCaml source browsing ==================================== Camel spotter: Oh, it was extremely interesting, very, very - quite... it was dull; dull, dull, dull, oh God it was dull. Sitting in the Waterloo waiting room. ... from You're No Fun Anymore, Monty Python's Flying Circus OCaml module language is powerful. So extremely powerful that you can be lost yourself easily inside a huge OCaml project with tons of modules. Spotting the definition of a variable is sometimes "extremely interesting". Let's see such an "exciting" example: include M open N open O let _ = f 1 Suppose you are not familiar with the function f and want to spot its definition. Where to find it? Just from the code you are looking at, it is not sure: if you are enough lucky it may be f in m.ml, n.ml or o.ml. Otherwise, it may be O.f in n.ml. Or probably N.O.f in m.ml. If you are unlucky and the project is so sophisticated, there could be complex module operations in m.ml (i.e includes, functor applications) and therefore the definition might be found somewhere completely unexpected. Module packing, module load paths and library installation without .ml files complicate the situation even worse. You first days after joining a large OCaml project should be this kind of manual value definition spotting with find + grep commands. Yes, actually it is very educational: you can learn a lot about the project struggling in the source tree (only if your collegues have organized things very well :-P), but it is still a dull job... To say short, OCamlSpotter is a tool which does this dull job automatically for you and permits your energy for something more "interesting" like Yeti spotting: - The -annot option of ocamlc and ocamlopt is extended and creates <module>.spot files (<module>.spit for .mli), which record the location information of the names defined and used in the module. - A small application ocamlspot provides automatic where-about spotting of the definition of the name you are interested in. - ocamlspot.el provides interactive ocaml-spotting of definition locations in emacs. - Interfaces for other editors such as vi can be built easily, if you want. Donwload ======= http://www.furuse.info/jun/hacks/ocamlspotter/ocamlspotter-1.0.tgz?attredirects=0

LablGL 1.03

Archive: http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgtk-list/473.txt

As often after an ocaml release, here is a new release of LablGL. The main changes are: 2008-12-21: * support windows compilation for ocaml 3.11 2008-10-25: * support Tcl/Tk 8.5 * require Raw.static in GlArray (reported by malc) * check for GL_ARB_texture_non_power_of_two in GlTex (reported by malc) 2008-01-10: * fix GlMap.eval_coord2 (reported by Florent Monnier) You can find it at: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgl.html There is a (semi-)binary release for windows, with both Togl and Glut support, that can be used directly with the OCaml MSVC or mingw ports. ocamlopt is supported too. Note that you cannot build yourself Togl support on mingw, as building the dll requires MSVC.

LablGtk 2.12.0

Archive: http://www.math.nagoya-u.ac.jp/~garrigue/soft/olabl/lablgtk-list/474.txt

Not so soon on the heels of ocaml 3.11, here is a new release of LablGtk2, the ocaml interface to the Gtk+2 GUI library and friends (glade, rsvg, gnomecanvas, gnomedruid, panel, gtkspell, gtksourceview.) This release is based on the gtk+-2.12.x series, hence the name. But it will work with older versions too. You can find it at: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html There is a (semi-)binary releases for windows, with glade and rsvg support, that can be used directly with the OCaml MSVC or mingw ports. ocamlopt is supported too. The main addition is support for custom tree models, but there are many smaller ones all over.

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 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