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

Alan Schmitt
2025-11-04T13:21:41Z

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

Hello

Here is the latest OCaml Weekly News, for the week of October 28 to
November 04, 2025.

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

Caml in the Capital
Ppxlib: Support for future compilers
Miou, a simple scheduler for OCaml 5
Cmarkit 0.4.0 - CommonMark parser and renderer for OCaml
OCaml library for Timeplus Proton timeseries streaming database
Book draft: "Control structures in programming languages"
oplot 0.85 - mathematical plotter
QCheck 0.27
Bytesrw 0.3.0 – The cryptographic edition
Other OCaml News
Old CWN

Caml in the Capital
═══════════════════

Archive: <https://discuss.ocaml.org/t/ann-caml-in-the-capital/17428/1>

Alistair O'Brien announced
──────────────────────────

Hi everyone 👋

We (@giltho and myself) are happy to announce the first OCaml meetup
in London (Caml in the Capital)! Think of it as the British cousin of
OCaml Users Meetup in Paris (OUPS).

What?
╌╌╌╌╌

Caml in the Capital is an informal evening of talks, demos, and
hacking from anyone working with or interested in OCaml. The goal is
to create a friendly local space for sharing ideas, showing off
projects, and connecting with other OCaml developers in the UK.

When?
╌╌╌╌╌

We’re aiming for February 2026. Please fill out this short poll to
help us pick a date:

👉 [Doodle poll link]

Options: Thu 5th Feb, Thu 12th Feb, Thu 19th Feb, Thu 26th Feb

The meetup will take place in central London (venue TBA — likely
Imperial College), starting around 6:30pm and running until 8:30pm,
with informal drinks and discussions afterwards.

[Doodle poll link] <https://doodle.com/group-poll/participate/b6VAjjRb>

What’s the `Fmt'?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

A mix of:

• Workshop-style talks – anything from an accessible introduction of
your work or research, a deep dive into your library, a live demo,
or a tutorial.
• Hacking / discussions

Call for presentations?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

If you’d like to give a talk, please message me or @giltho directly
with:

• A title and short abstract
• Expected time slot

Once we confirm the first date, we’ll:

• Confirm the programme and publish a new forum post
• Setup website, a Zulip channel, and a Meetup page for registration

Looking forward to meeting more OCaml users in person!

– Alistair & Sacha

Ppxlib: Support for future compilers
════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-ppxlib-support-for-future-compilers/17430/1>

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

*Handling future AST changes in ppxlib*

The OCaml 5.2 compiler release has introduced changes in core parts of
the AST types. Reflecting those changes when we bumped the internal
AST used by ppxlib in [0.36.0] caused breakage in a lot of reverse
dependencies. Despite [our efforts to keep the ecosystem up to date],
it has lead to a split in the opam universe between packages that are
compatible with 0.36.0 and above and those that aren't.

Looking at the 5.3 and 5.4 AST changes, we cannot reasonably keep the
same ["update the universe" approach] going forward I would like to
propose a slightly different but much more stable and sustainable
approach.

I think it's important to have a bit of context on why ppxlib is
designed the way it is and how we've been handling new compiler
releases over the past few years to understand this new approach and
how it's going to improve the situation.

The next section of this post will summarize this. If you're already
familiar with ppxlib's history and design choices, please skip ahead
to the [Proposed Approach section](#proposed-approach-for-53-onward).

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

[our efforts to keep the ecosystem up to date]
<https://discuss.ocaml.org/t/ann-ppxlib-0-36-0/16241#p-69148-ocaml-52-internal-ast-1>

["update the universe" approach]
<https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231>

Ppxlib and compiler releases: How it works today
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Ppxlib internal AST

Before ppxlib there was [ocaml-migrate-parsetree]. OMP had the
advantage of providing a stable API for ppx authors. Each ppx would
select a fixed version of the AST and be implemented as a full AST
rewrite, i.e. a `structure -> structure' or `signature -> signature'
function.

This had the advantage of making ppx-es forward compatible as omp
maintainers would add support for new compiler releases in the form of
a new module containing the AST types for this version and migration
functions to convert to/from the types matching the previous compiler
version.

OMP also came with a ppx driver, i.e. a program in charge of applying
a set of ppx-es on a given AST or source file and spit out the final
preprocessed AST for the compiler. The driver was responsible for
migrating the AST from the compiler's version to the one used by a
ppx. Because each ppx could require a different AST version, it also
potentially had to migrate the AST transformed by a ppx before it
passing it on to the next one.

