Hello

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

1. OCaml Meeting 2009 in Grenoble -- subscription open
2. More cores
3. camlp4 vs camlp5
4. OCamlSpotter: OCaml compiler extension for source browsing, version 1.0
5. LablGL 1.03
6. LablGtk 2.12.0

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
			

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
			

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
			

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
			

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.
			

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