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

Alan Schmitt
2025-07-15T17:14:57Z

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

Hello

Here is the latest OCaml Weekly News, for the week of July 08 to 15,
2025.

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

OCaml Language Committee: an update on a policy for conflicts of interest
OCaml intern for Claudius
An example for every OCaml package
Esa 0.1.0 - Enhanced Suffix Arrary(and further plans)
Tutorial: cut and pasting code
QCheck 0.24
New Odoc-3-Generated Package Documentation is Live on OCaml.org
Lwt.6.0.0~alpha (direct-style)
MirageOS on Unikraft
Other OCaml News
Old CWN

OCaml Language Committee: an update on a policy for conflicts of interest
═════════════════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ocaml-language-committee-an-update-on-a-policy-for-conflicts-of-interest/16927/1>

octachron announced
───────────────────

When discussing the proposition for include functors, the [language
committee] felt in the rabbit hole of discussing conflict of
interests.

After some discussions, as the current committee chair, I have decided
to propose to amend the committee description with our current
understanding of transparency-based policy for conflicts of interest
at <https://github.com/ocaml/RFCs/pull/55> .

The core idea behind that policy is that in a small-world community
like ours, trying to completely avoid conflicts would be
counter-productive. At the same time, making sure that anyone is aware
of potential conflicts is fairer for all participants.

Thus the current proposal, which is not definitive. In particular, if
we have any comments, you are more than welcome to participate in the
discussion in the RFC above.

[language committee]
<https://github.com/ocaml/RFCs/blob/master/Committee.md>

OCaml intern for Claudius
═════════════════════════

Archive:
<https://discuss.ocaml.org/t/ocaml-intern-for-claudius/16935/1>

Shreya Pawaskar announced
─────────────────────────

Hello Everyone! 👋👋

I am Shreya Pawaskar, an outreachy intern working on the Claudius
Project.

A little late to post my blogs here. But here we go!

This is my [first blog]. Here I've talked about my experience during
the contribution phase and my fav contribution.

And here's the [second one]. This one is all about the journey and the
learnings I made working with ocaml-gif. And ofcourse, the beautiful
cover image for my second blog is built and captured with Claudius!

[first blog]
<https://pawaskar-shreya-outreachy.hashnode.dev/outreachy-week-1>

[second one]
<https://pawaskar-shreya-outreachy.hashnode.dev/outreachy-week-3>

An example for every OCaml package
══════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/an-example-for-every-ocaml-package/16953/1>

John Whitington announced
─────────────────────────

(One day, maybe).

Wouldn't it be nice if every OCaml package had examples as well as
documentation? As part of a pilot programme funded by the OCaml
Software Foundation, I've been looking into the feasibility of such an
idea.

What do we mean by examples, and what distinguishes them from
documentation and from tests?

*What an example is*

• Examples are independent of the library they explain. They do not
require the source of the library, or any built artefacts.

• Examples are self-contained. They require only OCaml, a build
system, and the library in question to be installed.

• Examples are easy to build. They are built in a single command, and
do not depend on environment.

• Examples are easy to edit and play with. They are of a reasonable
size, split into chunks, and are commented liberally.

• Examples use standard techniques. Both in how the library is used,
and in how the OCaml code is written.

• Examples are open licensed. Users should be able to copy & paste
code from the examples without care.

*What an example is not*

• Examples are not tests. Unlike tests, examples do not care about
code coverage, cannot be automatically generated, and need not
necessarily be tightly integrated into the source repository.

• Examples are not in the API documentation. Examples need to be
buildable, and separate from the API documentation. This is not to
say that they might then not be automatically imported into the API
documentation one day.

• Examples need not be comprehensive. Better a small example than no
example at all. So long as the basics of an API are introduced, the
cliff is climbed and the API documentation should thereafter
suffice.

*Pilot project plan*

The plan was to build small examples for about twenty packages, put
together a place for them to live, and then try to upstream them. The
examples' home, prior to upstreaming, is the OCaml Nursery:

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

Most of these little examples have been submitted to upstream - you
may have noticed the pull requests on your repositories - with varying
degrees of interest / success.

