With the newly released beta for OCaml 5.0.0, I will be spending more time looking at updating opam packages to make them compatible with OCaml 5.0 in the coming month.
As an experiment, I am planning to have an open hacking session for opam packages on Friday afternoon starting at 16h00 Paris time. If people are interested to join me to do some live opam package fixing, you are very welcome.
Currently, I am planning to work with a manually updated synchronization note at: Opam package hacking afternoon for OCaml 5: 2022/10/28 - HackMD .
We’ve been hard at work getting our
nix-overlays package set ready for OCaml 5.0 too!
Feel free to look into this file for specific Git commits / branches and patches applied on top of many of the existing packages.
Our exclusion list for OCaml 5 has been getting smaller almost every day since a few months ago.
How will you select which packages to help out? What happens to PRs that may never get merged for whatever reason?
I generalize try to fix my own handful of packages first, because I have packages on opam either strongly coupled to the compiler (
codept) or exercising specific feature of the type system (
Then I try to pick packages according to two priority axes:
- interesting failures
- number of reverse dependencies
As a compiler maintainer, I am often more interested by interesting failures that may reveal an issue in the alpha or beta release. At the same time, fixing packages with highest number of reverse dependencies is often the best strategy to discover those kind of interesting failures.
Unmerged PRs are mostly an unavoidable part of the exercise. Sometimes, a quick local fix is not the right fix. Sometimes, the package maintainers are currently busy, and they may not have the time to review and merge PRs.
Thanks for organizing that. I’ve added a couple of notes about opam-alpha-repository in the HackMD notes.
For those interested, there is now also a
#hacking-events room on the OCaml Discord server dedicated to the event. I should be there in voice chat as well if someone needs any help.
I looked at the 5.0 build failures and it looks like the vast majority is due to deprecation and removals that happened at the time of the 4->5 move, and nothing Multicore-related. Typically this breaks useful packages that are not actively maintained, and haven’t been updated earlier to fix the deprecation warnings. This is not unexpected – we took advantage of the 5 transition to do a good Spring cleanup, and now someone has to fix stuff or mark packages incompatible.
Bad news: it’s going to be slightly boring work for the most part.
Good news: it’s easy, does not require any multicore-programming expertise, and fun to do as a group.
Count me in
I have started my hacking session by cleaning my own packages:
and I am now fixing my
phantom-algebra library which was still using jbuilder (…) since the library is pathological test case for the typechecher.
At the end of the session, I have updated my
phantom-algebra package: [new release] phantom-algebra (1.0.1) by Octachron · Pull Request #22405 · ocaml/opam-repository · GitHub
I had a look at
ocaml-gsl, which is using many deprecated C functions. I have fixed the build, but there are some errors in the test due to failure to link the Unix module. It seems good idea to investigate the failure since this is probably linked to the change of layout for the library bundled with the compiler outside of the standard library.
I ran into the (possibly same) Unix issue during a release recently. The fix was pretty simple fortunately (adding
unix to the libraries stanza).
My own stories:
- I looked at
parmap and send PRs to fix issues. (They all come from deprecation warnings or old-deprecated-stuff-removal of 5.0, never from the Multicore aspect.)
- I looked at
build_path_prefix_map and spent most of my time porting my development branch from
dune, only to discover that @rgrinberg had done that years ago on the remote branch and I had forgotten to
pull before hacking.
- Then I looked at
cubicle and fixed various warnings. I got stuck at a performance-critical use of
Obj.set_tag, and started thinking about how to avoid it. I had the nagging feeling that I had seen this use before, in another automated-theorem-proving project. I implemented a solution (and many fixes to unrelated deprecation warnings), and went to submit a PR. At this point I realized that there were already two PRs opened for OCaml 5 support, from last February, one of which had been the occasion for me to discuss
Obj.set_tag in details with @vlaviron.
My conclusion: always remember to look at the upstream project first, before starting to hack on OCaml 5 support, because these days with the excellent work of @kit-ty-kate and others it is likely that the issue has been looked at already.