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

Alan Schmitt
2025-05-20T11:52:44Z

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

Hello

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

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

Send us Talk and Workshop Proposals for Fun OCaml 2025 in Warsaw, September 15+16
Blog post: Using model-based testing on a Mirage filesystem implementation
Volunteers to review the relocatable-OCaml work?
Portable Lock Directories for Dune Package Management
Other OCaml News
Old CWN

Send us Talk and Workshop Proposals for Fun OCaml 2025 in Warsaw, September 15+16
═════════════════════════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/send-us-talk-and-workshop-proposals-for-fun-ocaml-2025-in-warsaw-september-15-16/16646/1>

Sabine Schmaltz announced
─────────────────────────

Hi everyone!

Fun OCaml 2025 is a 2 days open source hacking event dedicated to
OCaml enthusiasts and professionals. We focus on the impact and
potential of OCaml for solving real-world problems and get together in
Warsaw for a conference/hackathon over two days:

• Day 1 (Monday, September 15): talks (which are live-streamed) and
socializing/hacking.
• Day 2 (Tuesday, September 16): Workshops and hacking.

Topics we’re interested in:

• how you use OCaml in your business / in your projects
• OCaml libraries, frameworks, and other Open Source projects built on
OCaml
• hands-on demonstrations that encourage people to try things on the
second day of the event or at home
• seeing actual code and reasoning behind design decisions
• experience reports

For more details, check out the website and the CFP linked from there:

<https://fun-ocaml.com>

Blog post: Using model-based testing on a Mirage filesystem implementation
══════════════════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/blog-post-using-model-based-testing-on-a-mirage-filesystem-implementation/16666/1>

gasche announced
────────────────

I am attending the [MirageOS retreat] in Marrakesh, with in
particular:

• Mindy @yomimono, who implemented a small (but not so simple) file
system for Mirage, [Chamelon]
• Armaël @armael, who is interested in testing effectful, concurrent
and/or distributed systems

Armaël and myself decided to try to use model-based testing on
Chamelon.

Note: this is a long blog post, and you should feel free to skip at
any point. In particular, do skip the code sections if you don't care
about the details, they are here to make things precise but not
strictly necessary.

/Editor’s note: the blog post is too long for this newsletter. Please
read it [here]./

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

[Chamelon] <https://github.com/yomimono/chamelon/>

[here]
<https://discuss.ocaml.org/t/blog-post-using-model-based-testing-on-a-mirage-filesystem-implementation/16666/1>

Volunteers to review the relocatable-OCaml work?
════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/volunteers-to-review-the-relocatable-ocaml-work/16667/1>

gasche announced
────────────────

Hi discuss,

David @dra27 Allsopp has been working for a few years now on making
the OCaml compiler relocatable.

Currently you configure the compiler to be installed at a certain
path, and the resulting program and configuration depend on this path;
moving the installed prefix to a different place will break various
things. Having a relocatable compiler is good for Windows support, for
reproducible builds, for caching, etc.

An early version of this work was presented by David at the OCaml
compiler workshop 2022, and it is discuss in [a past Dicuss thread].

Good news! The work is now in a good enough shape that @dra27 has
started upstreaming parts of it – submitting them to the compiler
distribution. There is [an RFC] that describes the design, and we got
[a first PR] that is a test harness for the feature, with many more to
come.

Bad news: we don't know who would be available to review those PRs as
they come. @nojb made an effort to review the test harness, but is
also working on tons of other stuff (such as: trying to get stdlib
contributions across the finish line). My understanding is that
@Rucikir is not available to do this work. There is a risk that the
work is held back due to the absence of motivated reviewers to look at
it.

Would anyone around be interested in helping review this work? If so,
I'm happy to post links to further PRs as they come.

In my experience, PRs by @dra27 touch a varied number of obscure
topics that *no one* except maybe himself is an expert about – deep
stuff about how the compiler work that most of us are happy to ignore
because it usually stays out of the way. One typical example, I
suspect, is [#13728 : Add `Sys.runtime_executable' and
`caml_sys_proc_self_exe'] (which is not merged, not looking for
reviewers). If you find this PR super-obscure, welcome to the club, I
don't understand anything either. But if you also find it
*interesting*, you may be excellent volunteer material to review more
PRs on this.

Note: the contribution rules for compiler PRs is that each PR must be
approved by someone with commit rights (a compiler maintainer) to get
merged. By itself, an approval from another contributor does not
suffice. But it is certainly possible for maintainers to give approval
on behalf of another review – we do it in practice. If you review a PR
(about this or anything else) and you feel confident that it is okay
to merge it, please feel free to explicitly "approve" it through the
github interface.

[a past Dicuss thread]
<https://discuss.ocaml.org/t/relocatable-compiler-work/11218>

[an RFC] <https://github.com/ocaml/RFCs/pull/53>

[a first PR] <https://github.com/ocaml/ocaml/pull/14014>

[#13728 : Add `Sys.runtime_executable' and `caml_sys_proc_self_exe']
<https://github.com/ocaml/ocaml/pull/13728>

David Allsopp added
───────────────────

has been working for a few years now on making the OCaml
compiler relocatable.

Just to make it sound a little less Herculean, I haven’t been working
_solidly_ on it 😊 There were a few OCaml 5.0 and Windows opam
2.2-shaped diversions on the way…

In addition to the already opened test harness, there’s a draft (with
explanatory text) of the first of the main PRs at
<https://github.com/dra27/ocaml/pull/183> and a draft of the second
(currently without explanatory text, although that will be there by
next week) at <https://github.com/dra27/ocaml/pull/162>. The third is
still awaiting a small amount of tidying (which will hopefully also be
done by the end of next week 🥵)

