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

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

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

Hello

Here is the latest OCaml Weekly News, for the week of April 14 to 21,
2026.

Table of Contents
─────────────────

http-date v0.2 — Zero-dependency HTTP date parsing for OCaml
Caqti 2.3.0
layoutz 0.1.0 🪶 - Zero-dep Elm-style TUIs and terminal plots for your OCaml apps
Dune 3.22
ptt, a mailing list system as unikernel
Mollymawk and Albatross orchestrating all virtual machines
OUPS meetup april 2026
Stk 0.6 released
opam 2.5.1
Restarting OCaml.jp: The OCaml Japan User Group
Code navigation and search on Github
Seeking maintainers for our OCaml SIP server, gRPC, and HTTP/2 libraries
ppx_mixins: slightly more elegant mixin syntax
Experience Report: Refining Dune’s Dependency Graph
First beta release of OCaml 5.5.0
ocgtk 0.1: OCaml bindings for GTK 4 (preview release)
Old CWN


http-date v0.2 — Zero-dependency HTTP date parsing for OCaml
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-http-date-v0-2-zero-dependency-http-date-parsing-for-ocaml/17984/1>


Bikal Lem announced
───────────────────

  I just released v0.2 of http-date, an RFC 9110 compliant HTTP datetime
  decoder/encoder for OCaml.

  This is a major rewrite from v0.1. Here's what changed:

  Zero dependencies — Replaced the ocamllex/menhir parser with a
  hand-written implementation and removed the ptime dependency
  entirely. The library now only requires ocaml and dune.

  New type-safe API — The parsed result is now a polymorphic variant
  tagged by format (IMF, RFC850, `ASCTIME), so you always know which
  HTTP date format was parsed. The dayname, date, time, and datetime
  types are all exposed in the public API.

  Serious testing — Added property-based tests with alcobar and AFL fuzz
  testing infrastructure to build confidence in the hand-written parser.

  If you're working with HTTP headers in OCaml, give it a try:

  opam install http-date

  <https://github.com/bikallem/http-date>


Caqti 2.3.0
═══════════

  Archive: <https://discuss.ocaml.org/t/ann-caqti-2-3-0/17985/1>


Petter A. Urkedal announced
───────────────────────────

  I would like to announce the release of [Caqti] 2.3.0.

  TL;DR: Consider adding the `caqti.classic' to your link line
  (available since this version).  It currently only re-exports the
  `caqti' library, but will be replaced by a compatibility layer for the
  Caqti 2 API in Caqti 3 to allow incremental migration.


[Caqti] <https://github.com/paurkedal/ocaml-caqti>

Release Notes
╌╌╌╌╌╌╌╌╌╌╌╌╌

  Note that some of the new features of this release are only accessible
  through the still unstable `caqti.template' library, which will soon
  be stabilized as part of an upcoming Caqti 3 API.  Due to adjustments
  to module names, switching to `caqti.template' will not ensure future
  compatibility.  Instead, users are encouraged to add the new
  `caqti.classic' to their dependencies to ease migration to Caqti 3.

  • Added an alias `caqti.classic' for the `caqti' library.  This will
    be turned into a library providing compatibility with the current
    Caqti 2 API when Caqti 3 is released.  The two APIs can be used
    side-by-side to allow incremental migration.

  • The dialect descriptor for MariaDB in `caqti.template' now provides
    the server version.

  • Added `Query.parens', `Query.litf', `Query.vars', `Row_type.fields'
    to the `caqti.template' library.

  • Revised the interface for creating row types to allow instantiating
    parametric types applicatively.  Before this change, each
    application of a function representing a parametric type would
    generate a new type ID even when applied to the same type parameter
    argument.  The key part of this interface is the
    `Caqti_template.Constructor_type' module.

  • The query functions provided to request templates are now memoized,
    so that they are only called once per dialect.  This is meant as an
    optimization; it's still good practise to avoid side-effects here.

  • The new function `Query.with_pos_of' allows query generators to add
    source locations to the syntax tree, which will be emitted as SQL
    comments in the query string if the `enable_query_annotations' is
    set.  This should simplify debugging when the query is assembled
    from different parts of the application code.

  • The still unstable `caqti.template' library now supports multiple
    statements in a single request template, sent opportunistically as a
    single query where allowed.  This is still experimental.

  • Fixed package scoping of shim rules for sqlite3 (#133 by mefyl).

  • Fixed the error classification for the SQLite3 driver (#132).

  • Fixed reconnect after connection loss for PostgreSQL.


layoutz 0.1.0 🪶 - Zero-dep Elm-style TUIs and terminal plots for your OCaml apps
═════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-layoutz-0-1-0-zero-dep-elm-style-tuis-terminal-plots-for-your-ocaml-apps/17986/1>


Matthieu Court announced
────────────────────────

  Hello all! Thanks for your feedback last time - [layoutz] now has an
  Elm-style TUI runtime (quite [different in spirit] than (the
  excellent) Minttea) … a smoothed API .. and terminal plot built-ins.

  Looking for feedback! Many thanks


[layoutz]
<https://github.com/mattlianje/layoutz/tree/master/layoutz-ocaml>

[different in spirit]
<https://github.com/mattlianje/layoutz/tree/master/layoutz-ocaml#faq>


Dune 3.22
═════════

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


Continuing this thread, Shon announced
──────────────────────────────────────

  The Dune team is pleased to announce [the release of dune 3.22.2].

  This is a patch release consisting of bug fixes. See [the full
  changelog] for all the changes and for attribution to the contributors
  who made it all possible. Thank you, contributors!

  If you encounter a problem with this release, please report it in [our
  issue


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

[the full changelog] <https://github.com/ocaml/dune/releases/tag/3.22.2>

Fixed
╌╌╌╌╌

  • Revert the change in behavior of `--diff-command' back to
    3.21. Non-existent files are now passed to this command instead of
    being replaced with /dev/null ([#14098], fixes 13891, [@rgrinberg])


[#14098] <https://github.com/ocaml/dune/pull/14098>

[@rgrinberg] <https://github.com/rgrinberg>


ptt, a mailing list system as unikernel
═══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ptt-a-mailing-list-system-as-unikernel/17987/1>


Calascibetta Romain announced
─────────────────────────────

  Hey! We just launched a new mailing list powered entirely by OCaml
  unikernels. The website (itself a unikernel) is at
  <https://mailingl.st>. You can subscribe to ptt@mailingl.st by sending
  an email to ptt-subscribe@mailingl.st if you're interested in the
  development and deployment of SMTP-related unikernels.

  Fair warning: this is still a *public test* mailing list for now. In
  the long run, it will focus on our ptt project.


The SMTP protocol: a long and winding road!
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ In the beginning, email

  It all started with [Mr.MIME], our library for decoding and encoding
  emails. It's a synthesis of the relevant RFCs, but more importantly
  it's been battle-tested against real-world emails from the IEEE,
  [Enron], [KVM] and, most recently, the [caml-list].

  This work also let us build [Hamlet], a database of valid random
  emails generated using a fuzzer.

  Under the hood, Mr.MIME relies on [unstrctrd] for decoding the most
  general form of values found in an email (with internationalisation
  support via [rosetta]) and [prettym] for encoding emails while
  respecting SMTP constraints and (Comment) Folding Whitespace handling.


  [Mr.MIME] <https://github.com/mirage/mrmime>

  [Enron] <https://www.cs.cmu.edu/~enron/>

  [KVM] <https://yhbt.net/lore/kvm/>

  [caml-list]
  <https://discuss.ocaml.org/t/is-there-a-public-archive-for-the-caml-list/16374/6?u=dinosaure>

  [Hamlet] <https://github.com/mirage/hamlet>

  [unstrctrd] <https://github.com/dinosaure/unstrctrd>

  [rosetta] <https://github.com/mirage/rosetta>

  [prettym] <https://github.com/dinosaure/prettym>


◊ Next, the protocol

  Then came [colombe], our OCaml implementation of the SMTP protocol. It
  uses [ocaml-tls] for `STARTTLS' support.

  The protocol is supposedly "simple" (though the Internet always has
  surprises in store), but from day one we designed colombe to be
  independent of any scheduler and network layer. That way it slots
  right into unikernels without friction.


  [colombe] <https://github.com/mirage/colombe>

  [ocaml-tls] <https://github.com/mirleft/ocaml-tls>


◊ Finally, legitimacy

  On top of these core components, we built several email security
  layers:
  • [ocaml-dkim] handles signing and verifying email integrity in a
    streaming fashion (both for verification and signature generation)
  • [uspf] verifies sender identity and, like most of our libraries,
    stays independent of any scheduler or DNS implementation
  • [ocaml-dmarc] automates DKIM and SPF verification, stamps emails
    with the result, and checks alignment across a domain name
  • [ocaml-arc](github.com/robur-coop/ocaml-arc) lets you verify and
    sign emails to complete a chain of trust when an email passes
    through multiple SMTP servers (which is exactly what happens with a
    mailing list)

  We wrote a short article about all of this [here].


  [ocaml-dkim] <https://github.com/mirage/ocaml-dkim>

  [uspf] <https://github.com/mirage/uspf>

  [ocaml-dmarc] <https://github.com/dinosaure/ocaml-dmarc>

  [here]
  <https://blog.robur.coop/articles/2025-04-23-email-verification.html>


All in the form of unikernels
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Our first experiments already showed that we [could handle emails]
  with MirageOS unikernels. But we also hit real limitations: memory
  leaks, security vulnerabilities, and build issues.

  So we decided to start fresh, and take the opportunity to fully
  embrace OCaml 5 and effects. We rebuilt the key pieces from scratch:
  • a new effect-based scheduler: [Miou]/[Mkernel]
  • a much more complete TCP/IP stack: [Mnet]
  • a new FAT32 file system: [Mfat]

  `ptt' is built on this new stack, and so far we haven’t observed any
  memory leaks (thanks to [mkernel-memtrace] for tracing memory usage,
  viewable via [memtrace-viewer]). The CVEs related to [mirage-tcpip]
  were taken into account during ~mnet~’s development, and the build
  story is much simpler now. A GitHub action can build and actually run
  the unikernel to test it, as you can see with [mnet].

  Other unikernels using this approach are available too. If you’re
  curious, check out [this tutorial] on creating a unikernel in OCaml.


[could handle emails] <https://mirage.io/blog/2022-04-01-Mr-MIME>

[Miou] <https://github.com/robur-coop/miou>

[Mkernel] <https://github.com/robur-coop/mkernel>

[Mnet] <https://github.com/robur-coop/mnet>

[Mfat] <https://github.com/robur-coop/mfat>

[mkernel-memtrace] <https://git.robur.coop/robur/miou-solo5-memtrace>

[memtrace-viewer] <https://github.com/janestreet/memtrace/>

[mirage-tcpip] <https://github.com/mirage/mirage-tcpip>

[mnet] <https://github.com/robur-coop/mnet/blob/main/tests/simple.t>

[this tutorial] <https://robur-coop.github.io/mnet/>


Deployment
╌╌╌╌╌╌╌╌╌╌

  `ptt' also tackles the deployment question. We have [an article]
  presenting the "stateless" aspect of `ptt'. We'd also like to
  (re)introduce [Albatross](github.com/robur-coop/albatross), our secure
  unikernel orchestrator, and [Mollymawk], a web interface for deploying
  unikernels (which is itself a unikernel).

  More broadly, this is what [our cooperative] is working towards: we
  really want to improve the user experience, whether you're a developer
  or a deployer. We believe that actually developing, deploying, and
  using our unikernels is the only way to get them adopted more
  widely. So make sure to follow us on these projects too!


[an article] <https://blog.robur.coop/articles/2026-04-09-ptt.html>

[Mollymawk] <https://github.com/robur-coop/mollymawk/>

[our cooperative] <https://robur.coop>


Usage
╌╌╌╌╌

  Along the way, we found it really helpful to have a tool that lets you
  track every stage of an email’s lifecycle. That’s how [`blaze'] came
  about: a Swiss Army knife for handling emails.

  It’s still experimental, but it already lets you:
  • use our archive system (generate, read, index, etc.)
  • handle other archives such as `mbox' or `maildir'
  • communicate via the POP3 protocol
  • sign and verify emails (DKIM and ARC)
  • build emails from the command line
  • send emails
  • run a small local SMTP server

  `blaze' is how we iterate on our library APIs and validate
  implementations. It’s experimental, but it’s gradually turning into a
  full email client.


[`blaze'] <https://github.com/dinosaure/blaze>

◊ Archiving & Indexing

  We'd also like to present the [stem] project, which extracts word
  roots from a document (such as an email) and tokenises them to get
  something analysable without the complexity of natural language. This
  tokenisation is what powers our small [bm25] search engine. You can
  see results [here].

  This is also what drives our caml-list search engine, available as a
  unikernel: [blame], which you can try at
  <https://caml-list.robur.coop> (powered by [vif]).

  Beyond search, there's also email indexing via Message-IDs. For that
  we built [bancos]: a *persistent* radix tree in OCaml that supports
  *parallel* access! More details [here].

  Finally, our indexing system uses the PACKv2 format (the same one Git
  uses to store objects), implemented by the [carton] library. It has
  proven its stability through the [ocaml-git] project, so we decided to
  reuse it for archiving emails (much like [public-inbox] did, though in
  a different form).


  [stem] <https://git.robur.coop/robur/stem>

  [bm25] <https://en.wikipedia.org/wiki/Okapi_BM25>

  [here]
  <https://blog.robur.coop/articles/ptt_stem_and_search_engine.html>

  [blame] <https://github.com/robur-coop/blame>

  [vif] <https://github.com/robur-coop/vif>

  [bancos] <https://github.com/robur-coop/bancos>

  [here] <https://blog.robur.coop/articles/2025-18-12-bancos.html>

  [carton] <https://github.com/robur-coop/carton>

  [ocaml-git] <https://github.com/mirage/ocaml-git>

  [public-inbox] <https://public-inbox.org/README>


Conclusion
╌╌╌╌╌╌╌╌╌╌

  Thanks to all this work, OCaml now has a solid set of email-related
  projects. This journey started back in 2016 and there's still a long
  way to go, as we always aim to offer robu(r)st, battle-tested
  solutions. Unlike some implementations in other languages (though we
  are in discussion with folks in the Rust community), ours actually
  adhere to the standards!

  It may not seem like a big deal, and you won't see any major
  difference when just exchanging emails, but we believe this approach
  paves the way for a better internet. In the form of unikernels, it
  represents a genuine reclaiming of the means of communication!


Mollymawk and Albatross orchestrating all virtual machines
══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mollymawk-and-albatross-orchestrating-all-virtual-machines/17988/1>


Hannes Mehnert announced
────────────────────────

  Dear everyone,

  we just finished and deployed [Albatross] and [Mollymawk] to support
  virtual machines that are not MirageOS unikernels.

  The reasoning is simple: we embedded so many nice features (metrics,
  console output, deploying via web UI, multi-tenant, startup
  dependencies, restart-on-failure,..) that we really wanted to deploy
  our non-MirageOS virtual machines as well with the same mechanism and
  don't have duplicated code all over.

  For the time being, it only supports FreeBSD BHyve, but let us know if
  you're interested in other virtualization technologies and we will
  prioritize that work!

  We also wrote a brief blog article with screenshots:
  <https://blog.robur.coop/articles/mollymawk-other.html>


[Albatross] <https://github.com/robur-coop/albatross>

[Mollymawk] <https://github.com/robur-coop/mollymawk>


OUPS meetup april 2026
══════════════════════

  Archive: <https://discuss.ocaml.org/t/oups-meetup-april-2026/17989/1>


ancolie announced
─────────────────

  The next OUPS meetup will take place on *Wednesday, 29th of April*
  2026. It will start at *6:30pm* at the *45 rue d'Ulm* in Paris. It
  will be in the in the *Rataud amphitheater*.

  :warning: It's not in Jussieu as usual but in ENS Ulm! If you're not
  familiar with the place, there is a [map of the buildings].

  Please, *[register on meetup ]* as soon as possible to let us know how
  many pizza we should order.

  For more details, you may check the [OUPS’ website ].

  Moreover, we’d like to announce that the organizing team moved to the
  [OCaml Zulip]. Feel free to contact us there if you’d like to suggest
  talks.

  —

  This time we’ll have the following talks:

  *When Turing machines meet GADTs – Florian Angeletti*

  Have you ever wondered why one needs to write down explicit
  unreachable clauses in a GADT-pattern matching? Or how much
  computation one can sneak inside an OCaml type?

  This talk proposes to answers those questions and more with a deep
  dive into GADTs, the OCaml compiler implementation of the
  exhaustiveness checking for pattern match, and how to best trick the
  typechecker into finding the BB(3) champion by itself.

  *Extending OCaml's pattern matching – Yanni Lefki*

  Pattern matching has been studied for decades and has been the subject
  of extensive research and numerous extensions. Nevertheless, recent
  language features—such as Rust’s if-let construct, and recent work
  such as Cheng and Parreaux (OOPSLA 2024), suggest that there is still
  room for improvement. We propose a streamlined approach that unifies
  pattern matching with extended forms of conditionals.

  In particular, our prototype introduces binding-boolean-expressions,
  which allow variables to be bound within pattern guards, within
  if-conditions (and subsequently used in the then branch), and within
  while-conditions (and used in the loop body). Our system also
  incorporates Haskell-style views, enabling the definition of smart
  deconstructors, the dual of smart constructors.

  In this talk, we present an ML-like language equipped with evaluation
  rules, typing rules, and a simple compilation scheme. We conclude with
  a demonstration of our implementation: an OCaml PPX prototype that
  parses an extended ML syntax exposing these constructs, type-checks
  programs according to our (highly intuitive!) rules, and translates
  them into a correct OCaml AST via our (non-optimizing) transformation.

  —

  After the talks there will be some pizzas offered by the [OCaml
  Software Foundation] and later on we’ll move to a pub nearby as usual.


[map of the buildings]
<https://www.ens.psl.eu/IMG/pdf/Plan_45ULM_SS.pdf>

[register on meetup ]
<https://www.meetup.com/ocaml-paris/events/314296893/>

[OUPS’ website ] <https://oups.frama.io>

[OCaml Zulip] <https://ocaml.zulipchat.com>

[OCaml Software Foundation] <https://ocaml-sf.org>


Stk 0.6 released
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-stk-0-6-released/17994/1>


Zoggy announced
───────────────

  Hello,

  Stk is a SDL-based graphical user interface toolkit. Its interface is
  inspired by Gtk and should look familiar to developers using Lablgtk.

  Stk 0.6 is available. Among changes listed [here], this release
  introduces [Tooltips] and [handling of user's configuration],
  including user-defined themes.

  The `stk*' packages are available from my [personal opam repository].


[here] <https://zoggy.frama.io/ocaml-stk/posts/release-0.6.0.html>

[Tooltips]
<https://zoggy.frama.io/ocaml-stk/refdoc/stk/Stk/Tooltip/index.html>

[handling of user's configuration]
<https://zoggy.frama.io/ocaml-stk/doc-config.html>

[personal opam repository] <https://framagit.org/zoggy/opam-repository>


opam 2.5.1
══════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-5-1/17997/1>


Kate announced
──────────────

  Hi everyone,

  opam 2.5.1 is now available. This release is fixing a security issue
  ([OSEC-2026-03]) and other minor things. /Thanks to [@andrew] for
  reporting this issue./

  We invite everyone to upgrade to 2.5.1 as soon as possible.

  If you depend on the older opam package of your preferred
  distribution, distributions such as Debian Stable have already started
  backporting the relevant fix and the patched version should be
  available there very soon.

  You can read our [blog post] for relevant links and details.


[OSEC-2026-03]
<https://github.com/ocaml/security-advisories/blob/main/advisories/2026/OSEC-2026-03.md>

[@andrew] <https://github.com/andrew>

[blog post] <https://opam.ocaml.org/blog/opam-2-5-1/>

Try it!
╌╌╌╌╌╌╌

  The upgrade instructions are unchanged:

  For Unix systems
        bash -c "sh <(curl -fsSL
        <https://opam.ocaml.org/install.sh>) –version 2.5.1"
  or from PowerShell for Windows systems
        Invoke-Expression "& { $(Invoke-RestMethod
        <https://opam.ocaml.org/install.ps1>) } -Version 2.5.1"
  Please report any issues to the [bug-tracker].

  Happy hacking,

  <> <> The opam team <> <> :camel:


[bug-tracker] <https://github.com/ocaml/opam/issues>


Restarting OCaml.jp: The OCaml Japan User Group
═══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-restarting-ocaml-jp-the-ocaml-japan-user-group/17998/1>


mt_caret announced
──────────────────

  Dear OCaml community,

  We're excited to announce the relaunch of *OCaml.jp*
  ([https://ocaml.jp/]), the OCaml Japan User Group!

  Our goal is to grow and energize the OCaml community in Japan by
  bringing together users to foster broader adoption and deeper
  engagement with OCaml across the country.


[https://ocaml.jp/] <https://ocaml.jp/>

Current Activities
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  We've already kicked off a couple of initiatives:

  • *OCaml Weekly News - Japanese Edition*: We're maintaining a Japanese
     translation of the OCaml Weekly News at [https://ocaml.jp/cwn-ja/],
     making it easier for Japanese speakers to stay up to date with the
     latest happenings in the OCaml ecosystem.
  • *OCaml Meetup in Tokyo (August 2026)*: We are currently preparing to
     host an OCaml Meetup in Tokyo this August, the first one in [over
     ten years]! More details will be shared soon; please stay tuned!


[https://ocaml.jp/cwn-ja/] <https://ocaml.jp/cwn-ja/>

[over ten years] <https://ocaml.jp/events/>


Join Us!
╌╌╌╌╌╌╌╌

  We're using *Discord* as our primary communication platforms. Whether
  you're based in Japan, are a Japanese-speaking OCaml enthusiast
  anywhere in the world, or simply want to connect with the Japanese
  OCaml community, we'd love to have you join us!

  Please use the following link to join Discord:
  [https://discord.gg/qQTbny8KF4]

  We look forward to building a vibrant OCaml community in Japan
  together. よろしくお願いします！


[https://discord.gg/qQTbny8KF4] <https://discord.gg/qQTbny8KF4>


Code navigation and search on Github
════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-code-navigation-and-search-on-github/17999/1>


Pieter Goetschalckx announced
─────────────────────────────

  GitHub is now using [tree-sitter-ocaml] for [code navigation] and
  [code search].

  • Code highlighting should be more accurate (compared to the old
    TextMate grammar) and supports all features up to OCaml 5.4.
  • There is a symbols side panel for each file.
  • You can click on symbols to find definitions and references.
  • You can [search for definitions].
  • There is limited support for [nested structures].

  They enabled it [a few months ago] already, but I forgot to post it
  here.

  The code navigation is not always 100% accurate, but good enough to be
  helpful. If you encounter any issues with incorrectly highlighted
  code, this could be a tree-sitter-ocaml issue.


[tree-sitter-ocaml] <https://github.com/tree-sitter/tree-sitter-ocaml>

[code navigation]
<https://docs.github.com/en/repositories/working-with-files/using-files/navigating-code-on-github>

[code search]
<https://docs.github.com/en/search-github/github-code-search/understanding-github-code-search-syntax#symbol-qualifier>

[search for definitions]
<https://github.com/search?q=repo%3Aocaml%2Focaml+def%3Afind&type=code>

[nested structures]
<https://github.com/search?q=repo%3Aocaml%2Focaml+Make.t&type=code>

[a few months ago] <https://github.com/github/code-navigation/issues/14>


Seeking maintainers for our OCaml SIP server, gRPC, and HTTP/2 libraries
════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/seeking-maintainers-for-our-ocaml-sip-server-grpc-and-http-2-libraries/18000/1>


Wojtek Czekalski announced
──────────────────────────

  As we're moving off OCaml at [dialo], we'd like to donate the
  libraries we built to people who will properly maintain them. We built
  a highly performant telephony system using OCaml, but as a small team
  we ended up maintaining too much software for our liking.

  We initially built a SIP server implementation in OCaml, which was a
  perfect fit. We needed to connect it to the rest of our system in a
  language agnostic way. We chose gRPC and that's where things got
  difficult.

  At a smaller scale our own buggy implementation of gRPC on top of [h2]
  was good enough. Then we started scaling and at the same time
  transitioned to OCaml 5.0. The combination of those factors resulted
  in:

  1. Performance regressions in 5.0 related to memory management, both
     inside of app code, SIP stack, and inside of h2.
  2. We needed a more robust implementation of gRPC to handle errors and
     edge cases better.

  Long story short we ended up:

  1. Writing our own implementation of [http2]
  2. Rewriting the gRPC library exclusively for eio to limit the scope
     together with [decent codegen] and robust

  Then, in late 2025, we had to add new features to the SIP server and
  something inside us just broke. The SIP server had accumulated quite a
  bit of legacy code over 3.5 years, so we wanted to rewrite some
  parts. We were extremely excited to build the new architecture
  centered around effects — [only to discover that user-space effects
  and concurrency libraries don't really work well together], since
  callbacks lose their scope (duh). That was the final straw.

  We decided to run two 1-week stints to try rewriting the service in
  Rust and Go. We ended up choosing Rust. We still miss OCaml, but not
  having to implement and maintain our own http2/grpc/sip stack is a
  breath of fresh air.

  So here we are — we're gradually removing OCaml from our stack, and
  that's why we'd like to donate:

  • [ocaml-grpc] - the new code is on `dialo' branch, eio only at the
    moment, battle tested on production. It does have some bugs in it
    but few and it's pretty solid.
  • [haha (http2)] - overall good but could be better. We cancel fibers
    too often, it's a very low hanging fruit to make it much faster.
  • Our SIP stack — this is currently not open source, but we're happy
    to share the source code with the right person or team.

  Please write dms to me and feel free to ask me or @adamchol about
  specifics.


[dialo] <https://dialo.ai/>

[h2] <https://github.com/anmonteiro/ocaml-h2>

[http2] <https://github.com/dialohq/haha>

[decent codegen]
<https://github.com/dialohq/ocaml-grpc/blob/dialo/examples/routeguide/src/client.ml>

[only to discover that user-space effects and concurrency libraries
don't really work well together]
<https://discuss.ocaml.org/t/effect-composability-actual-callstack-vs-syntactic-scope/17536>

[ocaml-grpc] <https://github.com/dialohq/ocaml-grpc/tree/dialo>

[haha (http2)] <https://github.com/dialohq/haha>


ppx_mixins: slightly more elegant mixin syntax
══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ppx-mixins-slightly-more-elegant-mixin-syntax/18001/1>


Sacha Ayoun announced
─────────────────────

  Hello,

  I've written a tiny ppx called [`ppx_mixins'] so that one can write:
  ┌────
  │ type u [@@mixins Map.OrderedType + Printable]
  └────
  which gets desugared to
  ┌────
  │ type u
  │ include Map.OrderedType with type t := u
  │ include Printable with type t := u
  └────
  Not much but increases readability in a codebase that uses the "mixin"
  pattern a lot


[`ppx_mixins'] <https://github.com/soteria-tools/ppx_mixins>

Constructing type signatures
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  In the upcoming release, one can also write
  ┌────
  │ module type M = [%mixins Map.OrderedType + Printable]
  │ (* desugars to *)
  │ module type M = sig 
  │    type t 
  │    include Map.OrderedType with type t := t
  │    include Printable with type t := t
  │ end
  └────


Additional features
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  One can also override other types, e.g.
  ┌────
  │ type u [@@mixins Mappable(key = int; value := v)]
  │ (* desugars to *)
  │ type u
  │ include Mappable with type t := u and type key = int and type value := v
  └────


Limitations
╌╌╌╌╌╌╌╌╌╌╌

  • No support for parametric types, e.g. `with type 'a u = 'a v'
  • No support for tuple and function types, e.g. `with type t = int ->
    bool'

  This is because the preprocessor parses the payload as an expression,
  and these don't parse nicely a expressions.  Deeper support (e.g. for
  mixins with type parameters) would probably also require language
  support.


Experience Report: Refining Dune’s Dependency Graph
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/experience-report-refining-dune-s-dependency-graph/18002/1>


Robin Bate Boerop announced
───────────────────────────

  *Refining Dune's Dependency Graph: Per-Module Library Filtering*

  I've been working on improving Dune's inter-library dependency
  tracking, and wanted to share the experience — both the technical
  details and what it's like as a first-time contributor to this large
  open source OCaml project.


The Problem I Took On
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  When `libA' depends on `libB', Dune gives every module in `libA' a
  glob dependency on /all/ `.cmi' files in `libB'. If any `.cmi' in
  `libB' changes, every module in `libA' is recompiled — even modules
  that never reference `libB'.

  For projects with many libraries, this creates a cascade of
  unnecessary recompilations. The issue that tracks this matter [#4572]
  has been open since 2021.


[#4572] <https://github.com/ocaml/dune/issues/4572>


My Approach
╌╌╌╌╌╌╌╌╌╌╌

  Dune already runs `ocamldep' to compute intra-library module
  dependencies. The key insight: that same output tells us which
  /libraries/ each module references, via their entry module names. We
  can use this to filter both the build dependencies and the `-I~/'-H~
  compiler flags per-module.

  The implementation ([PR #14116] and [PR #14186]) works as follows:

  1. For each module and its transitive intra-library dependencies, read
     the `ocamldep' output (both `.ml' and `.mli')
  2. Union all referenced module names, including `-open' flags
  3. Map those names to libraries via a `Lib_index'
  4. Transitively close the filtered library set via `Lib.closure'
  5. Use the result for both hidden deps and `-I~/'-H~ compiler flags,
     partitioning into direct (visible via `-I') and hidden (via `-H')
     based on `requires_compile' membership

  With both deps and flags filtered, a clean build will fail if a module
  references a library it doesn't declare — previously, overly-broad
  `-I' flags could mask such errors.


[PR #14116] <https://github.com/ocaml/dune/pull/14116>

[PR #14186] <https://github.com/ocaml/dune/pull/14186>


A False Start
╌╌╌╌╌╌╌╌╌╌╌╌╌

  My first attempt ([PR #14021]) tried to implement the filtering in a
  single PR without sufficient test coverage. It was closed after review
  revealed that the approach was fragile in edge cases I hadn't
  anticipated — particularly around transparent module aliases and
  virtual libraries.


[PR #14021] <https://github.com/ocaml/dune/pull/14021>


Challenges
╌╌╌╌╌╌╌╌╌╌

  *Transparent module aliases.* OCaml's module alias mechanism means
   `ocamldep' doesn't always report all libraries a module transitively
   depends on. If `libB' has `module M = LibC.Something', and a module
   in `libA' uses `LibB.M', `ocamldep' reports `LibB' but not
   `LibC'. The fix: transitively close the filtered library set using
   `Lib.closure', bounded by the compilation context.

  *Root modules.* The `(root_module)' stanza creates a module that
   implicitly aliases all libraries in the compilation context. When
   `ocamldep' reports a reference to a root module, we can't determine
   which underlying libraries are actually needed, so we fall back to
   the full dependency set.

  *Virtual libraries.* When virtual library implementations are present
   in the compilation context, parameter libraries may not appear in
   `requires_compile', so filtering could miss them. Another fallback
   case.

  *Menhir-generated modules.* These mock modules aren't in the
   `ocamldep' dependency graph, so we skip filtering for them.

  *Null build overhead.* The filtering reads `.d' files and computes
   library closures per-module. On a fresh `dune' process (no memo
   cache), this is new work on every build — including null builds where
   nothing changed. This is a real trade-off: better incremental rebuild
   performance at the cost of some null-build overhead.


Prerequisite Test PRs
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Before the implementation PRs, I submitted six test-only PRs to
  document existing behavior and establish a safety net:

  • [#14017] — Baseline tests documenting current inter-library
    recompilation behavior
  • [#14031] — Test documenting module name shadowing between stanzas
    and libraries
  • [#14100] — Test verifying library file deps in compilation rules and
    sandboxed builds
  • [#14101] — Test verifying transparent alias incremental build safety
  • [#14129] — Test verifying incremental builds with alias re-exported
    libraries
  • [#14178] — Test documenting `ocamldep' behavior with transparent
    alias chains

  This made the implementation PRs' diffs focused on the actual change,
  and gave reviewers confidence that existing behavior was preserved. It
  also helped me understand the edge cases that tripped up my first
  attempt.


[#14017] <https://github.com/ocaml/dune/pull/14017>

[#14031] <https://github.com/ocaml/dune/pull/14031>

[#14100] <https://github.com/ocaml/dune/pull/14100>

[#14101] <https://github.com/ocaml/dune/pull/14101>

[#14129] <https://github.com/ocaml/dune/pull/14129>

[#14178] <https://github.com/ocaml/dune/pull/14178>


The Review Process
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The Dune maintainers ([@rgrinberg] and [@art-w]) provided thorough,
  constructive reviews. Some highlights:

  • Replacing my hand-rolled transitive closure with `Lib.closure' from
    the existing library — a cleaner approach I wouldn't have found
    without familiarity with Dune's internals
  • Identifying that both `.ml' and `.mli' ocamldep output need to be
    read, since the interface can reference different libraries than the
    implementation
  • Suggesting per-module `-I~/'-H~ flag filtering, which makes clean
    builds more precise and improves caching
  • Questioning every fallback case and special-cased module kind,
    leading to simpler code

  The PRs went through significant refactoring during review — the final
  versions are substantially tighter than the initial submissions.


[@rgrinberg] <https://github.com/rgrinberg>

[@art-w] <https://github.com/art-w>


What Could Be Better
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Working on this was a positive experience overall, but a few things
  created friction:

  *No way to benchmark before merging.* The null-build overhead question
   came up late in the process. I discovered through manual benchmarking
   that the change added \~70% to null build time — a significant
   regression. Dune's benchmark CI workflow runs only on pushes to main,
   not on PRs. Contributor-accessible performance tooling would help
   catch regressions before they land.

  *Review momentum vs. rebasing.* The test PRs merged quickly, but the
   implementation PR required multiple rounds of review over
   days. Between rounds, main moves forward, requiring rebases that risk
   introducing conflicts. The contributor carries the burden of keeping
   branches fresh. This is compounded when PRs depend on each other —
   every rebase of #14116 required rebasing #14186 as well. GitHub has
   no first-class support for PR stacks, so this is manual and
   error-prone. Of course, all GitHub-hosted repos suffer from this.

  *Flaky CI*. Many CI runs had errors that were not related to my
   code. It was often an upstream provider of an OCaml package that was
   unreachable or faulty (temporarily). These problems often resolved
   themselves, but caused day-long delays in the PR lifetimes. The
   problem stems from the setup code that is run and re-run over and
   over in CI jobs.


Reflections
╌╌╌╌╌╌╌╌╌╌╌

  The Dune codebase is well-structured, with clear separation between
  the build engine, rule generation, and scheduler. It is also of good
  quality, making it feel like time spent on keeping the quality high is
  worthwhile.

  I found the cram test infrastructure good for testing. Each test
  scenario is a self-contained shell script with expected output, making
  it easy to document and verify exact recompilation behavior. It
  inspires confidence in the code.

  The maintainers have been responsive and the review process, while
  slowed by thoroughness, is collaborative and professional. Thank you,
  maintainers!


Steffen Smolka then replied
───────────────────────────

        GitHub has no first-class support for PR stacks

  It does now: <https://github.github.com/gh-stack/>


First beta release of OCaml 5.5.0
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/first-beta-release-of-ocaml-5-5-0/18006/1>


octachron announced
───────────────────

  With most developer tools available and the good stability of the
  compiler, I am happy to announce the first beta release of OCaml
  5.5.0.

  Compared to the last alpha, this new version improves the manpage for
  ocamlopt and fixes:

  • two runtime bugs (for ephemerons and the bytecode interpreter)
  • two type system bugs (for classes and module-dependent functions)
  • three warning or error message bugs

  (See the Changelog below for a full list).

  Concerning the associated compiler tools, most of them are already
  available (as least in a preview version), and there are patches in
  progress for the remaining ones. You can track the last remaining
  update efforts on the [release readiness meta-issue].

  Thus, it should be safe to test your libraries and programs with the
  new version OCaml 5.5.0 version in preparation of the final release.
  If everything goes well, we might see a release in May.

  If you find any bugs, please report them to the [GitHub issue
  tracker].

  If you are interested by the full list of new features and bug fixes,
  the [changelog for OCaml 5.5.0] is the most up-to-date resource.


  Happy hacking, Florian Angeletti for the OCaml team.


[release readiness meta-issue]
<https://github.com/ocaml/opam-repository/issues/29463>

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

[changelog for OCaml 5.5.0]
<https://github.com/ocaml/ocaml/blob/5.5/Changes>

Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands on opam 2.1 and later:

  ┌────
  │ opam update
  │ opam switch create 5.5.0~beta1
  └────

  The source code for the beta is also available at these addresses:

  • GitHub: <https://github.com/ocaml/ocaml/archive/5.5.0-beta1.tar.gz>
  • OCaml archives at Inria:
    <https://caml.inria.fr/pub/distrib/ocaml-5.5/ocaml-5.5.0~beta1.tar.gz>


Fine-Tuned Compiler Configuration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  If you want to tweak the configuration of the compiler, you can switch
  to the option variant with:


  ┌────
  │ opam update
  │ opam switch create <switch_name> ocaml-variants.5.5.0~beta1+options <option_list>
  └────

  where `option_list' is a space separated list of `ocaml-option-*'
  packages. For instance, for a flambda and no-flat-float-array switch:

  ┌────
  │ opam switch create 5.5.0~beta1+flambda+nffa ocaml-variants.5.5.0~beta1+options ocaml-option-flambda ocaml-option-no-flat-float-array
  └────

  All available options can be listed with `opam search ocaml-option'.


Changes compared to the last alpha
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Documentation update

  • [#14684]: Improve ocamlopt's manual page (Samuel Hym, review by
    Florian Angeletti)


  [#14684] <https://github.com/ocaml/ocaml/issues/14684>


◊ Runtime fixes

  • [#14644], [#14647]: Fix a bug related to unhandled effects in
    bytecode.  (Vincent Laviron, report by Thibaut Mattio, review by
    Nicolás Ojeda Bär, Stephen Dolan and Olivier Nicole)
  • [#14349], [#14718]: runtime, fix in the orphaning of ephemerons
    (Gabriel Scherer, review by Olivier Nicole and Damien Doligez,
    report by Jan Midtgaard)


  [#14644] <https://github.com/ocaml/ocaml/issues/14644>

  [#14647] <https://github.com/ocaml/ocaml/issues/14647>

  [#14349] <https://github.com/ocaml/ocaml/issues/14349>

  [#14718] <https://github.com/ocaml/ocaml/issues/14718>


◊ Type system fixes

  • [#14557], [#12150], [#14696]: ensure that the self type of class
    cannot escape through type constraints.  (Leo White, review by
    Florian Angeletti)
  • [#14667]: enable application related warnings for module-dependent
    functions (Florian Angeletti, review by Gabriel Scherer)


  [#14557] <https://github.com/ocaml/ocaml/issues/14557>

  [#12150] <https://github.com/ocaml/ocaml/issues/12150>

  [#14696] <https://github.com/ocaml/ocaml/issues/14696>

  [#14667] <https://github.com/ocaml/ocaml/issues/14667>


◊ Error messages and warning fixes

  • [#14690]: Fix `Name_type_mismatch' error message when the expected
    type is an alias: print the expanded path on the right-hand side of
    the equality, not the alias twice.  (Weixie Cui, review by Florian
    Angeletti)
  • [#14719], [#14721]: compute arity correctly for module-dependent
    function (Florian Angeletti, report by Jeremy Yallop, review by
    Stefan Muenzel)
  • [#14655], [#14691]: check for size overflow in caml_ba_reshape
    (Stephen Dolan, review by Xavier Leroy)


  [#14690] <https://github.com/ocaml/ocaml/issues/14690>

  [#14719] <https://github.com/ocaml/ocaml/issues/14719>

  [#14721] <https://github.com/ocaml/ocaml/issues/14721>

  [#14655] <https://github.com/ocaml/ocaml/issues/14655>

  [#14691] <https://github.com/ocaml/ocaml/issues/14691>


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/5>


Continuing this thread, Chris Armstrong announced
─────────────────────────────────────────────────

  /ocgtk preview1 release has landed in opam./

  (preview0 was abandoned as considerable work was required to get it
  building on other Linux distributions and Mac). A special thanks to
  @jmid for helping me get it over the line.

  In addition to the features above, it includes:

  • Extended support for more GLib types, including integer primitives
    (guint8, int16, guint32, etc) and lists (GLib.SList and GLib.List)
  • Gobject interfaces

  The combination of the above enables more methods to be generated
  (that were previously excluded) when they include those types in their
  parameters and/or return types, opening up much more of the API
  surface of GTK (and related libraries).

  *Next steps*: my focus now is on internal cleanup and reorganisation
   to better structure the tests and split gir_gen (the GObject code
   generator) into a seperate dune project. This will reduce the
   dependency list considerably and enable targeting earlier OCaml
   versions, as well as reducing release headaches related to gir_gen
   (which is not required by packages just using ocgtk)


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: 70479 bytes --]

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