[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 25076 bytes --]

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
════════════════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-restricted-2-0-0-limit-which-system-operations-and-which-parts-of-the-filesystem-your-program-can-access/17942/1>


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:

  • [opam]
  • [api]
  • [examples]
  • [git repo]
  • [License AGPL]

  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)


[restricted] <https://opam.ocaml.org/packages/restricted/>

[restricted] <https://removewingman.codeberg.page/restricted/>

[pledge on Linux] <https://justine.lol/pledge/>

[opam] <https://opam.ocaml.org/packages/restricted/restricted.1.2.0/>

[api] <https://removewingman.codeberg.page/restricted/>

[examples]
<https://codeberg.org/removewingman/restricted/src/branch/main#usage-and-examples>

[git repo] <https://codeberg.org/removewingman/restricted>

[License AGPL]
<https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License>

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)
═══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-offer-compiler-engineer-for-catala-cnaf-social-benefits-agency/17943/1>


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)
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocgtk-0-1-ocaml-bindings-for-gtk-4-preview-release/17944/1>


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.


[ocgtk] <https://github.com/chris-armstrong/ocgtk>


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.


[ROADMAP.md]
<https://github.com/chris-armstrong/ocgtk/blob/main/ROADMAP.md>


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.

  1. Download the repository:<https://github.com/chris-armstrong/ocgtk>
     (you can use the v0.1-preview0 tag to get what I’ve mentioned here)
  2. Pin the conf-gtk4 and ocgtk packages in their respective
     subdirectories
     1. `opam pin conf-gtk'
     2. `opam pin ocgtk'
  3. 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
══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-out-channel-redirect-0-1-redirect-and-capture-out-channel-output/17945/1>


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.


[out-channel-redirect] <https://github.com/hhugo/out-channel-redirect>

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
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-ppxlib-0-38-0/17948/1>


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!


[here] <https://github.com/ocaml-ppx/ppxlib/releases/tag/0.38.0>

[this thread]
<https://discuss.ocaml.org/t/ann-ppxlib-support-for-future-compilers/17430>

[here]
<https://ocaml-ppx.github.io/ppxlib/ppxlib/Ppxlib/Ast_builder/Default/index.html#future-asts>

[there]
<https://ocaml-ppx.github.io/ppxlib/ppxlib/Ppxlib/Ast_pattern/index.html#future-asts>

[new manual section]
<https://ocaml-ppx.github.io/ppxlib/ppxlib/compatibility.html#future_compilers>

[open an issue] <https://github.com/ocaml-ppx/ppxlib/issues/new>

[discussions] <https://github.com/ocaml/ocaml/issues/14668>


A Proposal for Voluntary AI Disclosure in OCaml Code
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/a-proposal-for-voluntary-ai-disclosure-in-ocaml-code/17950/1>


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].


[ocaml-ai-disclosure] <https://github.com/avsm/ocaml-ai-disclosure>

[extension attributes] <https://ocaml.org/manual/5.3/attributes.html>

[blog post] <https://anil.recoil.org/notes/opam-ai-disclosure>

[W3C disclosure proposal for HTML]
<https://www.w3.org/community/ai-content-disclosure/>

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 post with more details]
<https://anil.recoil.org/notes/opam-ai-disclosure>

[FAQ in the proposal repository]
<https://github.com/avsm/ocaml-ai-disclosure>


Blog: OCaml documentation as markdown
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-ocaml-documentation-as-markdown/17951/1>


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)
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-hotseat-squava-a-tiny-lablgtk2-demo/17957/1>


Damien Guichard announced
─────────────────────────

  <https://pastebin.com/Nwu2aC7A>

  The [Squava board game].

  <https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/8/87c31d9f127f99f12e96ecff6c579b710926f945.png>

  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.

  <https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/6/66cc412e804f7d1e81a6d11ea5c4645f3edfc871.jpeg>


[Squava board game] <https://boardgamegeek.com/boardgame/112745/squava>


opentelemetry 0.90 (and associated libraries)
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-opentelemetry-0-90-and-associated-libraries/17958/1>


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.trace' to 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.


[opentelemetry 0.90]
<https://github.com/ocaml-tracing/ocaml-opentelemetry/releases/tag/v0.90>

[Trace] <https://github.com/ocaml-tracing/ocaml-trace/>

[changelog]
<https://github.com/ocaml-tracing/ocaml-opentelemetry/blob/main/CHANGES.md#090>

[here] <https://ocaml-tracing.github.io/ocaml-opentelemetry/>


Dune 3.22
═════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-3-22/17912/2>


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].


[the release of dune 3.22.1]
<https://github.com/ocaml/dune/releases/tag/3.22.1>

[our issue tracker] <https://github.com/ocaml/dune/issues>

Fixed
╌╌╌╌╌

  • Restore compatibility with Windows 7 (#13905, @nojb)

  • `dune test' now 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-trace' to 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].

  [Alan Schmitt]


[send me a message] <mailto:alan.schmitt@polytechnique.org>

[the archive] <https://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>

[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>

[Alan Schmitt] <https://alan.petitepomme.net/>


[-- Attachment #1.1.2: Type: text/html, Size: 39950 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 568 bytes --]