Previous week Up Next week


Here is the latest Caml Weekly News, for the week of March 05 to 12, 2013.

  1. Commercial Users of Functional Programming 2013
  2. OPAM mailing-lists ERRATUM
  3. Barista 2.0-beta release
  4. A brief guide to a bit of the OCaml type checker
  5. llpp v15
  6. [ocamlgraph] Johnson's algo, C-bindings, GraphML reader, edge dominators
  7. If you distribute oasis' with your software, please use a recent (>= 0.3.0) version of Oasis
  8. OpenGL Ocaml mailing-list
  9. Other Caml News

Commercial Users of Functional Programming 2013


Thomas Gazagnaire announced:
This year, CUFP 2013 will be in Boston (and it is still co-located with ICFP 
If you use OCaml (or any other functional language) for practical 
applications, then you should consider applying!

CUFP 2013
Boston, MA, United States
Sep 22-24
Talk Proposal Submission Deadline 29 June 2013
Co-located with ICFP 2013
Sponsored by SIGPLAN

The annual CUFP workshop is a place where people can see how others
are using functional programming to solve real world problems; where
practitioners meet and collaborate; where language designers and users
can share ideas about the future of their favorite language; and where
one can learn practical techniques and approaches for putting
functional programming to work.

Giving a CUFP Talk

If you have experience using functional languages in a practical
setting, we invite you to submit a proposal to give a talk at the
workshop. We are looking for both experience reports and
in-depth technical talks.

Experience reports are typically 25 minutes long (but negotiable), and
aim to inform participants about how functional programming plays out
in real-world applications, focusing especially on lessons learned and
insights gained. Experience reports don't need to be highly technical;
reflections on the commercial, management, or software engineering
aspects are, if anything, more important.

Technical talks are also 25 minutes long (also negotiable), and should
focus on teaching the audience something about a particular technique
or methodology, from the point of view of someone who has seen it play
out in practice. These talks could cover anything from techniques for
building functional concurrent applications, to managing dynamic
reconfigurations, to design recipes for using types effectively in
large-scale applications. While these talks will often be based on a
particular language, they should be accessible to a broad range of

If you are interested in offering a talk, or nominating someone to do
so, send an e-mail to marius(at)twitter(dot)com or
sperber(at)deinprogramm(dot)de or by 29 June 2013 with a short
description of what you'd like to talk about or what you think your
nominee should give a talk about. Such descriptions should be about
one page long.

There will be a short scribes report of the presentations and
discussions but not of the details of individual talks, as the meeting
is intended to be more a discussion forum than a technical
interchange. You do not need to submit a paper, just a proposal for
your talk! Note that we will need all presenters to register for the
CUFP workshop and travel to Boston at their own expense.

Program Committee

Marius Eriksen (Twitter, Inc.), co-chair
Mike Sperber (Active Group), co-chair
Mary Sheeran (Chalmers)
Andres Löh (Well-Typed)
Thomas Gazagnaire (OCamlPro)
Steve Vinoski (Basho)
Jorge Ortiz (Foursquare, Inc.)
Blake Matheny (Tumblr, Inc.)
Simon Marlow (Facebook, Inc.)

More information

For more information on CUFP, including videos of presentations from
previous years, take a look at the CUFP website at Note that presenters, like other attendees, will need
to register for the event. Presentations will be video taped and
presenters will be expected to sign an ACM copyright release
form. Acceptance and rejection letters will be sent out by July 16th.

Guidance on giving a great CUFP talk

Focus on the interesting bits: Think about what will distinguish your
talk, and what will engage the audience, and focus there. There are a
number of places to look for those interesting bits.

Setting: FP is pretty well established in some areas, including
formal verification, financial processing and server-side
web-services. An unusual setting can be a source of interest. If
you're deploying FP-based mobile UIs or building servers on oil
rigs, then the challenges of that scenario are worth focusing
on. Did FP help or hinder in adapting to the setting?

Technology: The CUFP audience is hungry to learn about how FP
techniques work in practice. What design patterns have you
applied, and to what areas? Did you use functional reactive
programming for user interfaces, or DSLs for playing chess, or
fault-tolerant actors for large scale geological data processing? 
Teach us something about the techniques you used, and why we
should consider using them ourselves.

Getting things done: How did you deal with large software
development in the absence of a myriad of pre-existing support
that are often expected in larger commercial environments (IDEs,
coverage tools, debuggers, profilers) and without larger, proven
bodies of libraries? Did you hit any brick walls that required
support from the community?

Don't just be a cheerleader: It's easy to write a rah-rah talk
about how well FP worked for you, but CUFP is more interesting
when the talks also spend time on what doesn't work. Even when the
results were all great, you should spend more time on the
challenges along the way than on the parts that went smoothly.

OPAM mailing-lists ERRATUM


Fabrice Le Fessant announced:
Finally, there will be only one mailing-list devoted to OPAM (for both
users and developers discussions), it is now opam-devel AT, and you can subscribe on this page:

Barista 2.0-beta release


Xavier Clerc announced:
This post announces the 2.0-beta release of the Barista project, whose
goal is to provide a library for Java class file construction and a
Java [dis]assembler, released under the LGPLv3. Since, the previous
version is almost one-year old, this version brings a lot of changes.

Home page:
Forge page:

Main changes since 2.0-alpha3:
- update for Objective Caml 4.00.1
- update for Camlzip 1.05
- new 'graph' command, allowing to generate the graph of classes references
from a list of archives (supported file formats: Dot, GEXF, and GraphML)
- new 'Lookup' module allowing to search for Java elements (classes,
constructors, fields, and methods) from string queries
- new 'Manifest' module providing support for archive manifest files
- new 'ArchiveBuilder' module allowing to construct archives from classes,
and handling manifest, services, and copy from other archives
- the 'flow' command can now generate output to either GEXF, or GraphML, in
addition to Dot
- improved handling of classpaths
- improved performance for class encoding (about 50% speed-up)
- improved performance for stack state computations (about 30% speed-up)
- optimization of switches (turning lookup switches into table
switches if it saves some place)
- new peephole optimizations, in order to avoid simple conversions of
- API CHANGE: class types for 'traversal' objects enhanced with new methods
- API CHANGE: 'Traversal' module renamed to 'ClassTraversal'
- new 'traversal' class type allowing to fold over class elements
- new 'ArchiveTraversal' module allowing to traverse archives
- bug: incorrect handling of some 'package-info' class files
- bug #86: '-ocaml-prefix' doesn't really work
- bug #87: install shouldn't build anything
- bug #89: do not activate warnings by default
- bug #104: configure script should be executable
- bug #110: error in annotation encoding of string value
- bug #111: invalid stack frame when locals are changed in a protected block
- bug #116: invalid stack frame after "invokespecial" instruction

A brief guide to a bit of the OCaml type checker


oleg announced:
When studying the OCaml type checker I have come across an elegant but
seemingly little known type generalization algorithm based on type
levels. Interestingly, the same levels also help type check local
modules, existentials, and polymorphic records. I am thankful to
Didier Rémy, the discoverer of the algorithm, for describing the
bigger picture, sharing intuitions and history, and pointing out more
applications of the type levels (e.g., MLF).

The following web page

attempts to popularize the algorithm, explain it on toy type checkers
and describe its implementation in the OCaml type checker. Hopefully
one might get a better idea what the OCaml type checker is really

llpp v15


malc announced:
New version of llpp (tagged v15) is now available at


llpp a graphical PDF viewer which aims to superficially resemble


* Proper subject line in the announcement message
* Bugfixes
* Synced with post 1.2 MuPDF (a lot of security holes plugged)
* Workaround for bug (stippling) in Intel's HD graphics drivers
* now fetches thirdparty modules directly instead of
relying on mupdf-thirdparty archive

[ocamlgraph] Johnson's algo, C-bindings, GraphML reader, edge dominators


Johannes Schauer announced:
it appears that ocamlgraph doesnt have a mailinglist and while I could've just
bothered the three developers is person I thought I might get more input by
writing to this list. :)