*Opinions requested, please!*

Are you interested in adding examples for your package or someone
else's package? To the nursery or to upstream? What do you think of
the definition of example I gave above? Do you think examples should
sit in a separate space like the nursery or be upstreamed or both?
Opinions requested on all those topics, please!

Esa 0.1.0 - Enhanced Suffix Arrary(and further plans)
═════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-esa-0-1-0-enhanced-suffix-arrary-and-further-plans/16956/1>

Geoffrey Borough announced
──────────────────────────

I just ported the original C++ Enhanced Suffix Tree to pure OCaml, you
can find it here: <https://github.com/gborough/esa>.

It's the first time I have attempted at writing low allocation/no
allocation code in OCaml and I must say this has been a great learning
experience for the past few weeks, and it makes me appreciate more how
OCaml is able to provide low level tunings that match other low level
languages, whilst staying functional at the same time.

One of my personal goals(also our company tech alignment) is to bring
OCaml up to the same level of convenience as *Python* in some areas of
AI/LLM. We are inspired by existing efforts in the OCaml community to
take on this challenge and our plan of attack will be more or less
similar. Currently we are tackling the following problems:

• Porting Google Sentencepiece(in progress): Enhanced Suffix Arrary
done as a dependency, Double-Array Trie and few other tokenizer
utilities in progress.
• Porting Hugging Face Tokenizers(in progress): Pending the completion
of sentencepiece though less dependent codes are being converted.

The end product probably contains a mixture of pure OCaml as well as a
fair amount of FFI code. I dread to think how they are going to look
like obviously there will be a ton of verbatim translations to OCaml,
but I have little doubt about matching C++/Rust performance most of
the time. We'll also look into the upcoming OxCaml extension to see if
more performance can be eked out.

Hopefully we will have something to show for the community in the near
future.

Tutorial: cut and pasting code
══════════════════════════════

Archive:
<https://discuss.ocaml.org/t/tutorial-cut-and-pasting-code/16957/1>

Daniel Bünzli announced
───────────────────────

Dear all,

I sometimes notice that my code gets cut and pasted or vendored
litterally or modified in other projects. *That's very fine*, it's the
reason why I publish almost all my code under [a license] that makes
that extremely simple.

Yet people often fail to abide by the simple, single phrase request of
the license which is (emphasis added):

Copyright (c) [year] [fullname]

Permission to use, copy, modify, and/or distribute this
software for any purpose with or without fee is hereby
granted, *provided that the above copyright notice and
this permission notice appear in all copies*.

In all my source files you can find a header that has the copyright
notice and a SPDX license identifier [as per convention]
([example]). So I kindly ask you when you reuse my code:

1. If you copy the whole file to retain that copyright
header. Reformatting the header is ok. Also if you end up reworking
the code significantly indicating:
┌────
│ (* Part of this code is based on the xxx project and
│ Copyright (c) 2020 The xxx programmers.
│ SPDX-License-Identifier: ISC *)
└────
works for me.

2. If you copy say a single function please add a comment with the
copyright notice and the SPDX license identifier. For example:
┌────
│ (* This code is Copyright (c) 2011 The xxx programmers.
│ SPDX-License-Identifier: ISC *)
└────

