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

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

[-- Attachment #1: Type: text/plain, Size: 23192 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of May 20 to 27,
2025.

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

nanoev 0.1
15th MirageOS retreat May 13th - 20th
MlFront_Signify 2.3.1 - OpenBSD-compatible signify
Opam 103: Bootstrapping a New OCaml Project with opam, by OCamlPro
Retirement of Multicore CI Pipelines
Dune 3.19
Wrote a Record/Replay Debugging tutorial
A no-maths guide to monads
macOS Metal Framework bindings for compute applications
Other OCaml News
Old CWN


nanoev 0.1
══════════

  Archive: <https://discuss.ocaml.org/t/ann-nanoev-0-1/16682/1>


Simon Cruanes announced
───────────────────────

  Hello,

  I'm happy to announce the first release of [nanoev], yet another event
  loop abstraction. My goal with it is to have a narrow-waist interface
  between event loops (for now, `select' and `poll') and various
  abstractions built directly on top (for now using `picos'), without
  tying the event loop abstraction itself to a particular scheduler. The
  core interface for the event loop is basically:

  ┌────
  │ type t
  │ 
  │ val wakeup_from_outside : t -> unit
  │ 
  │ val step : t -> unit
  │ (** Run one step of the event loop until something happens *)
  │ 
  │ val close : t -> Unix.file_descr -> unit
  │ (** Close the file descriptor and clean it up *)
  │ 
  │ val max_fds : t -> int
  │ (** Maximum number of file descriptors that can be observed at once. *)
  │ 
  │ val on_readable :
  │   t -> Unix.file_descr -> 'a -> 'b -> (closed:bool -> 'a -> 'b -> unit) -> unit
  │ 
  │ val on_writable :
  │   t -> Unix.file_descr -> 'a -> 'b -> (closed:bool -> 'a -> 'b -> unit) -> unit
  │ 
  │ val run_after_s : t -> float -> 'a -> 'b -> ('a -> 'b -> unit) -> unit
  └────

  and nothing else. I've also started experimenting with using it to
  drive [tiny_httpd].

  • docs: <https://c-cube.github.io/nanoev/>
  • release link: <https://github.com/c-cube/nanoev/releases/tag/v0.1>


[nanoev] <https://github.com/c-cube/nanoev>

[tiny_httpd] <https://github.com/c-cube/tiny_httpd>


15th MirageOS retreat May 13th - 20th
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-15th-mirageos-retreat-may-13th-20th/16085/2>


Continuing this thread, gasche said
───────────────────────────────────

  I'm just back from the [Mirage retreat], an event where people
  interested in [Mirage] meet for one week to work whatever they
  want. This retreat was organized by Hannes Mehnert as all past
  retreats, in Marrakech. Hannes ( @hannes ) asked participants to write
  a blog post to spread the word – hence this post.


[Mirage retreat] <https://retreat.mirage.io/>

[Mirage] <https://mirage.io/>

a Mirage retreat, in general
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The retreat is unlike most other professional events that I attend,
  typically academic conferences. We are hosted in a place that is
  otherwise used as a hostel within the medina, the old city centre of
  Marrakech. Bed comfort is minimal (a room of six people, two of them
  snoring), but there are people on-site who prepare food and the food
  is great. There is very little structure for the day: we had a meeting
  every morning after breakfast to mention what we had done the day
  before, and talk sessions in the evening (typically one or two talks
  for around 40 minutes).

  The participants come in all shapes, some are regular contributors to
  the Mirage ecosystem and some (like me) know very little about
  Mirage. Some (like me) are very familar with OCaml and others know
  little about the language. Some people know about networking,
  security, system administration, communication protocols. The lack of
  structure encourages people to wander around, for example sitting
  alongside someone doing something specific and precise, to try
  something you and learn along. Last time I ended up writing bits of a
  network driver in OCaml, despite knowing nothing about network
  drivers; this time I worked on model-based testing of filesystems (see
  <https://discuss.ocaml.org/t/blog-post-using-model-based-testing-on-a-mirage-filesystem-implementation/16666>
  ), despite knowing nothing about file system implementations.

  Morocco has better network connectivity than during my first retreats,
  but it remains somewhat flaky – and our network-usage habits keep
  increasing. In particular, I could not attend any online meeting, and
  this was /very/ nice – just like conferences, it is liberating to be
  busy for one week uninterrupted. In the past I managed to adapt to
  low-network usage fairly well. This time I noticed that I depend on
  github a lot, and I don't know how to have a good offline or
  network-restricted experience, to do code-reviews in particular. I
  wish offline version-controlled tools for code-review and bugtracking
  were more widely employed.

  Overall I find this organization excellent: participants get a place
  and time to learn from each other. I think it could potentially be
  used for other topics. For example people mentioned that it could be
  interesting to have a retreat focused on documentation in the OCaml
  ecosystem, and I find the idea interesting.

  (The rest of this post is basically a narrated version of my work log
  for the week; please feel free to just skip it.)


My OCaml-focused work
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  One of my projects for the week was to take the time to review large
  pull-requests on the OCaml compiler that I wouldn't dare attacking
  usually, because my agenda is perpetually full of other things. I did
  a first round of review on [structured diagnostics], and additional
  reads through most of the [modular explicits] pull request (PR). In
  particular I wrote a small manual section for modular explicits,
  submitted as a [separate PR]. I hope to have moved from "it would be
  nice if these were reviewed /someday/" to a more short-term phase
  where I try to get these past the finish line before moving to other
  topics – but we never know.

  I also went through the lists of PRs I had been assigned to, sometimes
  a while ago. (OCaml triagers assign PRs to each other to keep track of
  them and try to bring them to a decision, but in practice we often
  forget to do this and they linger around.) This was fairly effective
  and my stack of assigned PRs has been about cut in half:

  • reviewed and merged:
    ⁃ `install_printer' cleanup (@pirbo) [#13969]
    ⁃ ocamltest C refactors (@MisterDA) [#13962]
    ⁃ format break hint fix (@Octachron) [#13853]
    ⁃ local structure items (@nojb) [#14009]
    ⁃ document `row_more' and `row_fixed' (@goldfirere) [#14023]
  • closed:
    ⁃ immediacy computation revamp (@ccasin) [#11841]
  • adopted and merged:
    ⁃ generational stack scanning (@xavierleroy) [#13594]
    ⁃ statmemprofs and bigarrays (@stedolan) [#13675]
    ⁃ recursive module error messages (@shivam-909) [#13608]
  • adopted but not yet merged
    ⁃ distinguish two kinds of mutexes (@gasche) [#13716] (needs a
      review)
    ⁃ source locations in implementations and interfaces (@malekbr)
      [#12654] (needs a review)

  A few of those PRs I "adopted", that is, I took control of the PR as
  the submitter would to rebase the PR and resubmit. In some cases this
  was mostly to apply my own review comments (sometimes someone else's),
  the change were minor and I could merge quickly. In some cases the
  changes were more invasive, and I would ask for another review. In one
  case I got stuck and wasn't sure how to rebase, so I asked the
  original author.

  "Adopting" PRs in this way is a new process to me, I generally try to
  guide the authors through making all the changes themselves. I wanted
  to go through my stack faster, and in some cases I knew that the
  authors were unresponsive and unavailable to make those changes. I
  found it fun, but it is probably best reserved to this situation where
  authors are unavailable.


[structured diagnostics] <https://github.com/ocaml/ocaml/pull/13766>

[modular explicits] <https://github.com/ocaml/ocaml/pull/13275>

[separate PR] <https://github.com/ocaml/ocaml/pull/14048>

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

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

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

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

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

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

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

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

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

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

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


Side errands
╌╌╌╌╌╌╌╌╌╌╌╌

  I worked on a race between domain-termination and compaction:
  [#14025]. I decided to try to make Dune more pleasant for building the
  OCaml compiler, and sent a draft/RFC PR at [dune#11819]. I heard a
  remark that it's painful not to be able to use lazy thunks anymore for
  library initialization code (lazy thunks are not concurrency-safe in
  OCaml 5); I tried to think about why this is hard to fall asleep again
  after a snoring attack, and ended up writing [#14043] instead. I
  motivated myself into [asking for volunteers] to review the
  Relocatable Compiler work.

  I also participated as a speaker to two talk sessions in the
  evening. I did a short demo of [Monolith] and model-based testing in
  general – that was before we decided to use it on a Mirage
  filesystem. I talked about the OCaml Software Foundation and recent
  discussions around improving the security of the OCaml ecosystem.


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

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

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

[asking for volunteers]
<https://discuss.ocaml.org/t/volunteers-to-review-the-relocatable-ocaml-work/16667/>

[Monolith] <https://gitlab.inria.fr/fpottier/monolith>


MlFront_Signify 2.3.1 - OpenBSD-compatible signify
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mlfront-signify-2-3-1-openbsd-compatible-signify/16683/1>


jbeckford announced
───────────────────

  I am pleased to announce the new package `MlFront_Signify' is
  available in opam.

  `signify' was created by OpenBSD for maintainers to sign distributions
  and for users to verify those distributions. That is described in
  [signify: Securing OpenBSD From Us To You] and the [signify manpage].

  `MlFront_Signify' is compatible with `signify'. The C code comes from
  firmware update code for the embedded Linux router distribution
  OpenWrt (much easier to build using OCaml tools compared to OpenBSD
  code). The _executable_ `mlfront-signify' has most of the same CLI
  options as OpenBSD `signify' and includes the same trivial tests as
  `signify', but on Unix you should just use your package manager's
  `signify'. The main contribution of `MlFront_Signify' is the OCaml
  _library_ that is documented at:
  • <https://dkml.gitlab.io/build-tools/MlFront/MlFront_Signify/MlFront_Signify/Signify/index.html>

  I used it with
  <https://discuss.ocaml.org/t/ann-combining-llvm-mc-lld-precompiled-c-and-bytecode/16675?u=jbeckford>
  to perform auto-upgrades. A few MlFront packages participate:
  • `MlFront_Signify' to verify a potential upgrade
  • `MlFront_ZipFile' to unpack a verified upgrade
  • `MlFront_Cache' to provide an immutable store where multiple
    versions can co-exist

  In particular, the `SHA256.sig' file in the file listing
  <https://github.com/diskuv/dkcoder/releases/tag/2.3.202505202143> was
  created using `MlFront_Signify' with the `SHA256' checksum file as
  input. That serves the same purpose as
  <https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/SHA256.sig>.

  /MlFront_ZipFile has an important bugfix so please upgrade it to 2.3.1
  as well./

  Thanks to the Mirage project where I use its `mirage-crypto-rng'
  secure random generator!

  Enjoy.


[signify: Securing OpenBSD From Us To You]
<https://www.openbsd.org/papers/bsdcan-signify.html>

[signify manpage] <https://man.openbsd.org/signify>


Opam 103: Bootstrapping a New OCaml Project with opam, by OCamlPro
══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-opam-103-bootstrapping-a-new-ocaml-project-with-opam-by-ocamlpro/16686/1>


OCamlPro announced
──────────────────

  *Greetings Cameleers,*

  We’re back with a new installment in our `opam deep-dives' series!

  [*Opam 103: Bootstrapping a New OCaml Project with opam*]

  This time, we’re taking a step back to focus on a beginner-friendly
  guide to setting up a toy OCaml project with `opam', `dune',
  `cmdliner', and `alcotest'.

  This article is aimed at newer members of the ecosystem who may be
  wondering:

  • How do I structure an OCaml project from scratch?
  • How to best use opam in my dev workflow?
  • How do I write a minimal `.opam' file?
  • What about a fully fledged one?

  We walk through the `opam' rationale and offer guidance for building
  your first opam-compliant package — the kind you can confidently pin
  and use locally before getting to publishing it.

  As always, we hope this piece serves as a helpful reference for those
  onboarding into the `opam' and the OCaml ecosystem and getting their
  first taste of the tooling.

  :link: Check out the other `opam deep-dives' articles on
  <https://ocamlpro.com/blog/>

  Feel free to share feedback or thoughts right here in this thread!

  Thank you all for your time, and until next time, *The OCamlPro Team*


[*Opam 103: Bootstrapping a New OCaml Project with opam*]
<https://ocamlpro.com/blog/2025_04_29_opam_103_starting_new_project/>


Retirement of Multicore CI Pipelines
════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/retirement-of-multicore-ci-pipelines/16691/1>


Mark Elvers announced
─────────────────────

  We believe that the two OCurrent pipelines setup for testing OCaml
  multicore have now served their purpose and will be retired.

  • [https://ocaml-multicoretests.ci.dev:8100]
  • [https://ocaml-multicore.ci.dev:8100]

  Please let me know if you still feel these have value.


[https://ocaml-multicoretests.ci.dev:8100]
<https://ocaml-multicoretests.ci.dev:8100>

[https://ocaml-multicore.ci.dev:8100]
<https://ocaml-multicore.ci.dev:8100>


Dune 3.19
═════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-3-19/16693/1>


Etienne Marais announced
────────────────────────

  The Dune team is happy to announce the release of dune `3.19.0'
  :smile:

  This release contains some important bug fixes along with some
  improvements for the `foreign_library' stanza. It introduces support
  for concurrent builds through the RPC server.

  If you encounter a problem with this release, you can report it on the
  [ocaml/dune] repository.


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

Changelog
╌╌╌╌╌╌╌╌╌

◊ Fixed

  • Fixed a bug that was causing cram tests attached to multiple aliases
    to be run multiple times. (#11547, @Alizter)
  • Fix: pass pkg-config (extra) args in all pkgconfig invocations. A
    missing –personality flag would result in pkgconf not finding
    libraries in some contexts. (#11619, @MisterDA)
  • Fix: Evaluate `enabled_if' when computing the stubs for stanzas such
    as `foreign_library' (#11707, @Alizter, @rgrinberg)
  • Fix $ dune describe pp for libraries in the presence of
       `(include_subdirs unqualified)' (#11729, fixes #10999,
       @rgrinberg)
  • Fix `$ dune subst' in sub directories of a git repository (#11760,
    fixes #11045, @Richard-Degenne)
  • Fix a crash involving `Path.drop_prefix' when using Melange on
    Windows (#11767, @nojb)


◊ Added

  • Added detection and warning for common typos in package dependency
    constraints (#11600, fixes #11575, @kemsguy7)
  • Added `(extra_objects)' field to `(foreign_library)' stanza with
    `(:include)' support.  (#11683, @Alizter)


◊ Changed

  • Allow build RPC messages to be handled by dune's RPC server in eager
    watch mode (#11622, @gridbugs)
  • Allow concurrent build with RPC server (#11712, @gridbugs)


Wrote a Record/Replay Debugging tutorial
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/tutorial-wrote-a-record-replay-debugging-tutorial/16709/1>


Sid Kshatriya announced
───────────────────────

  I've written a *tutorial* on Record/Replay debugging. If you're
  interested in reverse debugging please check it out [here].

  You can do Record/Replay style debugging of your `ocamlc.opt' compiled
  executables. You will be able to place breakpoints on all symbols
  exposed by the `ocaml.opt' compiler – this includes C functions +
  OCaml functions from your OCaml program and do things like
  reverse-continue.

  For more context please see an announcement I made a couple of months
  ago:
  <https://discuss.ocaml.org/t/ann-a-tool-to-reverse-debug-ocaml-other-binary-runs/16366/1>

  (What's new in this new discuss.ocaml.org post is to give focus to the
  tutorial I've very recently written)

  *How can `rr' / _Software Counters_ mode `rr' help me in OCaml if I'm
   not interested in gdb style debugging the OCaml executables ?*

  There are some other useful things that `rr' can do for OCaml-ers.

  *Here is one:* Let's say you want to know what programs have been
   executed when you compile a ocaml program via dune.

  ┌────
  │ $ dune init project hello_world
  │ $ cd hello_world/
  │ $ rr record -W -- dune b
  │ rr: Saving execution to trace directory `/home/sidk/.local/share/rr/dune-5'.
  └────

  Now run `rr ps'. You will get the exact invocations of all the
  programs that `dune build' triggered ! This takes you all the way down
  to showing you `ld' and `ar' invocations !

  Very useful when you want to know what happened in the whole process
  tree.

  /editor’s note: please follow the post link to see this big terminal
  output./


[here]
<https://github.com/sidkshatriya/me/blob/master/009-rr-on-aarch64.md>


A no-maths guide to monads
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-a-no-maths-guide-to-monads/16712/1>


Raphaël Proust announced
────────────────────────

  Prompted by someone complaining online about Haskell documentation, I
  wrote a zero-maths guide to monads (in OCaml, but it applies somewhat
  more broadly, it's just OCaml has nice binding opearators):

  <https://raphael-proust.gitlab.io/code/no-maths-guide-to-monads.html>


macOS Metal Framework bindings for compute applications
═══════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-macos-metal-framework-bindings-for-compute-applications/16713/1>


Lukasz Stafiniak announced
──────────────────────────

  Hi!

  I'm happy to announce the `metal' package with bindings to the Metal
  framework, with a relatively broad coverage except it _does not_ cover
  anything graphics or UI related.

  • Hosted on GitHub: [lukstafi/ocaml-metal: OCaml bindings to Apple
    Metal for general compute applications]
  • API documentation: [Metal (metal.Metal)]
  • Released to the repository: [metal 0.1.0 (latest) · OCaml Package]
  • Example usage: [ocannl/arrayjit/lib/metal_backend.ml at master ·
    ahrefs/ocannl]

  Enjoy!

  P.S. Disclaimer: code contains AI slop (and likely also my own
  errors). It's my first major employment of / "collaboration" with
  Large Language Models and I leaned into accepting choices made by the
  models.


[lukstafi/ocaml-metal: OCaml bindings to Apple Metal for general compute
applications] <https://github.com/lukstafi/ocaml-metal>

[Metal (metal.Metal)]
<https://lukstafi.github.io/ocaml-metal/metal/Metal/index.html>

[metal 0.1.0 (latest) · OCaml Package]
<https://ocaml.org/p/metal/latest>

[ocannl/arrayjit/lib/metal_backend.ml at master · ahrefs/ocannl]
<https://github.com/ahrefs/ocannl/blob/master/arrayjit/lib/metal_backend.ml>


Other OCaml News
════════════════

>From the ocaml.org blog
───────────────────────

  Here are links from many OCaml blogs aggregated at [the ocaml.org
  blog].

  • [The origin of the pipeline operator (`|>`)]


[the ocaml.org blog] <https://ocaml.org/blog/>

[The origin of the pipeline operator (`|>`)]
<https://batsov.com/articles/2025/05/22/the-origin-of-the-pipeline-operator/>


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 #2: Type: text/html, Size: 37224 bytes --]