Previous week Up Next week


Here is the latest OCaml Weekly News, for the week of May 30 to June 06, 2017.

  1. qcheck 0.6
  2. Odig 0.0.2
  3. deprecating opam 1.2.0
  4. OCaml hacking evening in Cambridge, (MA, *US*) on June 6th
  5. findlib-1.7.3
  6. From the OCaml discourse
  7. Ocaml Github Pull Requests
  8. Other OCaml News

qcheck 0.6


Simon Cruanes announced:
I have the please to announce the release of QCheck 0.6. QCheck is a
feature rich property testing library inspired from Haskell's

This new release contains several significant improvements, thanks to
the help of Guillaume Bury and Jan Midtgaard.

- better generation of functions, with proper printing and shrinking.
- functions to leverage generators to produce values satisfying a predicate.
- colorful runners.
- better shrinkers and random generators.
- gathering basic statistics and optionally displaying an histogram of sampled values.

QCheck is available on opam.
Release URL:

Odig 0.0.2


Daniel Bünzli announced:
It's my pleasure to announce odig 0.0.2. 

odig is an ISC licensed library and command line tool to mine
installed OCaml packages. It supports package distribution
documentation and metadata lookups and generates cross-referenced
API documentation for your opam switches.

Sample output:

The two main features of this release are:

# odoc generated API documentation

The default documentation backend was changed from `ocamldoc` to
`odoc` [0]. Using `odoc` notably provides inter-package
cross-references and correct output on functor heavy code bases.

As with the `ocamldoc` backend, odig remains a dumb command
driver, all the hard API doc generation work is being done by
`odoc` on the `cmt[i]` files and credits should go to:

* Thomas Refis and Leo White for the current `odoc` incarnation.
* Fabrice Le Fessant for designing and implementing the essential `cmt[i]` 
* David Sheets, Leo White and Jeremy Yallop for working through a lot 
  of the initial hard details and implementing earlier prototypes.

To get API documentation for the packages installed in your
current opam switch the following sequence of commands should be

  opam install odoc ocaml-manual odig
  odig odoc
  odig doc

If you are a packager consult `odig help packaging` to understand
how `odig` generates API documentation using `odoc` and other
conventions to provide a good odig experience to the users of
your package.

This is the last release of `odig` that will provide the
`ocamldoc` backend. If you are interested in improving `odoc`'s
output by comparing with what ocamldoc gave on your package this
is the time to do it. This can be done here:

or, if your package is not listed there with `odig ocamldoc PKG
&& odig odoc PKG && odig doc --compare PKG`. File any issue on
the `odoc` tracker, but please make sure it's not already reported, we
are already aware of some problems.


# Experimental data-driven toplevel loaders

This release adds experimental toplevel loaders. The idea here is
to kill the general need for `.ocamlinit` files in your projects
and not bother you having to know in whichever package and/or
archive a particular module you need might be tucked.

In order to load any toplevel module `M` simply:

   #use "";;
   Odig.load "M";;

this will lookup in your build directory and/or in the package
install base and load appropriate dependencies by simply
consulting the OCaml compiled object files (no `META` file are
involved in this process).

The loaders are not perfect yet, the main *current* limitations are:

1. No support to resolve ambiguities, if there is one you can't load. 
2. No support to mandate specific load order for modules that rely on 
   side-effects (this will be achieved via opam v2 extension fields). 
3. For now they are also too slow on some modules with many deps (e.g. 
   `Odig.load "Core"`). However the load time is entirely reasonable on 
   small and medium scale libraries (e.g. `Odig.load "Irmin_mem"`). The 
   very first load might be a bit slow though.


and ` ()` for more details. Except for failures due to
ambiguous resolutions, feedback and concrete failures/problems
report are welcome on `odig`'s issue tracker.

deprecating opam 1.2.0


Anil Madhavapeddy announced:
[ this is cross-posted from ]

This is all for remaining users of OPAM 1.2.0, to see if it can be actively
deprecated in favour of OPAM 1.2.2 and higher.

### Why deprecate opam 1.2.0

OPAM 1.2.0 was released in October 2014, and saw rapid uptake from the
community. We did some rapid bugfixing to solve common problems, and OPAM 1.2.2
was released in April 2015. Since then, 1.2.2 has been a very solid release and
has been the stable version in use to date.

Unfortunately, part of the bugfixes in the 1.2.2 series resulted in an `opam`
file format that is not fully backwards compatible with the 1.2.0 syntax, and
the net effect is that users of 1.2.0 now see a broken package repository. Our
CI tests for new packages regularly fail on 1.2.0, even if they succeed on 1.2.2
and higher.

