I’m just back from the Mirage retreat, an event where people interested in Mirage meet for one week to work whatever they want. This retreat was organized by Hannes Mehnert as all past retreats, in Marrakech. Hannes ( @hannes ) asked participants to write a blog post to spread the word – hence this post.
a Mirage retreat, in general
The retreat is unlike most other professional events that I attend, typically academic conferences. We are hosted in a place that is otherwise used as a hostel within the medina, the old city centre of Marrakech. Bed comfort is minimal (a room of six people, two of them snoring), but there are people on-site who prepare food and the food is great. There is very little structure for the day: we had a meeting every morning after breakfast to mention what we had done the day before, and talk sessions in the evening (typically one or two talks for around 40 minutes).
The participants come in all shapes, some are regular contributors to the Mirage ecosystem and some (like me) know very little about Mirage. Some (like me) are very familar with OCaml and others know little about the language. Some people (not me) know about networking, security, system administration, communication protocols. The lack of structure encourages people to wander around, for example sitting alongside someone to try something new and learn along. Last time I ended up writing bits of a network driver in OCaml, despite knowing nothing about network drivers; this time I worked on model-based testing of filesystems (see Blog post: Using model-based testing on a Mirage filesystem implementation ), despite knowing nothing about file system implementations.
Morocco has better network connectivity than during my first retreats, but it remains somewhat flaky – and our network-usage habits keep increasing. In particular, I could not attend any online meeting, and this was very nice – just like conferences, it is liberating to be busy for one week uninterrupted. In the past I managed to adapt to low-network usage fairly well. This time I noticed that I depend on github a lot, and I don’t know how to have a good offline or network-restricted experience, to do code-reviews in particular. I wish offline version-controlled tools for code-review and bugtracking were more widely employed.
Overall I find this organization excellent: participants get a place and time to learn from each other, work on their own stuff and also get out of their comfort zone. I think it could potentially be used for other topics. For example people mentioned that it could be interesting to have a retreat focused on documentation in the OCaml ecosystem, and I find the idea interesting.
(The rest of this post is basically a narrated version of my work log for the week; please feel free to just skip it.)
My OCaml-focused work
One of my projects for the week was to take the time to review large pull-requests on the OCaml compiler that I wouldn’t dare attacking usually, because my agenda is perpetually full of other things. I did a first round of review on structured diagnostics, and additional reads through most of the modular explicits pull request (PR). In particular I wrote a small manual section for modular explicits, submitted as a separate PR. I hope to have moved from “it would be nice if these were reviewed someday” to a more short-term phase where I try to get these past the finish line before moving to other topics – but we never know.
I also went through the lists of PRs I had been assigned to, sometimes a while ago. (OCaml triagers assign PRs to each other to keep track of them and try to bring them to a decision, but in practice we often forget to do this and they linger around.) This was fairly effective and my stack of assigned PRs has been about cut in half:
- reviewed and merged:
- closed:
- immediacy computation revamp (@ccasin) #11841
- adopted and merged:
- generational stack scanning (@xavierleroy) #13594
- statmemprofs and bigarrays (@stedolan) #13675
- recursive module error messages (@shivam-909) #13608
- adopted but not yet merged
A few of those PRs I “adopted”, that is, I took control of the PR as the submitter would to rebase the PR and resubmit. In some cases this was mostly to apply my own review comments (sometimes someone else’s), the change were minor and I could merge quickly. In some cases the changes were more invasive, and I would ask for another review. In one case I got stuck and wasn’t sure how to rebase, so I asked the original author.
“Adopting” PRs in this way is a new process to me, I generally try to guide the authors through making all the changes themselves. I wanted to go through my stack faster, and in some cases I knew that the authors were unresponsive and unavailable to make those changes. I found it fun, but it is probably best reserved to this situation where authors are unavailable.
Side errands
I worked on a race between domain-termination and compaction: #14025. I decided to try to make Dune more pleasant for building the OCaml compiler, and sent a draft/RFC PR at dune#11819. I heard a remark that it’s painful not to be able to use lazy thunks anymore for library initialization code (lazy thunks are not concurrency-safe in OCaml 5); I tried to think about why this is hard to fall asleep again after a snoring attack, and ended up writing #14043 instead. I motivated myself into asking for volunteers to review the Relocatable Compiler work. I wanted to learn more about owi, and I implemented a small feature: owi#688.
I also participated as a speaker to two talk sessions in the evening. I did a short demo of Monolith and model-based testing in general – that was before we decided to use it on a Mirage filesystem. I talked about the OCaml Software Foundation and recent discussions around improving the security of the OCaml ecosystem.