OCaml Weekly News

Check out this paper, whose purpose is to explain and document the module.

I vividly remember how strange it looked the first time I tried using it. Other people recommended some resources to understand how to used it and how the boxing model works. I strongly recommend using the fmt library that abstracts a lot of complexity of the Format module.

Not a tutorial, but you might find it helpful to see some examples of Format usage.

Here's a pretty-printer for a small subset of XML:

https://gist.github.com/keleshev/5af7502e6810b8986d9f5332e7e8a795

A pretty-printer for a subset of JavaScript:

https://github.com/Virum/compiler/blob/28e807b842bab5dcf11460c8193dd5b16674951f/JavaScript.ml#L112

A pretty-printer for a subset of Python:

https://github.com/Virum/compiler/blob/master/Python.ml#L130

Personally, I like the Format module very much and never had to reach for another library, but I remember that it was tricky to wrap my head around when I just started to use it.

I'm happy yo announce a new release of decompress.0.8 available for installation via OPAM. The distribution provides a new package rfc1951 which implements the Request for Comments 1951 - a subset of zlib.

By this change, we put a prefix on previous modules Inflate and Deflate to recognize which format you use. Semantically, we don't have an update of the API. However, decompress needs a new package now: checkseum which depends on optint.

checkseum is a little library à la digestif to provide a shared interface which allows to use an implementation of ADLER-32 or CRC32C. Implementation could be a C implementation or an OCaml implementation, so when the use want to link decompress (or checkseum), he needs to specify which implementation he wants to use: checkseum.c or checkseum.ocaml - at this stage of dune, this dependency needs to be the first of the rest. By the OCaml implementation, we keep the possibility to compile decompress to JavaScript.

Finally, optint is a little library which provide an abstract type to represent an 32-bits integer. From your architecture (x64 or x86), optint will use an unboxed integer (fast) or a boxed int32 (slow). So, at least, you have a integer with 32 bits availables (or more - 63 on x64).

The next release is focus on to implement (finally) GZIP and, may be, LZO. The new internal design of decompress allows to put on top of rfc1951 the GZIP header. Then, we provided an inverted stub of decompress (to use decompress on a C code) to allow a real benchmark with others implementations.

We have the pleasure of celebrating the birthday of Nikola Tesla and Marcel Proust by announcing the release of OCaml version 4.07.0. This is a major release with a lot of new features, see the changelog below.

It is available as a bunch of OPAM switches, or as a source download here: http://caml.inria.fr/pub/distrib/ocaml-4.07.

Happy hacking, – Damien Doligez for the OCaml team.

OCaml 4.07.0 (10 July 2018)

(Changes that can break existing programs are marked with a "*")

It is my pleasure to announce the 1.0.0 release of Dune!

Dune is a built system for OCaml and Reason projects. It aims at building things fast and providing a smooth user experience.

Dune 1.0.0 is now available on github and in opam.

This is a big milestone for the project as it is the first release using the new Dune name that the community helped to choose. Dune started about a year and a half ago as the more narrow scoped Jbuilder and as since then proven itself to be the right tool for the job.

A big part of the work for this release was preparing the project for long-term support. Dune is the kind of project that will pretty much continue to evolve forever: it needs to keep up with the OCaml compiler evolving, development workflows changing, new kinds of tools with specific needs, etc… While doing so, it also needs to offer stability so that projects released now will continue to build with future versions of Dune.

Meeting these two constraints is a challenge. However, we had to do this for the renaming: we changed many things in Dune using what we learned from the Jbuilder experience. Still, Dune is able to understand and build Jbuilder projects. The mechanism used to support both Jbuilder and Dune projects is fully generic and will be the basis for future evolution.

You can find the full list of changes and bug fixes since Jbuilder 1.0+beta20 on the github release page. Following is an overview of some the new features:

• General cleanup of the syntax: less parentheses, better behaved variables
• Introduction of a dune.configurator library to help projects with C stubs detect and query the environment
• General improvement of the default behavior: more parallelism by default, development mode by default
• Better support for changing the defaults: it is now possible to set the default flags or change what dune build does by default
• Support for setting the build directory
• Better support for expectation tests on Windows