As we prepare the plan for [1.2.2 -> 2.0
migration](, it is clear that we need
a "one-in one-out" policy on releases in order to preserve the overall health of
the package repository -- maintaining three separate releases and formats of the
repository is not practical. Therefore the 1.2.0 release needs to be actively
deprecated, and we could use some help from the community to make this happen.

### Who is still using opam 1.2.0?

I found that the Debian Jessie (stable) release includes 1.2.0, and this is
probably the last major distribution including it. The [Debian
Stretch]( is due to become the stable
release on the 17th June 2017, and so at that point there will hopefully be no
distributions actively sending opam 1.2.0 out.

Is there anyone else that is still packaging 1.2.0? Please comment here if so,
and we should move them away.

### How do we deprecate it?

Due to the format changes happening in a minor version, it's a bit difficult to
give opam 1.2.0 users a smooth transition experience, to my knowledge (Louis
Gesbert or Thomas Gazagnaire may correct me here). I would propose:

- putting a notice on that 1.2.2 is the only supported stable release.
- can we somehow put in a request to debian-stable to add a post-installation
message that the upstream package will no longer work since the repository?

If there are any users of opam 1.2.0, particularly industrial ones, please do
speak up now. By performing an active deprecation of an older release, I hope we
can focus our efforts on ensuring the opam users have a good out-of-the-box
experience with opam 1.2.2 and the forthcoming opam 2.0 :-)
Hendrik Boom replied:
Yes.  There's Devuan stable.  It is Debian without systemd, and it 
will take a while for it to catch up when Debian relabels their 

I'll ask about it on the devuan mailing list.  Perhaps they can 
accelerate the opam-related packages.  I don't  know whether that will 
be compatible with their automated workflow.
Anil Madhavapeddy then said:
Thanks for checking, Hendrik.  It may be worth mentioning to them that
OPAM 1.2.0 is already broken in practical terms (unless the repository
it defaults to is rolled back), and so we encourage backports to 1.2.2
in this case.
Evgeny Roubinchtein also replied:
FreeBSD ports still only has opam 1.2.0:  DragonFly may
be in the same boat, since, IIRC the ports collection is shared between the
two.   Also, what about pkgsrc?

The opam-2.x/master's "cold" target "just worked" for me when I tried it on
FreeBSD (after a tiny patch that has already been merged), so I am
optimistic that producing an updated port for FreeBSD is mostly a matter of
going through the motions.  One annoyance is that well-behaved ports are
only supposed to access network during the "fetch" stage, so one would need
to replicate in the FreeBSD port's Makefile the targets from the opam
source tree that download various things during opam's build (I think it's
mostly things in src_ext).  That isn't an insurmountable obstacle, by any
means, but just a bit of work that needs to be done.
David Allsopp then said:
(which is in the process of being merged) and
(which will head in a similar direction soon).

13fdc7e gives you make -C src_ext cache-archives which will download all the
src_ext tarballs to src_ext/archives
If you then explicitly download the ocaml sources tarball to src_ext/archives/,
then 0f2234 ensures that make cold uses it
Hannes Mehnert also replied to Evgeny:
> FreeBSD ports still only has opam 1.2.0:

To clarify, FreeBSD ports has opam 1.2.2 (since May 2015), not 1.2.0.

OCaml hacking evening in Cambridge, (MA, *US*) on June 6th


Gabriel Scherer announced:
I am happy to announce an OCaml hacking session in the evening of June
6th in Cambridge, MA, US. The event will take place at MIT, between
17:00 and 23:30, in the room 4-145. Access instructions can be found

This event, organized by Clément Pit-Claudel, Thomas Bourgeat and
myself, is open to all OCaml programmers, advanced or
beginners. Attendees will be encouraged and assisted in making
a contribution to an OCaml open source project, including in
particular the OCaml compiler implementation itself -- we will propose
a list of tasks and project ideas, and try to help in providing
technical advice, feedback and guidance for contribution.

Coming with a project in mind is also welcome, on the compiler
codebase or any other OCaml codebase. Many blocks of the OCaml
ecosystem would benefit from contributions, including documentation
contributions and the website. If you were waiting
for an opportunity to scratch an OCaml-y itch in a friendly place,
there it is!

Event implementation details are still being arranged, but we are not
planning on having food at the event itself. We may go out in groups
around dinner time, but feel free to eat beforehand or bring your own

Feel free to ask any question to me by email, on the list, or on the
Discourse forum thread:



Gerd Stolpmann announced:
in the last version of findlib there was a small error regarding the num
library. It was announced that this library is now optional (as it will
be omitted from ocaml-4.06 onwards), however the build did not skip over
all parts of it if missing. There is now findlib-1.7.3 fixing this
single bug.

From the OCaml discourse

The editor compiled this list:
Here are some links to messages at that may
be of interest to the readers.

- Anton Bachin talks about "A welcoming, community-oriented Lwt"

- Petter A. Urkedal talks about "ppx_regexp 0.2.0 and 0.3.0"

- Petter A. Urkedal talks about "ppx_compose 0.0.3"

- Thomas Gazagnaire talks about "DataKit dev reports"

- Alfredo Beaumont talks about "salsa20-core 0.2.0"

Ocaml Github Pull Requests

Gabriel Scherer and the editor compiled this list:
Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.

- Manual: minimal documentation for compiler plugins

Other OCaml News

From the ocamlcore planet blog:
Here are links from many OCaml blogs aggregated at OCaml Planet,

New in libguestfs: Rewriting bits of the daemon in OCaml

Full Time: Front-end Developer at issuu in Copenhagen

PureScript/React Front-End Developer at CollegeVine (Full-time)

Frama-C 15 - Phosphorus is out. Download ithere.

A modular formalization of type theory in Coq

More type classes in OCaml

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