Johnson's Algorithm

I fixed an implementation by Pietro Abate of Johnson's algorithm for
enumerating elementary circuits in a directed graph. He first demonstrated his
solution here:

The fixed version can be found in this git repository:

I tested that implementation against several other implementations for cycle

- An extended version of Johnson's algo by K.A. Hawick and H.A. James in D
- Johnson's algo by F. Meyer in Java
- Johnson's algo as part of networkx in Python
- My own implementation of Tarjan's algorithm in Python

The whole testing framework sits at

We use the implementation of Johnson's algorithm in Ocaml by P. Abate and
myself with the additional feature to (optionally) only enumerate cycles up to
a given length. The (still generic) version of the Ocaml implementation can be
found at:

So maybe it would be useful to integrate this into ocamlgraph?

Using Ocamlgraph from C

My ocaml code heavily uses ocamlgraph. I was asked to write a Python binding
for my code but I thought that it would make more sense to allow my code to be
used from C because every other language has some way to make use of C
libraries. For example it would then be straight forward to use Python ctypes
for a Python binding.

So is there some existing code that allows ocamlgraph based code to be used
from C where I could get some inspiration from how to best do the
implementation and build system?

GraphML reader

Pietro Abate recently contributed a GraphML writer to ocamlgraph. I'm
tempted to write a GraphML reader but should I accomplish to do this,
it would make most sense if the result could also be integrated into
ocamlgraph. GraphML is XML based, so what XML reader library would the
ocamlgraph authors prefer I use for that task?

