The week that was - 2025 w27
Rather varied week this week. A number of our EEG interns have started their work with us for the summer, with two nice projects falling under my direct supervision, with Lucas and Jeremy. It’s great to get to watch people start their first forays into the world of hacking on OCaml, once the customary “I was a baby when you started maintaining OCaml” comments et al are out of the way 😂 It’s also great to get to see the excitement, and reassuring to know that it is still an exciting thing to get to do for new people too!
The two projects are of particular interest to me. I’ve poked (and supervised
some other poking) at various aspects related to OCaml’s Load_path
, which is a
fairly innocuous-looking data structure at the heart of the compiler which is
simply responsible for mapping from names of files to locations based on the
provided -I
search directories. As ever, a simple-sounding operation but with
wide-reaching complexity and impact - it’s an interesting piece of code to want
to rip out and replace if you’re writing a JavaScript toplevel, for example (no
file system…); it’s a remarkably hot piece of code if you suddenly find that
your file system is being slow (hello Windows, occasionally…). First week on
this is mostly about settling in, becoming familiar with the vagaries of OCaml’s
build system and development workflow, but even in week 1 there’s an unexpected
nice piece of refactoring opening up. In ocaml/ocaml#11198,
as part of OCaml 5.0, we finally moved the extra libraries to separate
directories from the main Standard Library one but, to maintain compatibility,
you can still say #load "unix.cma"
from the toplevel, etc. but you get an
alert that you should added #directory "+unix"
beforehand (and, one day, you
might have to). The code for that is a bit fiddly because the Load_path
is
further down the dependency graph from the modules responsible for displaying
and processing alerts and warnings, so it had to be passed as a hook. It’s a
nice demonstration with effects that this warty bit of code becomes naturally
cleaner, as the actual lookup of files takes place much higher up in main.ml
where it’s completely natural simply to display the alert. More exciting things
to come with this.
The other project extends work I’ve poked at with changes like ocaml/ocaml#13745
where we start to take advantage of recent changes in the way Dynlink
is built
that mean it can be used for the main toplevel (a largely historical accident
means that we at present have two almost-but-not-quite identical ways of loading
bytecode into a running OCaml program…). Being able to
#load "my-numerical-library.cmxs"
in the Bytecode toplevel gives us the best
of worlds, hopefully - we get the power of native code for the library we’re
using and the flexibility and compilation-speed of the bytecode interpreter
for writing and experimenting around that library. You can do that at present
using ocamlnat (the native OCaml toplevel) but its compilation speed is slow and
other solutions such as the ocaml-jit project are not totally portable and not
particularly “drop-in”. I’m also really excited about the converse side of
this project - being able to run the bytecode interpreter in a native
program. Add the compiler frontend into your program, and what you have at that
point is the ability to embed OCaml as a scripting language into any program as
trivially as you can embed Lua, JavaScript, etc… so we might start to be able
to have a world where you can configure your complex application using actual
OCaml scripts but without needing OCaml to be on your end-user’s machine.
Needless to say, I have scheming ideas for how this might be highly useful in
opam packaging one of these days…
While working on the ever-overdue Relocatable OCaml at the weekend (the last prerequisite PR got merged on Friday, with thanks to Damien and Nicolás for the rubberstamp, and Antonin a while back for the deep-dive reviewing!), I discovered some broken stuff, following a rebase. Turns out it wasn’t me, and I’d been able to open ocaml/ocaml#14114 to fix the fault. Whilst checking that, I saw that the ppc64 port of OCaml appeared to be broken, but I just left that with a note on the PR. Some distant debugging on Monday with me connected to one of our POWER9 machines and Stephen Dolan suggesting tweaks to a broken test over Slack led us to ocaml/ocaml#14116 and a particularly humorous mantra of Stephen’s for investigating broken tests in OCaml:
- If it’s running too slowly, trying removing a zero from all constants in the test
- If it’s not working at all, trying add a zero to all constants in the test
Works a charm, as you can see from the PR…
In between times, I managed to give a performance at MedRen2025 in Newcastle, which has no connection to OCaml whatsover, beyond the amusing observation that it featured music written between c.1450 and 1528, which is just older than the opening sentence of my final-year undergraduate computer science disseration many years ago (which began, somewhat unusually, “In 1529, …”). We all managed not to get blown away at Fitzwilliam College for the EEG Garden Party, and Relocatable OCaml became a little less far from completion, but that’s for another post…