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

Alan Schmitt
2025-01-21T15:47:43Z

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

Hello

Here is the latest OCaml Weekly News, for the week of January 14 to 21,
2025.

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

OCaml Software Foundation: January 2025 update
ppxlib.034.0
Release of Carton 1.0.0 and Cachet
Opam repository archival, phase 2 - OCaml 4.08 is the lower bound
Ocaml-posix 2.1.0 released!
Release of ocaml-eglot 1.0.0
Semgrep is hiring to help scale their static analysis engine
Dune dev meeting
Tarides: 2024 in Review
Other OCaml News
Old CWN

OCaml Software Foundation: January 2025 update
══════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ocaml-software-foundation-january-2025-update/15951/1>

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

Happy new year!

This is an update on recent works of the [OCaml Software Foundation],
covering our 2024 actions – the previous update was in [January 2024].

The OCaml Software Foundation is a non-profit foundation ([earlier
thread]) that receives funding from [our industrial sponsors] each
year, and tries its best to spend it to support and strengthen the
OCaml ecosystem and community.

The funding volume we receive each year is around 200K€. (For
comparison: this is the yearly cost of one experienced full-time
software engineer in many parts of the world.) We do not fund people
full-time for long periods. Most actions receive from 3K€ to 20K€.
The work to prepare and execute actions is mostly done by the (unpaid)
[Executive Committee]. It is currently formed by Nicolás Ojeda Bär,
Damien Doligez, Xavier Leroy, Kim Nguyễn, Virgile Prevosto and myself,
with administrative personnel provided by [INRIA] and general
assistance by Alan Schmitt.

Our current sponsors (thanks!) are [ahrefs], [Jane Street], [Tezos],
[Bloomberg], [Lexifi], [SimCorp], [MERCE] and [Tarides]. (If your
company would like to join as a sponsor, please [get in
touch]. Unfortunately, we still cannot efficiently process small
donations, so we are not calling for individual donations.)

Feel free to use this thread for questions/suggestions :-)

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

[January 2024]
<https://discuss.ocaml.org/t/ocaml-software-foundation-january-2024-update/13828>

[earlier thread]
<https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476>

[our industrial sponsors] <http://ocaml-sf.org/#sponsors>

[Executive Committee] <http://ocaml-sf.org/about-us/>

[INRIA]
<https://en.wikipedia.org/wiki/French_Institute_for_Research_in_Computer_Science_and_Automation>

[ahrefs] <https://ahrefs.com/>

[Jane Street] <https://janestreet.com/>

[Tezos] <https://tezos.com/>

[Bloomberg] <https://bloomberg.com/>

[Lexifi] <https://lexifi.com/>

[SimCorp] <https://simcorp.com/>

[MERCE] <https://www.mitsubishielectric-rce.eu/>

[Tarides] <https://tarides.com/>

[get in touch] <http://ocaml-sf.org/becoming-a-sponsor/>

Recent actions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Education and outreach

We funded a new edition of the Spanish [summer school] on functional
programming in OCaml, organized in Saragossa by Ricardo Rodriguez and
Roberto Blanco.

We continued funding the OCaml meetups in Paris and Toulouse,
France. In 2024, a [new meetup] started in Chennai, India (first
[discuss thread]), which we are delighted to support as well.

We are sponsoring the [JFLA 2025], a functional programming conference
in France, and an [OCaml Bridge Workshop] at Functional Conf 2025, a
large Asian conference on functional programming.

[summer school] <https://webdiis.unizar.es/evpf/index.html>

[new meetup] <https://www.meetup.com/chennai-ocaml-meetup/>

[discuss thread]
<https://discuss.ocaml.org/t/chennai-ocaml-meetup-june-2024/14695>

[JFLA 2025] <https://jfla.inria.fr/jfla2025.html>

[OCaml Bridge Workshop]
<https://confengine.com/conferences/functional-conf-2025/proposal/21057/ocaml-bridge-workshop>

◊ Research

