OCaml Weekly News
Hello
Here is the latest OCaml Weekly News, for the week of December 20 to 27, 2022.
Table of Contents
OCaml 4.14.1 released
octachron announced
We have the pleasure of celebrating the birthday of Oronce Finé by announcing the release of OCaml version 4.14.1.
This release is a collection of safe bug fixes, cherry-picked from the OCaml 5.0.0 release. If you were using OCaml 4.14.0 and cannot yet upgrade to OCaml 5, this release is for you.
The 4.14 branch is expected to receive more backported fixes during the maturation of OCaml 5. Thus don’t hesitate to report any bugs on the OCaml issue tracker.
See the list of changes below for more details.
Installation Instructions
The base compiler can be installed as an opam switch with the following commands:
opam update opam switch create 4.14.1
The source code for the release candidate is also directly available on:
Changes in OCaml 4.14.1 (20 December 2022)
- Compiler User-Interface and Warnings:
- Build System:
- Bug Fixes:
- #10768, #11340: Fix typechecking regression when combining first class modules and GADTs. (Jacques Garrigue, report by François Thiré, review by Matthew Ryan)
- #11204: Fix regression introduced in 4.14.0 that would trigger Warning 17 when calling virtual methods introduced by constraining the self type from within the class definition. (Nicolás Ojeda Bär, review by Leo White)
- #11263, #11267: caml/{memory,misc}.h: check whether
_MSC_VERis defined before using it to ensure that the headers can always be used in code which turns on -Wundef (or equivalent). (David Allsopp and Nicolás Ojeda Bär, review by Nicolás Ojeda Bär and Sébastien Hinderer) - #11314, #11416: fix non-informative error message for module inclusion (Florian Angeletti, report by Thierry Martinez, review by Gabriel Scherer)
- #11358, #11379: Refactor the initialization of bytecode threading, This avoids a “dangling pointer” warning of GCC 12.1. (Xavier Leroy, report by Armaël Guéneau, review by Gabriel Scherer)
- #11387, module type with constraints no longer crash the compiler in presence of both shadowing warnings and the
-bin-annotcompiler flag. (Florian Angeletti, report by Christophe Raffalli, review by Gabriel Scherer) - #11392, #11392: assertion failure with -rectypes and external definitions (Gabriel Scherer, review by Florian Angeletti, report by Dmitrii Kosarev)
- #11417: Fix regression allowing virtual methods in non-virtual classes. (Leo White, review by Florian Angeletti)
- #11468: Fix regression from #10186 (OCaml 4.13) detecting IPv6 on Windows for mingw-w64 i686 port. (David Allsopp, review by Xavier Leroy and Sébastien Hinderer)
- #11489, #11496: More prudent deallocation of alternate signal stack (Xavier Leroy, report by @rajdakin, review by Florian Angeletti)
- #11516, #11524: Fix the
deprecated_mutableattribute. (Chris Casinghino, review by Nicolás Ojeda Bär and Florian Angeletti) - #11194, #11609: Fix inconsistent type variable names in “unbound type var” messages (Ulysse Gérard and Florian Angeletti, review Florian Angeletti and Gabriel Scherer)
- #11622: Prevent stack overflow when printing a constructor or record mismatch error involving recursive types. (Florian Angeletti, review by Gabriel Scherer)
- #11732: Ensure that types from packed modules are always generalised (Stephen Dolan and Leo White, review by Jacques Garrigue)
- #11737: Fix segfault condition in Unix.stat under Windows in the presence of multiple threads. (Marc Lasson, Nicolás Ojeda Bär, review by Gabriel Scherer and David Allsopp)
- #11776: Extend environment with functor parameters in
strengthen_lazy. (Chris Casinghino and Luke Maurer, review by Gabriel Scherer) - #11533, #11534: follow synonyms again in #show_module_type (this had stopped working in 4.14.0) (Gabriel Scherer, review by Jacques Garrigue, report by Yaron Minsky)
- #11768, #11788: Fix crash at start-up of bytecode programs in no-naked-pointers mode caused by wrong initialization of caml_global_data (Xavier Leroy, report by Etienne Millon, review by Gabriel Scherer)
- #11803, #11808: on x86, the destination of an integer comparison must be a register, it cannot be a stack slot. (Vincent Laviron, review by Xavier Leroy, report by Emilio Jesús Gallego Arias)
Js_of_ocaml 5.0
Hhugo announced
I’m pleased to announce the release of js_of_ocaml 5.0. It should soon be able available in opam.
Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js.
This is the first release supporting OCaml 5 effects handlers. Thanks to Jérôme Vouillon and Olivier Nicole for the contribution (based on previous work from Armaël Guéneau and Patrick Ferris).
Js_of_ocaml supports for effect handlers can be enabled by passing the --enable=effects flag. This is based on transformation of
the whole program to continuation-passing style. As a consequence, tail calls are also fully optimized. This is not the default for
now since the generated code is slower, larger and less readable. The
performance impact is especially large for code that involves a lot of
function calls without allocation, since the transformation introduces many intermediate continuation functions. We hope to improve
on this by transforming the code only partially to continuation-passing style, and by trying alternative compilation strategies.
See https://ocsigen.org/js_of_ocaml/latest/manual/effects to learn how to enable the support for effect handlers when using dune.
You can try it out in this https://ocsigen.org/js_of_ocaml/5.0.1/manual/files/toplevel/index.html running in the browser.
CFP - JFLA 2023 - Journées Francophones des Langages Applicatifs
Archive: https://discuss.ocaml.org/t/cfp-jfla-2023-journees-francophones-des-langages-applicatifs/10482/2
Timothy Bourke announced
This message is intentionally written in French. It is a call for registrations to, and extra information for, the “Francophone Days on Functional Languages” to be held at the end of January. There are a number of submissions involving OCaml, some written in English. The PDFs will be available online in January.
Les inscriptions pour les JFLA 2023 sont ouvertes : http://jfla.inria.fr/jfla2023.html#inscription
Grâce aux nombreuses soumissions de qualité, et à nos orateurs invités — Sylvie Boldo, Cyril Cohen et Xavier Leroy —, le programme construit avec le comité cette année s’annonce particulièrement engageant et stimulant ! Les détails se trouvent sur le site web.
L’inscription est un forfait qui comprend notamment l’hébergement en pension complète sur le site des journées :
- participant·e plein tarif : 700 euros
- étudiant·e orateur·ice : 0 euro
Les inscriptions des étudiant·e·s orateur·ices sont financées par nos sponsors académiques et industriels. Ces inscriptions (gratuites) sont néanmoins nécessaires pour la réservation de l’hébergement.
Nous espérons que vous serez nombreux à participer à ces journées. La finalisation des inscriptions, notamment le paiement, reste possible jusqu’au 20 janvier, mais le nombre de places est limité : inscrivez-vous donc maintenant !
OCaml Job
Christophe Raffalli announced
We have a project involving OCaml, React-Rescript, postgresql, distributed data (a.k.a. “cloud”). We may hire some people in February of Mars, but to answer a call, we would like declarations of intent from people that may be interested.
Important: the job will be in French Polynesia.
We are using the most advanced OCaml’s features (GADT, Effect, Domain, …). Thus, candidates should really be skilled OCaml programmers. Prior knowledge of posgresql, distributed data starage of React/Rescript will be appreciated.
Maintenance bottlenecks in the compiler distribution
gasche announced
This is a public announcement that we are experiencing a maintenance bottleneck with development of the OCaml compiler distribution (the github/ocaml/ocaml repository).
Our development process naturally generates a fair amount of maintenance work to, among other things, discuss and integrate proposed patches, fix bugs, and react to feature requests. We don’t have enough people doing this maintenance work; currently the vast majority of this work is being done by about 5 people: David Allsopp, Florian Angeletti, Nicolás Ojeda Bär, Xavier Leroy, and myself.
Despair not! Bug fixes tend to be prioritized and handled quickly; I believe that the OCaml releases remain of satisfying quality. But other aspects are affected negatively, for example:
- our ability to react to proposed changes in a timely manner,
- the experience of people trying to contribute to the compiler codebase,
- various potential improvements that get stalled by lack of manpower to work on them.
Context
The OCaml compiler distribution moved to Github in January 2014. Since then, maintainers have been constantly complaining that there are more people willing to submit changes/PRs than people willing to review them, creating a bottleneck on the reviewing side. (We point this out in the first section of our CONTRIBUTING.md document.)
But the effort to upstream Multicore OCaml has unfortunately made the situation worse, for at least two reasons:
- Integrating the completely new Multicore runtime required a lot of review, integration and documentation work. We onboarded experienced Multicore developers as upstream maintainers and this helped smooth out the process, but we have still been less available with other maintenance tasks that piled up in the meantime.
- The sequential glaciation indirectly reduced the maintenance workforce. In November 2021 we stopped merging non-multicore-related features in the development version; as a result, various maintainers and heavy contributors moved away from working on the main development branch, to do their experiments in separate repositories (which is completely fine), and also more or less stopped following issues and performing maintenance on the main branch (which aggravated the maintenance issue).
Now that OCaml 5 has been released, many contributors will be coming back with many exciting change proposals to upstream. At the same time, our users are playing with Multicore features and will soon find countless bugs to fix, limitations to lift, etc. It’s not easy to play OCaml maintainer right now.
What can people do to help?
- Contribute to the maintenance effort
Heavy contributors, in particular core developers but not only, should be expected to participate to this collective maintenance effort. We are having discussions right now about our expectations.
In my personal opinion, anyone who dedicates a substantial portion of their time to working on code intended for eventual upstreaming should dedicate a fraction of this time to collective maintenance of the development branch. This is the most healthy way to ensure that the volume of maintenance work scales with the volume of submissions. (10%? 20%? Something like this.) (If you are paid by someone to work on the compiler, please make sure that your pay cover this maintenance fraction.)
Occasional contributors who would like to help with OCaml development should also consider whether they can help with this. (No pressure!) We have several instances of people helping with code reviews, triaging, helping make decisions on design questions etc. (I remember nice contributions in this direction from Daniel Bünzli, Gabriel Radanne, Nathanaëlle Courant, Favonia, Guillaume Munch-Maccagnoni and Kate for example.)
- Generate less maintenance work
If you interact with the compiler distribution as a software project, please be mindful of the maintenance load that you generate. If you send a Pull Request, make sure that its purpose/justification is explained very clearly, that it is easy to review; that the benefits of the change (explain those clearly) outweigh the long-term and also the short-term costs of integrating it. Similarly for feature requests or enhancement proposals: now is the time to focus on the uncontroversial things that are clear improvements, and to justify, explain them very clearly.
How?
It may not be immediately clear to people what “participate to the maintenance work” means concretely. Right now I see three obvious approaches.
- Subscribe to github/ocaml/ocaml notifications and jump in when you want.
- Look at our issues (258 open as I write this) and see whether you think can help. Maybe some are out of date / irrelevant and could be closed – say it. Maybe some bugs could be fixed, or some enhancement requests could be fulfilled. If you can, give it a try. It’s best to start with issues where the desired outcome is clear a consensual (a clear bug to be fixed, with no immediate downside; a small interface improvement that does not introduce much complexity and is well-justified; etc.), rather than work on some weird syntax proposal that will in turn require ample discussion and may be turned down in the end. (If you find a wonky proposal that failed to gather consensus and probably never will, it’s actually helpful to suggest closing the issue.)
- Look at our pull requests (246 open as I write this) and try to see whether you can help. Again, it’s best to focus on PRs where there is a clear motivation/need. Look at the code, feel free to ask questions on things you don’t understand or comment on aspects you don’t like so much. If the PR is stale, maybe it should be rebased (would you like to give it a try?), or there isn’t much that can be reused and it could be closed – feel free to say so.
We have received the feedback that those three approaches are still confusing to some people. In the upcoming weeks (probably in January) we will have more discussions about how to organize maintenance, to find more focused processes that encourage people to contribute in this way. I don’t think that there is a silver bullet, a magic process that will make it much easier, so I would encourage anyone interested to first some of the three basic approaches above and see if it works for them.
In my experience people often self-censor and do not try to react to PRs or issues that are not in their area of expertise. But most of the compiler codebase is in only a very few people’s area of expertise, the rest of us (myself included) just make do with their imperfect understanding and try to help anyway. Do not hesitate to walk into issues outside of your comfort zone, it is a great way to learn about the compiler distribution codebase.
Happy maintaining!
Results of the OCaml User Survey 2022
Kim Nguyễn announced
on behalf of the OCSF, I’m pleased to announce that the report on the OCaml User Survey 2022 is now available. Unfortunately, the results are not as meaningful as we would have hoped, since this instance of the survey attracted far less respondents than the previous one. On the upside, this allowed us to discover that some members of the OCaml community are expert in the fields, we hope to use their expertise to improve the whole process next time. It still allowed the OCSF to draw some preliminary conclusions, and highlight some pain points where the OCSF can maybe help improve the OCaml ecosystem as a whole.
Last, I would like to apologies since it took me an inordinate amount of time to process the results and release the report. While I have already gotten in touch with some people regarding next year’s iteration, if anyone would like to help (from proof reading to publishing in a more modern way than producing a PDF with latex), don’t hesitate to message me.
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.