Edge dominators

The current implementation of dominators in ocamlgraph only computes
vertex dominators. I also need edge dominators. When I implemented to
also calculate those, how would the ocamlgraph maintainers like my
contribution? Just an email to all three developers listed on the
website? I'm a bit puzzled because I'm not used to sending code to
individuals instead of mailing lists or bug trackers and also because
the link to on the front page Julien Signoles gives a 404.

If you distribute oasis' with your software, please use a recent (>= 0.3.0) version of Oasis


Gabriel Scherer explained:
The number of packages available through OPAM that list "oasis" as a
dependency (see list below) is too high -- oasis being designed to let
developers pre-generate to avoid any actual dependency on it.

The reason for this is a glitch in old versions of Oasis (< 0.3.0)
that makes the generated break with OCaml >= 4.00.0; OPAM
packagers list oasis as a dependency to regenerate a fixed at
compilation time. This is the case in particular for the latest
versions of the following packages:
- ANSITerminal*
- bench*
- ocaml-expect
- ocaml-posix-resource
- ocaml-radixtree
- ocaml-sqlexpr
- optimization1d*
- root1d*

(*): oasis is the only dependency besides the ubiquitous ocamlfind

If you distribute in your source releases, please make sure
that it is generated with a recent version of Oasis (>= 0.3.0). This
allows to remove oasis (and its four own dependencies) from the
dependencies of your package.

You can check which version of Oasis a given comes from with
the command:
ocaml -version

If your package provides a with version >= 0.3.0, and "oasis
setup" is still present in the "build" field of OPAM metadata
description (or "oasis" marked as a dependency for no other reason),
this is a packaging bug that you should report to the relevant package
maintainer or on the opam repository bugtracker ( ).

PS: I learned about the bad interaction between Oasis < 0.3.0 and
OCaml >= 4.00.0 from Anil Madhavapeddy in the following bugtracker
Christophe Troestler replied:
Note that, for now, you must include

    let () =
      try Topdirs.dir_directory (Sys.getenv "OCAML_TOPLEVEL_PATH")
      with Not_found -> ();;

at the beginning of (before (* OASIS_START *)) in order for to run with the dynamic mode during development.  This will
be automatically done by later versions of oasis.  I usually ship the
self-contained only in tarballs.
Wojciech Meyer also replied and Gabriel Scherer said:
> One of the reasons why people don't regenerate but rely on
> Oasis is very prosaic: some of the projects (if not most) are source
> hosted on github, but github does not host files, however git tags can be
> used to download the tarball using single URL.
> I'd add to Gabriel's suggestion to host these files somewhere, ocamlcore
> seems to be like a natural choice.

Indeed. The recommendation is rather orthogonal to the choice of
maintainers to distribute with they released tarball or not.
If they don't, fine, if they do, please distribute the
generated from a recent OASIS.

As a downstream user, I would have a preference for people to generate
the statically on their side (some less work and dependencies
for us users), but I understand that just tarballing the development
repository is a quick&easy way to push a release, made even easier by
github, so it's a reasonable choice -- and I understand that people
don't want to clutter their versioned repo with auto-generated files.

(The initial reason for my e-mail was benchmarking considerations:
we're considering using the OPAM compiler variant system to test
in-development branches of the OCaml compiler, which mean possibly
tight (edit, compile, opam install, benchmark) cycles. OPAM would be
used to install just what's needed for the benchmarks, so maybe one
library or two but mostly only the benchmarking library. In this
context, it's important to have as few dependencies as possible, and
I'm eager to remove the "oasis" dependency of "bench" and
Maxence Guesdon then said:
Github can host a website for each project, using a gh-pages
branch, see

The website is then hosted on <yourlogin><yourproject>.
For example:

Then, using "git archive" command you can easily create an archive of
your sources, copy it into the gh-pages branch and upload it
(add+commit+push), making it available from your project website.

OpenGL Ocaml mailing-list


Anil Madhavapeddy announced:
I've created:

as requested. Enjoy!

Other Caml News

From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to the
recent posts from the ocamlcore planet blog at

Adding namespaces to OCaml:

Barista: 2.0-beta:

Barista 2.0-beta:

Jane Street's core library 109.11.00:


A library to record OCaml backtraces:

Opa 1.1.1 is coming soon. The book is here.:

ocaml hash function and complex data structures:

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