The OCaml Software Foundation is typically not involved in funding
research, focusing on actions that have an immediate impact on the
language and its community. Nevertheless, in 2023 we funded one year
of post-doctoral work for Takafumi Saikawa in relation to his
maintenance work on the type-checker of OCaml. In 2024 we funded one
year of research engineer for the [Salto] project, building a static
analyzer for OCaml, and one year of PhD grant for [Alistair O'Brien]
in Cambridge (complementing other funding sources for a full PhD),
continuing his [impressive work] on constraint-based type inference
for OCaml.

[Salto] <https://salto.gitlabpages.inria.fr/>

[Alistair O'Brien] <https://github.com/johnyob>

[impressive work] <https://github.com/johnyob/dromedary/>

◊ Ecosystem

◊ Infrastructure

As in previous years, we fund the work of Kate Deplaix to check that
the OCaml ecosystem is compatible with upcoming compiler releases;
in 2024 Kate worked on OCaml 5.2 and 5.3.

We are trying our best to support the work of opam-repository
maintainers, through individual funding grants for the active
maintainers. This year, on the suggestion of the repository
maintainers, we are also funding the work of [Robur] to migrate
unmaintained packages to a separate archive ([discuss thread 1],
[thread 2]).

[Robur] <https://robur.coop/>

[discuss thread 1]
<https://discuss.ocaml.org/t/proposed-package-archiving-policy-for-the-opam-repository/15713>

[thread 2]
<https://discuss.ocaml.org/t/opam-repository-archival-phase-1-unavailable-packages/15797/2>

◊ Tools

In 2024 we have funded one month of maintenance of the `opam' client
by Raja Boujbel and her colleagues.

We renewed our partial support for the work of Antonio Monteiro on
[Melange]. For more Melange news, see for example the announcement
of [Melange 4].

[Melange] <https://melange.re/v4.0.0/>

[Melange 4] <https://melange.re/blog/posts/melange-4-is-here>

◊ Libraries

We keep supporting the work of Petter Urkedal on the [Caqti]
library, the main database connection library in the OCaml
community.

The [Owl] library for scientific computing has been [restructuring]
in 2024, with its two maintainers moving to permanent jobs demanding
their time and therefore less available. The OCaml Software
Foundation is providing a small grant to help the maintainers
transition to a different contribution model and/or preserve a part
of their maintenance activity, as they think is best.

We have been funding documentation work by John Whitington to
collect or create usage examples of important OCaml libraries, prior
to their upstreaming in the documentation of each project. See his
[ocaml-nursery] repository.

We support the contributions of Daniel Bünzli to the OCaml
ecosystem. This year, Daniel used this support to fund the
development of

• [jsont], a new library for declarative JSON data manipulation
• [bytesrw], a library of composable byte stream readers and writes,
with support for various compression and hashing algorithms
• [support] for Unicode 16.0 in his Unicode libraries

Finally, we have been funding Nathan Rebours to take an active part
in the maintenance of the ppxlib project, see his [ppxlib
maintenance summary].

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

[Owl] <https://github.com/owlbarn/owl>

[restructuring]
<https://discuss.ocaml.org/t/owl-project-restructured/14226>

[ocaml-nursery] <https://github.com/johnwhitington/ocaml-nursery>

[jsont]
<https://discuss.ocaml.org/t/ann-jsont-0-1-0-declarative-json-data-manipulation-for-ocaml/15702>

[bytesrw]
<https://discuss.ocaml.org/t/ann-bytesrw-0-1-0-composable-byte-stream-readers-and-writers/15696>

[support]
<https://discuss.ocaml.org/t/ann-unicode-16-0-0-update-for-uucd-uucp-uunf-and-uuseg/15270>

[ppxlib maintenance summary]
<https://discuss.ocaml.org/t/ppxlib-maintenance-summary/14458>

ppxlib.034.0
════════════

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

Nathan Rebours announced
────────────────────────

We're happy to announce that we just released ppxlib.0.34.0.

The full patch notes are available on the release page [over here].

The main features are OCaml 5.3 compatibility, new AST pretty-printing
utilities and the ppxlib-tools package, support for `[@@deriving ...]'
on class types and the addition of missing `Pprintast' entry points.

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

Changes summary
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ 5.3 compatibility

ppxlib.0.34.0 is the first official ppxlib release that's compatible
with the new 5.3 compiler.

The ppxlib driver now also comes with a `-keywords' CLI option,
similar to the compiler's that allow you to compile and preprocess
with the 5.3 compiler code that uses `effect' as an identifier. This
is pretty niche but it's there should you need it.

Please note that means you can use ppx-es with a 5.3 compiler but not
that ppx-es can consume/produce 5.3 language features. We're currently
working on a fix allowing you to use the effect syntax in files that
require preprocessing as it's not possible with 0.34.0. The fix should
be released in the next few days as 0.34.1.

◊ AST pretty-printing

We added a new `Pp_ast' module that allows you to pretty print AST
fragments.

The only way ppxlib would print ASTs before were as S-expressions. In
practice we found that it was not always helpful and wanted a more
readable and human friendly way of displaying the AST.

The default output of those printer is a simplified version of the AST
to keep things clear and avoid cluttering the output with information
that is not always useful. For example, if you run
`Ppxlib.Pp_ast.Default.expression' on the AST for `x + 2', you'll get
the following:
┌────
│ Pexp_apply
│ ( Pexp_ident (Lident "+")
│ , [ ( Nolabel, Pexp_ident (Lident "x"))
│ ; ( Nolabel, Pexp_constant (Pconst_integer ( "2", None)))
│ ]
│ )
└────
The alert reader will note that there are no locations or attributes
and that the `expression' record layer is omitted here.

You can of course configure the printer to display more information if
you need to.

We've been using these new printers internally to debug migration code
and they have been a huge help so we hope they will make working with
ppxlib easier for you too.

In addition to this new module, we also added a command line utility
called `ppxlib-pp-ast' to pretty print ASTs from source files, source
code fragments or even marshalled AST files. It is very similar to the
old `ppx_tools''s `dumpast'.

Note that it will print ppxlib's internal AST after it's been migrated
from the installed compiler's version. This is something that we could
not simply achieve with OCaml's own `-dparsetree'.

This should be a useful tool for debugging ppx related bugs or
learning about the AST and we hope ppx authors and users will like it.

◊ Other changes

As mentioned above, we also added some missing `Pprintast~¹ entries
such as ~binding', `longident' and `payload'.

It is now possible to use `[@@deriving ...]' on class type
declarations and therefore to write derivers for class types.

¹: /To the confused readers:/ `Pprintast' /is entirely different from/
`Pp_ast' /mentioned above as it prints the source code corresponding
to a given AST./

Plans for the next release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Internal AST bump to 5.2

Our next release will bump our internal AST to 5.2. It is a pretty big
change because 5.2 changed how functions were represented in the AST
and this impacts *A LOT* of ppx-es.

@patricoferris has been working very hard on this over the past few
months to minimize the amount of breakage and to send patches upstream
where that was not possible to get the rest of the ecosystem ready for
the bump.

We wanted to first release the 5.3 compatibility but now that's out of
the way we're able to focus on the bump again.

@patricoferris will create a dedicated thread shortly to explain a bit
what's been going on and what to expect from this release.

◊ Drop support for OCaml < 4.08

It is time for us to drop support for very old compilers. Keeping
support for OCaml 4.07 and before requires maintenances of quite heavy
compatibility layers and prevents us from using some language features
in ppxlib's source code while providing little to no benefits since
the vast majority of users already upgraded to much more recent
compilers.

If you're still relying on those older compilers and the newest
ppxlib, please reach out, either here or via a ppxlib issue.

Special thanks
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

We wanted to thank our external contributors for this release: @hhugo,
@nojb and @dra27 for their help on the 5.3 compat and @mattiasdrp for
bringing the `Pprintast' module up to speed.

Special thanks as well to @pedrobslisboa who started integrating their
excellent [ppx-by-example] into ppxlib's documentation.

Finally, I'd also like to thank the OCaml Software Foundation who's
been funding all my work on ppxlib and made this release possible!

Happy preprocessing to you all!

[ppx-by-example] <https://github.com/pedrobslisboa/ppx-by-example>

Release of Carton 1.0.0 and Cachet
══════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-release-of-carton-1-0-0-and-cachet/15953/1>

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

I'm delighted to announce the release of [Carton 1.0.0] and [Cachet]
(which will be released soon into `opam-repository').

Carton is a reimplementation of the Git PACK format. A PACK file is
what you can find in your `.git/objects/pack' in your favourite Git
repository. It contains mainly all your Git objects. This format
provides a good compression ratio and the ability to extract objects
almost directly. It can be seen as a read-only key-value database — in
effect, modifying Git objects is impossible.

This project is built around the OCaml implementation of Git that we
have. But the PACK format is also interesting in its own right and
outside the Git concepts.

The PACK format offers double compression. A zlib compression
(proposed by [decompress]) as well as a compression between objects in
the form of a binary patch (proposed by [duff]).

So, if the "words" appear quite frequently (like the words used in a
programming language — if, else, then, etc.), the second level of
compression becomes very interesting where an object (such as a file)
is simply a succession of patches with other objects.

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

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

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

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

Cachet, a library for `mmap' syscall
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Carton and the PACK format very often use syscall `mmap'. The point is
to be able to take advantage of the kernel cache system to read a PACK
file. The kernel can read a file in advance when reading a page via
`mmap'. Basically, the kernel anticipates that you might want to get
the next page after the one you requested.

However, in the case of Carton, it is sometimes necessary to ‘go
back’, particularly for patched objects whose source is often
upstream.

Cachet is an intermediate layer for `mmap' that caches previously
obtained pages. In this way, we take advantage of both the kernel for
subsequent pages and our library for previous pages.

Let's take a concrete example. Carton can analyse a PACK file as `git
verify-pack' does. Let's make a comparison with and without Cachet.

┌────
│ +--------------+-------------+----------------+-----------------+
│ | | with cachet | without cachet | git verify-pack |
│ +--------------+-------------+----------------+-----------------+
│ | time | 17.8s | 41.8s | 9.3s |
│ +--------------+-------------+----------------+-----------------+
│ | cache misses | 936M | 1933M | 246M |
│ +--------------+-------------+----------------+-----------------+
└────

As you can see, using Cachet improves Carton's execution time. We're
still not as competitive as git-verify-pack, but we're getting close!

Cachet offers to cache previously loaded pages. Its cache system is
very basic and is just a small array whose size is a power of
two. Next, we simply reuse the OCaml hash function — in this respect,
it may be worth testing another hash function.

◊ Cachet & schedulers

Like most of our projects, Cachet is independent of schedulers. There
is therefore a variant with [Lwt] and a variant with [Miou]. However,
we need to clarify a behaviour related to the use of Cachet. Reading a
file, whether with `read(3)' or `mmap(3P)', does not block, but it can
take some time.

As we have already experienced and explained [here], it may be
necessary to explain to the scheduler whether it is appropriate to do
something else after such a syscall. In the case of Lwt, it might be a
good idea to insert `Lwt.pause' just after our syscall so that Lwt
gives another service the opportunity to run despite the time taken
trying to read from a file. However, particularly for Lwt, this means
closing Cachet in the hell of the monad (in other words, there is no
way to escape it) because of this possible `Lwt.pause' (which returns
`unit Lwt.t').

The composition of Cachet with Lwt is therefore quite different from
what we've been able to experiment with. One of [our other articles]
suggests not using functors (too much), and although we can in fact
abstract `Lwt.t' from `unit Lwt.t' (and even reduce it such that `type
'a t = 'a') with the [HKP] trick, we opted for composition by hand.

The problem relates to Lwt (and Async) and doesn't apply to Miou when
it's possible to raise effects. However, from such a composition, a
choice has been made to give Lwt the opportunity to do something else
after `mmap'. We could, in other types of applications, make another
choice on this precise question.

[Lwt] <https://github.com/ocsigen/lwt>

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

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

[our other articles]
<https://blog.robur.coop/articles/tar-release.html>

[HKP]
<https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-kinded-polymorphism.pdf>

Carton
╌╌╌╌╌╌

Carton is a library that was originally developed for ocaml-git. It
was internal to the project but we considered that the PACK format's
field of application could be wider than that of Git. We decided to
extract the project from `ocaml-git' and make it a library in its own
right. Carton's objective remains fairly rudimentary. It consists of:
• extract objects from a PACK file (whether or not these objects are
Git objects)
• generate an `*.idx' file from a PACK file in order to have quick
access to the objects
• verifying a PACK file such as `git verify-pack' does
• and finally generate a PACK file from a list of objects

Carton is a library and a tool that you can now use on your Git
repositories. Here are a few examples of how to use `carton'. We'll
start by cloning a repository to test Carton and go to the folder
containing the PACK file.
┌────
│ $ opam install carton.1.0.0
│ $ git clone https://github.com/ocaml/ocaml
│ $ cd ocaml/.git/objects/pack/
└────

Carton can check a PACK file. Verifying means extracting all the
objects in the file from memory and calculating their hash. This
command is similar to `git verify-pack'.
┌────
│ $ carton verify pack-*.pack
└────

Carton can extract a specific object (commit, tree or blob) from a
PACK file using its associated `*.idx' file and the object identifier
(the hash of the commit, for example).
┌────
│ $ carton get pack-*.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2
└────

Instead of extracting objects from a PACK file into memory, you can
also extract them as files using `explode'.
┌────
│ $ mkdir loose
│ $ carton explode 'loose/%s/%s' pack-*.pack > entries.pack
└────

Finally, Carton can create a new PACK file from a list of objects
stored in files with make. It can also generate the `*.idx' file
associated with the new PACK file. As we've just re-packaged the
objects in the repository, we should find the same objects.
┌────
│ $ carton make -n $(cat entries.pack | wc -l) -e entries.pack new.pack
│ $ carton index new.pack
│ $ carton get new.idx 89055b054eeec0c6c6b6118d6490b6792da7fef2
└────

Please note that the above actions, applied to `ocaml/ocaml', may take
some time due to the history of this project.

In the example above, we can see the extraction of a Git object, the
extraction of all the objects in a PACK file and the creation of a new
PACK file based on all the extracted objects.

As you can see, creating a PACK file can take a long time. However,
the advantage of the PACK file lies particularly in obtaining the
objects and in the rate of compression of the PACK file:

┌────
│ +--------+-------------+----------+-------+--------------+
│ | | pack-*.pack | new.pack | loose | loose.tar.gz |
│ +--------+-------------+----------+-------+--------------+
│ | size | 355M | 648M | 8.3G | 1.8G |
│ +--------+-------------+----------+-------+--------------+
└────

The PACK file is primarily designed to provide access to objects
according to their identifiers. This access must be as fast as
possible, even if the object is first compressed with decompress and
can be compressed in the form of a patch with duff. Here are a few
metrics to give you an idea.

┌────
│ +--------------+-------------+----------+---------+
│ | | pack-*.pack | new.pack | loose |
│ +--------------+-------------+----------+---------+
│ | git cat-file | ~ 0.01s | N/A | N/A |
│ +--------------+-------------+----------+---------+
│ | carton get | ~ 0.20s | ~ 0.30s | |
│ +--------------+-------------+----------+---------+
│ | cat | N/A | N/A | 0.0006s |
│ +--------------+-------------+----------+---------+
└────

What's important to note is the ability to have random access to
objects simply by having the associated `*.idx' file, the production
of which is quite efficient. This is not or hardly the case for
compression formats such as GZip. And that's the whole point of PACK
files, with an indexing method for almost immediate access to objects
according to their identifiers and offering a very good compression
ratio.

*NOTE*: Carton does not compress the repository as well as Git. The
main reason is that Git has some heuristics relating to Git objects
that Carton does not implement - because Carton wishes to be
independent of Git concepts. These heuristics apply in particular to
the order in which we want to pack objects. In addition, Git prepares
the ground so that the antecedents of a blob object (which is a file
in your repository), for example, are the old versions of that same
blob (and therefore the old versions of your file).

In this context, the patch algorithm implemented by [duff] applies
very well and gives very good results.

For more details on these heuristics, you can read [this discussion]
that serves as documentation.

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

[this discussion]
<https://github.com/git/git/blob/master/Documentation/technical/pack-heuristics.txt>

◊ Carton & parallelism

As always, our libraries are independent of schedulers. There is a
version of Carton with Lwt and a version with Miou.

Some of the tasks Carton performs, such as indexing, are highly
parallelizable. In this case, the new derivation of Carton with Miou
exists to take advantage of the latter's domain pool.

It was also quite easy to parallelize the work on `carton index' and
`carton verify'. Here are some other metrics which, thanks to OCaml 5
and Miou, bring us closer to Git performance:

┌────
│ $ hyperfine \
│ -n git \
│ "git verify-pack pack-03a3a824757ff4c225874557c36d44eefe3d7918.idx" \
│ -n carton \
│ "carton verify pack-03a3a824757ff4c225874557c36d44eefe3d7918.pack -q --threads 4"
│ Benchmark 1: git
│ Time (mean ± σ): 329.2 ms ± 0.9 ms [User: 384.2 ms, System: 27.8 ms]
│ Range (min … max): 327.7 ms … 330.9 ms 10 runs
│
│ Benchmark 2: carton
│ Time (mean ± σ): 712.1 ms ± 10.9 ms [User: 1111.8 ms, System: 1112.6 ms]
│ Range (min … max): 695.4 ms … 726.8 ms 10 runs
│
│ Summary
│ git ran
│ 2.16 ± 0.03 times faster than carton
└────

*NOTE*: it may come as a surprise that Carton is 2 times slower than
Git for analysing a PACK file, but it should be noted that almost the
entire Carton implementation is in OCaml! At this stage, the idea is
more to give you an idea, but we literally find ourselves comparing a
Bugatti with a [Citroën 2CV].

[Citroën 2CV] <https://www.youtube.com/watch?v=Pkhibs9n7tE>

◊ Carton & Emails

Finally, this in-depth rewrite of Carton allows us to take advantage
of the PACK format for storing our emails.

In fact, we are experimenting with and developing an email solution
within our cooperative, and email archiving is one of our
objectives. Based on our experience of implementing Git, we thought
that the PACK format could be a very interesting format for archiving
emails.

It combines two features, rapid access to emails and compression by
patches, which are very interesting when it comes to handling
emails. Finally, it also corresponds more or less to the way we use
email:
• we don't want to delete them (more often than not, we want to keep
them _ad vitam aeternam_)
• and we don't modify them

It therefore corresponds to a sort of read-only database. For more
details on this aspect of Carton and the results of our experiments, I
suggest you read our [recent article on our cooperative's blog].

[recent article on our cooperative's blog]
<https://blog.robur.coop/articles/2025-01-07-carton-and-cachet.html>

Opam repository archival, phase 2 - OCaml 4.08 is the lower bound
═════════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/opam-repository-arcival-phase-2-ocaml-4-08-is-the-lower-bound/15965/1>

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

It is my pleasure to announce below the list of opam packages that
will move to the opam-repository-archive on February 1st 2025. In
total there are 5855 opam files scheduled for being moved within 1218
unique packages. This decreases the size of the opam-repository by
roughly 20%.

/Editor note: please follow the post link for the other articles with
whole list./

This list contains all packages that are not compatible with OCaml >=
4.08, and packages that after archiving those are not installable due
to missing dependencies. The "not installable" list has been generated
by [archive-opam], and this may of course contain bugs.

A smaller list contains a re-run of phase 1 (packages that are
available: false) - where the availability was added between Dec 15th
and now.

If you find a package in the list and you’d like to retain it in the
opam-repository, there are some options:

• (a) you can install it on your system (`opam install'): this means
there’s a bug in the archive-opam utility, please provide the
package name and version in the [opam-repository-archive Phase 2
PR], together with your opam version, OCaml version, and operating
system;
• (b) it is not installable: please figure out the reasoning (the
“Reasoning” may help you to find the root issue), and try to fix it
yourself - if you’re unable to fix the root cause, please also
comment in the [opam-repository-archive Phase 2 PR] with the package
name and version.

If you’ve any questions, please don’t hesitate to ask here or on
GitHub or via another communication channel.

You can help further on the archiving process:

• as mentioned in the last announcement please add the
`x-maintenance-intent' to your packages (a good choice for a lot of
packages is `x-maintenance-intent: [("latest")]' if you’re
maintaining the latest version only) - this will be considered in
Phase 3 (March 1st 2025);
• if you are the author or maintainer of a package that is no longer
useful or maintained, you can as well mark your opam files in the
opam-repository with `x-maintenance-intent: [("none")]' (this will
be taken into account in Phase 3 - March 1st 2025);
• if you flagged your preliminary releases with `flags:
avoid-version', and they can now be removed (e.g. since a stable
version has been released), please open a pull request to replace
the `avoid-version' with `deprecated'.

Please note that the next Phase will be announced on February 15th
with all packages where the `x-maintenance-intent' does not match, and
which do not have any reverse dependencies - archiving is scheduled
for March 1st.

To keep track of the announcements, please look at the
[opam-repository tag].

A big thanks to the OCaml Software Foundation for funding the
opam-repository archival project.

[archive-opam] <https://github.com/hannesm/archive-opam>

[opam-repository-archive Phase 2 PR]
<https://github.com/ocaml/opam-repository-archive/pull/6>

[opam-repository tag] <https://discuss.ocaml.org/tag/opam-repository>

Ocaml-posix 2.1.0 released!
═══════════════════════════

Archive:
<https://discuss.ocaml.org/t/ocaml-posix-2-1-0-released/15974/1>

Romain Beauxis announced
────────────────────────

Hi all!

Version `2.1.0' of `ocaml-posix' has been released!

• Repo: <https://github.com/savonet/ocaml-posix>
• API doc: [ocaml-posix]

While it was long overdue, this version only include minor changes,
along with the addition of `posix-math2'.

These packages are intended to provide a consistent, extensive set of
bindings for the various POSIX APIs to be used with [ocaml-ctypes]
when building bindings to C libraries that require the use of these
APIs.

While working on OCaml projects, it is common to have to interface
with APIs derived from the POSIX specifications, `getaddrinfo',
`uname' etc.

The core OCaml library provides their own version of these APIs but:
• They only cover parts of it
• They wrap some native types such as `socketaddr' into custom, opaque
OCaml types, making it impossible to re-use, for instance when using
a C library API requiring a POSIX `sockaddr'.

Thus, having a large, consistent set of bindings for these APIs that
reflect the actual C types, structures and etc greatly improves the
usability of the language and ecosystem as a whole by making it
possible to interface it with a large set of C libraries in a reusable
way.

The project has been mostly stable for a couple of years (and so have
the POSIX standards), but could use some more hands if there is more
need in the community to extend the set of POSIX APIs supported by the
language.

[ocaml-posix] <https://www.liquidsoap.info/ocaml-posix/>

[ocaml-ctypes] <https://github.com/yallop/ocaml-ctypes>

Release of ocaml-eglot 1.0.0
════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-release-of-ocaml-eglot-1-0-0/15978/1>

Xavier Van de Woestyne announced
────────────────────────────────

Hi everyone!

We (at [Tarides]) are _particularly pleased_ to announce the first
release of [OCaml-eglot], An overlay on [Eglot] (the _built-in_ [LSP]
client for Emacs) for editing OCaml!

• [Github repository]
• [Package on MELPA]
• [Features list]
• [Installation procedure]
• [Comparison table with Merlin]

[Tarides] <https://tarides.com/>

[OCaml-eglot] <https://github.com/tarides/ocaml-eglot>

[Eglot] <https://www.gnu.org/software/emacs/manual/html_node/eglot/>

[LSP] <https://microsoft.github.io/language-server-protocol/>

[Github repository] <https://github.com/tarides/ocaml-eglot>

[Package on MELPA] <https://melpa.org/#/ocaml-eglot>

[Features list]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#features>

[Installation procedure]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#installation>

[Comparison table with Merlin]
<https://github.com/tarides/ocaml-eglot?tab=readme-ov-file#comparison-of-merlin-and-ocaml-eglot-commands>

More precisely
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Typically, developers who use Emacs (`43.7%' in 2022, [according to
the OCaml User Survey]) use a major mode (such as the venerable
[caml-mode], or [tuareg]) and [Merlin] to provide IDE services. In
2016, Microsoft has released LSP, a generic protocol for interacting
with editors which, at first, was only used by Visual Studio Code,
but, since 2020, has really become the norm. De-facto, following the
LSP standard gives very good _default_ (completion, jump to
definition, …). OCaml has excellent LSP ([ocaml-lsp-server]) support,
which is used in particular by the [OCaml platform for Visual Studio
Code].

With the aim of reducing maintenance for all possible editors, going
LSP seems to be a good direction. A pertinent choice, especially since
the major historical editors (such as Vim and Emacs) offer, in their
recent versions, LSP clients _out of the box_. However, in the same
way that the OCaml client for VSCode integrates *OCaml-specific*
features, it was necessary to support these features on the Emacs side
(and in the future, Vim) to compete with Merlin, which is the goal of
`ocaml-eglot', to *provide a tailored development experience for OCaml
code editing*!

[according to the OCaml User Survey]
<https://ocaml-sf.org/docs/2022/ocaml-user-survey-2022.pdf>

[caml-mode] <https://github.com/ocaml/caml-mode>

[tuareg] <https://github.com/ocaml/tuareg>

[Merlin] <https://github.com/ocaml/merlin>

[ocaml-lsp-server] <https://ocaml.org/p/ocaml-lsp-server/latest>

[OCaml platform for Visual Studio Code]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>

User feedback and future development
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

We've just released the first version of OCaml-eglot, and, much like
the various editor-related projects (Merlin, Vscode-ocaml-platform,
Merlin for Emacs, Merlin for Vim), *we're more than open to community
collaboration, user feedback*, in order to provide the best possible
user experience!

_Happy Hacking_!

Semgrep is hiring to help scale their static analysis engine
════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/job-remote-semgrep-is-hiring-to-help-scale-their-static-analysis-engine/15982/1>

Emma Jin announced
──────────────────

Semgrep is an application security company focused on detecting and
remediating vulnerabilities. The static analysis engine is primarily
written in OCaml. We're looking for a software engineer to help us
support scanning larger repositories and add many more users. The
ideal candidate has owned a critical tool, worked on an OCaml project,
and is interested in static analysis.

If this sounds interesting to you, see our job posting at
<https://job-boards.greenhouse.io/semgrep/jobs/4589941007>! Let me
know if you have any questions!

Dune dev meeting
════════════════

Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/21>

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

Hi Dune enthusiasts :camel:,

We will hold the regular Dune Dev Meeting on *Wednesday, January, 22nd
at 16:00* CET. As usual, the session will be one hour long.

Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers!

:calendar: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

The agenda is available on the[ meeting dedicated page]. Feel free to
ask if you want to add more items in it.

[ meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-01-22>

:computer: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [GitHub Wiki]

[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>

[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>

[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>

Tarides: 2024 in Review
═══════════════════════

Archive: <https://discuss.ocaml.org/t/tarides-2024-in-review/15990/1>

Thomas Gazagnaire announced
───────────────────────────

At [Tarides], we believe in making OCaml a mainstream programming
language by improving its tooling and integration with other
successful ecosystems. In 2024, we focused our efforts on initiatives
to advance this vision by addressing key technical challenges and
engaging with the community to build a stronger foundation for OCaml’s
growth. This report details our work, the rationale behind our
choices, and the impact achieved. We are very interested in getting
your feedback: [please get in touch] (or respond to this thread!) if
you believe we are going in the right direction.

/__TL;DR__ – In 2024, Tarides focused on removing adoption friction
with better documentation and tools; and on improving adoption via the
integration with three key thriving ecosystems: multicore programming,
web development, and Windows support. Updates to [ocaml.org] improved
onboarding and documentation, while the [Dune Developer Preview]
simplified workflows with integrated package management. Merlin added
support for [project-wide reference support] and [odoc 3], which is
about to be released. OCaml 5.3 marked the first stable multicore
release, and `js_of_ocaml' achieved up to 8x performance boosts in
real-world commercial applications thanks to added support for
WebAssembly. On Windows, opam 2.2 brought full compatibility and CI
testing to all Tier 1 platforms on `opam-repository', slowly moving
community packages towards reliable and better support for
Windows. Tarides’ community support included organising the first [FUN
OCaml conference], many local meetups, and two rounds of Outreachy
internships./

[Tarides] <https://tarides.com>

[please get in touch] <https://tarides.com/contact/>

[ocaml.org] <http://ocaml.org>

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

[project-wide reference support]
<https://tarides.com/blog/2024-08-28-project-wide-occurrences-a-new-navigation-feature-for-ocaml-5-2-users/>

[odoc 3] <https://discuss.ocaml.org/t/odoc-3-0-planning/14360>

[FUN OCaml conference] <https://fun-ocaml.com/>

Better Tools: Toward a 1-Click Installation of OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Our primary effort in 2024 was to continue delivering on the [OCaml
Platform roadmap] published last year. We focused on making it easier
to get started with OCaml by removing friction in the installation and
onboarding process. Our priorities were guided by the latest [OCSF
User Survey], direct user interviews, and [feedback] gathered from the
OCaml community. Updates from Tarides and other OCaml Platform
maintainers were regularly shared in the [OCaml Platform Newsletter].

[OCaml Platform roadmap] <https://ocaml.org/tools/platform-roadmap>

[OCSF User Survey]
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2023/13469>

[feedback] <https://discuss.ocaml.org/tag/user-feedback>

[OCaml Platform Newsletter]
<https://discuss.ocaml.org/tag/platform-newsletter>

◊ OCaml.org

OCaml.org is the main entry point for new users of OCaml. Tarides
engineers are key members of the OCaml.org team. Using
[privacy-preserving analytics], the team tracked visitor behaviour to
identify key areas for improvement. This led to a redesign of the
[installation page], simplifying the setup process, and a revamp of
the [guided tour of OCaml] to better introduce the language. Both
pages saw significant traffic increases compared to 2023, with the
installation page recording 69k visits, the tour reaching 65k visits
and a very encouraging total number of visits increasing by +33%
between Q3 and Q4 2024

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/1/137aea463013b31666bcade145a0067f2c1d6b82.png>

Efforts to improve user experience included a satisfaction survey
where 75% of respondents rated their experience positively, compared
to 17% for the previous version of the site. User testing sessions
with 21 participants provided further actionable insights, and these
findings informed updates to the platform. The redesign of OCaml.org
community sections was completed using this feedback. It introduced
several new features: a new [Community landing page], an [academic
institutions page] with course listings, and an [industrial users
showcase]. The team also implemented an automated [event announcement]
system to inform the community of ongoing activities.

Progress and updates were regularly shared through the [OCaml.org
newsletters], keeping the community informed about
developments. Looking ahead, the team will continue refining the
platform by addressing feedback, expanding resources, and monitoring
impact through analytics to support both new and experienced OCaml
users. Lastly, the infrastructure they build is starting to be used by
other communities: [Rocq] just announced their brand new website,
built using the same codebase as ocaml.org!

[privacy-preserving analytics] <https://plausible.ci.dev/ocaml.org>

[installation page] <https://ocaml.org/install>

[guided tour of OCaml] <https://ocaml.org/docs/tour-of-ocaml>

[Community landing page] <https://ocaml.org/community>

[academic institutions page] <https://ocaml.org/academic-users>

[industrial users showcase] <https://ocaml.org/industrial-users>

[event announcement] <https://ocaml.org/events>

[OCaml.org newsletters]
<https://discuss.ocaml.org/tag/ocamlorg-newsletter>

[Rocq] <https://rocq-prover.org/>

◊ Dune as the Default Frontend of the OCaml Platform

One of the main goals of the OCaml Platform is to make it easier for
users—especially newcomers—to adopt OCaml and build projects with
minimal friction. A critical step toward this goal is having a single
CLI to serve as the frontend for the entire OCaml development
experience (codenamed [Bob] in the past). This year, we made
significant progress in that direction with the release of the [Dune
Developer Preview].

Setting up an OCaml project currently requires multiple tools: `opam'
for package management, `dune' for builds, and additional
installations for tools like OCamlFormat or Odoc. While powerful, this
fragmented workflow can make onboarding daunting for new users. The
Dune Developer Preview consolidates these steps under a single CLI,
making OCaml more approachable. With this preview, setting up and
building a project is as simple as:

1. `dune pkg lock' to lock the dependencies.
2. `dune build' to fetch the dependencies and compile the project.

This effort is also driving broader ecosystem improvements. The
current OCaml compiler relies on fixed installation paths, making it
difficult to cache and reuse across environments, so it cannot be
shared efficiently between projects. To address this, we are working
on making the compiler relocatable ([ongoing work]). This change will
enable compiler caching, which means faster project startup times and
fewer rebuilds in CI. As part of this effort, we also [maintain]
patches to core OCaml projects to make them relocatable – and we
worked with upstream to merge (like [for ocamlfind]). Tarides
engineers also continued to maintain Dune and other key Platform
projects, ensuring stability and progress. This included organising
and participating in regular development meetings (for [Dune], [opam],
[Merlin], [ppxlib], etc.) to prioritise community needs and align
efforts across tools like Dune and opam to avoid overlapping
functionality.

The Dune Developer Preview is an iterative experiment. Early user
feedback has been promising (the Preview’s NPS went from +9 in Q3 2024
to +27 in Q4 2024), and future updates will refine the experience
further. We aim to ensure that experimental features in the Preview
are upstreamed into stable releases once thoroughly tested. For
instance, the package management feature is already in Dune 3.17. We
will announce and document it more widely when we believe it is mature
enough for broader adoption.

[Bob] <https://speakerdeck.com/avsm/ocaml-platform-2017?slide=34>

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

[ongoing work] <https://hackmd.io/@dra27/ry56XtKii>

[maintain]
<https://github.com/ocaml-dune/opam-overlays/tree/main/packages>

[for ocamlfind] <https://github.com/ocaml/ocamlfind/pull/72>

[Dune] <https://discuss.ocaml.org/tag/dev-meetings>

[opam] <https://github.com/ocaml/opam/wiki/2024-Developer-Meetings>

[Merlin]
<https://github.com/ocaml/merlin/wiki/Public-dev%E2%80%90meetings>

[ppxlib] <https://github.com/ocaml-ppx/ppxlib/wiki#dev-meetings>

◊ Editors

In 2024, Tarides focused on improving editor integration to lower
barriers for new OCaml developers and enhance the experience for
existing users. Editors are the primary way developers interact with
programming languages, making seamless integration essential for
adoption. With more than [73% of developers using Visual Studio Code
(VS Code)], VS Code is particularly important to support, especially
for new developers and those transitioning to OCaml. As part of this
effort, Tarides wrote and maintained the [official VS Code plugin for
OCaml,] prioritising feature development for this editor. We also
support other popular editors like Emacs and Vim—used by many Tarides
engineers—on a best-effort basis. Improvements to [OCaml-LSP] and
[Merlin], both maintained by Tarides, benefit all supported editors,
ensuring a consistent and productive development experience.

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/9/9b63754a94bc853f608e630dd9908097570a33ac.png>

While several plugins for OCaml exist ([OCaml and Reason IDE]–128k
installs, [Hackwaly]–90k installs), our [OCaml VS Code plugin] –now
with over 208k downloads– is a key entry point for developers adopting
OCaml in 2024. This year, we added integration with the Dune Developer
Preview, allowing users to leverage Dune's package management and
tooling directly from the editor. Features such as real-time
diagnostics, autocompletion, and the ability to fetch dependencies and
build projects without leaving VS Code simplify development and make
OCaml more accessible for newcomers.

The standout update in 2024 was the addition of [project-wide
reference support], a long-requested feature from the OCaml community
and a top priority for commercial developers. This feature allows
users to locate all occurrences of a term across an entire codebase,
making navigation and refactoring significantly easier—especially in
large projects. Delivering this feature required coordinated updates
across the ecosystem, including changes to the OCaml compiler, Merlin,
OCaml LSP, Dune, and related tools. The impact is clear: faster
navigation, reduced cognitive overhead, and more efficient workflows
when working with complex projects.

Additional improvements included support for new Language Server
Protocol features, such as `signature_help' and `inlay_hint', which
enhance code readability and provide more contextual
information. These updates enabled the introduction of new commands,
such as the "Destruct" command. This [little-known but powerful
feature] automatically expands a variable into a pattern-matching
expression corresponding to its inferred type, streamlining tasks that
would otherwise be tedious.

<https://tarides.com/blog/images/2024-05-21.merlin-destruct/merlin-destruct-1~kHA8_iC67tU-2us0hsjbhQ.gif>

[73% of developers using Visual Studio Code (VS Code)]
<https://survey.stackoverflow.co/2024/technology#1-integrated-development-environment>

[official VS Code plugin for OCaml,]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>

[OCaml-LSP] <https://github.com/ocaml/ocaml-lsp>

[Merlin] <https://github.com/ocaml/merlin>

[OCaml and Reason IDE]
<https://marketplace.visualstudio.com/items?itemName=freebroccolo.reasonml>

[Hackwaly]
<https://marketplace.visualstudio.com/items?itemName=hackwaly.ocaml>

[OCaml VS Code plugin]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>

[project-wide reference support]
<https://tarides.com/blog/2024-08-28-project-wide-occurrences-a-new-navigation-feature-for-ocaml-5-2-users/>

[little-known but powerful feature]
<https://tarides.com/blog/2024-05-29-effective-ml-through-merlin-s-destruct-command/>

◊ Documentation

Documentation was identified as the number one pain point in the
latest [OCSF survey]. It is a critical step in the OCaml developer
journey, particularly after setting up the language and
editor. Tarides prioritised improving `odoc' to make it easier for
developers to find information, learn the language, and navigate the
ecosystem effectively. High-quality documentation and tools to help
developers get "unstuck" are essential to reducing friction and
ensuring a smooth adoption experience.

Tarides is the primary contributor and maintainer of [`odoc'], OCaml’s
main documentation tool. In preparation for the [odoc 3 release], our
team introduced two significant updates. First, the [`odoc' Search
Engine] was integrated, allowing developers to search directly within
OCaml documentation via the [Learn page]. Second, the [`odoc'
Cheatsheet] provides a concise reference for creating and consuming
OCaml documentation. We would like to believe that these updates,
deployed on ocaml.org, were the main cause of a **45% increase in
package documentation usage** on [https://ocaml.org/pkg/] in Q4 2024!

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/a/a974b30576399d84e1b26936b4b31bdf364e76db.png>

Another area where developers often get stuck is debugging programs
that don’t work as expected. Alongside reading documentation, live
debuggers are crucial for understanding program issues. Tarides worked
to improve native debugging for OCaml, focusing on macOS, where LLDB
is the only supported debugger. Key progress included a [name mangling
fix] to improve symbol resolution, restoring ARM64 backtraces, and
introducing Python shims for code sharing between LLDB and GDB.

OCaml’s error messages remain a common pain point, particularly for
syntax errors. Unlike [Rust’s error index], OCaml does not (yet!) have
a centralised repository of error explanations. Instead, we are
focused on making error messages more self-explanatory. This requires
developing new tools, such as [`lrgrep'], a domain-specific language
for analysing grammars built with Menhir. `lrgrep' enables concise
definitions of error cases, making it possible to identify and address
specific patterns in the parser more effectively. This provides a
practical way to improve error messages without requiring changes to
the compiler. In December 2024, @let-def successfully defended his PhD
(a collaboration between Inria and Tarides) on this topic, so expect
upstreaming work to start soon.

[OCSF survey]
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2023/13469>

[`odoc'] <https://github.com/ocaml/odoc>

[odoc 3 release] <https://discuss.ocaml.org/t/odoc-3-0-planning/14360>

[`odoc' Search Engine]
<https://tarides.com/blog/2024-02-28-two-major-improvements-in-odoc-introducing-search-engine-integration/>

[Learn page] <https://ocaml.org/docs>

[`odoc' Cheatsheet]
<https://tarides.com/blog/2024-09-17-introducing-the-odoc-cheatsheet-your-handy-guide-to-ocaml-documentation/>

[https://ocaml.org/pkg/] <https://ocaml.org/pkg/>

[name mangling fix] <https://github.com/ocaml/ocull/pull/13050>

[Rust’s error index]
<https://doc.rust-lang.org/error_codes/error-index.html>

[`lrgrep'] <https://github.com/let-def/lrgrep>

◊ OCaml Package Ecosystem

The last piece of friction we aimed to remove in 2024 was ensuring
that users wouldn’t encounter errors when installing a package from
the community. This required catching issues early—before packages are
accepted into `opam-repository' and made available to the broader
ecosystem. To achieve this, Tarides has built and maintained extensive
CI infrastructure, developed tools to empower contributors, and guided
package authors to uphold the high quality of the OCaml package
ecosystem.

In 2024, Tarides’ CI infrastructure supported the OCaml community at
scale, handling approximately **20 million jobs on 68 machines
covering 5 hardware architectures**. This infrastructure continuously
tested packages to ensure compatibility across a variety of platforms
and configurations, including OCaml’s Tier 1 platforms: x86, ARM,
RISC-V, s390x, and Power. It played a critical role during major
events, such as new OCaml releases, by validating the ecosystem’s
readiness and catching regressions before they impacted
users. Additionally, this infrastructure supported daily submissions
to `opam-repository', enabling contributors to identify and resolve
issues early, reducing downstream problems. To improve transparency
and accessibility, we introduced a CI pipeline that automates
configuration updates, ensuring seamless deployments and allowing
external contributors to propose and apply changes independently.

In addition to maintaining the infrastructure, Tarides developed and
maintained the CI framework running on top of it. A major focus in
2024 was making CI checks available as standalone CLI tools
distributed via `opam'. These tools enable package authors to run
checks locally, empowering them to catch issues before submitting
their packages to `opam-repository'. This approach reduces reliance on
central infrastructure and allows developers to work more
efficiently. The CLI tools are also compatible with GitHub Actions,
allowing contributors to integrate tests into their own workflows. To
complement these efforts, we enhanced `opam-repo-ci', which remains an
essential safety net for packages entering the repository. Integration
tests for linting and reverse dependencies were introduced, enabling
more robust regression detection and improving the reliability of the
ecosystem.

To uphold the high standards of the OCaml ecosystem, every package
submission to `opam-repository' is reviewed and validated to ensure it
meets quality criteria. This gatekeeping process minimises errors
users might encounter when installing community packages, enhancing
trust in the ecosystem. In 2024, Tarides continued to be actively
[involved] in maintaining the repository, ensuring its smooth
operation. We also worked to guide new package authors by updating the
[contributing guide] and creating a detailed [wiki] with actionable
instructions for adding and maintaining packages. These resources were
[announced on Discuss] to reach the community and simplify the process
for new contributors, improving the overall quality of submissions.

[involved]
<https://github.com/ocaml/opam-repository/blob/master/governance/README.md#maintenance>

[contributing guide]
<https://github.com/ocaml/opam-repository/blob/master/CONTRIBUTING.md>

[wiki] <https://github.com/ocaml/opam-repository/wiki>

[announced on Discuss]
<https://discuss.ocaml.org/t/opam-repository-updated-documentation-retirement-and-call-for-maintainers/14325>

Playing Better with the Larger Ecosystem
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Concurrent & Parallel Programming in OCaml

_"Shared-memory multiprocessors have never really 'taken
off', at least in the general public. For large parallel
computations, clusters (distributed-memory systems) are
the norm. For desktop use, monoprocessors are plenty
fast."_ – [Xavier Leroy, November 2002]

Twenty+ years after this statement, processors are multicore by
default, and OCaml has adapted to this reality. Thanks to the combined
efforts of the OCaml Labs and Tarides team, the OCaml 5.x series
introduced multicore support after [a decade of research and
experimentation.] While this was a landmark achievement, the path to
making multicore OCaml stable, performant, and user-friendly has
required significant collaboration and continued work. In 2024,
Tarides remained focused on meeting the needs of the broader community
and commercial users.

OCaml 5.3 (released last week) was an important milestone in this
journey. With companies such as [Routine], [Hyper], and [Asemio]
adopting OCaml 5.x, and advanced experimentation ongoing at Jane
Street, Tezos, Semgrep, and others, OCaml 5.3 is increasingly seen as
the first “stable” release of the multicore series. While some
[performance issues] remain in specific parts of the runtime, we are
working closely with the community to address them in OCaml
5.4. Tarides contributed extensively to the [5.2] and [5.3] releases
by directly contributing to **nearly two-thirds of the merged pull
requests**. Since Multicore OCaml was incorporated upstream in 2023,
we have been continuously involved in the compiler and language
evolution in collaboration with Inria and the broader OCaml ecosystem.

Developing correct concurrent and parallel software is inherently
challenging, and this applies as much to the runtime as to
applications built on it. In 2024, we focused on advanced testing
tools to help identify and address subtle issues in OCaml’s runtime
and libraries. The [property-based test suite] reached maturity this
year, uncovering over 40 critical issues, with 28 resolved by Tarides
engineers. Trusted to detect subtle bugs, such as [issues with
orphaned ephemerons], the suite has become an integral part of OCaml’s
development workflow. Importantly, it is accessible to contributors
without deep expertise in multicore programming, ensuring any changes
in the compiler or the runtime do not introduce subtle concurrency
bugs.

<https://tarides.com/blog/images/false-alarms-plot-errors-only.png>

Another critical effort was extending ThreadSanitizer (TSAN) support
to most Tier 1 platforms and [applying it extensively to find and fix
data races in the runtime]. This work has improved the safety and
reliability of OCaml’s multicore features and is now part of the
standard testing process, further ensuring the robustness of the
runtime.

Beyond testing, we also worked to enhance library support for
multicore programming. The release of the [Saturn library] introduced
lock-free data structures tailored for OCaml 5.x. To validate these
structures, we developed [DSCheck], a static analyser for verifying
lock-free algorithms. These tools, along with Saturn itself, provide
developers with reliable building blocks for scalable multicore
applications.

Another promising development in 2024 was the introduction of the
[Picos] framework. Picos aims to provide a low-level foundation for
concurrency, simplifying interoperability between libraries like Eio,
Moonpool, Miou, Riot, Affect, etc. Picos offers a simple,
unopinionated, and safe abstraction layer for concurrency. We believe
it can potentially standardise concurrency patterns in OCaml, but we
are not there yet. Discussions are underway to integrate parts of
Picos into higher-level libraries and, eventually, the standard
library. We still have a long way to go, and getting feedback from
people who actively tried it in production settings would be very
helpful!

[Xavier Leroy, November 2002]
<https://sympa.inria.fr/sympa/arc/caml-list/2002-11/msg00274.html>

[a decade of research and experimentation.]
<https://tarides.com/blog/2023-03-02-the-journey-to-ocaml-multicore-bringing-big-ideas-to-life/>

[Routine] <https://routine.co/>

[Hyper] <https://hyper.systems>

[Asemio]
<https://tarides.com/blog/2024-09-19-eio-from-a-user-s-perspective-an-interview-with-simon-grondin/>

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

[5.2]
<https://tarides.com/blog/2024-05-15-the-ocaml-5-2-release-features-and-fixes/>

[5.3]
<https://tarides.com/blog/2025-01-09-ocaml-5-3-features-and-fixes/>

[property-based test suite]
<https://github.com/ocaml-multicore/multicoretests>

[issues with orphaned ephemerons]
<https://github.com/ocaml/ocaml/pull/13580#issuecomment-2478454501>

[applying it extensively to find and fix data races in the runtime]
<https://tarides.com/blog/2024-08-21-how-tsan-makes-ocaml-better-data-races-caught-and-fixed/>

[Saturn library]
<https://tarides.com/blog/2024-12-11-saturn-1-0-data-structures-for-ocaml-multicore/>

[DSCheck]
<https://tarides.com/blog/2024-04-10-multicore-testing-tools-dscheck-pt-2/>

[Picos] <https://ocaml-multicore.github.io/picos/doc/picos/index.html>

◊ Web

Web development remains one of the most visible and impactful domains
for programming languages; [JavaScript, HTML, and CSS are the most
popular technologies] in 2024. For OCaml to grow, it must integrate
well with this ecosystem. Fortunately, the OCaml community has already
built a solid foundation for web development!

On the frontend side, in 2024, Tarides focused on strengthening key
tools like [`js_of_ocaml'] by expanding its support for WebAssembly
(Wasm). `js_of_ocaml' (JSOO) has long been the backbone of OCaml’s web
ecosystem, enabling developers to compile OCaml bytecode into
JavaScript. This year, we [merged Wasm support back into JSOO],
unifying the toolchain and simplifying adoption for developers. The
performance gain of Wasm has been very impressive so far:
CPU-intensive applications in commercial settings have seen **2x to 8x
speedups** using Wasm compared to traditional JSOO. We also worked on
better support for effect handlers in `js_of_ocaml' to ensure
applications built with OCaml 5 can run as fast in the browser as they
used to with OCaml 4.

On the backend side, Tarides maintained and contributed to Dream, a
lightweight and flexible web framework. Dream powers projects like
[our own website] and the [MirageOS website], where we maintain a fork
to make Dream and MirageOS work well together. Additionally, in 2024,
we enhanced `cohttp', adding [proxy support] to address modern HTTP
requirements.

While Tarides focused on JSOO, `wasm_of_ocaml', Dream, and Cohttp, the
broader community made significant strides elsewhere. Tools like
Melange offer an alternative for compiling OCaml to JavaScript, and
frameworks like Ocsigen, which integrates backend and frontend
programming, continue to push the boundaries of what’s possible with
OCaml on the web. Notably, Tarides will build on this momentum in 2025
through a [grant] to improve direct-style programming for Ocsigen.

[JavaScript, HTML, and CSS are the most popular technologies]
<https://survey.stackoverflow.co/2024/technology#most-popular-technologies-language>

[`js_of_ocaml'] <https://github.com/ocsigen/js_of_ocaml>

[merged Wasm support back into JSOO]
<https://github.com/ocsigen/js_of_ocaml/pull/1494>

[our own website] <https://tarides.com/>

[MirageOS website] <https://mirageos.org>

[proxy support] <https://github.com/mirage/ocaml-cohttp/pull/847>

[grant] <https://nlnet.nl/project/OCAML-directstyle/>

◊ Windows

Windows is the most widely used operating system, making first-class
support for it critical to OCaml’s growth. In 2024, **31% of visitors
to [ocaml.org]** accessed the site from Windows, yet the platform’s
support historically lagged behind Linux and macOS. This gap created
barriers for both newcomers and commercial users. We saw these
challenges firsthand, with Outreachy interns struggling to get started
due to tooling issues, and commercial users reporting difficulties
with workflow reliability and compilation speed.

To address these pain points, Tarides, in collaboration with the OCaml
community, launched the [Windows Working Group]. A key milestone that
our team contributed to was the release this year of **opam 2.2**,
three years after its predecessor. This release made the upstream
`opam-repository' fully compatible with Windows for the first time,
removing the need for a separate repository and providing Windows
developers access to the same ecosystem as Linux and macOS users. The
impact has been clear: feedback on the updated installation workflow
has been overwhelmingly positive, with developers reporting that it
"just works." The [install page] for Windows is now significantly
shorter and simpler!

In the OCaml 5.3 release, Tarides restored the MSVC Windows port,
ensuring native compatibility and improving performance for Windows
users. To further support the ecosystem, Tarides added Windows
machines to the opam infrastructure, enabling automated testing for
Windows compatibility on every new package submitted to opam. This has
already started to improve package support, with ongoing fixes from
Tarides and the community. The results are publicly visible at
[windows.check.ci.dev], which we run on our infrastructure, providing
transparency and a way to track progress on the status of our
ecosystem. While package support is not yet on par with other
platforms, we believe that the foundations laid in 2024—simplified
installation, improved tooling, and continuous package
testing—represent a significant step forward.

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

[Windows Working Group]
<https://tarides.com/blog/2024-05-22-launching-the-first-class-windows-project/>

[install page] <https://ocaml.org/install>

[windows.check.ci.dev] <https://windows.check.ci.dev/>

Community Engagement and Outreach
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

In 2024, Tarides contributed to building a stronger OCaml community
through events, internships, and support for foundational
projects. The creation of [FUN OCaml 2024] in Berlin was the first
dedicated OCaml-only event for a long time (similar to how the OCaml
Workshop was separated from ICFP in the past). Over 75 participants
joined for two days of talks, workshops, and hacking, and the event
has already reached [5k+ views on YouTube]. Tarides also co-chaired
the OCaml Workshop at [ICFP 2024] in Milan, bringing together
contributors from academia, industry, and open-source
communities. These events brought together two different kinds of
OCaml developers (with some overlap), bringing an interesting energy
to our community.

To expand local community involvement, Tarides organised OCaml hacking
meetups in [Manila] and [Chennai]. To make it easier for others to
host similar events, we curated a list of interesting hacking issues
from past [Cambridge sessions], now available on [GitHub].

As part of the Outreachy program, Tarides supported two rounds of
internships in 2024, with results published on [Discuss] and
[watch.ocaml.org]. These internships not only provided great
contributions to our ecosystem but also brought fresh insights into
the challenges faced by new users. For example, interns identified key
areas where documentation and tooling could be improved, directly
informing future updates.

Tarides also maintained its commitment to funding critical open-source
projects and maintainers. We continued funding [Robur] for their
maintenance work on MirageOS (most of those libraries are used by many
–including us– even in non-MirageOS context) and [Daniel Bünzli],
whose libraries like `cmdliner' are essential for some of our
development.

Finally, Tarides extended sponsorships to non-OCaml-specific events,
including [JFLA], [BobConf], [FSTTCS], and [Terminal Feud] (which
garnered over 100k views). These events expanded OCaml’s visibility to
new audiences and contexts, introducing the language to a broader
technical community that –we hope– will discover OCaml and enjoy using
it as much as we do.

[FUN OCaml 2024] <https://fun-ocaml.com/>

[5k+ views on YouTube]
<https://www.youtube.com/channel/UC3TI-fmhJ_g3_n9fHaXGZKA>

[ICFP 2024] <https://icfp24.sigplan.org/>

[Manila]
<https://discuss.ocaml.org/t/announcing-ocaml-manila-meetups/14300>

[Chennai]
<https://discuss.ocaml.org/t/chennai-ocaml-meetup-october-2024/15417>

[Cambridge sessions]
<https://tarides.com/blog/2023-03-22-compiler-hacking-in-cambridge-is-back/>

[GitHub] <https://github.com/tarides/compiler-hacking/wiki>

[Discuss] <https://discuss.ocaml.org/tag/outreachy>

[watch.ocaml.org] <https://watch.ocaml.org>

[Robur] <https://blog.robur.coop/articles/finances.html>

[Daniel Bünzli] <https://github.com/sponsors/dbuenzli>

[JFLA] <https://jfla.inria.fr/jfla2024.html>

[BobConf] <https://bobkonf.de/2025/en/>

[FSTTCS] <https://www.fsttcs.org.in/>

[Terminal Feud] <https://www.youtube.com/watch?v=fMy0XhFdLAE>

What’s Next?
╌╌╌╌╌╌╌╌╌╌╌╌

As we begin 2025, Tarides remains committed to making OCaml a
mainstream language. Our focus this year is to position OCaml as a
robust choice for mission-critical applications by enhancing developer
experience, ecosystem integration, and readiness for high-assurance
use cases.

We aim to build on the Dune Developer Preview to further improve
usability across all platforms, with a particular emphasis on Windows,
to make OCaml more accessible to a broader range of
developers. Simultaneously, we will ensure OCaml is ready for critical
applications in industries where reliability, performance, and
security are essential. Projects like [SpaceOS] showcase the potential
of memory- and type-safe languages for safety-critical systems. Built
on MirageOS and OCaml’s unique properties, SpaceOS is part of the
EU-funded [Orchide] project and aims to set a new standard for edge
computing in space. Additionally, SpaceOS is being launched in the US
through our spin-off [Parsimoni]. However, these needs are not limited
to Space: both the [EU Cyber Resilience Act] and the [US cybersecurity
initiatives] highlight the growing demand for type-safe,
high-assurance software to address compliance and security challenges
in sensitive domains. Tarides believes that OCaml has a decisive role
to play here in 2025!

I’d like to personally thank our sponsors and customers, especially
Jane Street, for their unwavering support over the years, and to
[Dennis Dang], our single recurring GitHub sponsor. Finally, to every
member of Tarides who worked so hard in 2024 to make all of this
happen: thank you. I’m truly lucky to be sailing with you on this
journey!

/We are looking for [sponsors on GitHub], are happy to [collaborate on
innovative projects] involving OCaml or MirageOS and offer [commercial
services] for open-source projects – including long-term support,
development of new tools, or assistance with porting projects to OCaml
5 or Windows./

[SpaceOS]
<https://tarides.com/blog/2023-07-31-ocaml-in-space-welcome-spaceos/>

[Orchide] <https://orchide.pages.upb.ro/>

[Parsimoni] <https://parsimoni.co>

[EU Cyber Resilience Act]
<https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act>

[US cybersecurity initiatives]
<https://tarides.com/blog/2024-03-07-a-time-for-change-our-response-to-the-white-house-cybersecurity-press-release/>

[Dennis Dang] <https://github.com/dangdennis>

[sponsors on GitHub] <https://github.com/sponsors/tarides>

[collaborate on innovative projects] <https://tarides.com/innovation/>

[commercial services] <https://tarides.com/services/>

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

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

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

• [Using `clang-cl' With OCaml 5]
• [Florian’s compiler weekly, 13 January 2025]
• [OCaml 5.3: Features and Fixes!]
• [Git, Carton and emails]

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

[Using `clang-cl' With OCaml 5]
<https://tarides.com/blog/2025-01-15-using-clang-cl-with-ocaml-5>

[Florian’s compiler weekly, 13 January 2025]
<https://gallium.inria.fr/blog/florian-cw-2025-01-13>

[OCaml 5.3: Features and Fixes!]
<https://tarides.com/blog/2025-01-09-ocaml-5-3-features-and-fixes>

[Git, Carton and emails]
<https://blog.robur.coop/articles/2025-01-07-carton-and-cachet.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: 92594 bytes --]