Portable Lock Directories for Dune Package Management
═════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/portable-lock-directories-for-dune-package-management/16669/1>

Steve Sherratt announced
────────────────────────

We've recently made a change to how lock directories work in the [Dune
Developer Preview].

Previously when Dune would solve dependencies for a project and
generate a lock directory, the lock directory would be specialized for
the computer where it was generated, with no guarantee it would work
on a different computer. This posed a problem for checking lock
directories into version control for projects with multiple
developers, since one developer might lock the project on their Mac,
say, only for another developer on Linux to be unable to build it due
to its MacOS-specific lock directory.

This post is to announce that Dune now supports generating /portable/
lock directories; a lock directory generated on one computer will now
contain a dependency solution for a range of different computers,
making it safe to check lock directories into version control.

[Dune Developer Preview] <https://preview.dune.build/>

Technical Details
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

In Opam the dependencies of a package can be different depending on
properties of the computer where the package is being installed. A
package might have a different set of dependencies when being
installed on MacOS verses Linux verses Windows, or the dependencies
might vary depending on the CPU architecture. It's even possible
(though quite rare in practice) for the dependencies of a package to
vary between operating system distributions, or even operating system
versions.

This expressive power makes Opam very flexible as it allows packages
to be specialized for the environment where they will be
installed. The drawback of this approach is that there might not be a
single solution to a dependency problem that works everywhere. Each
combination of OS/architecture/distro/version could, in theory,
require a different dependency solution. There are way too many
combinations of those properties to run Dune's dependency solver once
for each combination in a reasonable amount of time. Instead we
elected to compromise and have Dune only generate a solution for
common platforms by default, while allowing users to specify a custom
list of platforms to solve for in their `dune-workspace' file.

Lockfiles now look a little different to account for the fact that
they now contain multiple different platform-specific dependency
solutions. For example, formerly, the lockfile for the
`ocaml-compiler' package on an x86 machine running Windows, you might
have had a `depends' field like:

┌────
│ (depends arch-x86_64 system-mingw mingw-w64-shims flexdll)
└────

Most of these dependencies are specific to Windows; it's unlikely that
you'll be able to install any of these dependencies on Linux or MacOS.

With the portable lock directories feature enabled, this field now
might look like:

┌────
│ (depends
│ (choice
│ ((((arch x86_64)
│ (os linux))
│ ((arch arm64)
│ (os linux))
│ ((arch x86_64)
│ (os macos)
│ (os-distribution homebrew)
│ (os-family homebrew))
│ ((arch arm64)
│ (os macos)
│ (os-distribution homebrew)
│ (os-family homebrew)))
│ ())
│ ((((arch x86_64)
│ (os win32)
│ (os-distribution cygwin)
│ (os-family windows)))
│ (arch-x86_64 system-mingw mingw-w64-shims flexdll))
│ ((((arch arm64)
│ (os win32)
│ (os-distribution cygwin)
│ (os-family windows)))
│ (system-mingw mingw-w64-shims flexdll))))
└────

This new syntax is similar to a match-statement, listing the
dependencies for each platform for which Dune's solver ran. You can
change the platforms Dune will solve for by adding something like this
to `dune-workspace':

┌────
│ (lock_dir
│ (solve_for_platforms
│ ((arch arm64)
│ (os openbsd))
│ ((arch x86_32)
│ (os win32))))
└────

After running `dune pkg lock' again, the lockfile for `ocaml-compiler'
will be updated with these dependencies:

┌────
│ (depends
│ (choice
│ ((((arch arm64) (os openbsd))) ())
│ ((((arch x86_32)
│ (os win32)))
│ (system-mingw ocaml-option-bytecode-only flexdll))))
└────

A few other fields of lockfiles now also use the new syntax. Dune
lockfiles contain the commands needed to build and install each
package, as well as the names of any system packages needed by the
Opam package, and each of these fields can also have platform-specific
values.

Lockfile names now include the version number of the package. The
`ocaml-compiler' package used to have a lockfile named
`ocaml-compiler.pkg' but now has a name like
`ocaml-compiler.5.3.0.pkg' instead. This is because it's possible that
different platforms may require different versions of the same package
in the dependency solution, so the lock directory needs to be able to
contain multiple lockfiles for the same package without them colliding
on filename.

How do I get it?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

This feature is live in the latest version of the [Dune Developer
Preview]. Follow the instructions on that page to install a version of
Dune with this feature. With portable lock directories enabled, Dune
will temporarily remain backwards compatible with the original lock
directory format, though support will likely be dropped at some
point. Generate a new lock directory by running `dune pkg
lock'. You'll know your lock directory is portable if each file inside
it has a version number in its filename.

Happy reproducible building!

[Dune Developer Preview] <https://preview.dune.build/>

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

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

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

• [The week that was - 2025 w20]
• [OCaml Web Development: Essential Tools and Libraries in 2025]
• [The week that was - 2025 w19]

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

[The week that was - 2025 w20]
<https://www.dra27.uk/blog/week-that-was/2025/05/18/wtw-20.html>

[OCaml Web Development: Essential Tools and Libraries in 2025]
<https://tarides.com/blog/2025-05-15-ocaml-web-development-essential-tools-and-libraries-in-2025>

[The week that was - 2025 w19]
<https://www.dra27.uk/blog/week-that-was/2025/05/09/wtw-19.html>

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