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.
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 (orec and phantom-algebra).
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.
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 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 jbuilder to 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.