This had a few disadvantages though:
1. poor performance as the AST was traversed and migrated
(i.e. copied) several times through the course of a single driver
run.
2. transformations semantic issues: the order in which ppx-es were
applied was uncertain or rather tied to the set of ppx-es version
used. That meant that updating one ppx could change its "turn" and
result in a different AST returned by the driver. This also did not
allow ppx-es to interact together reliably.

ppxlib aimed at fixing those issues by forcing ppx-es to agree on the
AST version to use. ppxlib provides its own, fixed AST version that
ppx-es have to use. Its driver handles the migration to/from the
current compiler and provides a smooth API to write transformations as
rewriting rules. The driver then handles the AST rewrite by
recursively applying those rules in the right places in a single AST
traversal.

[ocaml-migrate-parsetree]
<https://github.com/ocaml-ppx/ocaml-migrate-parsetree>

◊ Support for new compilers

Support for new compilers comes in two stages.

◊ Build and preprocess old code with new compiler

This is the most basic support, that is making sure that one can
still build and preprocess its code using the newest compiler,
provided they don't use any of the new language features.

To do this, we add the new AST types and migration functions, just
as OMP used to do. This does not allow new features in the code
because those cannot be represented with the old AST types and the
migration would fail (*This was also an existing limitation of
OMP*).

This is usually released early on, when the compiler is still in
beta and is a non breaking change, all reverse dependencies still
build with this new version.

◊ Support new language features

To support new language features, we bump the AST used by
ppxlib. This means new features don't have to be migrated anymore
and are therefore supported.

This does change types that are exposed as part of ppxlib's API and
can cause breakage in reverse dependencies, depending on which part
of the AST were modified and which part each individual ppx uses
explicitly.

We provide tools that can help make ppx code more robust as they
allow matching over and producing AST nodes without explicitly
referencing the types themselves: `metaquot', `Ast_builder' or
`Ast_pattern' for instance. That's not always enough though and
eventually, those ppx-es have to be updated to be compatible with
the latest version of ppxlib.

As was the case for the 5.2 AST bump, when we release such a ppxlib
version, we send PRs to help maintainers of our opam reverse
dependencies update and carefully add upper bounds to the versions
that aren't compatible anymore.

This worked pretty well for a few years as the AST was relatively
stable and the parts that were modified were not directly used by a
lot of ppx-es.

A problem with this approach is that even though we can help
maintainers go through the update, we cannot release packages in
their stead which means that unmaintained ppx-es aren't compatible
anymore no matter how much effort we put into easing the upgrade. It
is also often the case that not all ppx-es have a compatible release
straight away and this results in a transition period with the opam
universe split mentioned in the introduction.

Proposed approach for 5.3 onward
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

The first part of this plan is to freeze ppxlib's internal AST for
each major versions. That means that until we release ppxlib.1.0.0 our
internal AST will always be the 5.2 AST.

The second and most important part is to provide complete forward
compatibility despite the AST freeze. We will allow migrating new
features down to our AST by encoding them inside specific language
extensions and migrating them back to their original form before
returning the preprocessed AST to the compiler.

This will allow existing ppx-es to be used with new compilers AND to
be used in the same files as new language features as long as they
don't have to directly interact with them without being updated in any
way.

We will also provide a stable API to allow ppx-es that would like to
add special support for these new features to build and match over
such nodes.

You can take a look at the examples below to get an idea of what that
would look like for recent language features such as the [effect
syntax](#effect-syntax-example) from OCaml 5.3 or the [bivariance
annotation](#bivariant-type-parameter-example) from OCaml 5.4.

As part of these changes, we will deprecate ppxlib's copy of
`Ast_helper' in favor of `Ast_builder', aiming to remove `Ast_helper'
entirely in 1.0.0. We have been maintaining two distinct modules for
quite a while now. `Ast_helper' also has a tendency to encourage its
users to generate all their code with `Location.none' as their
location which makes the life of their users a bit hard when they have
to interpret compiler errors.

This can be seen as a middle ground between the approach proposed
[here] 6 years ago (/that we gave up on due to its complexity/) and
the current situation.

[here] <https://discuss.ocaml.org/t/the-future-of-ppx/3766>

◊ Limitations

Encoding new features into extension points is not always easy, only
specific parts of the AST can be replaced by an extension point. To
keep things under control and prevent ppx-es from generating
inconsistent nodes, all new features will always be migrated into an
extension point. That means that if the impacted node cannot directly
be encoded that way, we will encode the first suitable parent node. In
some scenarios, that can climb up the AST types quite significantly,
potentially all the way to the `structure_item~/~signature_item'. This
means that new features won't be equal when it comes to how easy it is
to use them in conjunction with some ppx-es. It's important to keep in
mind that this is still a net improvement as it was previously not
possible to use them together at all.

