OCaml Weekly News

I recently started contributing to Dune with no prior familiarity with the code base. One thing I found rewarding was closing old issues — some filed as far back as 2018 — and I wanted to share the approach I used.

I'm happy to announce the release of ocaml-wire 0.9.0 to opam!

ocaml-wire is a set of combinators to describe binary protocols in OCaml. "Binary" as in fixed-layout: sizes and shapes are mostly known up front, so you're reading fields at known offsets rather than parsing a free-form grammar (like in Menhir). There are already many good binary parser frameworks in OCaml – here's what's different in ocaml-wire:

• The central data structure is EverParse's 3D grammar. The OCaml combinators describe a 3D structure. Following Daniel's tagged final encoding approach, you build a codec that describes a struct and how to serialise/deserialise it from an OCaml value.
• Which means every description can compile down to a .3d file and from there to C via EverParse – and the generated C compiles cleanly with -std=c99 -Wall -Werror. So you could, in theory (I haven't pushed on this too far for now), build and link a complex stack as an standalone, external C parser whose memory safety, single-pass behaviour, and conformance to the 3D spec are proven in F*(EverParse doesn't give you serialisers, unfortunately).
• If you prefer, you can still use the OCaml parsers/verifiers, which have been made reasonably fast (i.e. no extra allocations on the hot path), and as they are streaming codecs you can just read or write a single field of the structure without parsing the whole thing. They also compile trivially to JavaScript via js_of_ocaml, if you need to parse the same format in the browser.

A small example – a packet with two nibble-wide fields, a big-endian length, and a variable-size payload whose length is read from the Length field:

open Wire

type packet = { version : int; flags : int; length : int; payload : string }

let f_version = Field.v "Version" (bits ~width:4 U8)
let f_flags   = Field.v "Flags"   (bits ~width:4 U8)
let f_length  = Field.v "Length"  uint16be
let f_payload = Field.v "Payload" (byte_array ~size:(Field.ref f_length))

let codec =
  let open Codec in
  v "Packet" (fun version flags length payload -> { version; flags; length; payload })
    [ f_version $ (fun p -> p.version);
      f_flags   $ (fun p -> p.flags);
      f_length  $ (fun p -> p.length);
      f_payload $ (fun p -> p.payload) ]

Field.ref f_length is the dependent-size bit: the payload's length comes from the f_length field read earlier in the same struct. That same codec value is what you hand to Everparse.schema to get the 3D file out, and what backs Codec.get / Codec.set for streaming field access from OCaml. ocaml-wire also ships the infrastructure for generating FFI stubs and for differential testing to make sure the verified C and hand-written OCaml parsers agree. So far they seem to :-)

You can read more about it here: https://gazagnaire.org/blog/2026-03-31-ocaml-wire.html.

To try it: opam install wire

Feedback very welcome on the issue tracker (or bellow)!

Hi everyone,

I wanted to share that valkey 0.2.0 is now on opam:

• opam: https://opam.ocaml.org/packages/valkey/valkey.0.2.0/
• Repo and Getting Started: https://github.com/avifenesh/ocaml-valkey/blob/main/docs/getting-started.md

The main thing I wanted with this project was to focus on the current Valkey stack with the newer OCaml stack.

So valkey is built around:

• OCaml 5
• Eio-native direct-style concurrency
• RESP3 only
• Modern Valkey features and real cluster behavior

A few parts I'm happy with:

• Cluster support with a strong focus on durability and high availability: topology refresh, periodic background refresh, MOVED / ASK / CLUSTERDOWN handling, replica-aware reads, AZ-aware routing, and failover-aware sharded pub/sub replay
• connection/runtime behavior: circuit breaker, reconnect handling, keepalive, TLS, and optional separation between socket I/O and parsing via Eio.Domain_manager, so one side of the system does not block the other
• batch support: scatter-gather across slots, atomic single-slot flows with WATCH / MULTI / EXEC, multi-slot helpers, and in 0.2.0 also WATCH guards for read-modify-write CAS plus cross-slot pfcount_cluster
• command surface: typed helpers across a pretty broad set of commands, Client.custom /~custom_multi~ for custom commands and multi-node execution, and named commands so you can register command templates once and reuse them later
• scripting: local script caching and optimistic EVALSHA handling with automatic fallback/retry on NOSCRIPT, so callers don't need to manage that flow themselves

There is also already a pretty good amount of validation around it: integration tests, property tests, fuzzing, chaos testing, examples, and guides.

Performance-wise, it also came out pretty nicely: in several scenarios it gets to 90%+ of the C reference client.

opam update
opam install valkey eio_main

Current next steps on the roadmap are things like:

• client-side caching
• connection pools / blocking pools
• IAM + mTLS
• Valkey module support (JSON, search, bloom)

If there's a feature people care about, I'd be very happy to reprioritize the roadmap around real interest.

I'd also really love feedback from the OCaml community on the API, ergonomics, docs, and general design.

I'm very familiar with the Valkey world, but OCaml is more of a side fun for me than my daily language, so feedback from people who really live in the OCaml ecosystem is especially valuable to me.

If you try it, I'd love to hear what you think.

I am pleased to introduce the UnifiedScript_Std and UnifiedScript_Top packages. Unified scripts are a way to write tests and documentation simultaneously. Cram tests and MDX scripts are both similar to unified scripts, but unified scripts aren't tied to Markdown (MDX) or tied to POSIX shell commands (cram tests).

Examples:

• Markdown example: Here are the zillions of tests from ocaml-re converted into Markdown: ocaml-re/EXAMPLES.md. Custom OCaml REPL printers are used so that many of the tests are printed as Markdown tables. aside: Wouldn't it be nice if tests you are already writing became documentation? That was a 4 year follow-up to https://discuss.ocaml.org/t/what-are-the-biggest-reasons-newcomers-give-up-on-ocaml/10958/13?u=jbeckford

• .ml example: The following is a snippet from a regular OCaml .ml module where the (* ... *) comments are OCaml REPL toplevel responses maintained by the unified tools.

  let lyrics =
    "Everybody step to the left."
    (* val lyrics : string = "Everybody step to the left." *)[@ocamlformat "disable"]
  
  let (_ : string) =
    Printf.sprintf "Now let's sing: %s" lyrics
    (* - : string = "Now let's sing: Everybody step to the left." *)[@ocamlformat "disable"]
  

Docs are at dk/docs/UNIFIED_SCRIPTS.md (of course generated by the unified tools).

Install the tools with:

opam pin add UnifiedScript_Std https://gitlab.com/dkml/build-tools/MlFront/-/releases/permalink/latest/downloads/MlFront.tar.gz
opam pin add UnifiedScript_Top https://gitlab.com/dkml/build-tools/MlFront/-/releases/permalink/latest/downloads/MlFront.tar.gz

After feedback I'll release them officially to opam. I would like feedback overall and also specifically on the agent skill that converts expect tests to unified tests.

I'm happy to announce the first version (v0.0.1) of openrouter_api, a library for querying large language models via OpenRouter, a service which provides access to a variety of models under a unified API.

• opam: https://opam.ocaml.org/packages/openrouter_api/
• GitHub: https://github.com/mt-caret/openrouter-ocaml
• docs: https://mt-caret.github.io/openrouter-ocaml/openrouter_api/index.html

I've been using this library in my personal projects whenever I want to integrate an AI model, and I've found it quite useful; I hope others will find it useful as well. Issues and contributions are welcome.

Date and location have been confirmed! June 3rd at the Jane Street office!! I have updated the post.

We're still open for presentation proposals as well!