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

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

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