Similarly, providing a nice API to allow building and destructing
encoded new features will vastly depend on the features themselves and
how entangled they are with new AST types. We will likely not always
expose such builder/destructor pairs and might only add some of them
if the demand is high enough.

It is also part of the reason why we will probably still bump our AST
at some points in time even if much less frequently than we have in
the past. When that eventually happens, we will be able to maintain
the previous major versions for quite a while as this will just be a
matter of adding our newest migrations there as well.

◊ Effect syntax example

OCaml 5.3 introduced the following syntax:
┌────
│ match f () with
│ | v -> Complete v
│ | effect (Xchg msg), k ->
│ ...
└────

This special effect pattern is represented in the 5.3 AST with the
`Ppat_effect' variant:
┌────
│ | Ppat_effect of pattern * pattern
└────

We cannot represent this in the 5.2 AST and previously, any attempt at
migrating such a node down would have failed. With this new approach
we instead migrate it to something along those lines:
┌────
│ [%ppxlib.migration.ppat_effect? (Xchg msg, k)]
└────
and the upward migration knows to translate this to the right
`Ppat_effect' node. This migration needs to work without context
outside the extension so that any ppx that would unknowingly copy such
a node elsewhere in the AST would not cause an uninterpreted extension
error later on during the compilation.

If this is passed down to an existing ppx as part of its payload and
it tries to interpret it, it should fail as it won't know what to do
with such an extension.

*Note that ppx authors should never rely on the actual extension point
encoding, we reserve ourselves the right to change that encoding as
part of minor or patch releases of ppxlib. Such nodes should be left
untouched or dealt with using the stable API described below.*

Now if a ppx author needs to add explicit support for effects they
will be able to use something like:
┌────
│ val ppat_effect : loc: location -> pattern -> pattern -> pattern
└────
from `Ast_builder' to generate such a node. Of course if your ppx
generates an `effect' pattern with an older compiler, this will lead
to a compile error as the extension won't be translated unless
migrated back up. Authors will have to be mindful of this and properly
document when/how they'll generate newer nodes and eventually restrict
their ppx to the right range of compilers.

These will likely come with a "destruct" version in `Ast_pattern'. For
the `effect' pattern it should look like:
┌────
│ val ppat_effect : (pattern * pattern, 'a, 'b) t -> (pattern, 'a, 'b) t
└────

◊ Bivariant type parameter example

This example is probably a bit of a stretch as it is a very niche
syntax change and is highly unlikely to actually be used in the wild,
but it makes a good example of a feature that is hard to encode.

In OCaml 5.4, a new variant was added to the `Asttypes.variance' type:
`Bivariant'. The `variance' type is used in the AST to describe how a
type parameter behaves relative to the type itself. This can be
manually annotated for each parameter when writing a type declaration
or a class.

The `Bivariant' case is a bit of a special one as a parameter can only
be `Bivariant' (i.e. covariant AND contravariant) with the type if it
does not actually appear in the concrete type definition, that is in
cases such as:
┌────
│ type 'a t = A
└────

For reasons that we won't expand upon here, 5.4 introduced the
following syntax to allow one to explicit annotate a parameter as
bivariant:
┌────
│ type +-'a t
└────

The problem is that the variance cannot be replaced directly by an
extension point, see the type `type_declaration' for instance:
┌────
│ and type_declaration =
│ {
│ ptype_name: string loc;
│ ptype_params: (core_type * (variance * injectivity)) list;
│ ^^^^^^^^
│ (** [('a1,...'an) t] *)
│ ptype_cstrs: (core_type * core_type * Location.t) list;
│ (** [... constraint T1=T1' ... constraint Tn=Tn'] *)
│ ptype_kind: type_kind;
│ ptype_private: private_flag; (** for [= private ...] *)
│ ptype_manifest: core_type option; (** represents [= T] *)
│ ptype_attributes: attributes; (** [... [\@\@id1] [\@\@id2]] *)
│ ptype_loc: Location.t;
│ }
└────

In this example we have to encode the entire parent node of the type
declaration as an extension point.

This means that it spreads in quite a few places, `type_declaration'
can be found in `structure_items', `signature_items' and inside some
`module_type' nodes as well.

Given there's very little to no use for this syntax, we won't be
providing any function to build or destruct such nodes initially.

Miou, a simple scheduler for OCaml 5
════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-miou-a-simple-scheduler-for-ocaml-5/12963/17>

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

I am delighted to announce the release of Miou version 0.5.0. This
release now uses `poll(2)~/~ppoll(2)' instead of `select(3P)' in order
to improve I/O management performance.