It is my pleasure to announce a new release (#5) of Stdcompat!

Stdcompat is a compatibility module for OCaml standard library, available from OCaml 3.07 to OCaml 4.07.0 (that is to say, the whole spectrum of OCaml compilers available in OPAM).

Stdcompat.* redefines (most of the) symbols available in OCaml 4.07.0 standard library, such as List.find_opt, floatarray, Uchar.t, Seq.t, result, etc.

Stdcompat has no dependency! Former versions used to rely on cppo but the preprocessing is now done by a ./configure script (generated with autoconf).

OPAM packages result, seq, uchar are optional dependencies: if they are installed, types declared by stdcompat are compatible with the types these packages declare.

Stdcompat can be opened in the beginning of a module: its signature follows the signature of the standard library, including the new Stdlib module.

Github repository: https://github.com/thierry-martinez/stdcompat Available in OPAM: opam install stdcompat

Happy hacking!

Currently we have 2 options to write frontend-related code in OCaml: js_of_ocaml and bucklescript. I have no experience with this two libraries and I want to pick one. Has anybody tried both of them or made some analysis with comparison? Could you please share your thoughts and experience about both libraries if so. I'm interested in: performance of generation, source-mapping, performance, quality, safety and readability of generated JS, simplicity of use, pros and cons of both solutions, etc. Thank you very much for your responses. OCaml community is the best!

We've made extensive use of js_of_ocaml for internal apps at Jane Street. I can't give a detailed comparison with Bucklescript, but I can tell you what I know of the tradeoffs.

• First, js_of_ocaml runs pretty fast, but I've heard tell that Bucklescript is faster. js_of_ocaml now supports separate compilation of Javascript, so subsequent recompilations are quite zippy, in my experience. That said, the initial compilation takes material time. Dune does separate compilation for js_of_ocaml by default, and does a single, more compact javascript executable when run in production mode. Anyway, we haven't found performance of the compiler to be an obstacle with js_of_ocaml.
• js_of_ocaml is highly compatible with OCaml's semantics. Advanced libraries like Async and Incremental that make fairly aggressive use of OCaml's memory model work under js_of_ocaml without modification, which is great. I believe you have to be a bit more careful when compiling with Bucklescript. (See incr_dom for an interesting application of Incremental to the browser.)
• js_of_ocaml is highly compatible in a another way: it is essentially always fully up to date with the latest OCaml. That's because it's easier to maintain, by virtue of operating only on OCaml bytecode. Bucklescript is a more fullsome set of patches to the compiler, and so it typically lags a few versions behind. That alone is for us a sufficiently compelling reason to stick to js_of_ocaml.
• Bucklescript seems to have a more active web-dev community, associated with the Reason community. I think this is mostly because Bucklescript generates easy to read javascript output. I don't care much about readable JavaScript output (especially in a world with sourcemaps), but the community surely has value. For example, the OCaml React bindings are currently Bucklescript-only (though @jordwalke has suggested that porting to js_of_ocaml would be totally doable.)

Anyway, good luck in picking! I think people have had good experiences with both, so you can't go too far wrong.

Oh, and for people who are concerned about bindings, this project from LexiFi looks pretty cool. I think we haven't started using it yet, but some folk internally are currently kicking the tires. It looks pretty cool to me.

https://github.com/LexiFi/gen_js_api

We are pleased to announce a new release of Sundials/ML, an OCaml interface to the Sundials suite of numerical solvers (CVODE, CVODES, IDA, IDAS, ARKODE, KINSOL).

This release adds support for Sundials 3.1.x, and most notably for the new generic matrix and linear solver interfaces. The OCaml interface changes but the library is backward compatible with the older versions of Sundials (2.5.0 onwards) that are still current in some packaging systems.

OCaml 4.02.3 or greater is now required and optionally OCamlMPI 1.03.

Information and documentation: http://inria-parkas.github.io/sundialsml/
Source code (BSD): https://github.com/inria-parkas/sundialsml

opam install sundialsml # (requires Sundials 2.5.0 or above)

There is a draft paper that describes our implementation. It is still undergoing peer review, but we would be happy to share it by private mail.

We gratefully acknowledge the original authors of Sundials, and the support of the ITEA 3 project 11004 MODRIO (Model driven physical systems operation), Inria, and the Departement d'Informatique de l'ENS.

Here are links from many OCaml blogs aggregated at OCaml Planet.

• OCaml 4.07.0 released