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

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

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