3. If you end up vendoring a significant part of the code without
modifying it (that is if technically you depend on the project)
please mention it in your toplevel `LICENSE' file.

Now let's be clear, I will not call the police if don't do this or if
you pretend to have written code you did not. Police and lawyers are
at the top of the list of people I do not want to deal with or inflict
onto other people.

What I'm seeking here is attribution. Not for having my name in your
project, I couldn't care less and the copyrights of my projects are
contributor based anyways. This is so that the code contribution can
be traced for the little times I manage to convince people to pay me
for making them rather than investing my own money in these projects.

Btw. this should not only be about my code. This is about any open
source code you cut and paste from (and I also [do this]).

Ah and yes, please, if you are using them, also teach your LLMs to do
that. If they are able to write OCaml code it's also thanks to me :–)

Thank for your attention.

Daniel

[a license] <https://choosealicense.com/licenses/isc/>

[as per convention] <https://spdx.dev/learn/handling-license-info/#how>

[example]
<https://github.com/dbuenzli/jsont/blob/527808203554fcf9b93eb2ca79ed596937233149/src/jsont_base.ml#L1-L4>

[do this]
<https://github.com/dbuenzli/typegist/blob/62798edf20688d8bf021928d0eb3b1a0580da583/src/typegist.ml#L40-L48>

QCheck 0.24
═══════════

Archive: <https://discuss.ocaml.org/t/ann-qcheck-0-24/16198/3>

Jan Midtgaard announced
───────────────────────

QCheck 0.26 is now available from your favorite opam repository!
:tada:

<https://github.com/c-cube/qcheck/releases>

The 0.26 release adjusts the `QCheck' and `QCheck2' `float' generator
distributions, which was previously confined to a subset of floating
point numbers. Users may experience that existing tests known to pass
start to fail with the new and broader distribution. In addition the
release contains a number of other fixes and documentation
improvements, incl. the removal of an annoying newline which would
cause the test suite to fail on OCaml 5.4.0:

• Align printed `collect' statistics and also add a percentage
• Fix `QCheck{,2}.Gen.float' generator which would only generate
numbers with an exponent between 2^{-21} and 2^{22}
• Elaborate on the `QCheck~/~QCheck2' situation in the README
• Add a missing `description' field to the *.opam files
• Document `Shrink' invariants in the `QCheck' module
• Fix a `qcheck-ounit' test suite failure on OCaml 5.4, removing a
needless extra newline
• Fix `QCheck2' `float_range' operator which would fail on negative
bounds
• Fix `QCHECK_MSG_INTERVAL' not being applied to the first in-progress
message

Thanks to @Pat-Lafon, @rmonat, and @kit-ty-kate for contributing!
:pray:

New Odoc-3-Generated Package Documentation is Live on OCaml.org
═══════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/new-odoc-3-generated-package-documentation-is-live-on-ocaml-org/16967/1>

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

Hi everyone,

I just merged the patch <https://github.com/ocaml/ocaml.org/pull/3124>
which enables the new and improved package documentation built with
odoc 3 on OCaml.org. Thanks @mtelvers, @jonludlam, @panglesd for
putting in the effort to make this happen for OCaml.org!

Thanks to everyone who gave us feedback when we ran this on the
staging environment
(<https://discuss.ocaml.org/t/help-test-the-new-odoc-3-powered-package-documentation-pages/16795/6>),
we're reasonably confident that things work well enough to apply this
upgrade. :orange_heart:

In case you see something that could be improved, please let us know
(by replying here or by opening an issue on
<https://github.com/ocaml/ocaml.org>)!

Cheers Sabine

Lwt.6.0.0~alpha (direct-style)
══════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-lwt-6-0-0-alpha-direct-style/16972/1>

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

It is a great pleasure to announce the release of the first alpha
release of Lwt 6. This major version bump brings two major changes to
Lwt:

• Using Lwt in direct-style! (Big thanks to @c-cube !!)
• Using multiple Lwt schedulers running in separate domains!

Direct-style
╌╌╌╌╌╌╌╌╌╌╌╌

This contribution from @c-cube is available in alpha00. It comes in
the form of an `lwt_direct' package which provide an `Lwt_direct'
module which provide two core functions:

