Previous week Up Next week


Here is the latest Caml Weekly News, for the week of February 28 to March 06, 2012.

  1. Release - A multi-process daemon framework
  2. OCamlnet-3.5.1
  3. Camlp5 6.04 - configurable name
  4. TypeRex release 1.0.0 candidate 2
  5. application scope for hashtable on weak pointers
  6. [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature?
  7. Commercial Users of Functional Programming 2012: Call for Presentations
  8. Other Caml News

Release - A multi-process daemon framework


Andre Nathan announced:
I've just created the Release repository on Github:

From the README:

  Release is a multi-process Lwt-enabled daemon framework for
  OCaml, providing facilities for type-safe inter-process
  communication and privilege-dropping.

  Its goal is to make it easy to write servers that are
  released from the calling terminal and to release root
  privileges when those are not necessary.

This is not yet a stable release and I'm still working on some features,
but any feedback would be much appreciated.



Gerd Stolpmann released:
There is a patch release available, 3.5.1, fixing a few errors, mostly

- Missing symbols on FreeBSD-9
- Missing symbols on Debian Wheezy (probably because of stricter 
- posix_spawn is disabled on Mac (for the time being until the problem
  can be further tracked down)
- Mac OS does not like fchmod on shared memory

Camlp5 6.04 - configurable name


Daniel de Rauglaudre announced:
New release of Camlp5 (6.04) where:

The *names* of all what are built (executables, library) are now
configurable, allowing to have 'strict' and 'transitional' modes
both installed in the same computer in different places.

    ./configure --strict
    make world.opt
    make install
    ./configure --transitional name=camlp5t
    make world.opt
    make install

In that case, executables in transitional mode are camlp5t, camlp5to,
camlp5tr and so on... and the library is installed in a directory
named camlp5t instead of camlp5. No conflict between the two modes.

Download at:

TypeRex release 1.0.0 candidate 2


Tiphaine Turpin announced:
This is time for a second release candidate for TypeRex, our new
OCaml development environment for Emacs. We want to thank the many early
adopters, for their useful feedback and encouraging comments.

The new version is available on TypeRex website at:

It fixes a number of issues, here is the list of changes:

- Improved performance on large libraries (lazy environments, more cache)
- Fixed encoding bug with 3bytes utf8 characters
- Use line/column positions instead of absolute bytes (fixes windows eol)
- More robust ml/mli switching (contributed by Wojciech Meyer)
- Fixed camlp4 first-class modules
- Compiles with 3.11.2 as claimed (no more 3.12 syntax in the code)
- Made the prefix key customizable (C-o by default)
- Added option --disable-version-check to configure script
- Source extensions customizable (e.g., .eliom), mlp included by default
- Allow to disable syntax coloring completely
- Applied Jun Furuse's indentation patch and changed a few defaults
- Use the caml-mode error regexp instead of tuareg's
- Fixed coloring of constructors in type definitions
- Fixed the crash when starting emacs on several files (>=3)
- Fixed wrapper for -a
- Less risky names in lisp code
- Slightly improved documentation (ocamlbuild, libraries, module packing)
- Tuareg actions use TypeRex stdlib path instead of hard-coded default

Summary of TypeRex features:

    * Improved syntax coloring
    * Auto-completion of identifiers (experimental)
    * Browsing of identifiers: show type and comment, go to definition,
      cycle between alternate definitions, and semantic grep;
    * Strictly semantic-preserving, local and whole-program refactoring:
          o renaming identifiers and compilation units
          o open elimination and reference simplification
    * Robust /w.r.t./ not-recompiled, possibly unsaved buffers
    * Scalable (used regularly on a few hundreds of source files)

application scope for hashtable on weak pointers


Philippe Strauss asked and Daniel Bünzli replied:
> I have a use case for an hashtable of values who'll needs to get aged and 
> removed after a while,

That's not a good use case for weak hash tables. I explain why in this answer 



Tiphaine Turpin also replied:
A value in a weak hash-table may be collected provided :
- it is not reachable (from the roots of the reachable heap, i.e., the
stack, C-registered pointers, etc.) except through paths having a
weak-pointer (which is the case for the weak hash-table)
- the triggering conditions for the GC are met.
A typical use-case is hash-consing (physical sharing of
structuraly-equal data, for memory-efficiency).

> my use case would be to first age out when a threshold of number of 
> bindings is reached, also, after some wall time, flush oldest entries 
> (LRU). 
Maybe you can have a "LRU-sorted" (normal) array of not-too-old data and
a weak array (or hash-table) of aged data that the GC may collect, if no
one else points to it, but which you can still use until the next collection

[community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature?


Gabriel Scherer asked, triggering a large thread:
In the process of discussing bug #5312, the caml team would like to
know if people still have use of the @responsefile feature under
windows. If not, it could be removed from the runtime -- that is from
all OCaml programs.

@responsefile is a feature/convention under Windows to provide files
containing command-line argument options; when a tool parses
command-line options and encounters a file name prefixed by a '@'
character, it expands its contents as if it were part of the
command-line invocation. This is used to circumvent the historically
fairly ridiculous limit on command-line length in the old ''.

The OCaml toolchain copes with @responsefile in two places -- as far
as I know, but I'm not familiar with anything Windows. First, when the
compiler invokes external tools (linkers, etc.) under Windows, it uses
a @responsefile if the command-line length exceeds a fixed limit --
curently 4096, used to be 256 and annoy users.

Second, under Windows only, the OCaml runtime considers @-prefixed
arguments as responsefile file names, and expands them during its
initialization phase. This is silently done by the OCaml *runtime*, so
all OCaml programs are affected; the compilers, but also the user
programs. Did you know that you shouldn't use '@' in your command-line
parameters syntax if you want your program to work on Windows?

The first use has been problematic in the past because some of the
underlying toolchains (Cygwin, mingw...) did not support
@responsefiles. The second case is now problematic as the @-syntax
conflicts with the warning-as-error syntax of the compiler: as
reported by Dmitry Grebeniuk, "-w @a" under windows complains about
a missing file "a", while it really should mark all warnings as
errors -- a very bad idea for future compatibility when new warnings
are added, by the way; don't use that in released OCaml software.

According to our Windows spies, the command-line restrictions are
nowadays very reasonable: 8K for, and 32K internally. Maybe
the @responsefile feature has outlived its use, and this bug could be
fixed by simply removing the @-files expansion phase of the runtime.

This change would however affect all user programs, so it should not
be taken lightly; it could break your programs.

What do OCaml Windows user think? Do you still rely on @reponsefile?
Please complain if you do -- or your users do -- and don't hesitate to
pass the question to off-list OCaml Windows users.

Some links:
  - previous angry discussions about @responsefile:
  - documentation about the compiler warning options:
  - a warning against using "-warn a -warn-error a" -- unrelated, but can't 

Commercial Users of Functional Programming 2012: Call for Presentations


Ashish Agarwal announced:
                                    CUFP 2012
                        CALL FOR PRESENTATIONS
                             Copenhagen, Denmark
                                    Sep 13-15
                          Co-located with ICFP 2012
                           Sponsored by SIGPLAN
            Talk Proposal Submission Deadline 29 June 2012

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're looking for two kinds of talks:

Experience reports are typically 25 minutes long, 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, 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 sperber(at)deinprogramm(dot)de or
avsm2(at)cl(dot)cam(dot)ac(dot)uk by 29 June 2012 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!  

Program Committee

    Mike Sperber (Active Group), co-chair
    Anil Madhavapeddy (University of Cambridge), co-chair
    Ashish Agarwal (New York University)
    Thomas Arts (QuviQ AB)
    Chris Houser (LonoCloud)
    Tomas Petricek (University of Cambridge)
    Heiko Seeberger (Typesafe)
    Stefan Wehr (factis research)
    Noel Welsh (untyped)

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.

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


TypeRex 1.0.0rc2:

Camlp5 6.04:

Spotlight on Opa app: OpaChess by Mads Hartmann Jensen:

Finding all the elementary circuits of a directed graph:

Connected Cloud Control: OpenFlow in Mirage:

Node.js vs. Opa: Web Framework Showdown:


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