OCamlPro Highlights: April 2014

Authors: Çagdas Bozman
Date: 2014-05-20
Category: OCamlPro



Here is a short report on some of our activities in April 2014, and a short analysis of OCaml evolution since its first release.

OPAM Improvements

We're still working on release 1.2. It was decided to include quite a few new features in this release, which delayed it a little bit since we want to be sure to get it right. It's now getting stabilized, documented and tested. One of the biggest improvements concerns the development workflow and the use of pinned packages, which is a powerful and complex feature that could also get a bit confusing. We are grateful for the large amount of feedback from the community that helped in its design. The basic idea is to use OPAM metadata from within the source packages, because it's most useful while developping and helps get the packaging right. It was possible before, but a little bit awkward : you now only need to provide an opam file or directory at the root of your project, and when pinned to either a local path or a version-controlled repository, opam will pick it up and use it. It will then be synchronized on any subsequent opam update. You can even do this if there is no corresponding package in the repository, OPAM will create it and store it in its internal repository for you. And in case this metadata is getting in the way, or you just want a quick local fix, you can always do opam pin edit <package> to locally change the metadata used by opam.

During this month, we've also been improving performance by a large amount in several areas, because delays could become noticeable for people using it on eg. raspberry pis. There is an important clarification on the handling of optional dependencies; and we worked hard on making the build of OPAM as painless as possible on every possible setting.

OPAM Weather Service

Last month, we presented an online service for OPAM, to provide advanced CUDF solvers to every OPAM user. The service is provided by IRILL, and based on the tools they implemented to manipulate CUDF files (some of them are also used directly in OPAM).

This month, we are happy to introduce a new service, that we helped them put online: the OPAM Weather Service, an instantiation for OPAM of a service they also provide for Debian. It shows the evolution of the installability of all packages in the official OPAM repository, for three stable versions of OCaml (3.12.1, 4.00.1 and 4.01.0). It should help maintainers track dependency problems with their packages, when old packages are removed or new conflicting dependencies are introduced.

An Internship on OCaml Namespaces

This month, we welcomed Pierrick Couderc for an internship in our lab. He is going to work on adding namespaces to OCaml. His goal is to design a kind of namespaces that extend the current module mechanism in a consistent but powerful way. One challenge of his job will be to make these namespaces also extend our big functors to provide functors at the namespace level.

Pierrick is not a complete newcomer in our team: last year, he already worked for us with David Maison (now working at TrustInSoft) on an online service to edit and compile OCaml code for students.

The Evolution of OCaml Sources

This month, there was also a lot of activity for the Core team, as we are closing to the feature freeze for OCaml 4.02. We took this opportunity to have a look at the evolution of OCaml sources since the first release of OCaml 1.00, in 1996.

Our first graph plots the size of uncompressed OCaml sources in bytes, from the first release to the current trunk:

ocaml-bytes

The graph shows four interesting events:

  • in 2002-2003, between 3.02 and 3.06, an increase of 4 MB
  • in 2007, between 3.09.3 and 3.10.0, an increase of again 4 MB
  • in 2013, between 4.00.1 and 4.01.0, an increase of 2 MB
  • in 2014, between 4.01.0 and 4.02.0, a decrease of 6 MB

Our second graph plots the number of files per kind (OCaml sources, OCaml interfaces, C sources and C headers):

ocaml-file

We can now check the files that were added and removed at the four events that we noticed on the first graph:

  • the first event corresponds to the addition of 174 files for camlp4 in 3.04, and then 70 files for ocamldoc in 3.06. Also, labltk increased a lot, with many new examples;
  • the second event corresponds to the addition of 225 files for ocamlbuild in 3.10.0, and the replacement of camlp4 (renamed into camlp5) by a new implementation;
  • the third event corresponds to ... a change in the size of boot/myocamlbuild.boot, the bytecode file used by ocamlbuild to bootstrap itself !
  • finally, the incoming new event corresponds to the removal of camlp4 and labltk from 4.02, i.e. about 300 files for each of them.

Our third graph shows the number of lines per kind of file, again:

ocaml-lines

This graph does not show us much more than what we have seen by number of files, but what might be interesting is to compute the ratio, i.e. the number of lines per file, for each kind of file:

ocaml-ratio

There is a general trend to increase the number of lines per file, from about 200 lines in an OCaml source file in 1996 to about 330 lines in 2014. This ratio increased considerably for release 3.04, because camlp4 used to generate a huge bootstrap file of its own pre-preprocessed OCaml sources. More interestingly, the ratio didn't decrease in 2014, when camlp4 was removed from the distribution ! Interface files also grew bigger, but most of the increase was in 3.06, when ocamldoc was added to the distribution, and an effort was done to document mli files.



About OCamlPro:

OCamlPro is a R&D lab founded in 2011, with the mission to help industrial users benefit from experts with a state-of-the-art knowledge of programming languages theory and practice.

  • We provide audit, support, custom developer tools and training for both the most modern languages, such as Rust, Wasm and OCaml, and for legacy languages, such as COBOL or even home-made domain-specific languages;
  • We design, create and implement software with great added-value for our clients. High complexity is not a problem for our PhD-level experts. For example, we developed the prototype of the Tezos proof-of-stake blockchain.
  • We have a long history of creating open-source projects, such as the Opam package manager, the LearnOCaml web platform, and contributing to other ones, such as the Flambda optimizing compiler, or the GnuCOBOL compiler.
  • We are also experts of Formal Methods, developing tools such as our SMT Solver Alt-Ergo (check our Alt-Ergo Users' Club) and using them to prove safety or security properties of programs.

Please reach out, we'll be delighted to discuss your challenges: contact@ocamlpro.com or book a quick discussion.