┌────
│ val run : (unit -> 'a) -> 'a Lwt.t
│ val await : 'a Lwt.t -> 'a
└────

and allows you to write code such as

┌────
│ run (fun () ->
│ let continue = ref true in
│ while !continue do
│ match await @@ Lwt_io.read_line ic with
│ | line -> await @@ Lwt_io.write_line oc line
│ | exception End_of_file -> continue := false
│ done)
└────

There are a few more functions. All of which is documented in
[lwt_direct.mli].

[lwt_direct.mli]
<https://github.com/ocsigen/lwt/blob/6.0.0-alpha00/src/direct/lwt_direct.mli>

Multi-scheduler
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

This addition is not available in alpha00 but should be added to
alpha01 soon. It allows to call `Lwt_main.run' in different domains
and benefit from actual parallelism. (Sneak peek in [this pull
request])

[this pull request] <https://github.com/ocsigen/lwt/pull/1058>

Installation
╌╌╌╌╌╌╌╌╌╌╌╌

`lwt.6.0.0~alpha00' and `lwt_direct.6.0.0~alpha00' will soon be
released on opam ([PR on opam-repo]. I'll publish some more alphas as
the work progresses, and announce the releases on this thread.

You can also pin the packages to the lwt-6 branch to get everything a
little bit earlier:

┌────
│ opam pin lwt https://github.com/ocsigen/lwt.git#lwt-6
│ opam pin lwt_direct https://github.com/ocsigen/lwt.git#lwt-6
└────

[PR on opam-repo] <https://github.com/ocaml/opam-repository/pull/28175>

Feedback
╌╌╌╌╌╌╌╌

Don't hesitate to chime in on here with any feedback you may
have. Ideas, comments, requests, suggestions, etc.

MirageOS on Unikraft
════════════════════

Archive: <https://discuss.ocaml.org/t/mirageos-on-unikraft/16975/1>

shym announced
──────────────

On behalf of all the developers involved (namely @fabbing, @Firobe,
@n-osborne and me), it’s my pleasure to announce that the first
release of the [Unikraft] backend support in MirageOS unikernels.

[Unikraft] is a unikernel development kit: it is a pretty large
[collection of components] that can be picked up, or not, in the
unikernel tradition of modularity. The scope of Unikraft is much
larger than [Solo5], as it aims to make it easy to turn any Unix
server into an efficient unikernel. This was in fact a first
motivation to explore using Unikraft as MirageOS backend: to
experiment and see what performance we could get, in particular using
their `virtio'-based network interface, as `virtio' is implemented
currently only for one specific `x86_64'-only backend in Solo5.

Some of the immediate performance differences we observed are detailed
further, but that is not all we hope from this Unikraft backend in the
long-term. In particular, Unikraft is on the road to be
multicore-compatible (i.e. having one unikernel use multiple
cores). While this is not ready today and there are still significant
efforts to get there, it means that this MirageOS backend will be able
to benefit from these efforts and eventually support the full feature
set of OCaml 5.

Furthermore, the Unikraft community (which is quite active) is
experimenting with a variety of other targets such as bare-metal for
some platforms or new hypervisors (e.g. seL4). Any new target Unikraft
supports can be then supported "for free" by MirageOS too. For
example, this already brings `firecracker' as a new supported VMM for
MirageOS.

Lastly, since Unikraft is POSIX-compatible (for a large subset of
syscalls), this potentially enables MirageOS unikernel to embed OCaml
libraries that have not been ported to use the Mirage interfaces in
the future. This would be useful for large libraries which are hard to
port ([owl] comes to mind).

[Unikraft] <https://unikraft.org>

[collection of components]
<https://unikraft.org/docs/internals/architecture>

[Solo5] <https://github.com/Solo5/solo5/>

[owl] <https://ocaml.xyz/>

Overview of the Unikraft support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

To add new MirageOS backends requires to create or modify a series of
components:

• a [OCaml cross compiler] that can build this new backend, in
particular by building its corresponding runtime and providing a way
to build unikernel images (instead of normal executables),
• new libraries for the [Unikraft system support], and its [network]
and [block] devices,
• [support for the new backends] in the `mirage' tool.

Using Unikraft with a QEMU or a Firecracker backend is as simple as
choosing the `unikraft-qemu' target or the `unikraft-firecracker' one
when configuring a unikernel.

[OCaml cross compiler] <https://github.com/mirage/ocaml-unikraft>

[Unikraft system support] <https://github.com/mirage/mirage-unikraft>

[network] <https://github.com/mirage/mirage-net-unikraft>

[block] <https://github.com/mirage/mirage-block-unikraft>

[support for the new backends]
<https://github.com/mirage/mirage/pull/1607>

◊ The OCaml/Unikraft cross compiler

To build the [OCaml cross compiler] to Unikraft, we use the [Unikraft]
core, the Unikraft [lib-musl] and [musl] itself. [musl] is the C
library recommended by Unikraft to build programs using the POSIX
interface. This made it easy to build the OCaml 5 runtime, in
particular because it provides an implementation of the `pthread' API
which is now used in many places in the runtime[^*]. This could also
make it easier to port some libraries that depend on `Unix' to work on
Unikraft backends.

[^*]: Adding support for Thread-Local Storage has been a large part of
the work to get OCaml 5 working on Solo5: even if the creation of
threads is not supported, TLS is still necessary to get the runtime to
compile.

The OCaml cross compiler _per se_ builds upon the work that has been
upstreamed to ease the [creation of cross compilers], using almost the
same series of patches than for `ocaml-solo5'. So the only version of
the compiler that is currently supported for OCaml/Unikraft is OCaml
5.3. Almost all the patches will be in the upcoming OCaml 5.4 and
there should no longer be any patches required by OCaml 5.5.

Note that we didn’t go with the full standard Unikraft POSIX stack,
which includes [lwIP] to provide network support. We had a prototype
at some point relying on lwIP to validate our progress on other
building blocks but it raised many incompatibility issues with the
standard MirageOS network stack so we dropped support for lwIP in that
first release; we developed instead the libraries required to plug the
MirageOS stacks into the low-level interfaces provided by the Unikraft
core.

[OCaml cross compiler] <https://github.com/mirage/ocaml-unikraft>

[Unikraft] <https://unikraft.org>

[lib-musl] <https://github.com/mirage/unikraft-lib-musl>

[musl] <https://musl.libc.org/>

[creation of cross compilers]
<https://discuss.ocaml.org/t/building-an-ocaml-cross-compiler-with-ocaml-5-3/15918>

[lwIP] <https://savannah.nongnu.org/projects/lwip/>

◊ The new MirageOS libraries for Unikraft support

The Unikraft support comes with packages using the standard names:
`mirage-block-unikraft' and `mirage-net-unikraft' to support the block
and network devices. Those libraries are implemented directly on top
of the low-level Unikraft APIs, and so are using `virtio' on both QEMU
and Firecracker VMMs. To evaluate the quality of the implementations
for those devices, we ran a couple of small benchmarks. You can find
those benchmarks (the unikernels along with some scripts to set them
up and run them) in the `benchmarks' directory in [@Firobe’s fork of
mirage-skeleton, `benchmarks' branch].

[@Firobe’s fork of mirage-skeleton, `benchmarks' branch]
<https://github.com/Firobe/mirage-skeleton/tree/benchmarks>

◊ Network device

To measure the performance of the network stack, we have tweaked the
simple [network skeleton] unikernel to compute some statistics and
used a variable number of clients all sending 512MB of null
bytes. We have run this benchmark both on a couple of `x86_64'
laptops and on a LX2160 `aarch64' board, all running a GNU/Linux OS.

We have observed a lot of variability in the performance of the
`solo5-spt' unikernel (sometimes better, sometimes worse than
`unikraft-qemu') depending on the actual computer used, so those
measures should be read with a grain of salt.

On two different `x86_64' laptops:

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/0/0ee00c0dca5cb89a4dceb6165e43cf5a46df2e01.jpeg>

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

On the LX2160 `aarch64' board:

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/original/2X/f/fd4364c26dbd295590ef76346449a6daef50784d.jpeg>

[network skeleton]
<https://github.com/mirage/mirage-skeleton/tree/main/device-usage/network>

◊ Block device

To measure the performance of the block devices, we wrote a simple
unikernel copying data from one disk to another. We can see that the
performance of `unikraft-qemu' is lower than `solo5-hvt' for small
buffer sizes; fortunately, the situation improves with larger buffer
sizes. We ran this benchmark only on a `x86_64' laptop as there’s
currently an [issue with two block devices] on `aarch64' on
Unikraft.

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/e/ee6f250ff3b0fc3efebdbe7b836198b0648cf24a_2_1380x974.png>

It is worth mentioning that I/Os can be parallelised, which also
gives a significant performance boost. Indeed,
`mirage-block-unikraft' can leverage the parallelised virtio backend
of QEMU and Firecracker; it takes care of limiting I/Os to what the
hardware supports in terms of both parallelism and sector size.

[issue with two block devices]
<https://github.com/unikraft/unikraft/issues/1622>

◊ Current limitations

1. In our tests only Linux appeared well supported to compile Unikraft
at the moment so we’ve restricted our packages to that OS for now.
2. Unikraft supports various backends itself; in this first release,
we’ve only added support and tested its two major ones: [QEMU] and
[Firecracker].

[QEMU] <https://www.qemu.org/>

[Firecracker] <https://firecracker-microvm.github.io/>

How to use
╌╌╌╌╌╌╌╌╌╌

To try the new Unikraft backend for MirageOS, you need to use an OCaml
5.3 switch, so create one first if needed. Then add our opam overlay
to get access to our latest versions of the packages until they are
published on the standard repository and install `mirage' and the
OCaml/Unikraft cross compiler. The short version could be:

┌────
│ $ opam switch create unikraft-test 5.3.0
│ $ opam repo add mirage-unikraft-overlays https://github.com/Firobe/mirage-unikraft-overlays.git
│ $ opam install mirage ocaml-unikraft-backend-qemu ocaml-unikraft-x86_64
└────

See below for some explanations about the numerous OCaml/Unikraft
packages.

From then on, you can follow the standard procedure (see how to
[install MirageOS] and how to [build a hello-world unikernel]) to
build your unikernel with the Unikraft backend of your choice.

┌────
│ $ mirage configure -t unikraft-qemu
│ $ make
└────

[install MirageOS] <https://mirage.io/docs/install>

[build a hello-world unikernel] <https://mirage.io/docs/hello-world>

◊ Details about the various packages for the OCaml/Unikraft cross compiler

The [OCaml cross compiler] to Unikraft is split up into 14 packages
(see the [PR to `opam-repository'] for more details) so that users
can:

• choose which of the backends (QEMU or Firecracker) and which of the
architectures (`x86_64' and `arm64') they want to install, where all
combinations can be installed at the same time,
• choose which architecture is generated when they use the `unikraft'
ocamlfind toolchain by installing one of the two
`ocaml-unikraft-default-<arch>' package,
• install the `ocaml-unikraft-option-debug' to enable the (really
verbose!) debugging messages.

The virtual packages can be installed to make sure one of the
architecture-specific packages is indeed installed:

• `ocaml-unikraft' can be installed to make sure that there is indeed
a `unikraft' ocamlfind toolchain installed,
• `ocaml-unikraft-backend-qemu' and
`ocaml-unikraft-backend-firecracker' can be intalled to make sure
that the `unikraft' ocamlfind toolchain supports the corresponding
backend.

Those virtual packages will be used in particular by the `mirage' tool
when the target is `unikraft-qemu' or `unikraft-firecracker'.

All those packages use one of two version numbers. The backend
packages use the Unikraft version number they are using, while the
OCaml compiler packages _per se_ use version `1.0.0'.

[OCaml cross compiler] <https://github.com/mirage/ocaml-unikraft>

[PR to `opam-repository']
<https://github.com/ocaml/opam-repository/pull/27856>

Conclusion
╌╌╌╌╌╌╌╌╌╌

This is a first release, which we are experimenting with; we expect to
run it in production in the coming months but it may need improvements
nevertheless. Notably absent from this release is an early attempt to
leverage Unikraft’s POSIX compatibility to implement Mirage interfaces
instead of hooking directly to Unikraft’s internal components. This
early version used Unikraft’s `lwIP'-based network stack instead of
Mirage’s (fooling Mirage into thinking it was running on Unix), and it
may be interesting to revisit this kind of deployment, in particular
for easy inclusion of unix-only OCaml libraries in unikernels.

We are eager for reviews, comments and discussion on the
implementation, design and approach of this new Mirage backend, and
hope it will be useful to others.

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

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

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

• [Introducing Jane Street's OxCaml Branch!]

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

[Introducing Jane Street's OxCaml Branch!]
<https://tarides.com/blog/2025-07-09-introducing-jane-street-s-oxcaml-branch>

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