https://patrick.sirref.org/shelter/ shelter /shelter/ Shelter https://tangled.sh/@patrick.sirref.org/shelter A shim between a user and the shell that provides greater reproducibility and insight into what your code is doing! Give me Shelter! Shelter combines the caching and reproducibility of Dockerfiles with the ease of interaction of the shell. I'd be interested to use Ryan's package management work as a means to specify the base environment users want. Here is an example of running Shelter and making use of the branchable sessions. shelter> echo hello > hello.txt sheltermain#bbd691arw @ session exp-1]]>shelterexp-1#bbd691arw echo world >> hello.txt]]>shelterexp-1#dd5bab8rw @ session main]]>sheltermain#bbd691arw echo "to the" >> hello.txt]]>sheltermain#b9abef4rw cat hello.txt hello to the]]>sheltermain#d1c1728rw @ session exp-1]]>shelterexp-1#dd5bab8rw @ replay main]]>shelterexp-1#df1b4e1rw cat hello.txt hello to the world]]>shelterexp-1#67162b7rw]]> The @ character allows the user to interact directly with Shelter's build-in operators. @ session exp-1 creates a new session as there is no exp-1 session. It points to the head commit of the branch it came from (git checkout -b exp-1). From there we make changes and switch between branches until we perform a replay. A replay is a rebase without any merge conflict checks, it simply finds the least common ancestor of the two branches and re-applies the commits from your current branch (here exp-1) onto the head of the target branch (here main). Under the hood Shelter is a light-weight, reimplementation of obuilder. It uses the similar ideas, like snapshotting filesystems (e.g. ZFS) and Linux namespaces (e.g. Void). Between the low-level store and the interactive shell parts, there is an Irmin store. References Context Backlinks Patrick Ferris 2026 6 17 https://patrick.sirref.org/a-shell-is-born/ a-shell-is-born /a-shell-is-born/ A Shell is Born Merry passed a milestone this week after installing the following packages vim fakeroot fakechroot debootstrap and successfully performing a fakechroot debootstrap. To me, this signals that Merry is closer than ever to being an actual POSIX-ish shell. This is exciting because we now have a completely customisable, OCaml implementation of a shell that can run a significant number of existing shell scripts in the world. Let the hacking commence! Patrick Ferris 2026 6 17 Installation You can install the binary, msh, today: opam pin git+https://git.sirref.org/merry eval opam env msh Patrick Ferris 2026 6 17 What's next? There are a few avenues to try next. In the short-term, more testing of the shell is probably worthwhile. In particular, trying to boot an Alpine Linux image with msh as the default shell would be good. Integrating the various components of Shelter is also on the list. A time-travelling POSIX shell is within reach; the actual semantics still need to be ironed out. I know for certain that some shell options and built-ins will be the first issues to arise going forward. As a fun experiment, Anil's vibecoded OCaml busybox translation could be plumbed into msh. This would allow a very versatile, but zero-forking shell! Throw in an in-memory Eio filesystem into the mix and the whole thing becomes in-memory... mirageSH. Patrick Ferris 2026 6 17 Weeknotes Below are a collection of weeknotes for Merry. Patrick Ferris 2026 7 4 https://patrick.sirref.org/weekly-2026-w26/ weekly-2026-w26 /weekly-2026-w26/ Shell Benchmarks, Back to Writing A little late due to travel, but I did a little benchmarking of Merry. Patrick Ferris 2026 7 4 Signal Handling in Merry In order to even run shellbench, I first had to fix some bugs in the shell implementation. Shellbench aims to warm up the shell before starting any benchmarks; it includes this prelude before getting started: __ready= trap __ready=1 HUP kill -HUP " $ MAIN_PID " until " $ __ready " ; do __dummy= ; done Whilst writing Merry, I hadn't really considered that the return context from a trap needed to be taken into consideration! I had assumed they would be silently ignored, how else would we know where to thread that context back into the shell's execution. Even after reading through the specification for trap I am still none the wiser. I've opted to place some sensible signal polling points during the execution of the commands to run any signals that have come in. The single handlers in Merry simply push thunks onto a run queue. Looking at the Dash source code, it seems to be something that happens just before evaluation. Patrick Ferris 2026 7 4 Benchmarking Merry Patrick Ferris 2026 7 4 Medium-to-small potatoes I used shellbench to understand where some of the performance pitfalls were coming from. $ ./shellbench -s bash,zsh,msh sample/func.sh ----------------------------------------------------------------------------------- name bash zsh msh ----------------------------------------------------------------------------------- func.sh: no func 775,539 1,124,485 5,229 func.sh: func 398,861 197,169 93,424 ----------------------------------------------------------------------------------- * count: number of executions per second This particular benchmark first runs nothing (i.e. :) and then a function lookup and execution. Surprisingly msh is slower at doing nothing! I perf-ed a run of msh test.sh with just a single : in the file: Patrick Ferris 2026 7 4 Test built-in After making various improvements to Merry that almost halved the memory usage (e.g., removing extraneous string manipulations, adding a fast-path to the PATH variable for resolving programs). I was still pretty far off the performance of these other shells. I decided to have a look at dash which has a simple implementation. This flame graph is for the following shell script: f : ; while __count= $ __count + 1 && " $ __count " ; do f done echo " count is $ __count " And here are some rudimentary benchmarks: $ time -p dash test.sh count is 10001 real 0.01 user 0.01 sys 0.00 $ time -p msh test.sh count is 10001 real 15.53 user 4.28 sys 12.28 It turns out the massive slowdown is very simple to explain. In the dash flamegraph there is a oexpr stack; which comes from the bltin/test.c file. dash, along with the other shells, does not spawn a process for the -test command! Forcing dash to do use the binary gives: $ time -p dash test.sh count is 10001 real 7.55 user 3.95 sys 3.44 Which is much more respectable in terms of performance compared to msh. Plenty of work to do though! Patrick Ferris 2026 7 4 Parsing arithmetic expressions There was some obvious low-hanging fruit to help improve some of the performance differences. The first was pre-parsing arithmetic expressions. Morbig, the static parser, does not implement arithmetic expression parsing; so Merry does it for us. Before, it was on-demand, as we encountered an expression of the form $((<e>)). Now, it happens up front. This should improve tight-loops. Patrick Ferris 2026 7 4 Writing More on this soon, but I have started writing two separate papers bringing all of this work together. Patrick Ferris 2026 6 16 https://patrick.sirref.org/weekly-2026-w25/ weekly-2026-w25 /weekly-2026-w25/ Three weeks in the Shell The last three weeks have been focused work on building Merry. In practice, I wanted to run the following two commands through Merry's shell: msh: Seemingly innocuous. But both commands run thousands of lines of shell script. Whether that's Debian package maintainer scripts or state-machines for processing package release files. What follows is a handful of the bugs and the shell scripts that caused them. Patrick Ferris 2026 6 16 Field Splitting Edge-cases abound in the POSIX shell specification; and field splitting is one of the most serious perpetrators. Field splitting happens after word expansion. It is a known footgun amongst shell script authors. $ count echo " Count: $ # " ; ; FOO= " hello world " ; count $ FOO Count: 2 Quoting variables that need expanding will prevent field splitting from taking place, but it is an easy thing to forget. Field splitting uses the IFS (internal field separator) environment variable to determine how to do the splitting, and it comes with some extra rules beyond "split on these characters". $ IFS= " " ; FOO= " hello world " ; echo $ FOO hello world $ IFS= " " ; FOO= " hello world " ; echo " $ FOO " hello world $ IFS= " : " ; FOO= " a:b:c: " ; echo $ FOO a b c $ IFS= " : " ; FOO= " a:b::c:d " ; echo $ FOO a b c d $ IFS= " : " ; FOO= " :a:b:c " ; echo $ FOO a b c $ IFS= ; FOO= " unset IFS " ; echo $ FOO unset IFS Patrick Ferris 2026 6 16 Variable assignment How a shell stores variables also impacts field splitting. Naively, Merry stored variables as strings, but really they should be stored as their expanded form. Consider this example of saving a function output in a variable called base. iter echo " a " echo " b " echo " c " base= iter for n in $ base ; do echo " Got $ n " done for n in " $ base " ; do echo " Got $ n " done Later, when we come to iterate across the fields of $base we wouldn't be able to reconstruct the intial fields that $(iter) produced if we simply saved the result as a string. Too much information would have been lost. Patrick Ferris 2026 6 16 Redirections Redirections control what file descriptors point to. Each redirection has a lifetime associated with it. For example: cat < README.md really says "open README.md and execute the cat program mapping the process's FD 0 to the FD of README.md". When cat returns that redirection is no longer valid. Other redirections are not so simple. Consider: $ echo " !dlrow olleh " > input.txt $ read line ; echo $ line < input.txt | rev hello world ! There are lots of redirections here too. Firstly the standard input for everything inside the braced command (read line2; echo $line) should be the open file descriptor for input.txt. The standard output of the braced command should be the writing end of a pipe whose reading end is passed to rev as that process's standard input. The final standard output for rev should be unchanged from what it was originally (the shell's standard output). Getting redirections right is hard, consider this snippet from the debootstrap scripts (all in the context of stdout and stderr pointing to a debootstrap.log file and file descriptor 4 pointing at the true stdout). for m in $ MIRRORS ; do pkgdest= " $ TARGET / $ DLDEST pkg " $ s " " $ c " " $ a " " $ m " " $ path " " if ! -e " $ pkgdest " ; then continue ; fi pkgs_to_get= " download_debs " $ m " " $ pkgdest " $ pkgs_to_get 5>&1 1>&6 " if " $ pkgs_to_get " ; then break ; fi done 6>&1 Patrick Ferris 2026 6 16 More niche built-ins As the dust begins to settle on the nuts and bolts of implementing a POSIX-ish shell, new challenges are allowed to emerge from deep within scripts. One such challenge is the seemingly endless (I know, they're finite) shell built-ins! Whilst trying to run debootstrap using its fakechroot variant, I bumped into getopts... a whole command-line parsing shell built-in. Patrick Ferris 2026 6 16 https://patrick.sirref.org/eio_mem/ eio_mem /eio_mem/ An In-memory Filesystem for Eio Towards the end of last week and the beginning of this week, I threw together a prototype for an in-memory filesystem for Eio: Eio_mem. Concretely, this provides a means for constructing an Eio.Fs.dir_ty Eio.Path.t value that is completely in-memory. Thanks to Eio's capability-first approach, any existing code implemented against the _ Eio.Path.t API should just work with the in-memory filesystem. There's a convenient Eio_mem.Fs.load function that can take a path from one filesystem (most likely a normal one from Eio_linux or Eio_posix) and replicate it into the in-memory filesystem. For example, you might have a static web-server pointing to a directory like "/var/www". The following might be the only change you need to make it completely in-memory (example from ocaml-cohttp): let port = ref 8080 in Arg.parse ignore "An HTTP/1.1 server"; Eio_main.run @@ fun env -> + Eio_mem.run @@ fun menv -> Eio.Switch.run @@ fun sw -> - - let htdocs = Eio.Stdenv.cwd env in + + + let htdocs = Eio.Stdenv.cwd menv in let socket = Eio.Net.listen env#net ~sw ~backlog:128 ~reuse_addr:true The keen-eyed reader might have noticed the filter parameter. This can be used to ignore certain paths (here I ignored .git and _build which were adding substantial time to loading the filesystem). Patrick Ferris 2026 6 4 https://patrick.sirref.org/weekly-2026-w23/ weekly-2026-w23 /weekly-2026-w23/ Using meio to debug Merry During a large rewrite of Merry, I introduced a regression causing certain shell programs to hang indefinitely. I thought it might be a good opportunity to try out Meio. First, let's look at a trace of Meio from some real-world programs. For example: meio -- msh -c "sleep 100". One problem that comes up immediately from this example is that the tree hierarchy of tasks and cancellation contexts makes it tricky to reason about the logging. Here, we can see the pipeline's cancellation context clearly labelled pipeline-id1. This is an Eio.Switch.t for the pipeline sleep 100. The actual execution log for sleep 100 bubbles back up to the main fiber (that has no name, so it is called <task>). The daemon fiber, for ensuring the spawned process is reaped, is attached to the switch and is displayed below it. Meio has a long way to go. Most programs are too fast to be monitored in this way. Using something like tokio-console's model might be a better idea here focusing less on the tree strucuture of the program, and more on the performance and monitoring of individual tasks. Without this, it turns out Meio was not all that useful for debugging this specific issue (which ended up being some bad pipe management on my part). Patrick Ferris 2026 4 28 https://patrick.sirref.org/weekly-2026-w17/ weekly-2026-w17 /weekly-2026-w17/ Shell forks revisited Whilst I did get up to some other work last week, I decided to dedicate this weekly to fork-ing in the shell. Patrick Ferris 2026 4 28 Must we fork? I have spent some time trying to figure out: can you implement a shell that never has to fork and run its own code (as opposed to fork+exec-ing, which is necessary)? There are, at least, two bits of POSIX shell semantics that make this hard: concurrency and redirects, particularly in the presence of shell built-ins. Individual commands in a pipeline, according to the POSIX specification, will have their standard input and output connected up before other redirections. The standard input, standard output, or both of a command shall be considered to be assigned by the pipeline before any redirection specified by redirection operators that are part of the command. Additionally: ...each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. Where a subshell is defined as: Subshell: A shell execution environment, distinguished from the main or current shell execution environment. We will note that subshell child process. In practice, however, the two are used fairly interchangeably given the semantics of spawning a child process. Perhaps the two most crucial aspects of a given command in a subshell are that: It is run in parallel with the other commands. It should be reentrant. In what follows we will assume that we are discussing a multi-command pipeline . Patrick Ferris 2026 4 28 Pipeline parallelism The POSIX specification does not mandate parallelism explicitly for commands in a pipeline. However, in practice the semantics of a pipeline necessitate concurrency at the very least. Suppose we have where produces an infinite amount of output (e.g., cat /dev/urandom) and consumes a finite amount of input (e.g., hxd-xxd -l100). What is the result of running this pipeline with the default POSIX shell options? $ dash -c " cat /dev/urandom | hxd.xxd -l100 " 00000000: 5033 7981 ae44 d475 074c 5361 0a9e 3828 P3y..D.u.LSa..8 00000010: f88c 1f9e 3b0e bcde 528a f78c b1e4 7195 .... ; ...R.....q. 00000030: 57c5 680a 2c81 a999 71b6 708e 95df e720 W.h.,...q.p.... 00000040: 004c 407a 8365 9448 65c6 b435 bed2 4084 .L@z.e.He..5..@. 00000050: 62ea 96ab 2b23 0385 f9d2 fc30 d090 1719 b...+#.....0.... 00000060: 68d1 c514 h... cat: write error: Broken pipe There are three factors that influence the pipeline's execution behaviour (i.e. what is done about the commands that are run and the exit status we return). pipefail: With pipefail set to false (the default), the exit status of the pipeline is entirely decided upon by the exit status of the rightmost command (above ). With pipefail, the pipe will exit with 0 if all commands exit with 0; otherwise the non-zero exit status of the rightmost command is taken. !: If the pipeline begins with ! then this inverts the exit code in the way you might expect. All commands must terminate. Whilst in theory does not terminate, the termination of closes the reading end of the pipe resulting in the Broken pipe system error. Let's replace with the following compound command that also produces, left to its own devices, infinite output on stdout. while echo " some bytes " ; do : done | hxd.xxd -l100 In this example, we no longer have the luxury of being able to fork and exec. The compound command (the while loop) forces our hand -- we must rely on the internal execution logic of the shell to keep it going. How then do we prevent from blocking our shell from spawning ? For most shells, this is where they might fork themselves and allow the while loop to execute in the child. The parent continuing on. Alternatively, the work could continue on in a separate thread (in OCaml parlance, domain). Fibers (green threads, coroutines etc.) are only possible if there are a sufficient number of co-operative yields (which can be hard to track: any control flow or shell built-in would need to ensure they periodically yield to the other commands in the pipeline). With that being said, it would seem we have workarounds to ensure the parallel aspects of pipelines are possible to build without forking the shell state itself. Patrick Ferris 2026 4 28 Command Reentrancy Command reentrancy deals with the fact that commands in a pipeline run in subshells. In practice, this means any should not impact the execution environment of any other . Commands may certainly interfere with one another: a rogue rm might remove a file that some other command was about to read or was in the middle of reading! of the POSIX shell specification describes the execution environment. In Merry we lift this into the ctx type making it completely immutable; the only way to update the context is to destructively declare new fields, e.g., . All shell built-ins work directly from the context as opposed to any state that might also be kept by the process itself (e.g., we do not call getcwd(3) to expand PWD, but instead read it from the context). Most state is handled nicely by this functional implementation of the shell; except open (or not) file descriptors. The exec built-in is particularly thorny in this regard: If exec is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment. So, exec 3>&1 says "in the current execution environment map file descriptor 3 to stdout" and exec > /dev/null says "in the current execution environment map stdout to /dev/null. This is often used to silence anything writing to stdout. info echo " INFO: $ 1 " >&3 exec 3>&1 > /dev/null info " Starting up server... " echo " Some noisy program spamming STDOUT " info " All is quiet... " If we are not running shell built-ins inside new child processes, then we must lift the file descriptor table into the context as well and disallow any two built-ins to run in parallel. Consider this example: exec < ./hello.txt while read line ; do echo " Got $ line " >&2 done | exec < ./world.txt ; cat If we allow exec to change the set of open file descriptors of the shell process directly, then individual commands in the pipeline are no longer re-entrant. The pipeline here is not being used to pipe bytes from one command to another, but instead to expose concurrency and the subshell behaviour. The second exec < ./world.txt has no impact on the currently opened file on stdin, the while loop continues to read ./hello.txt. This is straightforward to implement with fork as you can dup2 any files you need. The bookkeeping and isolation is all provided by the POSIX process semantics. Without fork, the file descriptors would have to be saved and restored on every suspension and resumption to provide an illusion of isolation. We could relax our rule to "disallow any two built-ins to run in parallel" by taking a lock on the file descriptor table, but considering the lock is held from the point of resumption until the next suspension it might not achieve very much in practice. Some of the intricacies of scheduling are also covered in Michael Greenberg's An executable and formal semantics of the POSIX shell. To motivate the question, consider the following two pipelines: (1) while true; do echo 5; done | true (2) Both pipelines spawn two processes, both of which use shell builtins exclusively: neither of these pipelines needs to make an execve system call (though some systems may implement true or echo as executables, Smoosh and most shells build them in). Scheduling is an opaque part of the POSIX specification. Indeed, as we have argued here, there is no semantics for scheduling. Here is a similar pipeline run through a script that straces for clone and fork calls on various shells: It might make an interesting use case for effects in OCaml -- whilst we can certainly piggyback on Eio's existing suspension mechanisms, this is slightly different in that we need to ensure some preconditions are true before resuming certain computations. Fiber-local state is insufficient as programs implicitly depend on global state of the process (in particular the FD table). In this sense, we need some form of suspension-resumption hooks. Patrick Ferris 2026 4 3 https://patrick.sirref.org/weekly-2026-w14/ weekly-2026-w14 /weekly-2026-w14/ Forking in Shells & Library Maintenance This week, Merry got close to executing apt-get install ca-certificates and running Debian's debootstrap scripts correctly. Nathan and I released Ppxlib 0.38.0, I added support to ocaml-proj for compiling to the browser and I fixed a long-standing bug in hilite. Patrick Ferris 2026 4 3 Forking in Merry So far, Merry has managed to support many features of the POSIX shell specification without needing to do a fork(2) without an exec. Or, to put it another way, all the forking that Merry does, will only be followed by running C code. This is actually a feature of Eio's Process API. It is required to make process execution safe in the context of multiple domains in OCaml (mostly due to ensuring consistency within the garbage collector). However, it is perfectly okay to fork and run OCaml code provided there is only a single domain. In a shell, many features of the shell language require that commands (or built-ins, function applications etc.) execute within a subshell. The specification does not go into detail about how shells should implement this, but many choose to fork in order to preserve some state in the parent (for example, the file descriptor table). Some shells try to minimise the number of forks as an optimisation. The korn shell (ksh) is one such shell. Using the notation $(command) will cause command to execute in a subshell of the current ksh. In many instances, ksh will not actually fork/exec a subshell when command is a built-in or a shell function. By trying to adhere to Multicore OCaml's "thou shalt not fork" commandment, Merry is much more similar to ksh in this regard. However, whenever there is an interaction with a shell built-in and semantics that need a child process, things get tricky very quickly. Consider the following: while echo " hello " ; do : done | head -n 3 We have a mix of shell built-ins, normal commands, a compound command (the while loop) and a pipeline. Each individual command in the pipeline requires you to run them in a subshell and set them up before executing them. Without a fork for that first command, you may end up looping forever which is not the intended behaviour here. I had a good conversation with Michael about the implications of this for reproducibility. For now, I have started implementing a fork for some of the shell features whilst still trying to maintain the functional core of the implementation. Patrick Ferris 2026 4 3 An OCaml 5.5 compatible Ppxlib Nathan and I released an OCaml 5.5 compatible version of ppxlib. Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ Ppxlib Releases › 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! Patrick Ferris 2026 4 3 https://patrick.sirref.org/ocaml-proj-virt/ ocaml-proj-virt /ocaml-proj-virt/ Browser support for ocaml-proj A while ago I built some "modern" bindings to PROJ4 in OCaml. After reading Jon Ludlam's weeknotes (and speaking with him and Anil, I thought it might be nice to add a Javascript backend to those bindings). This was relatively straight-forward using Dune's virtual libraries and is available on Github. With virtual libraries, your own data analysis could (if you wished) depend solely on the proj library and later choose to either link it with proj.c or proj.js depending on where the analysis is being deployed. I briefly looked at WASM support, but quickly realised there was not much appetite for it and trying to compile around the C FFI was going to be hard. Patrick Ferris 2026 4 3 Hilite updates Since I helped relaunch the ocaml.org website a few years ago, I have maintained hilite, a tool for doing build-time syntax highligting. It is being used on the ocaml.org website, in yocaml_markdown and also in Michael's webplats (when it works...). And it was Michael who led me to finally fixing and adding syntax highlighting support for Python and Go. Once I was on this roll, I finally took a look at fixing the long-standing bug of trying to highlight ocaml-mdx code, like the following: # 50.123 ; ; # 1 " file.ml " ; ; In fact, this code now highlights fine, but was the source of the bug. The syntax highlighting grammer confuses the ocaml-mdx # as a toplevel directive and trouble ensues. Patrick Ferris 2026 3 30 https://patrick.sirref.org/weekly-2026-w13/ weekly-2026-w13 /weekly-2026-w13/ Ppxlib release and Merry updates Patrick Ferris 2026 3 30 https://patrick.sirref.org/ppxlib-release-0-38-0/ ppxlib-release-0-38-0 /ppxlib-release-0-38-0/ Ppxlib Releases › 0.38.0 Nathan and I released ppxlib.0.38.0 last week. Its main feature is full migration support for the upcoming OCaml 5.5 compiler (currently in its alpha3 release). This means supporting the handful of new features landing in OCaml 5.5: modular explicits, external type declarations and arbitrary "local" structure items. As Nathan and I continue to find a plausible maintenance story for ppxlib, Nathan has opened an issue on the OCaml compiler to discuss the idea of adding additional extension points to the language. This comes from the desire to be able to store encoded versions of new OCaml features inside older abstract syntax trees. There are also some nice bug fixes in there too: A potential OOM loop has now been removed. Locations have been restored to long identifiers! Patrick Ferris 2026 3 30 Merry updates It turns out writing a POSIX(ish) shell is hard; at least, there is a vast number of slightly obscure features that one needs to support. I think this is surprising because most people writing shell scripts write simple shell scripts; scripts that use a much smaller subset of features. In the same breath, those same developers are likely to use something like apt-get install bash which runs a plethora of more advanced (and non-POSIX) shell scripts! Patrick Ferris 2026 3 30 Exec redirects In a shell script, you can use the built-in command exec to replace the current process with a new one (e.g. exec vim). However, there is a different mode of operation for exec: If exec is specified with no operands, any redirections associated with the exec command shall be made in the current shell execution environment. One of my litmus tests for Merry is the Debian debootstrap scripts (h/t Anil). One thing that it does is the following: err printf " err $ 1 " >&4 exec 4>&1 A lot of detail has been elided for clarity. exec 4>&1 sets up a redirection for the shell's execution environment in which file descriptor 4 is now an alias for standard output. So, writing to 4 (by redirecting a command's standard output to 4 i.e. >&4) will output to where standard output is going (most likely the terminal). For this to work, shell's must dup2 the relevant file descriptors which have the following condition: If the file descriptor newfd was previously open, it is closed before being reused; the close is performed silently (i.e., any errors during the close are not reported by dup2()). This is all very well, unless your program has an important file already open that happens to have file descriptor 4. The Eio Linux and POSIX backends suffer from this problem. Both make use of a file-based synchronisation mechanism for waking up the eventloop should another domain push a completion to the scheduler's run queue. On Linux this is via an eventfd and in POSIX, a pipe. This dup2 will close the eventfd and will likely grind Eio to a halt (or an assert false). For now, I have resorted to vendoring Eio and moving the eventfd file descriptors to higher values, though I have opened a PR to make this more configurable. This bug is quite easy to write up... it was not so easy to find! As a random example, consider the debconf/confmodule script which offers very little room for a buggy implementation! Patrick Ferris 2026 3 30 Outreachy The presentations from the demonstrations for this round of Outreachy are now online! Patrick Ferris 2026 2 9 https://patrick.sirref.org/outreachy-ocaml-tiff/ outreachy-ocaml-tiff /outreachy-ocaml-tiff/ Write support in OCaml TIFF library I am mentoring Tambe Salome during the December 2025 Outreachy round to add support for writing TIFF files in the ocaml-tiff library. You can now see the video of the demonstration day presentation: Patrick Ferris 2026 3 19 https://patrick.sirref.org/weekly-2026-w12/ weekly-2026-w12 /weekly-2026-w12/ A POSIX Shell in OCaml Long time, no weekly. Since the start of this year I have been building a POSIX shell in OCaml called msh (with the underlying library called Merry). Merry is available online now. Patrick Ferris 2026 3 19 A POSIX(ish) shell in OCaml Merry is a POSIX(ish) in OCaml. It uses Eio alongside Morbig (a static parser for POSIX shell). Patrick Ferris 2026 3 19 Why another (POSIX) shell? Shells have been around for a long time. In my research on the notion of metashell I wrote about Louis Pouzin originally coining the term: Patrick Ferris 2025 5 19 https://patrick.sirref.org/pouzin-shell/ pouzin-shell /pouzin-shell/ Metashells › Louis Pouzin's "SHELL" I spent some time reading part of the multics design documentation this week. Louis Pouzin coined the term "SHELL" in this document, and I was reminded yet again just how important it is to be a good writer even as a "computer science researcher". For example, this excerpt from the requirements section of the document The previous definitions imply that a command MUST be designed while keeping in mind the user, sitting at his console, wondering about what might be going on, mistyping or forgetting arguments, even if fully aware of the conventions, and possibly interfering with the command by hasty quits, carriage returns, and other temperamental reactions. And then later, when defining the "SHELL". We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, inside of another program if it were called. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". It still surprises how little the undergraduate degree in computer science at Cambridge focuses on writing skills. I built Shelter exploring the idea of a shell-like interface that allowed users to undo their shell actions (amongst other cool tricks). Unfortunately shell-like is not enough. Shelter cut many corners to masquerade as a shell (e.g. appending env to understand how a command may have altered the execution environment). I felt it was necessary to make Shelter a "SHELL"! To do that, I needed a solid foundation to build on. msh, the POSIX shell that comes with Merry, is by no means POSIX-complete in terms of features. But it is my daily driver at this point. It includes a pure OCaml rewrite of linenoise (a small, self-contained alternative to the venerable readline) called bruit. If you have docker installed on your machine, you can take it for a spin today: The patrickferris/msh docker image is just for trying it out. It is based on the OCaml 5.3 alpine image. Alternatively, you can build msh from source and have it available in your opam switch. There are many small paper cuts left to patch over, but most of it is porcelain (e.g. ctrl+left-arrow for moving in bruit). Unfortunately, these are the kinds of things that you will immediately stumble upon. Patrick Ferris 2026 3 19 What makes Merry different? Nothing. Merry is supposed to be a solid, POSIX-ish base to build on. Unfortunaltely, as it turns out, the subset of features from the POSIX specification that people actually use... is pretty much all of it. Every possible redirection, variable expansion, shell built-in and compound command make some appearance. Not to mention the non-POSIX bits of shell we all take for granted (e.g. &>-redirection). Merry and msh are useable. You will most likely find bugs if you use them. If, when using msh, you find something obscure happening you can enable debug mode either my setting the variable MSH_DEBUG or by invoking msh with -v -v. Patrick Ferris 2026 3 19 What's next? It is soon time to combine Shelter and Merry into the time-travelling, POSIX-ish shell that I have been trying to build since I first started working on Shelter. For this to be successful, I need Merry to be able to pass plenty of tests and right now that involves trying to install plenty of packages using tools like apk and apt. Patrick Ferris 2026 3 19 Shell MRDT What I am particularly interested in reasoning about, is the execution context in Merry. This value, alongside the file-system, constitutes a fairly deep understanding of the state that changes in each step of a shell's evaluation loop. This was, in terms of Shelter, the missing piece for truly building some kind of MRDT across shell sessions. Patrick Ferris 2026 3 19 TIFF in OCaml I picked up from the excellent Outreachy work of Tambe Salome in getting write-support in ocaml-tiff. We are getting closer to the kind of API I envisaged in this latest round of refinement and review. let / = Eio . Path . / let checkerboard ~ size = let v = Nx . zeros Nx . uint8 size ; size in for row = 0 to size - 1 do for col = 0 to size - 1 do if row + col mod 2 = 0 then Nx . set_item row ; col 254 v done done ; Nx . to_bigarray v let = Eio_posix . run @@ fun env -> Tiff_eio . with_open_out env # cwd / " example.tiff " @@ fun w -> let tif = Tiff . make checkerboard ~ size : 256 in Tiff . to_file tif w I have also been extremely pleased to see further external collaborators appearing: Nicolas helping out with metadata maintainence. Virgile adding support for reading multi-image TIFF files. Patrick Ferris 2025 12 15 https://patrick.sirref.org/weekly-2025-w50/ weekly-2025-w50 /weekly-2025-w50/ Merry Shell(e)y Aside from a serious amount of admin, last week I decided to spend a majority of my time thinking about shells. Patrick Ferris 2025 12 15 What is a shell? There is no single definition of what a shell is or isn't. Patrick Ferris 2025 12 15 https://patrick.sirref.org/ai-blues/ ai-blues /ai-blues/ AI Blues Undoubtedly last week, I suffered a severe case of "AI blues" (for lack of a better description). I have been doing some thinking, trying to distil my own thoughts on what aspects of vibecoding seem to irk me so much. Ultimately, it seems it is more about attitudes than anything else. Patrick Ferris 2025 12 15 Exploitative Increasingly, I am finding that other people's vibecoded work is my problem. I have been an active participant in OCaml's outreachy work for going on five years now, and a problem mentors have to face is deciding the appropriate amount of help to give to your intern when they come to you with questions. More than likely, you could answer with specifics and solve the problem at hand. However, this doesn't scale very well and doesn't help your intern learn where else they may look for answers (e.g. Dune's documentation, a project's README page, OCaml's package explorer, heck even just using some simple CLI tools!) or how they might go about debugging a certain problem. LLMs, in my experience, make this problem worse. When they come up short, they can leave their programmer higher and drier than they would be had they hit a problem on their own. There is an inertia to understanding problems now that there's lots of code lying around. Turning to your colleagues has a few problems that it didn't before: Your colleagues don't know whose understanding they are correcting: yours or the LLMs? If it is the latter, there seems to me to be an exploitative quality to even asking for help until you yourself know what's going wrong. Patrick Ferris 2025 12 15 Technological Accelerationism There is no doubt that LLMs are pretty good at writing large amounts of okay code. The generation of this code, and often subsequent publishing of it, completely outpaces the ability to maintain it. Programmers may be able to release ten times more libraries than they could before, but at the moment, they certainly cannot maintain ten times more libraries than they could before. Scale -- Patrick Ferris 2026 3 19 https://patrick.sirref.org/weekly-2026-w12/ weekly-2026-w12 /weekly-2026-w12/ A POSIX Shell in OCaml Long time, no weekly. Since the start of this year I have been building a POSIX shell in OCaml called msh (with the underlying library called Merry). Merry is available online now. Patrick Ferris 2026 3 19 A POSIX(ish) shell in OCaml Merry is a POSIX(ish) in OCaml. It uses Eio alongside Morbig (a static parser for POSIX shell). Patrick Ferris 2026 3 19 Why another (POSIX) shell? Shells have been around for a long time. In my research on the notion of metashell I wrote about Louis Pouzin originally coining the term: Patrick Ferris 2025 5 19 https://patrick.sirref.org/pouzin-shell/ pouzin-shell /pouzin-shell/ Metashells › Louis Pouzin's "SHELL" I spent some time reading part of the multics design documentation this week. Louis Pouzin coined the term "SHELL" in this document, and I was reminded yet again just how important it is to be a good writer even as a "computer science researcher". For example, this excerpt from the requirements section of the document The previous definitions imply that a command MUST be designed while keeping in mind the user, sitting at his console, wondering about what might be going on, mistyping or forgetting arguments, even if fully aware of the conventions, and possibly interfering with the command by hasty quits, carriage returns, and other temperamental reactions. And then later, when defining the "SHELL". We may envision a common procedure called automatically by the supervisor whenever a user types in some message at his console, at a time when he has no other process in active execution under console control (presently called command level). This procedure acts as an interface between console messages and subroutine. The purpose of such a procedure is to create a medium of exchange into which one could activate any procedure, inside of another program if it were called. Hereafter, for simplification, we shall refer to that procedure as the "SHELL". It still surprises how little the undergraduate degree in computer science at Cambridge focuses on writing skills. I built Shelter exploring the idea of a shell-like interface that allowed users to undo their shell actions (amongst other cool tricks). Unfortunately shell-like is not enough. Shelter cut many corners to masquerade as a shell (e.g. appending env to understand how a command may have altered the execution environment). I felt it was necessary to make Shelter a "SHELL"! To do that, I needed a solid foundation to build on. msh, the POSIX shell that comes with Merry, is by no means POSIX-complete in terms of features. But it is my daily driver at this point. It includes a pure OCaml rewrite of linenoise (a small, self-contained alternative to the venerable readline) called bruit. If you have docker installed on your machine, you can take it for a spin today: The patrickferris/msh docker image is just for trying it out. It is based on the OCaml 5.3 alpine image. Alternatively, you can build msh from source and have it available in your opam switch. There are many small paper cuts left to patch over, but most of it is porcelain (e.g. ctrl+left-arrow for moving in bruit). Unfortunately, these are the kinds of things that you will immediately stumble upon. Patrick Ferris 2026 3 19 What makes Merry different? Nothing. Merry is supposed to be a solid, POSIX-ish base to build on. Unfortunaltely, as it turns out, the subset of features from the POSIX specification that people actually use... is pretty much all of it. Every possible redirection, variable expansion, shell built-in and compound command make some appearance. Not to mention the non-POSIX bits of shell we all take for granted (e.g. &>-redirection). Merry and msh are useable. You will most likely find bugs if you use them. If, when using msh, you find something obscure happening you can enable debug mode either my setting the variable MSH_DEBUG or by invoking msh with -v -v. Patrick Ferris 2026 3 19 What's next? It is soon time to combine Shelter and Merry into the time-travelling, POSIX-ish shell that I have been trying to build since I first started working on Shelter. For this to be successful, I need Merry to be able to pass plenty of tests and right now that involves trying to install plenty of packages using tools like apk and apt. Patrick Ferris 2026 3 19 Shell MRDT What I am particularly interested in reasoning about, is the execution context in Merry. This value, alongside the file-system, constitutes a fairly deep understanding of the state that changes in each step of a shell's evaluation loop. This was, in terms of Shelter, the missing piece for truly building some kind of MRDT across shell sessions. Patrick Ferris 2026 3 19 TIFF in OCaml I picked up from the excellent Outreachy work of Tambe Salome in getting write-support in ocaml-tiff. We are getting closer to the kind of API I envisaged in this latest round of refinement and review. let / = Eio . Path . / let checkerboard ~ size = let v = Nx . zeros Nx . uint8 size ; size in for row = 0 to size - 1 do for col = 0 to size - 1 do if row + col mod 2 = 0 then Nx . set_item row ; col 254 v done done ; Nx . to_bigarray v let = Eio_posix . run @@ fun env -> Tiff_eio . with_open_out env # cwd / " example.tiff " @@ fun w -> let tif = Tiff . make checkerboard ~ size : 256 in Tiff . to_file tif w I have also been extremely pleased to see further external collaborators appearing: Nicolas helping out with metadata maintainence. Virgile adding support for reading multi-image TIFF files. Patrick Ferris 2026 2 9 https://patrick.sirref.org/fellowship-roundup/ fellowship-roundup /fellowship-roundup/ Fellowship Roundup Patrick Ferris 2026 2 9 Overview February is the final month of my current six-month fellowship work with Tarides. A lot of the work can be summarised by reading the roundups (see October, November, December and January). I have been writing throughout the fellowship. However, they do not quite capture all the work I have been doing. Below, I pick individual projects and expand on them more holistically rather than pointing at individual PRs or issues. Patrick Ferris 2026 2 9 Ppxlib Most of my time over the past six months has been devoted to ppxlib maintenance. A large proportion of this time has been solo development work. Ppxlib is a cornerstone library of the OCaml ecosystem (whether people like it or not). Moreover, it is completely invaluable to Jane Street too. Like other AST-based tools (e.g. ocamlformat, merlin), ppxlib must follow a regular release schedule to support newer compilers. During the years of multicore OCaml development, ppxlib maintenance was a little easier as the Parsetree rarely changed. However, since then, the same cannot be said. Since OCaml 5.2, here are just some of the Parsetree changes: Functions are represented according to their arity. Local module opens on types. Effect syntax. Modular explicits. External types. Locations for all parts of long identifiers. Labeled tuples. In a perfect world, each of these require a codec for serialising the feature into ASTs that do not support the feature, plenty of tests and new Ast_builder/Ast_pattern functions for using the feature. Nathan and I have been managing pretty well I would say, though we are not getting any technical debt work done. Patrick Ferris 2026 2 9 Outreachy As the OCaml coordinator for Outreachy I have been running the latest December 2025 round. We are lucky to have four projects on the go! Thibaut Mattio is mentoring two projects: an ML dashboard for Raven and an OxCaml backend for Raven. Xvw is mentoring a Yocaml project. I am mentoring a Geocaml project. Patrick Ferris 2026 2 9 Eio During my work on tools like Shelter I have made a few improvements to Eio including: A draft PR for incremental reading of directories. New fork actions for processes: setgid, setuid and process groups. Utility functions for overriding standard environments. Fixing documentation. Patrick Ferris 2026 2 9 OxCaml I have enjoyed my work on OxCaml went it has happend. I think a few tools have been useful including the try-oxcaml work. David and I also had fun at ICFP discussing some quick experiments related to io_uring and OxCaml. One road-blocker here is the comparative amount of time spent trying to keep the OxCaml ecosystem working. Given my limited time working on fellowship projects, the rate of change of OxCaml (including the opam ecosystem) meant most of the time was spent making it just work, not exploring or experimenting with the features themselves. I think this has got better in recent months and perhaps jumping back in I would be surprised at the progress that has been made there. Patrick Ferris 2026 2 9 Forester Tarides are funding some work on forester. This site uses forester by way of graft and I have spent some time working on these tools during the fellowship. This includes a bytesrw-based bibtex library in OCaml that could be released soon. Patrick Ferris 2026 2 9 Papers I had the great fortune of attending ICFP where I presented two talks and was co-author on a few others too. Anil Madhavapeddy David J. Scott Patrick Ferris Ryan T. Gibb Thomas Gazagnaire 2025 https://patrick.sirref.org/madhavapeddy2025docker/ madhavapeddy2025docker /madhavapeddy2025docker/ Functional Networking for Millions of Docker Desktops (Experience Report) Reference https://dl.acm.org/doi/10.1145/3747525 Proc. ACM Program. Lang. 10.1145/3747525 Anil Madhavapeddy David J. Scott Patrick Ferris Ryan T. Gibb Thomas Gazagnaire 2025 Abstract Docker is a developer tool used by millions of developers to build, share and run software stacks. The Docker Desktop clients for Mac and Windows have long used a novel combination of virtualisation and OCaml unikernels to seamlessly run Linux containers on these non-Linux hosts. We reflect on a decade of shipping this functional OCaml code into production across hundreds of millions of developer desktops, and discuss the lessons learnt from our experiences in integrating OCaml deeply into the container architecture that now drives much of the global cloud. We conclude by observing just how good a fit for systems programming that the unikernel approach has been, particularly when combined with the OCaml module and type system. Patrick Ferris 2025 https://patrick.sirref.org/ferris2025scientific_programming/ ferris2025scientific_programming /ferris2025scientific_programming/ What we talk about when we talk about scientific programming Reference https://watch.eeg.cl.cam.ac.uk/w/aYXqXLtgQawYMjVXjSQtjx Patrick Ferris 2025 Abstract Programming for the planet undoubtedly involves programming scientifically, but what kind of programming are we talking about and what makes it scientific? In what ways does it differ from other forms of programming, if at all? Is scientific programming, data science or machine learning fundamentally different to constructing a compiler or building a high-throughput web server? By considering how the scientific method (with its falsifiable hypotheses and repeatable and reproducible experiments) relates to scientific programming, I hope to explore how computer science and traditional programming techniques are coming up short in meeting the requirements of scientific programmers. Patrick Ferris Anil Madhavapeddy 2025 https://patrick.sirref.org/ferris2025hazel_of_ocaml/ ferris2025hazel_of_ocaml /ferris2025hazel_of_ocaml/ Generating a corpus of Hazel programs from ill-typed OCaml programs Reference https://patrick.sirref.org/var/tyde2025.pdf Patrick Ferris Anil Madhavapeddy 2025 Abstract When developing a new programming language, having a large corpus of both correct and incorrect programs allows language designers to test and explore the capabilities of their new language. However, bootstrapping such a corpus of incorrect programs is time-consuming and arduous. We therefore explore how to reuse code from more mature languages to generate a corpus of ill-typed code for newer ones. We have developed a compiler to Hazel, an emerging language with typed holes, from the more mature OCaml ecosystem. We find it practical to generate a comprehensive corpus of ill-typed programs for Hazel development, and discuss future larger scale efforts towards bridging ecosystems. See also the online hazel of ocaml compiler Max Carroll Anil Madhavapeddy Patrick Ferris 2025 https://patrick.sirref.org/carroll2025decomposable_type_highlighting/ carroll2025decomposable_type_highlighting /carroll2025decomposable_type_highlighting/ Decomposable Type Highlighting for Bidirectional Type and Cast Systems Reference https://maxcarroll0.github.io/papers/workshops/HATRA-decomposable-type-highlighting/ Max Carroll Anil Madhavapeddy Patrick Ferris 2025 Abstract We explore how to provide programmers with an interactive interface for explaining the process by which static types and dynamic casts are derived, with the goal of improving the debugging of static and dynamic type errors. To this end, we define mathematical foundations for a decomposable highlighting system within a bidirectional system, and show how these can be propagated through dynamic types in a cast system. Our prototype implementation in the gradually typed Hazel language includes a web-based user interface, through which we highlight the importance of type level debugging. Michael Winston Dales Alison Eyres Patrick Ferris Francesca A. Ridley Simon Tarr Anil Madhavapeddy 2025 https://patrick.sirref.org/dales2025yirgacheffe/ dales2025yirgacheffe /dales2025yirgacheffe/ Yirgacheffe: A Declarative Approach to Geospatial Data Reference https://dl.acm.org/doi/10.1145/3759536.3763806 10.1145/3759536.3763806 Michael Winston Dales Alison Eyres Patrick Ferris Francesca A. Ridley Simon Tarr Anil Madhavapeddy 2025 Abstract We present Yirgacheffe, a declarative geospatial library that allows spatial algorithms to be implemented concisely, supports parallel execution, and avoids common errors by automatically handling data (large geospatial rasters) and resources (cores, memory, GPUs). Our primary user domain comprises ecologists, where a typical problem involves cleaning messy occurrence data, overlaying it over tiled rasters, combining layers, and deriving actionable insights from the results. We describe the successes of this approach towards driving key pipelines related to global biodiversity and describe the capability gaps that remain, hoping to motivate more research into geospatial domain-specific languages. I had some great conversations with KC too with respect to my current research. Patrick Ferris 2026 2 9 Future Work As I enter my final year of the PhD, my goal would be to try and align more of my fellowship work with my own research wherever it makes sense. This research focuses on the following hypothesis: Embedding deep provenance tracking, reversible execution and mergeable histories directly into an interactive programming environment (a POSIX-like shell) greatly decreases the gap between exploratory scientific work and reproducible, publishable results; all whilst leaving existing workflows intact and being programming language agnostic. I want to focus on building these tools using Irmin, Eio, OxCaml etc. There are other projects I wish to continue regardless, like Outreachy, though just as a coordinator (not a mentor). Patrick Ferris 2026 2 9 Overlapping PhD Work There are multiple projects that overlap with my work. For example, Irmin, which I wrote a retrospective for. This is at the core of Shelter and suggests an extremely valid use case for a brancheable, mergeable database. In addition to this, continuing to work on Eio makes sense to me too. Eio currently has no maintainer and no active development, but the issues are piling up. In particular, I am making heavy use of Eio in Merry, a POSIX(ish) shell written in OCaml. Aside from research angles on brancheable and mergeable shells, I am also quite interested in how this might look in terms of OxCaml. I met with Anil and Thomas recently to discuss the future of Eio and there was some agreement that we are all heavy users of it and hope to keep up its maintenance and set of features. One large piece of work that is sorely needed here is moving Eio to bytes and not bigarray-backed Cstructs. Any libraries using bytesrw (e.g. jsont) incur an extra copy of data into and out of the bytes. Anil has been working on some of the pieces recently to make this better! Patrick Ferris 2026 2 9 Maintaining and Releasing my own libraries I have published quite a few OCaml libraries in my time, below is just a few libraries (filtered to not include OCurrent projects). Some of these are used in the community including hilite, ppx_deriving_yaml and the multi-codecs. I would like to do some general maintenance of some of these tools and release a few iterations of graft which now makes use of bib. Patrick Ferris 2026 2 9 Ppxlib Maintenance By far, maintenance of ppxlib takes up a majority of my time. I think, given the other work I need to focus on, it would be great to try to minimise the amount of time working on ppxlib. In particular, perhaps only maintaining ppxlib as far as OCaml release-readiness is a possibility and important bug fixes (like the OOM bug reported by Jane Street). Patrick Ferris 2026 2 9 Forester, Graft and Writing With all of this work, I am eager to communicate what I am up to and my thoughts on open source, OCaml, OxCaml etc. I am glad to be using Forester to do this, particularly as it is written in OCaml (and could make great use of my own work on Eio). I hope to continue working on Graft and related tools like bib. But I would also like to start writing some long-form content similar to the Irmin retrospective. Patrick Ferris 2025 11 15 https://patrick.sirref.org/weekly-2025-w46/ weekly-2025-w46 /weekly-2025-w46/ Shelter imports Most of this week was spent fixing bugs in Shelter in an attempt to get it ready to run the LIFE pipeline. To do so, Shelter requires a mechanism by which to pull in files from the outside world. That could be configuration files, source trees, data etc. For now, this has taken the form of a crude @ import statement. In true Forester fashion, I have transcluded the foreign tree from my Shelter logs. https://shelter.sirref.org/Shelter Programmers/ 2025 11 16 https://shelter.sirref.org/shelter-log-001/ https://shelter.sirref.org/shelter-log-001/ https://shelter.sirref.org/shelter-log-001/ Import statements Welcome to the first Shelter log! In this log I will explain the work I have been doing to add an @ import meta-command. The syntax thus far is relatively straightforward. ]]> There are a few key principles underlying @ import. It should be at least as expressive as Docker's COPY ... command. It should deal with a wider variety of import sources. In addition to local https:// archives over ssh etc. Imports, where possible, should be catalogued and shared across sessions. https://shelter.sirref.org/Shelter Programmers/ 2025 11 16 URIs as Sources branch already allows users to import local files and directories into their session. For example: By allowing arbitrary URIs in the import command, we hope to force users away from downloading data via curl or python scripts. Lifting these side-effectful imports into Shelter allows us to manage the data in a much cleaner fashion. https://shelter.sirref.org/Shelter Programmers/ 2025 11 16 Scripts as Sources One idea I had was to allow users to invoke scripts as there "import source". Something like: And using the same eBPF tracing we use during normal execution we can capture a fairly good idea of the tools and files needed to perform an import. https://shelter.sirref.org/Shelter Programmers/ 2025 11 16 Sharing Imports One example of better data management is that Shelter imports can be When a user imports some data, they can optionally name that piece of data. For example: Shelter stores that away and makes a link between the name, the URI and the underlying data. A user may then import the same piece of data into a different session by simply writing: intent via the naming scheme, it makes it possible to then version the data and have a means by which to update said data, one could imagine: Which will retry the original URI and see if the data has changed, or if it has not. There is an implicit versioning number that users can specify in the name should they choose to. Patrick Ferris 2025 11 15 https://patrick.sirref.org/eio-cap-debugging/ eio-cap-debugging /eio-cap-debugging/ Eio Debugging One of the promises of Eio's capability model is an improved debugging experience. Your program must be designed in such a way as to make resources explicit. If you have a load_config function, more than likely it will need access to the file-system. val load_config : _ Eio . Path . t -> Config . t Once all of your resources are explicit and threaded through your program, it becomes much easier to swap out one resource for another (provided they have the same interface). This week I was trying to get the LIFE pipeline running in shelter. Part of that involves pulling the appropriate geospatial container image, but my code was terrifically broken, failing with what looked to me with a Docker error. With only this clue, I knew that it was probably in the execution of some command in a child process, but which one? To trace this quickly, I could plug in a slightly different instance of the _ Eio.Process.mgr capability. Essentially unchanged from the one provided by the unix backend except that it would also print to stderr the command it was trying to run! let debug_process_mgr mgr : 'a Eio_unix . Process . mgr : 'a Eio_unix . Process . mgr = let module D = struct type t = unit let spawn_unix ~ sw ? cwd ? pgid ? uid ? gid ~ env ~ fds ~ executable args = Eio . traceln " Spawning subprocess... " Fmt . list string args ; Eio_unix . Process . spawn_unix ~ sw ? cwd ? pgid ? uid ? gid mgr ~ env ~ fds ~ executable args end in let module V = Eio_unix . Process . Make_mgr D in Eio . Resource . T , Eio_unix . Process . Pi . mgr_unix module V Whist there is a fair amount of jumping through first-class-module-shaped hoops here, all I am doing is rewrapping an existing "method" to a spawn a unix child process. Then using this helper function, I can push that into my standard environment. let env = Eio_unix . Stdenv . with_env ~ process_mgr : debug_process_mgr env # process_mgr env in Shelter . main config env : > _ Shelter . env dir cmd_file And sure enough I was querying for the Docker user before pulling the image! I hadn't run into this, as for the last while I have been using alpine and debian images that already exists locally. Patrick Ferris 2025 11 10 https://patrick.sirref.org/weekly-2025-w45/ weekly-2025-w45 /weekly-2025-w45/ Taking stock & Graft updates I ended up working on a real mix of things last week. I managed to get two large posts uploaded to this site: an ICFP recap and a deeper-dive into the random bits of OCaml hacking. This was pretty useful in terms of taking stock of where I was at, I always find post-conference, I'm a little lost. The conversations and ideas from ICFP are simultaneously exciting but also pretty inactionable. Patrick Ferris 2025 11 10 https://patrick.sirref.org/graft-updates/ graft-updates /graft-updates/ Graft Updates It would seem that there is a potential second user of Graft! A great source of motivation for some tidying and feature implementing. At the end of last week I fixed some little bugs in Graft and (more importantly) allowed users to name their subtrees. Upstream Graft also now pins and uses my Bibtex implementation. Patrick Ferris 2025 11 10 OCaml Geotessera As I discussed in my OCaml roundup, I spent a bit of time polishing the OCaml geotessera code. In particular this meant starting to handle low-level geospatial transformations allowing users to project latitudes and longitudes into the rows and columns of their raster data. I feel like I'm stumbling onto a path Michael has carved out with Yirgacheffe. I'm following along with his work excitedly and we had a good catch-up last week discussing how libraries should handle things like automatic, numeric precision conversion. As a fully paid-up member of the static types fan club, I'm often evangelising the benefits of types. However, I hit a little quirk of the Nx library in OCaml (a numpy equivalent). Take a look at this sum function: let sum nx = Nx . sum nx |> Nx . item ; ; val sum : 'a , 'b Nx . t -> 'a let arr = Nx . create Nx . int8 2 64 ; 64 ; ; val arr : int , Bigarray . int8_signed_elt Nx . t sum arr ; ; - : int = - 128 Even though sum takes an ('a, 'b) Nx.t array that stores elements with representation 'b and allows you to read/write to the elements with OCaml values of type 'a, the sum function performs the calculation in the world of the 'b representation type (here signed 8-bit integers). So we get an overflow! Perhaps not too surprising but easy to overlook! The moral of the story is that we still need to be careful in the OCaml world too. Patrick Ferris 2025 11 10 Shelter I did a little cleaning up of the Shelter code too. I noticed a few bugs from the demos I did at ICFP. Most were pretty straight-forward to fix, and the test-suite is now checking parallel for-loops and conditional execution are working. Patrick Ferris 2025 11 10 This week I hope to get a few things done this week: Run some part of the LIFE pipeline through Shelter. Deploy the Shelter daemon allowing other people to connect and take it for a spin. Spend some time writing and reading, pulling ideas together rather than always writing code! I have a slightly harebrained scheme that combines Shelter, atproto, Forester, capn(proto/web) and webcomponents... I want to see if I can pull that together. Patrick Ferris 2025 10 24 https://patrick.sirref.org/icfp-2025/ icfp-2025 /icfp-2025/ ICFP 2025 Two weeks ago I was fortunate enough to attend the International Conference on Functional Programming in Singapore. My first time in Asia and my second time at the conference, what follows are some thoughts and presentations I enjoyed whilst I was there. I must thank my office mate (and friend!) Ryan Gibb for his camaraderie and sage advice: "the best track is hallway track". Not to mention all of his photos too. Thanks Ryan! From right to left, top to bottom: Anil Madhavapeddy, Sadiq Jaffer, Patrick Ferris, Ryan Gibb and Roy Ang. Patrick Ferris 2025 10 24 Random Hacking Below are just some of the pieces of random hacking I got up to whilst in Singapore. Patrick Ferris https://patrick.sirref.org/oxcaml-and-uring/ oxcaml-and-uring /oxcaml-and-uring/ OxCaml and Uring Jane Street were a big presence at ICFP 2025, carting along with them a shiny new OCaml compiler: OxCaml. If have been playing around with OxCaml recently but nothing outside toplevels in Javascript. Until now! After talking to David, I spent some time converting a small corner of the ocaml-uring library to use a part of OxCaml. In particular making the following change: module Heap = struct type ptr = int32 # ... end type cqe = user_data_id : Heap . ptr ; res : int32 # ; The idea being that a completion queue entry (a notification that some operation has completed) could be fully represented using 64 bits (two 32-bit, unboxed values). You can see how this impacted the library! I'm not certain about this change (and I'm sure I did it wrong) but it was nice to realise OxCaml gives you this kind of control. However, I am worried about the ergonomics of manipulating values like int32# and the temptation to case it into an int (presumably losing a good portion of the value of having an unboxed value in the first place). Patrick Ferris 2025 10 24 Bibtex Parser On the flight over to Singapore, I started to write a post for this website. Some readers may remember that I use forester after a preprocessing step via graft to build this site. Part of that preprocessing consumes bibtex files and outputs forester trees. For the initial graft release I used the excellent Talaria Bibtex library. Unfortunately, it presented a pretty confusing API that, whilst nicely typed, felt a little cumbersome to use. Additionally, it was too specific in what it would accept as valid Bibtex. I wanted something that was a little more straight-forward to use (if a little fast-and-loose when it comes to types...). And so I built bib. This was my first real attempt at using the Bytesrw library. I was happy with the results, although I did have to copy a substantial amount of code from other bytesrw-compatible libraries. I'd be happy to shift to this bytes-first world if it wasn't for the ever-present-in-my-mind issue of relocatable values in the OCaml heap! Patrick Ferris 2025 10 24 Geocaml Libraries There has been some excellent outreachy work happening on the geocaml/ocaml-tiff library which is a potential Outreachy internship project for December 2025. More on this in a future post. On the way back (and a little during the conference), I spent some time building an OCaml counterpart to geotessera, a library for working with Tessera. The library is not ready for people to use directly, but I was working on various constituent parts including: Modern OCaml bindings to PROJ (a coordinate reference system projection library) Further work on a WKT library for OCaml Coming soon... ocaml-geotessera Patrick Ferris 2025 10 24 Talks Patrick Ferris 2025 10 24 Hazel of OCaml at TyDe The type-driven development (TyDe) workshop was held on the first day of ICFP at the NUS School of Computing. I find the workshop name to be a little misleading, but perhaps this comes from my engineering background. The talks focused a lot on type theory, presenting the formal mathematics of interesting type systems with less focus on why it might be useful to have such an exotic type system... but then again, that was the nature of the entire conference. I presented a talk on hazel_of_ocaml. The slides are here, along with the extended abstract. My talk ended up focusing a lot on the pedagogical benefits of having a type system that helped explain the most important thing a type system does... catch type errors! This work represents a small piece of work inside Max Carroll's excellent part II project, which he presented at the HATRA workshop: Decomposable Type Highlighting for Bidirectional Type and Cast Systems. Patrick Ferris 2025 10 24 Scientific Programming at PROPL I think it is important to be honest whenever you get a talk accepted that you otherwise feel should not have been. My talk "about scientific programming what we talk about when we talk" is one such talk. The slides are here. The talk itself was nothing to write home about, but I think there were a few nice ideas that came out of it and the conversations I had with fellow PROPL attenders. Patrick Ferris 2025 10 24 TMF Data Discrepancies Redux On the eve of my talk, I decided to re-run some analysis I did a few years ago on the tropical moist forest dataset, knowing that since then a few more years had become available. After fighting with some bit-rot in the Google Earth Engine script I had used, the new results were not very uplifting. Land Use Class Percent Change Undisturbed  -2.9 Degraded  -5.5 Deforested  8.6 Regrowth  0.5 Water  0.0 Other -0.6 The data in the table corresponds to the land use class values in Indonesia in the year 2008. The analysis computed the difference across each of the classes between the dataset released in 2021 and the dataset released in 2024. Most notably, the amount of deforested land has gone up by 8.6 percent! As a somewhat tangential, though related, aside, I had the pleasure of talking to Sam Westrick, Seong-Heon Jung and Sundara Vishnu Satish of the ParCour research group. They were telling me about MaPLe, a programming language from the MLs built for parallelism. We discussed some ideas of using real-world, geospatial algorithms as benchmarks for MaPLe. Michael, if you got this far remind me to chat to you about this! Patrick Ferris 2025 10 24 Shelter Reactions At the end of my talk, I briefly mentioned shelter. By far, this was the topic I got the most engagement on post-talk. During the conference, this was also true when people asked what I was working on. The tag line "a shell with undo" seemed to capture the attention of most people. I'm feeling a renewed sense of interest in my own work thanks to that, even if the "research" contributions are not very apparent. However, I also had a good discussion with KC about the underlying MRDT in Shelter and how we might think about collaborating in the future on MRDT-related work. Related to that, I managed to spend the evening in Chinatown with Roly Perera. Roly's work has focused on Fluid, a transparency-based programming language that allows authors to reveal their computation to their user. Excitingly, Roly presented a new text-based part of the language at PROPL. Our work is in the same universe, loosely orbiting some notion of reproducibility and explainability, but quite different in engineering work and how users might actually interact with our systems. I thoroughly enjoyed talking about solutions or research ideas that preserve existing workflows. Roly was great at pulling that out of the current work I have been doing. Patrick Ferris 2025 10 24 Other Talks and Highlights I was a part of, often in a very small way, some other talks that were presented at ICFP including Functional Networking for Docker, I encourage you to read Anil's notes on the topic. It is also worth mentioning Anil's post-posix talk (not unrelated to my Uring musings above). Michael gave an excellent, very live, talk about Yirgacheffe at PROPL which I thoroughly enjoyed. I'm also excited about his recent developments which I'm sure you can clue into over on his blog. Below is a non-exhaustive list of talks I enjoyed whilst at the conference. Some relevant, most of them not! By far, one of the best talks was Polynomial-time Program Equivalence for Machine Knitting. I think the talk really nailed the "here's the idea, the details are in the paper"-presenting style as they described an "...algorithm that canonicalizes the algebraic representations of the topological semantics of machine knitting programs". I attended most of the OxCaml tutorial presented by the incredibly friendly Gavin Gray. Ryan's talk Spatial Programming for Environmental Monitoring at PROPL was excellent. There's plenty more to talk about, and I'm sure my future posts will reference other parts of my experience at ICFP 2025. Thanks for reading, and if anybody is interested in any aspects of this do reach out! Patrick Ferris 2025 9 2 https://patrick.sirref.org/ocaml-weekly-2025-w32-w35/ ocaml-weekly-2025-w32-w35 /ocaml-weekly-2025-w32-w35/ OCaml Weekly 2025 w32 to w35 I have been working on a few different OCaml-related projects over the last few weeks. This is also coinciding with my partner and I moving across the UK, which has made finding time to write weeklies and posts a little tricky. Nevertheless, here are some of the things I have been thinking about and working on! I managed to publish one signficant post this month: a retrospective on Irmin. Patrick Ferris 2025 9 2 Eio Increasingly, I'm feeling the dream of a unified framework for asynchronous IO slipping through the OCaml community's fingers. It is perhaps not such a bad thing, and I think with the right library authoring we can at least get to a place where it isn't so bad, for example providing read functions as opposed to using an opinionated IO library directly. That being said, I am a very happy user of Eio when those choices do not matter, as is the case in building your own application (e.g. Shelter). To this end, I have spent a good bit of time upstreaming support for various missing pieces in Eio's API including: Setuid and setgid fork action's for the process API. Set process group support for job control in the process API. Responding to Buf_write.of_flow request, and tinkering with the example there. I think this does highlight the awkwardness of making code portable across concurrency mechanisms, particularly with Eio's structured concurrency. I did some investigating into EINTR bug which seems to be stemming from a known-issue on Uring in that writes are not buffered which usually does not matter except perhaps when there are parallel writes to stdout. Spent some time thinking about the fiber local storage across domains issue, I've passed on some thoughts to folks working on this. Patrick Ferris 2025 9 2 Vpnkit You might recall I was interested in using vpnkit. Hannes has done an amazing amount of work (patching and releasing) a series of packages to get this into a place that is much better and could be considered soon for merging. This defunctorisation is actually very useful for the Eio port I wrote a long time ago. Patrick Ferris 2025 9 2 Papers and Talks at ICFP Somehow, I have ended up on lots of papers and talks at ICFP and the co-located events in October. The vaguely OCaml-related ones include: Essentially a Vpnkit Experience Report. An extended abstract on generating a corpus of ill-typed Hazel programs was accepted into TyDe workshop. Relatedly, the work that project supported was accepted into HATRA which was the Part II project I supervised: Decomposable Type Highlighting for Bidirectional Type and Cast Systems. And two PROPL talks! Patrick Ferris 2025 9 2 Outreachy We have come to the end of another Outreachy round! I will write more on this soon in its own separate post. But for now I am very grateful to this round's mentors gridbugs and mdales, and also our fantastic interns. If you are interested, please do watch our demo day presentations. The next round is fast approaching and we still need to work out the logistics. But I had a good conversation with mdales about possible Geocaml projects that I intend to submit! Patrick Ferris 2025 8 7 https://patrick.sirref.org/irmin-retro/ irmin-retro /irmin-retro/ Irmin Retrospective Irmin is an OCaml library for building branchable and mergeable data stores. The data is mergeable in the sense of mergeable replicated data types. I have been using Irmin for over five years to build different kinds of interesting data stores including: A simple markdown-based note-taking web application. A content-addressed database. Mentoring an intern who worked on Irmin in the browser. Most recently, an Irmin-backed shell session manager. I was asked to provide some feedback recently on Irmin, so I thought writing a little retrospective here would be a good way to do that. The remit for the retrospective was about improving Irmin, so the content is focussed on pain points and areas of improvement. An in-memory Irmin store module Store = Irmin_mem . KV . Make Irmin . Contents . String Patrick Ferris 2025 8 7 What is Irmin? Irmin, at its simplest, is a key-value database. Users associate keys with values and can query and update these bindings. Additionally, this database supports versioning. This means independent snapshots of the database can coexist and users can switch between them and update them without fear of interfering with other versions. Different versions of the database can be combined by merging. When you set up your instance of an Irmin database, you also provide it with a merge function. # # show_type Irmin . Merge . f ;; type nonrec 'a f = old : 'a Irmin . Merge . promise -> 'a -> 'a -> 'a , Irmin . Merge . conflict result Lwt . t Patrick Ferris 2025 8 7 Design and API Irmin's API is very git-inspired. There is a large overlap of shared vocabulary and concepts: repositories, branches, commits, heads etc. Probably the most confusing aspect of this is the notion of a Store. When I was describing Irmin above, I used the term database to help distinguish between some of these concepts. In Irmin's documentation, it is used for multiple related (but different) concepts. In "Creating a Store" stores refer to the entire database, whereas in the Irmin API docs we have that: There are two kinds of store in Irmin: the ones based on persistent named branches and the ones based temporary detached heads. For Irmin library users, a Store.t can be thought of as a checkout of the database at a particular revision. This may be from a branch or a specific commit. # Store . of_branch ; ; - : Store . repo -> string -> Store . t Lwt . t = < fun > # Store . of_commit ; ; - : Store . commit -> Store . t Lwt . t = < fun > The overloading of the term is confusing. I think it leaves users unsure about what other people might mean when they say "store". Being careful with these terms, and the contexts in which they are used, would help avoid this confusion. Patrick Ferris 2025 8 7 Module and Functor Soup Undoubtedly for a majority of use-cases and users, Irmin is over-functorised. Nearly every module requires that you must apply some functor to access any useful code. In general, a user will have to interact with the Schema module when describing the types they want to instantiate their store with. To counteract this, Irmin has plenty of KV modules that provide a Make functor that only requires a user to provide a suitable content module for their store (i.e. something that provides a type, a runtime representation of that type and a merge function). # # show_module Irmin_mem . KV ;; module KV : sig type endpoint = unit type metadata = unit type hash type info = Store.info type contents_key = 'h type 'h node_key = 'h type 'h commit_key = 'h module ]]> sig ... end end I think it is fair to say the documentation is hard to follow as it is a module and functor soup. For example, looking at irmin.3.11.0, starting at the toplevel documentation page our path to finding this paricular module and functor is as follows: We jump into Irmin_mem from the nicely written landing page. We scroll down to find the KV module. We now make sense of the module's signature by following the KV_maker link. We see a Make (C : Contents.S) : sig ... end at the end of the module, and we navigate through that. Finally we have come to our journey's end, and find the schema module with type constraints like type Branch.t = string. There is a big assumption there that you know what the Schema module is telling you and how it relates to your "store". There is a counter-argument here, in that Irmin is incredibly flexible in terms of what you can use as types for your keys, branches, hashes etc. I was quite easily able to produce Irmin stores that use CIDs (self-describing content identifiers) for example. I think there is a middle ground. For Irmin to be usable it needs to reduce the complexity of the API. The complexity is due to, in large part, over-functorisation. If the functors cannot be removed then perhaps better documentation or more introductory libraries like irmin-containers would be helpful. Perhaps a standalone library that acts as an interface to Irmin stores would be helpful. I find myself time and again implementing something like that. Patrick Ferris 2025 8 7 Backends Galore Irmin has plenty of backends including a git-compatible one, a MirageOS backend, an in-browser IndexedDB backend and even a FoundationDB backend. Irmin needs to have fewer, better tested backends. Of course, some of these are likely driven by funding and use-case specific details. However, I think by focusing on a few key backends and striving for solid performance but also strong consitency guarantees, Irmin would become a more viable candidate for potential users. I also believe the browser backend plays a key part to making this work in order to facilate local-first applications. Patrick Ferris 2025 8 7 Syncing Remote Stores The synchronisation mechanisms in Irmin are powerful, but often the API is very confusing. For example, with the git-compatible Unix backend, nested deep in the documentation is the function required to create a remote endpoint. Once they have found this function, using it is not easy as it requires them to learn about the Mimic.ctx, which is an abstraction of the networking stack! Patrick Ferris 2025 8 7 Do Fewer Things and Do Them Well Irmin is simultaneously a database that supports: content-addressing, merging, key-value lookup, branches, transactions, complete OS portability etc. I think, in short, it tries to do too many things and comes up short on some of them in ways that really matter. When building the content-addressed database I needed strong guarantees about some atomic actions to perform on the underlying store. For example, setting the value and accessing the commit associated with it which was not possible with the API at that time in an atomic way. This kind of missing functionality is probably only understood after users stumble across it, but it also makes the library feel less focused and ready for production use-cases. Patrick Ferris 2025 8 7 Documentation It will probably come as no surprise that one of the main limitations of using Irmin is the lack of documentation and tutorials. This is a particular pain point as the API is not very straightforward. A while back, I started an Irmin book intending to help document the kinds of things real-world users would need in order to use Irmin in earnest. For example: ways to deal with type migrations or primers on runtime types. I still believe this sort of work would be invaluable, but there is a large cost to completing it, and it is not clear if there is enough interest in the project to warrant such an effort. The tutorials on the irmin website are still good starting points for most new users. But they quickly lack the depth for real-world scenarios. Patrick Ferris 2025 8 7 Feature Wishlist What follows are additional ideas for improving Irmin. Patrick Ferris 2025 8 7 Heterogeneous Stores missing feature for lots of first-time users of the library: you can only store values of a single type. This leads to a few common workarounds: Storing a serealised version of your values, essentially escaping the type-system and implementing a form of dynamic typing. Growing your value to hold lots of different types via some large variant type. Both of these options are feasible and have been used in practice. However, they are workarounds. A long time ago CraigFe created an RFC for heterogeneous stores, which I think about a lot. The main idea is to augment Irmin paths (keys) to be GADTs that carry type information about the kinds of values they access (similar to heterogeneuous variants of other data structures). Something like this alongside a simplified API would make Irmin more appealing as a library for persistent data storage. Patrick Ferris 2025 8 7 Real-world Retrospectives This echos some thoughts from the Documentation section. There are some very real-world Irmin use-cases out there. For example, for a long time (I'm not sure if this is still the case) parts of the Tezos blockchain were using Irmin which uses the irmin-pack backend. Does this make irmin-pack the best tested backend and perhaps should be the default backend for new users? Or is it hyper-specific to the Tezos use case? There are blogs on tarides.com about the irmin-pack backend, but they might be outdated and should not be the first place to find advice on which Irmin backend to use. Patrick Ferris 2025 8 7 Active Development and Engagement As far as I know, Irmin was at the forefront of technologies that have come to be described as local-first. There is a growing interest in this area (particularly as it acts as a counter-argument to an increasingly online, centralised model). I highly recommend reading Ink & Switch's essay on the matter. And it would be great to see more research via Irmin at things like the lofi unconference and the PLF workshop at SPLASH 2023! Thank you for reading! And thank you to all the Irmin contributors. I hope this might be useful in the future for building the next-generation Irmin! 2025 7 18 https://patrick.sirref.org/weekly-2025-07-18/ weekly-2025-07-18 /weekly-2025-07-18/ Back to shelter 2025 7 18 Capnproto Interface to Shelter I spent some time this week thinking about decoupling Shelter's builds from the CLI tool. This would allow users to connect to a remote daemon to build and store their sessions, opening up the possibility of using Shelter on Windows and macOS. The design so far keeps the metadata local, in an Irmin database. I will probably then augment the stored information with some kind of unique daemon identifier to know where the actual data is. This is all still quite fresh, and I will have more by the end of next week. 2025 7 18 OCaml-related Things Something I decided to do last week, was to make a clearer delineation between my OCaml work and research. That line is not always very distinct, but I have split of a separate set of weeklies for OCaml related things. Fear not, the OCaml weeklies are a subset of these weeklies and so I will, when I remember, transclude them for you. Patrick Ferris 2025 7 15 https://patrick.sirref.org/ocaml-weekly-2025-w29/ ocaml-weekly-2025-w29 /ocaml-weekly-2025-w29/ OCaml Weekly 2025 w29 Patrick Ferris 2025 7 15 Ppxlib I met with Nathan this week to discuss future plans for ppxlib. The current state of affairs is that ppxlib is becoming unmaintainable. This is primarily a knock-on effect from changes being made to OCaml's parsetree (e.g. labelled tuples being added in 5.4). Nathan has a plan that will provide two key properties. Migrations, which allow old compilers to be used with new ppxlib releases, will be more compatible. For example, we will be able to migrate new features downwards and back up without raising an error. Ppx authors will be able to use new features in an opt-in workflow, rather than ppxlib bumping the internal AST (like we did in ppxlib.0.36.0). This will reduce the maintenance burden significantly whilst still allowing users to write ppxes for new OCaml features. I also started looking into some older issues in ppxlib related to performance. This is work-in-progress, but I am trying to improve the performance of some passes done by ppxlib. To better understand what was making ppxlib slow, I wanted to use runtime_events_tools but I was dismayed to see it wanting to install over 100 packages! I opened a PR to reduce the number of packages. I think this kind of work goes a little unrecognised as it is not very glamorous. However, I think it really benefits the OCaml community in the long run. Patrick Ferris 2025 7 15 Outreachy In Outreachy news, we had a wonderful mid-internship video call with all the interns and mentors to catch-up on how everyone is getting along. Seeing the progress everyone has made was great! I am very grateful for the work that Michael and Steve have put in so far to make this a very successful Outreachy round for OCaml. In sadder news, an email was shared with all Outreachy mentors detailing the increasingly critical financial situation the project finds itself in. There are ongoing discussions about how costs can be cut including potentially only running a single round a year. Patrick Ferris 2025 7 15 Graft With the release of Forester.5.0, I made a plan to make a release of Graft.0.1. Unfortunately this is blocked by a new release of hilite, a tool I built for doing build-time syntax highlighting for OCaml code. This powers the syntax highlighting on ocaml.org. Patrick Ferris 2025 7 18 https://patrick.sirref.org/ocaml-quarterly-q2/ ocaml-quarterly-q2 /ocaml-quarterly-q2/ Quarterly OCaml Q2 Thanks to Tarides sponsorship, I get to work on open-source OCaml. This quarterly is a companion to my weeklies, summarising the last three months of development, peppered with ideas and thoughts about OCaml, its community and its future. Patrick Ferris 2025 7 18 What I wanted to work on? There were two main things I hoped to continue working on: ppxlib and outreachy. These are projects that I was previously working on, and in the case of Outreachy I have now been involved for many years. In addition to this, all of my Part II projects this year used OCaml in some regard. In general, I want to see more adoption of OCaml. Over the years this has taken many forms including my initial work on developing workflows for OCaml that just turned five years old. This directly fed into the rebranding and rethinking of ocaml.org itself. Patrick Ferris 2025 7 18 What I worked on? Patrick Ferris 2025 7 18 Ppxlib Ppxlib is the de facto standard library for building OCaml preprocessors. At the time of writing, opam list --depends-on=ppxlib informs me that there are 267 reverse dependencies. Janestreet is a heavy user of ppxes and has authored many. One of the main accomplishments this quarter was bumping the internal AST to 5.2. This allows ppx authors to use new OCaml language features in their ppxes. In bumping the AST, we knowingly broke compatability for pretty much every single reverse dependency. As best we can, we have been sending patches to ppx libraries and helping users migrate to the latest ppxlib. There is an interesting dicussion to had about the nature of open-source, and its interaction with industrial monorepos and community tended package repositories. Package ecosystems thrive whenever there is a dedicated community creating, maintaining and publishing packages. The idea is that the published world should be healthy. The publishing medium can act as natural limiting factor in the churn of breaking changes (in the case of OCaml this is via PRs to the opam-repository). This, I have come to notice, reacts poorly to changes coming from internally consistent monorepos where introducing breaking changes is easily fixed by applying patches there and then. Whatsmore, OCaml is often stated as an incredibly safe language to perform large refactorings thanks to its type system. Ppxlib sits awkwardly in the space of possible breaking changes. Tied to OCaml's parsetree, impacts of changes there ripple down to ppxlib. The compiler itself can remain internally consistent, and is protected as it need only parse source code. Ppxlib, on the other hand, exposes the parsetree to users and thus any changes to the parsetree will likely be felt by ppx authors. Since I started working on ppxlib, it feels as though the number of syntax changes has gone up (primarily from Janestreet work). Unless we make changes to how we provide support for these, maintainers of ppxlib will forever be stuck doing busy work! Thankfully, Nathan has thoughts on how to improve this. There are a slew of other features I have added to ppxlib including: Support for deriving from classes. Support for deriving from module bindings and signatures. Fixing compiler and ppxlib dummy locations. Bumping to 5.3. Migrations for 5.4. Patrick Ferris 2025 7 18 Outreachy Our two projects this year, one on claudius and one on dune, are going extremely well. At the time of writing, we just had a mid-internship call to catch up, and I was blown away by the progress each intern has made. Unfortunately, Outreachy is struggling with funding and the next round is perhaps not going to happen. This is a real shame and I am hoping that it will not be the case. Outreachy has been a wonderful source of new, committed OCaml developers. If you haven't already, do peruse the webpage on OCaml.org to see past internships or watch the demo day presentations. For the mentors involved, I believe it has also been a rewarding experience (though at times a challenging one). We are always looking for new mentors and project ideas, please do reach out to me if you are interested. Patrick Ferris 2025 7 18 Hazel OCaml's feature set allows it to shine at writing programming languages (and things of that ilk: compilers, interpretters, static analysis tools). Hazel is a research programming language with typed holes written completely in OCaml (via the reason dialect). Relating this back to the original intent of my work, to improve OCaml adoption, I believe this also means keeping existing users happy. In the last quarter I developed a compiler from OCaml to Hazel. Whilst new features are still being added to Hazel, I hope this could serve as a tool to help develop test-suites and standard library functions using existing OCaml solutions. In a student's work (Typed Debugging for Hazel), we used this tool to build a corpus of ill-typed Hazel programs to great effect. OCaml should continue to be a world-class programming language for building other programming languages. I hope to upstream some of this work to Hazel and provide some low effort maintenance to help keep their compiler in good shape. Patrick Ferris 2025 7 18 Systems Programming in OCaml In a cross-over with my own research, I have been developing many tools related to systems programming in OCaml including: An eBPF-based open syscall tracing tool. A library in OCaml for spawning void processes. A shell session manager that uses Irmin to manage sessions. It is nice to see a new push to finally land the direct-style Irmin PR! This work is means to develop the underlying libraries that support it. For example, I have opened a few PRs to Eio to add new "fork actions" to the spawn API. I also investigated the feasibility of changing the underlying mechanisms in Eio to use Picos. In the future, I think this could be important avoid further splitting the OCaml ecosystem. Patrick Ferris 2025 7 18 OxCaml I dabbled a little with OxCaml and build try-oxcaml to let people take it for a spin without having to perform opam repository gymnastics. It turned into a lot of work to track down some pretty inane bugs (type definitions differeing between js_of_ocaml and the OxCaml compiler, resulting in different Javascript runtime representations...). This unblocked a few of my colleagues to get OxCaml working on tools like odoc_notebooks and x-ocaml. Patrick Ferris 2025 7 18 Forester A good proportion of my work this quarter has been focused on how to present the very work that I am doing. Jon Sterling has been developing a tool for scientific thought called Forester which seemed like a possible candidate for writing and sharing my work. Porting my existing blog posts and website content from markdown to Forester's LaTeX-inspired syntax didn't seem like an option. In particular, many of my posts made use of additional markdown-based tools (like ocaml-mdx). This lead to the development of Graft: a preprocessor for Forester forests, converting markdown and bibtex to trees. Patrick Ferris 2025 7 18 What's next? So, I worked on most of what I wanted to work on and then some! Going forward I hope to keep maintaining ppxlib in some capacity and coordinating the OCaml community's Outreachy efforts. I hope to continue my small experiments (e.g. converting Eio to Picos). My own research makes heavy use of Irmin, and I would be interested to help with that too. More recently, a new library has been released for working with numerical data in OCaml called Raven: I am interested to use this library in Geocaml, a suite of geospatial tools written in OCaml that I maintain. I feel conflicted about the OxCaml efforts. I admit, I am not fully aware of the full benefits of the features, but I worry about some proliferation of modes that make the type system in OCaml unbearable to use. On top of this, with my ppxlib hat on, I worry about the impact of changing the compiler so frequently, placing strain on an already small community. That being said, by releasing OxCaml separately I do believe running it as an experimental set of packages will help understand the tool better. But I would not be building anything I intend to maintain or research with right now as that ecosystem is far too volatile. Finally, over the past two years I have done a lot of teaching. From Part II projects to supervisions. Going into next (academic) year, I intend to reduce my in-person teaching to focus on my research. However, I am interested in producing more materials for learning, maybe some of this in OCaml, perhaps something similar to Beautiful Racket. I have tried in the past to do these sorts of things, for example The Irmin Book. Patrick Ferris 2025 7 18 Thank you Thank you for reading this wrap up! And thank you again to Tarides for letting me work so freely on things that I think are good for the OCaml community. Patrick Ferris 2025 6 2 https://patrick.sirref.org/weekly-2025-06-02/ weekly-2025-06-02 /weekly-2025-06-02/ Forester as a Target Syntax This week included some time finishing opentrace and subsequently folding it into shelter. I have been writing up some more of the draft paper for shelter which I am excited to share in the near future. I revisited the upgrading vpnkit PR and pushed some more fixes. I have been thinking, again, about the promise of a direct-style world for OCaml that just hasn't quite landed yet. C'est la vie. Patrick Ferris 2025 6 2 Forester and Graft I spent a bit of time finally pulling out my changes to Forester to add markdown and bibtex support into a standalone tool: graft. Patrick Ferris 2025 6 2 https://patrick.sirref.org/graft/ graft /graft/ Graft https://github.com/patricoferris/graft Graft is a Forester preprocessor. It takes a forester (a directory of trees) written in a mixture of Markdown, Bibtex and Forester syntax and produces a new forest completely written in Forester syntax. Patrick Ferris 2025 6 2 Usage graft simply preprocesses a forest generating Forester trees from .md, .bib and .tree files. It will copy the structure of the input directory in the output directory. $ graft preprocess --output=grafted-trees trees $ forester build This assumes that you have updated your Forester toml file to put the grafted-trees directory as your source of trees. Patrick Ferris 2025 6 2 Example A typical "tree" might look something like A few things to note: The yaml frontmatter allows you to add some of the metadata fields from Forester. At any point in your markdown there is an escape hatch to Forester using a forester codeblock. It is very satisfying to find the separation of concerns works quite well. For a while I had been rebasing my development branch on Forester. I was also worried about trying to get the code upstream as it pulled in many dependencies. It seems that I have a very workable solution. I welcome contributions to graft including extra input formats. I am also considering extending the Forester configuration to contain some graft configuration for how it should generate new trees (e.g. at the moment every entry in a bibtex file is given a new tree). Patrick Ferris 2025 6 2 Maths Support As part of that process, graft now supports Markdown KaTeX. For example: Patrick Ferris https://patrick.sirref.org/mrdts/ mrdts /mrdts/ Mergeable Replicated Data Type Implementation Definition A mergeable replicated data type (MRDT) implementation for a data type is a tuple where: is the set of all possible states at a branch, is the initial state, implements every data type operation, implements the three-way merge strategy. Definition 2.1 from "Certified Mergeable Replicated Data Types". Patrick Ferris 2025 6 2 Revision Supervisions I have been doing revision supervisions for Discrete Maths and Foundations of Computer Science. I have also been marking Operating Systems past paper questions for the same group of first years. Patrick Ferris 2025 4 21 https://patrick.sirref.org/weekly-2025-04-21/ weekly-2025-04-21 /weekly-2025-04-21/ Shelter in the Forest I spent much of this week working on Shelter and things related to it. Some of that time was also spent on Forester. Patrick Ferris 2025 4 21 Forester I added two important quality-of-life features to my frontend to Forester this week. Patrick Ferris 2025 4 21 Bibtex Support I had previously mentioned adding support to Forester for Markdown. This week I added support for Bibtex too. From any *.bib file in your forest, Forester will now dutifully recognise it as a Bibtex file and convert, as best it can, all the entries into Reference trees. I'm becoming quite convinced of this model at the moment. I'm using Forester's Code.t as a target representation. In fact, to ease the process, I really shouldn't spend all my time on my website, I have reused my Yaml.t -> Code.t and Markdown.t -> Code.t functions in the Bibtex parser. To see it in action, you could have a look at the Build Systems à la Carte paper which is generated completely from Bibtex. Patrick Ferris 2025 4 21 Full Heading Support The eagled-eyed viewer may have noticed that the table of contents for this page has more than one level. I finally caved and spent an evening rejigging my Cmarkit.Doc.t -> Tree code which was hacky and broken and is now less hacky and less broken. In addition, headings support links and emphasis etc. Patrick Ferris 2025 4 21 Lunch with Jon Sterling I had a delightful lunch with Jon Sterling discussing the future of Forester, the nature of the Web (old and new) and the success posting weekly updates for our colleagues. Thanks Jon. Patrick Ferris 2025 4 21 Shelter Fixes I spent a good chunk of my week fixing bugs in Shelter with the aim to perhaps setup a VM somewhere and let people kick the tyres of what we've got so far. The first bug is pretty annoying. At the moment, our filsystem backend is ZFS and we make heavy use of snapshots and cloning in order to provide time-travelling capabilities. Unfortunately, ZFS will take a snapshot before data has fully made it to disk (or whatever is the equivalent point it should reach in ZFS). Commands that generated lots of disk activity would be snapshotted in a half finished state and this would cause all sorts of problems. Thanks to Mark Elvers for the pointer to how OBuilder uses ZFS for the OCaml macOS builders which unmount datasets immediately therefore inducing a flush of sorts. Shelter now follows a similar model with all of the slow downs that create. Anil and I discussed some amalgamation of overlayfs, tmpfs and ZFS to alleviate some of this but for now that's a premature optimisation. Patrick Ferris 2025 4 21 A small eDSL for Shelter Whilst testing Shelter, I ended up wanting a way to programmatically invoke the different run commands. This is similar to say a Dockerfile, but maybe with a little more expressivity. This lead me to revisit the Build systems à la Carte paper and rediscover selective applicative functors. I started playing around with a selective applicative interface to Shelter, this would allow you to express your dependencies statically but select them dynamically (as the paper says). module D = Shl Identity let shelterfile = let open D in let base_image = from " alpine " in let is_node_lst img = String . equal " v22.15.0 " stdout img in let cmds base = let node_version = run " node --version " base in Select . if' Select . map ~ f : is_node_lst node_version run " " run " " base in with_session " node " cmds base_image From this, we get a slightly more expressive way to describe images. Patrick Ferris 2025 4 21 Geocaml TIFF Library I was pleasantly surprised to receive a pull request from Michael adding support to ocaml-tiff for reading TIFF files compressed using LZW. I was also surprised to hear the TIFF LZW is a little different to others. In trying to get this PR merged, I moved the initialisation of the Eio eventloop to outside each individual test case. This one change then completely broke the entire test suite. After a period of debugging and help from Thomas Leonard the root cause was OCaml's OUnit2 library using process-level parallelism (via Unix.fork), sharing the ring between the parent and the child lead to the issues. Read more about that issue on the Eio issue tracker. Patrick Ferris 2025 4 21 Part II Students As the new term begins, it signals that there are only just over two weeks for the final year undegrads at Cambridge to submit their dissertations. The four students that I help supervise have been sending me drafts of their work (and reminder you can read about their projects) and I'm very impressed. I'm sure the next two weeks will be stressful, but I'm proud of what they have accomplished over the past academic year. Patrick Ferris 2025 3 31 https://patrick.sirref.org/weekly-2025-03-31/ weekly-2025-03-31 /weekly-2025-03-31/ Shelter, Hazel and More! Last week I focused on Shelter -- our idea that shells should have the same ability as reproducible build tools like Nix or Docker. To this end I now have a fairly fleshed out prototype. Patrick Ferris 2025 3 31 Shelter Prototype Shelter is a spin-off from the work Michael and I started with Shark. It takes the same ideas but applies them directly to a shell-like interface. We're still in the middle of working all of this, but you can read more about it at Shelter. Patrick Ferris 2025 3 31 Forester Hacking As you can probably tell, my website is still using Forester. I rebased my Markdown branch to include the new Atom syndication feature. Alongside that I added support for arbitrary HTML injection into Forester via codeblocks in Markdown. This was actually very straightforward thanks to Markup and being able to re-parse Forester syntax in the middle of converting a Markdown document. The HTML for the shell in Shelter uses this feature. If you are interested in taking this custom Forester for a spin, there's a branch on Github. In fact, nearly the only change beyond letting the core engine know about markdown files, is adding a new parser frontend. Patrick Ferris 2025 3 31 Hazel For one of my Part II students, I've been prototyping a transpiler from OCaml to Hazel. This has gone pretty well and now supports type annotations as well as straight-forward implementation translation. Consider the following OCaml map function. let rec map f = function | -> | x : : xs -> f x : : map f xs The tool, hazel_of_ocaml can translate this to Hazel code, including making the polymorphism explicit. forall b -> (a -> b) -> [a] -> [b] = typfun a -> typfun b -> fun f -> fun x1 -> case x1 | [] => [] | x :: xs => f(x) :: map(f)(xs) end in ?]]> You can copy and paste that codeblock into the hazel playground. But do note that it still needs some manual editing to add the type applications in directly (map@<a>@<b>). With the right amount of type-inferencing and scoping I actually think that you could place those type applications in yourself. This could make a nice Part II project I think. Patrick Ferris 2025 3 31 Ppxlib I recently wrote about the painful experience of miragrating ppxlib to the 5.2 OCaml AST. This week, Nathan Rebours and I merged a PR to add the 5.3 AST! Ppxlib has been playing catch-up with the compiler and we decided it was best to try to catch up quickly and deal with the ecosystem fallout all at once rather than incrementally. With this new AST merged, ppx authors can now use the new Pexp_effect parsetree node. I'll write a little more about this in a separate post soon. Patrick Ferris https://patrick.sirref.org/thesis-outline/ thesis-outline /thesis-outline/ Thesis Outline Patrick Ferris Hypothesis Embedding deep provenance tracking, reversible execution and mergeable histories directly into an interactive programming environment (a POSIX-like shell) greatly decreases the gap between exploratory scientific work and reproducible, publishable results; all whilst leaving existing workflows intact and being programming language agnostic. Patrick Ferris Contributions POSIX-compatibility: I'm interested in both being POSIX-compatible and thinking about the post-POSIX nature of the shell. But this bolsters claims about not breaking existing workflows and is relatively easy to measure. MRDT for Shell Histories: Spoke to KC about this, I think there is some interesting work here for developing a useful MRDT for this. Easy to use provenance tracing: as simple as searching your shell history! OS Design Discussion: Plan9, fork/exec, void processes, VURL etc. Patrick Ferris Outline Introduction: Setting the scene: exploratory programming, why a shell, scientific results etc. Background Design and Theory Implementation Evaluation Patrick Ferris Repositories Shell library Shelter Patrick Ferris 2025 11 15 https://patrick.sirref.org/eio-cap-debugging/ eio-cap-debugging /eio-cap-debugging/ Shelter imports › Eio Debugging One of the promises of Eio's capability model is an improved debugging experience. Your program must be designed in such a way as to make resources explicit. If you have a load_config function, more than likely it will need access to the file-system. val load_config : _ Eio . Path . t -> Config . t Once all of your resources are explicit and threaded through your program, it becomes much easier to swap out one resource for another (provided they have the same interface). This week I was trying to get the LIFE pipeline running in shelter. Part of that involves pulling the appropriate geospatial container image, but my code was terrifically broken, failing with what looked to me with a Docker error. With only this clue, I knew that it was probably in the execution of some command in a child process, but which one? To trace this quickly, I could plug in a slightly different instance of the _ Eio.Process.mgr capability. Essentially unchanged from the one provided by the unix backend except that it would also print to stderr the command it was trying to run! let debug_process_mgr mgr : 'a Eio_unix . Process . mgr : 'a Eio_unix . Process . mgr = let module D = struct type t = unit let spawn_unix ~ sw ? cwd ? pgid ? uid ? gid ~ env ~ fds ~ executable args = Eio . traceln " Spawning subprocess... " Fmt . list string args ; Eio_unix . Process . spawn_unix ~ sw ? cwd ? pgid ? uid ? gid mgr ~ env ~ fds ~ executable args end in let module V = Eio_unix . Process . Make_mgr D in Eio . Resource . T , Eio_unix . Process . Pi . mgr_unix module V Whist there is a fair amount of jumping through first-class-module-shaped hoops here, all I am doing is rewrapping an existing "method" to a spawn a unix child process. Then using this helper function, I can push that into my standard environment. let env = Eio_unix . Stdenv . with_env ~ process_mgr : debug_process_mgr env # process_mgr env in Shelter . main config env : > _ Shelter . env dir cmd_file And sure enough I was querying for the Docker user before pulling the image! I hadn't run into this, as for the last while I have been using alpine and debian images that already exists locally. Related https://patrick.sirref.org/ryangibb/ ryangibb /ryangibb/ Ryan Gibb PhD Student and Nix Guru https://ryan.freumh.org Fellow FN06 hacker. Contributions