Since I/O management is decoupled from the scheduler, this does not
change the Miou API or the `miou.unix' library.

I would particularly like to thank @backtracking for allowing us to
integrate part of his [bitv] library under a different licence, as
well as @haesbaert, the original author of [ocaml-iomux], for allowing
us to use `poll(2)~/~ppoll(2)'.

This has allowed us to go further, particularly with [vif], our web
framework for OCaml 5, and our website [builder-web] has been
completely rewritten to move to OCaml 5 (thanks to @reynir and
@yomimono who participated in this rewrite and provided important
feedbacks).

This release comes with a new package, [flux] (still experimental),
offering streaming abstractions that can be used with Miou. I would
like to thank @rizo for his sketch [streaming] in this regard
(pre-OCaml 5). This library takes advantage of the parallelism offered
by Miou (with `Miou.call') as well as resource management and
finalisers (with `Miou.Ownership'). A tutorial is available [here] to
create a tiny `curl' with a loading bar.

<https://raw.githubusercontent.com/robur-coop/flux/refs/heads/main/assets/fetch.gif>

Finally, we are continuing to lay the groundwork for the development
of unikernels with [mkernel]. We are currently experimenting with
three unikernels:
• [immuable], which reuses Vif to create websites in OCaml 5 in the
form of unikernels
• [chaos] (still at a very experimental stage), which aims to be an
NTP server
• [dns-resolver], which is a DNS query resolver in the form of a
unikernel

Finally, we would also like to thank everyone who has been involved in
the development of Miou and its related ecosystem, whether directly or
indirectly.

Happy hacking!

[bitv] <https://github.com/backtracking/bitv>

[ocaml-iomux] <https://github.com/ocaml-multicore/ocaml-iomux>

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

[builder-web] <https://git.robur.coop/robur/builder-web>

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

[streaming] <https://github.com/rizo/streaming>

[here] <https://robur-coop.github.io/flux/local/flux/flux.html>

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

[immuable] <https://github.com/dinosaure/immuable>

[chaos] <https://git.robur.coop/robur/chaos>

[dns-resolver] <https://github.com/mirage/dns-resolver/pull/6>

Cmarkit 0.4.0 - CommonMark parser and renderer for OCaml
════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-cmarkit-0-4-0-commonmark-parser-and-renderer-for-ocaml/17435/1>

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

Hello,

It's my pleasure to announce a new release of [cmarkit], an
ISC-licensed CommonMark parser and renderer for OCaml.

This release provides support for the latest version of the CommonMark
specification, updated data for Unicode 17.0.0, a notable semantic
change in the task item extension (thanks to @samoht) and a couple of
bug fixes and improvements mostly in the CommonMark renderer.

All the details are in the [release notes]. Thanks to everyone who
reported issues.

This release is brought to you by essential funding from the [OCaml
software foundation] and my [donors].

• Homepage: <https://erratique.ch/software/cmarkit>
• Docs: <https://erratique.ch/software/cmarkit/doc> (or `odig doc
cmarkit`)
• Install: `opam install cmarkit` ([opam PR])

—

P.S. I'm surprised by the number of users (or rather, dissatisfied
users :–) of the CommonMark renderer. If you are using it don't
hesitate to tell how/why you are using it in this thread, just curious
:–)

[cmarkit] <https://erratique.ch/software/cmarkit>

[release notes]
<https://github.com/dbuenzli/cmarkit/blob/main/CHANGES.md#v040-2025-11-01-zagreb>

[OCaml software foundation] <https://ocaml-sf.org/>

[donors] <https://github.com/sponsors/dbuenzli>

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

OCaml library for Timeplus Proton timeseries streaming database
═══════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-ocaml-library-for-timeplus-proton-timeseries-streaming-database/17440/1>

Michael Freeman announced
─────────────────────────

A high-performance, feature-rich OCaml driver for [Timeplus Proton] -
the streaming database built on ClickHouse.

[Timeplus Proton] <https://timeplus.com/>

*Features*
╌╌╌╌╌╌╌╌╌╌

• *Streaming Queries* - Process large datasets with constant memory
usage
• *Async Inserts* - High-throughput data ingestion with automatic
batching
• *Compression* - LZ4 and ZSTD support for reduced network overhead
• *TLS Security* - Secure connections with certificate validation
• *Connection Pooling* - Efficient resource management for
high-concurrency applications
• *Rich Data Types* - Full support for ClickHouse types including
Arrays, Maps, Enums, DateTime64
• *Idiomatic OCaml* - Functional API leveraging OCaml's strengths

<https://github.com/mfreeman451/proton-ocaml-driver>

Book draft: "Control structures in programming languages"
═════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/book-draft-control-structures-in-programming-languages/17443/1>

Xavier Leroy announced
──────────────────────

I am happy to announce that a draft of my upcoming book "Control
structures in programming languages: from goto to algebraic effects"
is now available at [https://xavierleroy.org/control-structures] .

The book compares several programming languages from the standpoint of
control structures. OCaml is used intensively to discuss control in
functional programming, including continuation-passing style, control
operators, exceptions, user-defined effects and effect handlers, with
many examples that I hope you'll like.

The book also discusses in depth a number of questions that are often
raised in this forum, such as the theory and practice of algebraic
effects and handlers, and the static checking of exceptions and
effects.

Enjoy!

[https://xavierleroy.org/control-structures]
<https://xavierleroy.org/control-structures>

oplot 0.85 - mathematical plotter
═════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-oplot-0-85-mathematical-plotter/17444/1>

sanette announced
─────────────────

Hello

I’m happy to announce a new version of [oplot], a library for plotting
mathematical functions, using openGL by default for fast rendering and
animations, but also providing high quality vector graphics exports.

This version has a new feature that math lovers will appreciate:
`implicit_curve' plotting!

For instance do you want to know what the solutions to the equation
(x²+y²-1)³ - x² y³ = 0 look like?

Here is the result:

<https://us1.discourse-cdn.com/flex020/uploads/ocaml/optimized/2X/0/00fbc53496cd6a8e5b9fb37807e9f5243b79e75e_2_1222x1000.png>

If you already dug into the problem of plotting implicit curves you
know that it’s sometimes very difficult to localize in advance the
various singularities of the curve. `oplot' gives you 3 ways of tuning
the computation: grid size, recursive grid size for subsampling where
the curvature of the curve seems high, and control over the iterations
of the Newton method. There is also a pole detection, where the
function changes sign but probably still doesn’t have a zero
there. You can obtain debug information for any curve, for instance
here you see the default parameters automatically detected for the
above curve: initial grid (green) and subsampling (cyan):

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

`oplot' is available in opam, doc is [here].

[oplot] <https://github.com/sanette/oplot>

[here] <https://sanette.github.io/oplot/oplot/Oplot/index.html>

QCheck 0.27
═══════════

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

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

QCheck 0.27 is now available from the opam repository :partying_face:

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

The 0.27 release is focused on improving the `float' shrinking support
and also contains a small patch to make the package compile with
OxCaml:
• Add `QCheck.Shrink.float' and enable shrinking for `QCheck.float'
• Add `QCheck.Shrink.float_bound' and enable shrinking for
`QCheck.float_bound_inclusive' and `QCheck.float_bound_exclusive'
• Add `QCheck.Shrink.float_range' and enable shrinking for
`QCheck.float_range'
• Enable shrinking for `QCheck.{pos_float,neg_float,exponential}'
• Patch `QCheck.Print.float' and `QCheck2.Print.float' to print
negative nans consistently as "-nan" also on Windows and macOS, and
correct documentation for `QCheck.{float,pos_float,neg_float}' in
that they may produce ~nan~s since #350 from 0.26
• Eta-expand a couple of partial application to compile under OxCaml

Happy testing! :smiley:

Bytesrw 0.3.0 – The cryptographic edition
═════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-bytesrw-0-3-0-the-cryptographic-edition/17450/1>

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

Hello,

It's my pleasure to announce a new release of the [bytesrw] set of ISC
licensed libraries.

Bytesrw extends the OCaml Bytes module with composable,
memory efficient, byte stream readers and writers
compatible with effect-based concurrency.

Optional support for compressed, hashed and encrypted
bytes depend, at your wish, on the C `zlib', `libzstd',
`blake3', `libmd', `xxhash' and `mbedtls' libraries.

This release adds optional libraries to support for `SHA-3' hashes,
cryptographically secure pseudo-random bytes streams, TLS encrypted
byte stream and low-level support for cryptographic operations on
slices:

• [`Bytesrw_sysrandom'] provides pseudorandom byte streams and entropy
directly sourced from your operating system primitives.

• [`Bytesrw_crypto.Psa'] provides low-level cryptographic operations
on byte slices via thin and safe bindings to the [TF-PSA-Crypto] C
library distributed with Mbed TLS. This library is an implementation
of the [PSA Crypto API Specification]. Its design is particularly
suited if you care about key materiel not being seen by the OCaml GC
(implementations also allow further degrees of isolation as can be
read in the API's [design goals]). Besides the API is nicely and
thoroughly documented. It is quite bureaucratic to use but that's
what you likely want from a cryptographic library (e.g. key usages
have to be declared upfront and are checked at runtime by
cryptographic operations).

• [`Bytesrw_crypto'] (will) provides a few higher-level operations
implemented over PSA. The module is rather shallow at the moment,
more will be added in the future as we abstract over our usage of
PSA Crypto. For now it mostly contains an API to access the hashes
provided by PSA Crypto in the way other `bytesrw' hashing modules
expose their hashing service. This notably provides the `SHA-3'
family of hashes which were not previously available in the set of
optional `bytesrw' libraries.

• [`Bytesrw_tls'] provides support for TLS encrypted streams and the
needed X.509 certificate management (including system lookups for
trusted CAs). The backend is provided by the [Mbed TLS] C
library. For now these streams are instantied over blocking fds, but
this restriction will be lifted in the future. I also added a little
tool called `certown' which you may find handy for dealing with
certificates for localhost when you develop servers.

Note that the binding to PSA cryptography has been used to implement a
few things (e.g. the horrific passkeys specification) but has not run
in production yet. However the binding is pleasantly unsophisticated,
the underlying C API is straightforward to bind to.

See the [release notes] for details about other changes.

This release was made possible thanks to a grant from the [OCaml
software foundation] and to my [donors].

• Homepage: <https://erratique.ch/software/bytesrw>
• Docs: <https://erratique.ch/software/bytesrw/doc> (or `odig doc
bytesrw')
• Install: `opam install bytesrw conf-…' ([opam pr])

—

P.S. Libraries that depend on Mbed TLS need the recent 4.0.0 version
which is quite fresh and may take a bit of time to trickle in system
package managers. If you trust me you can use my [distribution crutch]
opam repository to install it.

[bytesrw] <https://erratique.ch/software/bytesrw>

[`Bytesrw_sysrandom']
<https://erratique.ch/software/bytesrw/doc/Bytesrw_sysrandom/index.html>

[`Bytesrw_crypto.Psa']
<https://erratique.ch/software/bytesrw/doc/Bytesrw_crypto/Psa/index.html>

[TF-PSA-Crypto] <https://github.com/Mbed-TLS/TF-PSA-Crypto>

[PSA Crypto API Specification]
<https://arm-software.github.io/psa-api/crypto/1.2/>

[design goals]
<https://arm-software.github.io/psa-api/crypto/1.2/overview/goals.html>

[`Bytesrw_crypto']
<https://erratique.ch/software/bytesrw/doc/Bytesrw_crypto/index.html>

[`Bytesrw_tls']
<https://erratique.ch/software/bytesrw/doc/Bytesrw_tls/index.html>

[Mbed TLS] <https://www.trustedfirmware.org/projects/mbed-tls/>

[release notes]
<https://github.com/dbuenzli/bytesrw/blob/main/CHANGES.md#v030-2025-11-04-zagreb>

[OCaml software foundation] <https://ocaml-sf.org/>

[donors] <https://github.com/sponsors/dbuenzli>

[opam pr] <https://github.com/ocaml/opam-repository/pull/28836>

[distribution crutch] <https://github.com/dbuenzli/distrib-crutch.opam>

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

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

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

• [Supporting OCurrent: FLOSS/Fund Backs Maintenance for OCaml's
Native CI Framework]
• [WebAuthn & Passkeys in OCaml: Implementing Passwordless
Authentication]

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

[Supporting OCurrent: FLOSS/Fund Backs Maintenance for OCaml's Native CI
Framework]
<https://tarides.com/blog/2025-10-30-supporting-ocurrent-floss-fund-backs-maintenance-for-ocaml-s-native-ci-framework>

[WebAuthn & Passkeys in OCaml: Implementing Passwordless Authentication]
<https://fearful-odds.rocks/blog/webauthn-passkey-implementation-ocaml>

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