OCaml Weekly News

• :high_speed_train: Speedup opam update up to 70%. Thanks to @arozovyk, opam update now load opam file incrementally, only parsing the files that have changed since the last time you called opam update. Before that, opam files in opam repositories were all loaded after an update if there was any change. The performance improvement of this change thus depends on how often you call opam update and what type of repository and OS you are using. (#5824)
• :spiral_shell: Improved shell integration. A number of users have been hitting issues with opam's shell integration where parts of a previous environment was kept in the current environment, causing a number of issues. These can be triggered by, for example, nuking your opam root directory (by default ~/.opam or %LocalAppData%\opam). For this particular case we are still working on a fix, but many other users have reported similar issues without nuking their root directory and in that case we believe to have fixed the majority of issues. (dbuenzli/topkg#142, #4649, #5761)
• :spiral_shell:² We've also changed the default file to which opam init writes the opam shell integration to be .bashrc instead of the previous .profile or .bash_profile when bash is detected. Doing it this way prevents some issues with existing .profile files that source the .bashrc file and causing an infinity loop when opam asks users to make sure to source their .bashrc file into their .profile file. (#5819, #4201, #3990)
• :shield: The opam install script now installs an appropriate apparmor profile on systems configured with apparmor (this is enabled by default on Ubuntu). This change is not strictly speaking related to this release as it is deployed for every versions. (#5968).
• :ocean: Many more UI additions and improvements, bug fixes, …

:open_book: You can read our blog post for more information about these changes and more, and for even more details you can take a look at the release note or the changelog.

The upgrade instructions are unchanged:

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.5.0"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.0"

Please report any issues to the bug-tracker.

Happy hacking, <> <> The opam team <> <> :camel:

It's with guilty pleasure that I announce the new release of Slipshow 0.7.0: The Slipshow of Dorian Gray, on opam.

$ opam update
$ opam upgrade slipshow

This release contains a handful of bugfixes. But the highlight of the changelog is an experimental support for recording and replaying annotations!

Peek 2025-11-26 13-25

The gif above was made using the new feature. You can also view it live. If you want an example of a more interesting use of the feature than a picture of me grow old, you can also see this presentation. You can also find the doc here.

The exclusive feature, that might not be obvious above, is that once you've recorded a series of strokes, you can edit it. For instance, here is the timeline for this presentation:

You can see it live and edit it by pressing Shift + R in the presentation, and selecting one of the recording in the dropdown on the bottom left.

However experimental this is, I can't wait to see what kind of good and bad uses it can have for your presentations. Please post them here!

Thanks a lot to NLNet for their invaluable support.

And before the changelog, an exclusive information relevant to OCaml users! The drawing edition UI, and actually the whole drawing mechanism, is made using Functional Reactive Programming, in particular with @let-def's brr-lwd library! As always, I'd like to say thank you to the developers of open source libraries, you are so great.

Here are the release notes:

• I removed support for the "setext" headings: Underlining a title with dashes will no longer make a title. Sorry for breaking a standard, but that messes too much with the --- separator. Replace it with atx headings: # This is a title.
• A bug in the carousel was fixed, breaking the workaround. If you used +2 to go to the next meaningful page, you can now change that, either to +1 or to all.
• The semantics of focus and unfocus was changed. Before, you had to unfocus as many times as you focused. Now, you have to unfocus only once.
• If you find any migration problem, please open an issue and I'll help for the migration!

• Embed Liberation Sans fonts (and use them) (#150)
• Fix missing favicon (which was missing since speaker view) (#150)
• Fix changing step number from speaker note does not update serve mode state (#154)
• Fix blank lines considered as elements in carousel (#170)
• Allow to specify port in slipshow serve with -p or --port (#176)
• Fix link with no content in block raising a syntax error (#180)
• Remove support for Setext headings (#178)

• Allow to record and replay strokes (#187)
• Fix speaker note scrolling (#150)
• Fix script undos recovery when script execution fails (#150)
• Hide paused/unrevealed elems also for mouse (#150)
• Don't execute scripts when computing toc (#150)
• Mute medias in speaker view (#152)
• Use the perfect-freehand library to generate strokes. (#151)
• Fix order of execution of actions (center after enter) (#171)
• Fix pauses not being scoped in slides (#179)
• Fix exiting not where it should (#179)
• Fix unfocus behavior to match the docs (#179)
• Fix wrong position bug on custom dimensions (#182)
• Fix infinitely jiggling autoresizing (#187)
• Fix not being able to draw outside of inner presentation (#187)
• Fix permanent fast-moving bug (#187)

The compiler team at Tarides has been central to major changes in OCaml over the past years, including the design and integration of the multicore runtime and effect handlers in OCaml 5. Beyond that milestone, the team continues to shape the evolution of the language and its runtime: improving the OCaml/WASM toolchain, refining the behavior of OCaml 5 programs under load, and exploring new directions for the type system and tooling. The role suits someone who enjoys language implementation, runtime internals, and the practical constraints of deploying OCaml in production environments (especially performance).

Details: https://jobs.world.luccasoftware.com/tarides-com/compiler-engineer-a384e70c-cd83-4c82-9cdb-a2ab121329a7

As our projects and teams have grown, we are looking for a VP of Software Engineering to guide the group of team leads across Tarides. The role involves structuring delivery, keeping teams aligned with the technical roadmap, and maintaining a clear interface between engineering and the rest of the company. It is a VP-level position, but experienced team leads or engineering managers who are ready to step into a wider leadership role should consider applying.

Details: https://jobs.world.luccasoftware.com/tarides-com/vp-of--software-engineering-ad64996f-0d3c-4991-8af9-6b7f0e943faf

If you would like to discuss either post or want more context about current projects, feel free to reach out.

Best, Thomas

The multicore work merged in OCaml 5.0 introduced native support for scalable concurrency and shared-memory parallelism. Its design combines effect handlers for expressing structured concurrent workflows, a concurrent garbage collector aimed at responsive networked applications, and a modular memory model that supports local reasoning without sacrificing performance. With these foundations now in the mainline compiler, Tarides is helping partners migrate their systems to OCaml 5.

This third role focuses on the practical side of that transition: developing tooling to understand runtime behaviour, maintaining benchmarks that guide runtime improvements, and collaborating on future directions for the scheduler and GC. It is well-suited to someone who wants to work on the boundary between research-grade runtime design and the realities of large OCaml deployments.

Details: https://jobs.world.luccasoftware.com/tarides-com/runtime-systems-engineer-14f4aa23-9a0d-4d66-88b6-4f5805e70166

OCaml has a few libraries in the ppx_deriving family, like the famous ppx_deriving_yojson, allowing to very conveniently generate marshallers and unmarshallers for OCaml types. However, two elements didn’t suit me in this approach:

• These libraries pollute the namespace quite a bit when we start combining them (e.g. when developing user-facing apps that allow ingesting several serialization formats);
• Adding support for a new format is hard and requires some PPX expertise most OCaml users don’t have.

When discovering the Go language, I was pleasantly surprised by how easy it was to marshal and unmarshal structs with simple annotations, and wanted a similar hassle-free mechanism in OCaml. I also wanted to learn about GADTs, as I never had found any use for them in my projects before. This project was originally named Marshal, but a module of the same name already exists in the standard library. “Gendarme” is one way to translate “Marshal” in French.

Gendarme is a modular, extendable, PPX-heavy marshaller and unmarshaller based on type witnesses, supporting various data formats (CSV, JSON, TOML, YAML). The curious reader may find way more information on the project’s repository, but here’s the gist:

[%%marshal.load Yojson]

type t = { t_foo: int list [@json "foo"];
           t_bar: t list [@json "bar"] } [@@marshal]
type u = t * int [@@marshal]

let v = ({ t_foo = [1; 2]; t_bar = [{ t_foo = [3; 4]; t_bar = [] }] }, 3)

let json = [%encode.Json] ~v u
(*
val json : string = "[{\"foo\":[1,2],\"bar\":[{\"foo\":[3,4],\"bar\":[]}]},3]"
*)

Annotating a type my_type with [@@marshal] and providing the required additional data (such as field names in the case of records) builds a witness value my_type of type my_type Gendarme.ty that tells Gendarme how to marshal and unmarshal values.

Currently, only a subset of OCaml core types are supported, but generic support gets improved as the need appears in my personal and professional projects.

Gendarme was written both with users (application and library developers) and developers (people developing new Gendarme encoders) in mind. If your target format is able to encode objects/records (optional but nice to have), lists/arrays, and supports arbitrarily nesting them, then writing a new encoder requires writing at most 100 lines of what is essentially pattern-matching cases to tell Gendarme what to do with your data (see for example the code for gendarme-ezjsonm). Each encoder is heavily tested, and most of the encoders that we ship have more lines of code for tests than for their actual logic.

This is a very quick introduction, but if you are interested in this project, head over to its README to learn more! I’m obviously happy to answer any questions you may have.