OCaml Weekly News

Previous Week Up Next Week


Here is the latest OCaml Weekly News, for the week of January 04 to 11, 2022.

Table of Contents

New release of PPrint (20220103)

François Pottier announced

I am pleased to announce a new release of PPrint, the pretty-printing library, with improved documentation.

The documentation can also be viewed offline:

opam update
opam install pprint.20220103
opam install odig
odig odoc                 # this may take some time
odig doc pprint           # this opens the doc in your browser

Happy pretty-printing!

Bogue, the OCaml GUI

sanette announced

I'm happy to announce a brand new version of Bogue, a GUI (Graphical User Interface) library entirely written in ocaml, using SDL2 for hardware accelerated graphics.

The doc can be found here, it will be enriched over time.

Install with opam install bogue

In addition to the library, this installs an executable boguex to showcase about 50 useful constructions, see boguex -h for the list.

Some screenshots of a demo compiled with the latest version:



Note that many widgets are not shown in this demo: tables, menus, drop-down select lists, knob buttons,… I will add more images to the doc when I have some time!

Cohttp 5.0.0 and 2.5.6

Marcello Seri announced

We are glad to announce the release of version 5.0.0 and 2.5.6 of cohttp and its dependent packages.

The latter is a bug fix release that in particular backports the compatibility with the upcoming release 0.15 of core and async.

The first introduces the breaking changes announced in the previous release. I append the changelog below, which explains in details the changes and emphasizes the breaking changes:

Cohttp.Header: new implementation (lyrm #747)

  • New implementation of Header modules using an associative list instead of a map, with one major semantic change (function get, see below), and some new functions (clean_dup, get_multi_concat)
  • More Alcotest tests as well as fuzzing tests for this particular module.

The new header implementation uses an associative list instead of a map to represent headers and is focused on predictability and intuitivity: except for some specific and documented functions, the headers are always kept in transmission order, which makes debugging easier and is also important for RFC7230§3.2.2 that states that multiple values of a header must be kept in order.

Also, to get an intuitive function behaviour, no extra work to enforce RFCs is done by the basic functions. For example, RFC7230§3.2.2 requires that a sender does not send multiple values for a non list-value header. This particular rule could require the Header.add function to remove previous values of non-list-value headers, which means some changes of the headers would be out of control of the user. With the current implementation, an user has to actively call dedicated functions to enforce such RFCs (here Header.clean_dup).

Semantic changes

Two functions have a semantic change : get and update.


get was previously doing more than just returns the value associated to a key; it was also checking if the searched header could have multiple values: if not, the last value associated to the header was returned; otherwise, all the associated values were concatenated and returned. This semantics does not match the global idea behind the new header implementation, and would also be very inefficient.

  • The new get function only returns the last value associated to the searched header.
  • get_multi_concat function has been added to get a result similar to the previous get function.

update is a pretty new function (#703) and changes are minor and related to get semantic changes.

  • update h k f is now modifying only the last occurrences of the header k instead of all its occurrences.
  • a new function update_all function has been added and work on all the occurrences of the updated header.
New functions :
  • clean_dup enables the user to clean headers that follows the RFC7230§3.2.2 (no duplicate, except set-cookie)
  • get_multi_concat has been added to get a result similar to the previous get function.

Cohttp.Header: performance improvement (mseri, anuragsoni #778)

Breaking the headers are no-longer lowercased when parsed, the headers key comparison is case insensitive instead.

cohttp-lwt-unix: Adopt ocaml-conduit 5.0.0 (smorimoto #787)

Breaking Conduit_lwt_unix.connect's ctx param type chaged from ctx to ctx Lazy.t

other changes

  • cohttp-mirage: fix deprecated fmt usage (tmcgilchrist #783)
  • lwt_jsoo: Use logs for the warnings and document it (mseri #776)
  • lwt: Use logs to warn users about leaked bodies and document it (mseri #771)
  • lwt, lwt_unix: Improve use of logs and the documentation, fix bug in the Debug.enable_debug function (mseri #772)
  • lwt_jsoo: Fix exception on connection errors in chrome (mefyl #761)
  • lwt_jsoo: Fix Lwt.wakeup_exn Invalid_arg exception when a js stack overflow happens in the XHR completion handler (mefyl #762).
  • lwt_jsoo: Add test suite (mefyl #764).

We wish to thank to all the users and the contributors for their help leading to this release.

Multicore OCaml: December 2021 and the Big PR

Anil Madhavapeddy announced

Welcome to the December 2021 Multicore OCaml monthly report! The previous updates along with this update have been compiled by myself, @ctk21, @kayceesrk and @shakthimaan.

Well, it's finally here! @kayceesrk opened the Multicore OCaml PR#10831 to the main OCaml development repository that represents the "minimum viable" implementation of multicore OCaml that we decided on in November's core team review. The branch pushes the limits of GitHub's rendering capability, with around 4000 commits.

Once the PR was opened just before Christmas, the remaining effort has been for a number of developers to pore over the diff and look for any unexpected changes that crept in during multicore development. A large number of code changes, improvements and fixes have been merged into the ocaml-multicore trees since the PR was opened to facilitate this upstreaming process. We're expecting to have the PR merged during January, and then will continue onto the "post-MVP" tasks described last month, but working directly from ocaml/ocaml from now on. We therefore remain on track to release OCaml 5.00 in 2022.

In the multicore ecosystem, progress also continued:

  • Eio continues to improve as the recommended effects-based direct-style IO library to use with Multicore OCaml.
  • A newer domainslib.0.4.0 has been released that includes bug fixes and API changes.
  • The continuous benchmarking pipeline with further integration enhancements between Sandmark and current-bench is making progress.

We would like to acknowledge the following external contributors as well::

  • Danny Willems (@dannywillems) for an OCaml implementation of the Pippenger benchmark and reporting an undefined behaviour.
  • Matt Pallissard (@mattpallissard) reported an installation issue with Eio with vendored uring.
  • Edwin Torok (@edwintorok) for contributing a PR to domainslib to allow use of a per-channel key.

As always, the Multicore OCaml updates are listed first, which contain the upstream efforts, improvements, fixes, test suite, and documentation changes. This is followed by the ecosystem updates to Eio, Tezos, and Domainslib. The Sandmark, sandmark-nightly and current-bench tasks are finally listed for your reference.

editor’s note: please follow the archive link above for the full changelog.

Stéphane Lavergne asked and Robin Björklin replied

To clarify for relative newbies like myself: this would be a new way to do concurrent I/O, like Async and Lwt, but unlike those, it wouldn't require the use of a promise monad? In other words, does this mean that we'll have the choice between Async, Lwt and Eio in the near future for our concurrent I/O needs?

That's correct as far as I can tell. This presentation provides an introduction to the current state of eio: https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89

Set up OCaml 2.0.0-beta12

Sora Morimoto announced


  • Fallback to the version in which the assets exist if no assets exist in the latest opam release.
  • Instruct Cygwin setup to use "sys" symlinks during setup (partial workaround for bug with native symlinks in Cygwin setup - some depexts may still be affected)



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.