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

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

[-- Attachment #1.1.1: Type: text/plain, Size: 9968 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of July 07 to 14,
2026.

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

opam 2.5.2
ocaml-wire: a Binary wire format DSL with EverParse 3D output
Caqti 3.0.0
ocgtk 0.1: OCaml bindings for GTK 4 (preview release)
Old CWN


opam 2.5.2
══════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-5-2/18338/1>


Kate announced
──────────────

  Hi everyone,

  opam 2.5.2 is now available. This release is fixing:
  • a security issue ([OSEC-2026-10])
  • a regression from 2.5.1 preventing cross-compiled packages that use
    dune from installing properly ([ocaml/dune#14393])

  We invite everyone to upgrade to 2.5.2 as soon as possible.

  If you depend on the older opam package of your preferred
  distribution, maintainers of distributions such as Debian Stable have
  been notified and we expect backporting of the relevant fixes to be
  available there very soon.

  You can read our [blog post] for relevant links and details.


[OSEC-2026-10]
<https://github.com/ocaml/security-advisories/blob/main/advisories/2026/OSEC-2026-10.md>

[ocaml/dune#14393] <https://github.com/ocaml/dune/issues/14393>

[blog post] <https://opam.ocaml.org/blog/opam-2-5-2/>

Try it!
╌╌╌╌╌╌╌

  The upgrade instructions are unchanged:

  For Unix systems
  ┌────
  │ bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) --version 2.5.2"
  └────
  or from PowerShell for Windows systems
  ┌────
  │ Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.2"
  └────
  Please report any issues to the [bug-tracker].

  Happy hacking, <> <> The opam team <> <> :camel:


[bug-tracker] <https://github.com/ocaml/opam/issues>


ocaml-wire: a Binary wire format DSL with EverParse 3D output
═════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-wire-a-binary-wire-format-dsl-with-everparse-3d-output/18009/4>


Continuing this thread, Thomas Gazagnaire announced
───────────────────────────────────────────────────

  I'm happy to announce that `ocaml-wire' 1.0.0 is now on opam,
  installable with `opam install wire'.

  This release brings a round of robustness fixes and API cleanups to
  the previous version (hence the 1.0.0 tag). It also adds a lot of
  differential testing between the OCaml parsers/serialisers and the
  generated verified C parsers. Both are run on randomly generated
  schemas and random input bytes, and the test checks that they agree on
  what they accept or reject, and on the values they decode. Wherever
  they disagreed there was a bug, and those all seem to be fixed now.

        But how can these be interpreted as signed integers or
        floats? Is this left to the layers above?

  EverParse 3D has no signed or floating-point types, only unsigned
  integers, so to the C validator an int8 is a UINT8 and a float64 is a
  UINT64. The OCaml decoder does the reinterpretation, two's complement
  for the signed types and IEEE 754 for the floats, and for a plain
  field both sides accept every bit pattern. A constraint on the field
  (that the user would have added via the DSL) has to survive that
  projection. A signed ordering constraint has to be rewritten through
  the two's-complement identity before it reaches the C validator,
  because a naive unsigned comparison disagrees on bytes with the sign
  bit set (byte 200 is the signed value -56, accepted by OCaml and
  rejected by the naive C bound). Float finiteness (`is_finite',
  `is_nan') compiles to a test on the exponent bits, and a float
  ordering constraint, which has no faithful unsigned form, is rejected
  up front. The differential fuzzing is what surfaced those sign-bit
  disagreements and all of this has been hardened between 0.9 and 1.0.

  Zero-copy reads got safer too. `Codec.validate' now enforces every
  check `Codec.decode' does (enum membership, bounds, padding, `where'
  clauses), so validating untrusted input before a batch of zero-copy
  `Codec.get' calls no longer trusts bytes the decoder would have
  rejected (again, caught thanks to differential testing).

  The generated `.3d' files also turned out to be quite readable as
  protocol descriptions, and a whole codec family now projects to a
  single .3d that doubles as a spec and compiles to a standalone
  verified C parser with no FFI. The TCP/IP stack is a good one to
  compare: the [OCaml definitions] and the [generated 3d file].


[OCaml definitions]
<https://github.com/parsimoni-labs/ocaml-wire/blob/main/examples/net/net.ml>

[generated 3d file]
<https://github.com/parsimoni-labs/ocaml-wire/blob/main/examples/net/Net.3d>


Caqti 3.0.0
═══════════

  Archive: <https://discuss.ocaml.org/t/ann-caqti-3-0-0/18335/1>


Petter A. Urkedal announced
───────────────────────────

  I am happy to announce the release of [Caqti] 3.0.0.  This release
  bundles some breaking changes including switching to hierarchical
  modules.  The Caqti 3 API is mainly a reorganization of the
  `caqti.template' preview library and some remaining modules from the
  Caqti 2 API.

  Release notes:

  • The `caqti' library now holds the Caqti 3 API and `caqti.classic'
    contains a Caqti 2 compatibility wrapper.  Users of the Caqti 2 API
    must now add `caqti.classic' to their link lines.  Early adopters of
    the Caqti 3 API must replace `caqti.template' with `caqti' and
    adjust some module paths.  Switching to the new API is recommended,
    but may be done incrementally for existing applications.

  • Fixed initial comma when formatting rows, affecting
    `Caqti_type.pp_value' (Caqti 2) and `Caqti.Template.Row.pp' (Caqti
    3).

  • Put on hold deprecation of the `caqti-dynload' package due to [issue
    #140].

  • Foreign key constraints are now enabled for SQLite by default.

  It's good if opam-released projects add `caqti.classic' to their link
  lines before their next release (or switch API) and raise the lower
  bound on caqti to 2.3.0 (cf [the previous announcement]) if necessary.


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

[issue #140] <https://github.com/paurkedal/ocaml-caqti/issues/140>

[the previous announcement]
<https://discuss.ocaml.org/t/ann-caqti-2-3-0/17985>


ocgtk 0.1: OCaml bindings for GTK 4 (preview release)
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocgtk-0-1-ocaml-bindings-for-gtk-4-preview-release/17944/6>


Continuing this thread, Chris Armstrong announced
─────────────────────────────────────────────────

  *ocgtk 0.1-preview2 is now available on opam*

  This release significantly increases the amount of generated
  functionality, covering the vast majority of classes snd methods
  available in it’s generated libraries (GTK, Gio, Pango, Cairo, GDK,
  GDKpixbuf, Graphene)


Notable changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Extended Signals support

  Signsls with multiple parameters and non boolean return parameters are
  now supported, giving coverage to about 2/3 of supported signal types


◊ GValue support

  GValue is now properly supported as a prerequisite for proper signals
  support


◊ Extended primitives support

  Full coverage of integer types, list types, better array handling,
  GError mapping to result types and better GObject equality and
  hashing. All extend the coverage of supported methods that can be
  generated.


◊ Memory management

  A significant effort has gone into hunting down memory management
  bugs, especially with boxed record types, which now use a consistent
  GLib mechanism for handling references to them.


◊ Extended operating system and compiler versions support

  Most dependencies of ocgtk have been removed as they were only
  necessary for code generation, allowing us to extend support to
  Windows (MSYS2 only) and Ocaml versions going back to 4.14.


◊ Other improvements

  • Better handling of mutually dependent classes and interfaces by
    shortening their internal module name
  • constructor generation for classes: with this, we can do away with
    aliasing classes at the top level, presenting only their class types
    and constructors, also making unused code elimination better and
    reducing compilation bottlenecks

  The next release will focus on improved API documentation generation
  and gaps in record support and other primitives (constants, functions,
  callbacks, etc).


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 #1.1.2: Type: text/html, Size: 20663 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 568 bytes --]