OCaml Weekly News
Hello
Here is the latest OCaml Weekly News, for the week of March 31 to April 07, 2026.
Table of Contents
- restricted 2.0.0 limit which system operations and which parts of the filesystem your program can access
- Job offer: compiler engineer for Catala @ CNAF (social benefits agency)
- ocgtk 0.1: OCaml bindings for GTK 4 (preview release)
- out-channel-redirect 0.1 — Redirect and capture out_channel output
- ppxlib.0.38.0
- A Proposal for Voluntary AI Disclosure in OCaml Code
- Blog: OCaml documentation as markdown
- hotseat Squava (a tiny LablGtk2 demo)
- opentelemetry 0.90 (and associated libraries)
- Dune 3.22
- Old CWN
restricted 2.0.0 limit which system operations and which parts of the filesystem your program can access
removewingman announced
Hello,
I am happy to announce a new version of restricted.
This library lets you limit which system operations and which parts of the filesystem your program can access. Call it as early as possible in your program so that the rest of the code runs with reduced privileges. Currently, actual enforced restrictions are implemented for these operating systems:
- OpenBSD
- Linux (only filesystem view)
Even on other operating systems, you can still use restricted to document which privileges your program needs. Users can then test if your program respects these promises with tools such as pledge on Linux. Enjoy :slight_smile:
CHANGELOG:
- tested on:
- x86_64 openbsd (16/16 Tests passed)
- x86_64-alpine-linux (Landlock ABI version: 7) (4/12 Tests passed: file_read_unv, file_write_unv, file_create_unv_linux, file_cwrr_unv_linux)
Added
- API: exec promises and accesses optional
- OpenBSD: exec promises
Removed
- SystemOperation.TmpPath (deprecated see:
pledge (2))
Job offer: compiler engineer for Catala @ CNAF (social benefits agency)
Denis Merigoux announced
[The following is in French since this is a job offer in the French public sector]
Candidatez ici : https://www.lasecurecrute.fr/offre-emploi/ingenieur-expert-en-compilation-langages-de-programmation--f-h/normandie/1065497
La CNAF (Caisse Nationale des Allocations Familiales), tête de réseau des 101 CAF, représente la branche Famille de la Sécurité sociale et a pour mission de piloter la politique familiale et l’aide aux populations en situation de précarité ainsi que la politique d’action sociale.
Au sein de la Direction des Systèmes d’Information (DSI), comptant environ 880 collaborateurs, la Direction Prestations Flux et Décisionnel (DPFD) est découpée en 4 départements et vous serez rattaché au département « Prestations Individuelles et Référentiels Métiers » qui est présent sur les sites de Caen, Le Mans et Rennes.
Ce département a pour mission principale de concevoir, développer et maintenir le système d’information lié aux prestations individuelles (prestations versées aux allocataires telles que l’allocation familiale, l’allocation logement, la prime à la naissance, le RSA, la prime d’activité, …). Le département fournit ainsi des moteurs de règles, ainsi que les spécifications fonctionnelles associées afin de calculer le bon droit, au bon moment, pour les allocations versées par les CAF.
Dans le cadre de projets stratégiques pour la branche famille, la ou le candidat intégrera le centre technique Catala de la CNAF.
Catala est un langage de programmation dédié développé par l’Institut National de Recherche en Informatique et en Automatique (Inria), spécialement adapté à la transformation de spécifications juridiques et réglementaires en code informatique. La CNAF ayant décidé de s’appuyer sur Catala pour les projets de modernisation de son système de calcul des prestations sociales, elle souhaite également internaliser des compétences de maintenance sur l’outillage de Catala au travers de ce poste.
Le centre technique Catala a ainsi vocation à produire des contributions open-source sur Catala, mais aussi à répondre aux besoins d’expertise technique du département « Prestations Individuelles et Référentiels Métiers » pour ses projets liés aux moteurs de calcul des prestations sociales.
La personne recrutée travaillera avec l’équipe Catala de l’Inria (Louis Gesbert, Vincent Botbol, Romain Primet et moi-même) ! N’hésitez pas à me contacter si vous avez des questions sur le job :slight_smile:
Un petit aperçu des choses faites et à faire en compilation sur Catala : https://blog.merigoux.ovh/en/2026/02/19/building-proper-pl.html
ocgtk 0.1: OCaml bindings for GTK 4 (preview release)
Chris Armstrong announced
I’m pleased to announce the first preview release of ocgtk, OCaml bindings for GTK 4 (v0.1-preview0).
What is it?
ocgtk provides OCaml bindings for the GTK 4 widget toolkit and its associated libraries (GDK, GIO, Pango, GdkPixbuf, GSK, Graphene, Cairo). It targets OCaml >=5.3 (for now).
It is inspired by, and draws some core common code and many design ideas from, lablgtk3 — the long-standing GTK 3 bindings library. However, the APIs are not compatible: whereas lablgtk3’s bindings are largely hand-written, ocgtk uses a code generator that reads GObject Introspection (GIR) definition files to produce both C stubs and OCaml wrappers. This means binding coverage tracks the GIR definitions rather than hand-written effort, and the generated code follows a consistent procedural structure.
A note on tooling: the code generator itself was developed with heavy assistance from LLMs. However, the output (the C stubs and OCaml modules that form the actual library) is programmatically generated from the GIR definitions, not written by an LLM.
What’s implemented
- Bindings for GTK 4, GDK, GIO, Pango, GdkPixbuf, GSK, Graphene, and Cairo
- Classes, records, enumerations, and bitfields
- Constructors, methods, and properties
- Signals (no return values or parameters)
- A working example: a GTK 4 calculator application
What’s missing
This is a first milestone, not a production-ready release. Several important features are not yet supported:
- Interfaces: GObject interfaces are not yet supported. This has a broader impact than it might appear: not only are interface types themselves absent, but any method on a class that takes an interface as a parameter or returns an interface type is also suppressed. This means some methods on otherwise-supported classes will be missing from the bindings.
- Callbacks: Functions that accept OCaml callbacks as arguments (beyond signals) are not yet supported. This limits use of many asynchronous GIO APIs and some GTK patterns.
- Free functions: Top-level functions (not attached to a class) are not yet generated. Some utility APIs are therefore unavailable.
- Non-opaque record field access: Fields of non-opaque GLib/GDK records cannot yet be read directly.
- Multi-parameter signals: Only signals with zero parameters and no return value are supported; signals with complex signatures are silently skipped.
- GLib types: most GLib types are not bound, which means that several useful APIs that use lists, byte arrays, GVariants (heavily used by DBus) are not available.
These gaps mean you can build basic GTK applications, but expect to hit walls with more advanced widget usage, asynchronous I/O, or any API that relies heavily on interfaces.
There is a ROADMAP.md that lists the rough plan to deal with much of the above.
Documentation
API reference documentation is currently deficient. Accurately generating documentation from GIR definitions is an unsolved problem for this project, so for now the generated modules are largely undocumented. In the meantime, the GTK 4 documentation is the best reference for understanding what each binding corresponds to, and the examples in the repository illustrate practical usage — in particular the calculator example, which demonstrates a non-trivial GTK 4 application.
Stability
This code is untested in production environments. The generated bindings cover a large surface area, but test coverage is not yet comprehensive. I would caution against use in any production or safety-sensitive context at this stage. Comments or MRs are welcome.
This code has not been tested outside of Linux environments.
Installation and Usage
Download and pin the source code for now (I’m in the process of preparing an opam release. This is taking a some time to sort through cross-platform issues, so I’ll update here with a comment when that is available).
The bindings have been generated against GTK 4.14.5 (Ubuntu 24.04). If you have an older version, it should still compile (in theory), but you will receive runtime errors on APIs not available in your version.
- Download the repository:https://github.com/chris-armstrong/ocgtk (you can use the v0.1-preview0 tag to get what I’ve mentioned here)
- Pin the conf-gtk4 and ocgtk packages in their respective subdirectories
opam pin conf-gtkopam pin ocgtk
- Run
opam install ocgtk
Each library is exposed at the ocamlfind level as ocgtk.<libname> - for example, add ocgtk.gtk or ocgtk.gdk to your dune file, while depending on ocgtk in your opam / dune-project file.
Source and issue tracker: https://github.com/chris-armstrong/ocgtk
Feedback and bug reports welcome.
out-channel-redirect 0.1 — Redirect and capture out_channel output
Hhugo announced
I’m happy to announce the first release of out-channel-redirect, a library for redirecting and capturing output written to out_channels.
Features:
- Capture any out_channel into a string (with convenience shorthands for stdout and stderr)
- Redirect one channel into another
- Works on native (via dup/dup2), JavaScript (js_of_ocaml), and WebAssembly (wasm_of_ocaml)
- Expert API for manual redirection lifetime control
Installation:
opam install out-channel-redirect
Quick example:
let output, result =
Out_channel_redirect.capture_channel some_channel ~f:(fun () →
Printf.fprintf some_channel “hello”;
42)
(* output = “hello”, result = 42 *)
ppxlib.0.38.0
Nathan Rebours announced
The ppxlib team is happy to announce the release of ppxlib.0.38.0.
The main features of this release are support for OCaml 5.5 and improved support of OCaml 5.4 and 5.3. It also comes with a few bug fixes and a couple new API entries, you can read the extensive release notes here.
This is our first release since we announced our new approach to supporting new compilers in this thread. All support for compilers versions >= 5.3 is implemented using this technique and new language features are encoded into the AST. We've added Ast_builder and Ast_pattern functions to allow you to manipulate some of those, such as labeled tuples or effect patterns. You can see those in our API documentation here and there. We've also illustrated how to use them in our new manual section. If you're interested in producing or consuming other new language features that cannot be represented with our current internal AST (5.2), please open an issue so we can add the relevant helpers.
Given the ecosystem hasn't yet recovered from the 5.2 AST bump and ppxlib.0.36.0, we're glad that we can add support for new compilers without introducing further breakage and keep the maintenance burden within ppxlib's bounds.
We've started discussions with the compiler team to make this approach even more viable in the future on our end.
We'd like to thank @ceastlund who's our only external contributor for this release.
I'd personally like to thank @patricoferris for his help getting this out the door as well as the OCaml Software Foundation and OCamlPro for funding my work on ppxlib.
Thank you for reading and happy preprocessing!
A Proposal for Voluntary AI Disclosure in OCaml Code
Anil Madhavapeddy announced
Dear all,
I've put together an ocaml-ai-disclosure proposal to allow voluntary disclosure of AI usage in published OCaml code, using opam metadata and extension attributes in source code.
The repository and blog post have more details, some prototype tooling to extract attributes, and a FAQ, but in a nutshell I'm proposing something very similar to a W3C disclosure proposal for HTML.
Package Disclosures
An opam package can declare its disclosure using extension fields:
x-ai-disclosure: "ai-assisted" x-ai-model: "claude-opus-4-6" x-ai-provider: "Anthropic"
Note: This may just become a list of values in the final proposal, but you get the idea.
OCaml Module level
OCaml supports extension attributes, which we use via a floating attribute that applies to the entire compilation unit:
[@@@ai_disclosure "ai-generated"]
[@@@ai_model "claude-opus-4-6"]
[@@@ai_provider "Anthropic"]
let foo = ...
let bar = ...
These can also be scoped more finely via declaration attributes that apply to a single binding:
[@@@ai_disclosure "ai-assisted"]
let human_written x = ...
let ai_helper y = ...
[@@ai_disclosure "ai-generated"]
Disclosure follows a nearest-ancestor inheritance model like the W3C HTML proposal, whereby an explicit annotation overrides the inherited value.
I wrote a blog post with more details, as well as an FAQ in the proposal repository about some of the implications.
I couldn't find any other prior art of other language ecosystems trying anything similar, so I'd be interested in hearing about any others you all know about. If there's no interest in the wider ecosystem in doing this, then I'll just use it myself, but I figured there's no harm in starting the discussion!
Blog: OCaml documentation as markdown
David Sancho announced
I published a blog post about odoc's markdown backend and how I used it to make the melange.re documentation better, hope you like it:
https://sancho.dev/blog/ocaml-documentation-as-markdown
Thanks to @jonludlam @rgrinberg and @Alizter for reviewing the work that made it possible.
hotseat Squava (a tiny LablGtk2 demo)
Damien Guichard announced
The Squava board game.
Squava 1.1 has no vector graphics, however you can edit/shrink/stretch ./squava.png and the program will adapt the board using the new pixmap.
opentelemetry 0.90 (and associated libraries)
Simon Cruanes announced
Hello,
I'm thrilled to announce opentelemetry 0.90 (as well as opentelemetry-client, opentelemetry-client-cohttp-lwt, etc.).
Opentelemetry is an implementation of https://opentelemetry.io/ for OCaml; it covers both the core client API (for instrumentation of libraries, etc.) and the full SDK with various exporters. It is compatible with Trace.
This release is the result of months of work and is hopefully one of the last before 1.0. The changelog is pretty big, I reworked a lot of things; among others:
- move to ocaml-protoc/pbrt 4.0 (with mutable fields and a different codegen for protobufs)
- the API is closer to guidelines from https://opentelemetry.io (not fully there yet but better)
- modularity of the internal processing of signals is much improved, with better code reuse, pluggable ~everything, better queueing/batching, HTTP retries
- support for exporting as JSON instead of protobuf
- support for trace 0.11, which allows
opentelemetry.traceto eschew all its global state except for the global OTEL exporter - better lifecycle and cleanup
API documentation can be found here. As always, feedback, bug reports, etc are very welcome.
Dune 3.22
Continuing this thread, Shon announced
The Dune team is pleased to announce the release of dune 3.22.1.
If you encounter a problem with this release, please report it in our issue tracker.
Fixed
- Restore compatibility with Windows 7 (#13905, @nojb)
dune testnow runs tests in the default context only. When there is a single context, it is treated as the default. This fixes a crash when the workspace has no context named "default". (#13930, fixes #13904, @Alizter)- Fix
dune trace cat --chrome-traceto adhere to the Chrome Trace Event Format by providing timestamps and durations at microsecond granularity (#13911, fixes #13906, @Alizter)
Old CWN
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe to the caml-list.