Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: Alan Schmitt <alan.schmitt@polytechnique.org>
To: "lwn" <lwn@lwn.net>, caml-list@inria.fr
Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
Date: Tue, 08 Sep 2026 15:20:53 +0200	[thread overview]
Message-ID: <m2cxun516y.fsf@mac-03220211.irisa.fr> (raw)


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

Hello

Here is the latest OCaml Weekly News, for the week of September 01 to
08, 2026.

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

Working in the OCaml compilers backend
forcamla 0.4.0 - Simple Functional Reactive Programming
Typegist 0.0.0
Dependent if expressions without dependent types
Caps 0.1.0, a capability type system and library for OCaml
bstr, slice and bin (bigstring, encoders and decoders for binary formats)
OCaml 5.5.1 released
Slipshow!
ocp-indent 1.10.0
Intel ISA specification interpreter/compiler is written in OCaml
TyXML 5.0.0
Old CWN


Working in the OCaml compilers backend
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/working-in-the-ocaml-compilers-backend/18499/1>


Zane Hambly announced
─────────────────────

  Hello! long time lurker, first time caller here.

  I've been working in the OCaml backend mainly in native emission and
  `asmcomp' swapping out calls to C for instructions for each
  architecture the compiler supports. Some of the work was sponsored by
  OCSF but I have also been trying to make myself useful in other
  projects too.

  I have done a full write up on my [website].

  Because my work has also involved adding native atomics, I've been
  doing litmus testing on OCaml's memory model. If you are interested in
  seeing the results, I've also added a page [here]. This is something I
  plan on updating from time to time alongside some other tests I have
  planned. I have access to a whole pile of machines so I might as well
  use them!

  I come mainly from a hobbyist and historical computing background and
  have used OCaml extensively to help me in those endeavours. I plan on
  continuing my work on the compiler so you may see me around reviewing
  pull requests or sending my own in. If you have any questions, please
  feel free to ask!

  Thanks,

  Zane


[website] <https://zanehambly.com/ocaml>

[here] <https://zanehambly.com/reference/ocaml-atomics>


forcamla 0.4.0 - Simple Functional Reactive Programming
═══════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-forcamla-0-4-0-simple-functional-reactive-programming/18501/1>


Christopher Sumnicht announced
──────────────────────────────

  Hi everyone,

  I also made this package a bit ago (didn't know about
  discuss.ocaml.org until yesterday) called [forcamla] ([opam]). You can
  think of it like a very powerful spreadsheet editor. In particular, in
  forcamla we /equate/ variables instead of /assign/ them. forcamla also
  combines the power of spreadsheets with event listeners to organize
  program execution.


[forcamla] <https://github.com/rxdt-labs/forcamla>

[opam] <https://opam.ocaml.org/packages/forcamla/>

A Small Example
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ open Formula (* To use formula *)
  │ 
  │ let x = v 2 (* Create an integer term called x *)
  │ let y = v 2 (* Create an integer term called y *)
  │ let z = x + y
  │ let () = x =: 3 (* Set x to 3, and z now is 5 *)
  └────

  Observe there is no need to reassign `z'. It was /equated/ to `x + y'
  and will always update whenever `x' or `y' change.


Event Listeners
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  You can also construct event listeners using this framework. Here is a
  small game example to illustrate this:

  ┌────
  │ open Formula
  │ 
  │ type hero =
  │ {
  │   (* A bunuch of fields *)
  │   health: int formula
  │ }
  │ 
  │ let player =
  │ {
  │   (* Assign the fields *)
  │   health = v 3; (* Give health a value of something, say 3 in this case. *)
  │ }
  │ 
  │ let game_over () = print_endline "Game Over!"
  │ let () = when_satisfied (player.health =? 0) game_over
  └────

  Then you can do this:

  ┌────
  │ let () = player.health =: !(player.health - c 1) (* Nothing happens yet! player.health is 2 now. *)
  │ let () = player.health =: !(player.health - c 1) (* Nothing happens yet! player health is 1 now. *)
  │ let () = player.health =: !(player.health - c 1) (* Now something happens! player.health is 0 and "Game Over!" is printed to the screen! *)
  └────


Why?
╌╌╌╌

  I originally designed forcamla for games but I realized it is just a
  useful organizational tool in general. It is similar to Jane Street's
  [Incremental] but forcamla prioritizes ergonomics over efficiency.


[Incremental] <https://github.com/janestreet/incremental>


Typegist 0.0.0
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-typegist-0-0-0/18503/1>


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

  Hello,

  It's my pleasure to announce the first release of `typegist':

        Typegist represents the essence of OCaml types as values.
        This dynamic type representation can be used to devise
        generic type-indexed functions – value serializers,
        printers, parsers, differs, random generators, editors,
        ffi glue, etc. Any accessible type can be described up to
        the limits defined by its public interface.  Typegist does
        not model OCaml's type language in full detail, but
        focuses on a core structural subset decorated with
        typed-indexed metadata to provide an ergonomic interface
        for both producers and processors of the representation.
        Typegist is distributed under the ISC license. It has no
        dependencies.

  As mentioned above these values only partially model OCaml's type
  definition language, that's the reason why they are `Type.Gist.t' and
  not `Type.Repr.t' values. You should see typegist as a data
  interfacing language for your types rather than a faithful or
  canonical representation of your types (which I find less useful in
  practice).

  The representation special cases and annotates some of the `Stdlib'
  types: being too generic and losing all semantics in favour of
  generalized abstract non-sense is undesirable when you interface with
  other systems. For example. You want `list' values to show up as
  arrays in JSON, not as nested cons case objects. You want `None' to
  map to `null' not to a constant case object. You want `string' values
  that hold textual data to show up as plain JSON strings rather than
  hex digits or base64. Etc.

  This means that part of [the representation] is decidedly ad-hoc. It
  balances precision and genericity while making it [reasonably easy] to
  devise your own gist processors without getting bogged into pointless
  details of OCaml's type expression language.

  So next time it's time for you to write an `M.pp : t Fmt.t' function,
  write an `M.gist : t Type.Gist.t' instead. You'll get your printer and
  [more]. A companion release of `jsont' was made with the new optional
  `jsont.typegist' library that [translates] type gists into `jsont'
  JSON types for your JSON serialization pleasure (if that exists).

  While I don't expect typegist to change much, it hasn't been used in
  anger yet – but I'll waste no time. It's again a design that has been
  rotting for too long in a repo. This means that changes in the
  representation could still occur based on feedback if more precision
  is needed or better representation are found. However I'd expect such
  changes to mostly affect gist processors. Get in touch on the issue
  tracker if you run into difficulties or improvements.

  I have no plan to propose any mean to automate gist derivations from
  type definitions, but some people have expressed interest in doing
  that in the past.

  Happy typed-indexed programming!

  This first release was made possible thanks to a grant from the [OCaml
  Software Foundation]. I also thank my [donors] for their support.

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

  Best,

  Daniel

  — P.S. The API makes use – for good – of every new type gimick that
  was introduced in OCaml 5.5 :–)


[the representation]
<https://erratique.ch/software/typegist/doc/Typegist/Type/Gist/Expr/index.html>

[reasonably easy]
<https://erratique.ch/software/typegist/doc/cookbook.html#generic_funs_template>

[more]
<https://erratique.ch/software/typegist/doc/Typegist/Fun/Generic/index.html>

[translates]
<https://erratique.ch/software/jsont/doc/Jsont_typegist/index.html>

[OCaml Software Foundation] <https://ocaml-sf.org/>

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


Dependent if expressions without dependent types
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dependent-if-expressions-without-dependent-types/18506/1>


Didier Wenzek announced
───────────────────────

  This [post on Haskell for all] shows an insighful use of Church
  encoding to implement dependent if expressions without dependent
  types.

  The following OCaml code type checks and works:

  ┌────
  │ # let example bool = if_then_else bool 5 "hi!";;
  │ 
  │ # example t;;
  │  - : int = 5
  │ # example f;;
  │ - : string = "hi!"
  │ # example (f && t);;
  │ - : string = "hi!"
  │ # example (f || t);;
  │ - : int = 5
  │ # example (not t);;
  │ - : string = "hi!"
  └────

  This is simply based on Hindley-Milner type inference, with a single
  trick that is to be not too restrictive on the type for Church encoded
  booleans.

  Where the first idea to Church encode booleans would be to restrict
  the `then' and `else' cases to be the same (using a record to encode
  the forall type):

  ┌────
  │ type bool = { check : 'a. 'a -> 'a -> 'a; }
  └────

  Dependent if expressions require a liberal definition:

  ┌────
  │ type bool = { check : 'a 'b 'c. 'a -> 'b -> 'c; }
  └────

  And this is what is inferred when no type is enforced (ignoring the
  fact we get then weakly polymorphic types instead of forall types):

  ┌────
  │ let t if_branch else_branch = if_branch
  │ let f if_branch else_branch = else_branch
  │ 
  │ let if_then_else bool if_branch else_branch = bool if_branch else_branch
  │ 
  │ let (&&) a b if_branch else_branch = a (b if_branch else_branch) else_branch
  │ let (||) a b if_branch else_branch = a if_branch (b if_branch else_branch)
  │ let not a if_branch else_branch = a else_branch if_branch
  └────

  I encourage you read the full post, this is a really nice read.


[post on Haskell for all]
<https://haskellforall.com/2026/09/dependent-if-expressions>


Caps 0.1.0, a capability type system and library for OCaml
══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-caps-0-1-0-a-capability-type-system-and-library-for-ocaml/18507/1>


Yoann Padioleau announced
─────────────────────────

  Hi everyone,

  I am pleased to announce the first release of the caps library, which
  allows you to use /capability types/ in your OCaml programs (and
  libraries).

  The main idea is that after you used this library, your functions can
  have signatures like

  ┌────
  │ val foo: < Cap.network; Cap.stdout; Cap.random; .. > ->
  │   int -> float
  └────

  meaning this function requires the /network/, /stdout/, and /random/
  capabilities to work. The signature reveals the internal /effect/ this
  function has and the kind of system calls it internally does (or its
  callees),

  I designed this library while working at Semgrep on the semgrep
  codebase and it was useful to /sandbox/ or control parts of the
  codebase so that young engineers would not call dangerous functions in
  certain parts.  It is I think even more useful in the new coding-agent
  era to control in the signature the code generated by AI.

  For more information you can see my talk at the OCaml 2026 workshop
  here: <https://www.youtube.com/watch?v=4t_2wLz9EOo> as well as the
  corresponding slides <https://aryx.github.io/ocaml-caps/caps.html>
  (using the super cool Slipshow presentation tool announced here a few
  times).  See also the project page at
  <https://github.com/aryx/ocaml-caps>

  You can easily play with it by installing it via opam:

  ┌────
  │ $ opam update
  │ $ opam install caps
  └────

  Happy to answer questions.


bstr, slice and bin (bigstring, encoders and decoders for binary formats)
═════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-bstr-slice-bin-bigstring-encoders-decoders-for-binary-formats/18509/1>


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

  I am delighted to announce the release of [`bstr.0.1.0'], as well as
  `bin.0.1.0' and `slice.0.1.0'. These releases are the result of a
  synthetic work between several libraries, aimed at bringing together
  everything that might be useful to us in implementing formats and
  protocols within [our cooperative]. In particular, these libraries
  offer:
  • a comprehensive module for manipulating what are known as
    _bigstrings_ (replacing [bigstringaf] - because the name of that
    library is too long)
  • a library providing access to bigstrings and bytes (in short, [an
    abstraction] of [ocaml-cstruct])
  • finally, a library for describing binary formats from which one can
    derive an encoder and a decoder (in the spirit of what [repr] can
    offer)

  For those who want to understand the benefits of bigstrings, I’ve
  previously shared my thoughts on the subject [here]. Although we’ve
  since backtracked on the use of `ocaml-cstruct', particularly for
  performance reasons (see [this article]), bigstrings remain useful in
  certain cases: they should, fundamentally, be used wisely.

  Particular attention has been paid to performance using [`bechamel']
  (for micro-benchmarking), and we can draw a few conclusions from this:
  • `bstr' has the edge over `bigstringaf' as it uses tags that did not
    exist at the time `bigstringaf' was developed
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━
           bstr    bigstringaf 
    ───────────────────────────
     blit  4.4ns   4.8ns       
     sub   15.4ns  18.9ns      
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━
  • `slice.bstr' performs like `ocaml-cstruct' (which was to be
    expected)
  • `bin' challenges hand-written code in terms of decoding
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
           bin     hand-written (`ocaml-cstruct')  `repr'  `angstrom' 
    ──────────────────────────────────────────────────────────────────
     ipv4  11.9ns  11.9ns                          93.9ns  136ns      
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    ┌────
    │ let bin =
    │   let fn vihl tos total_length id ff ttl protocol checksum src dst =
    │     { version= vihl lsr 4; ihl= vihl land 0x0f; tos; total_length; id
    │     ; flags= ff lsr 13; frag_offset= ff land 0x1fff; ttl; protocol; checksum
    │     ; src; dst }
    │   in
    │   let open Bin in
    │   record ~name:"ipv4" fn
    │   |+ field ~name:"vihl" uint8 (fun t -> (t.version lsl 4) lor t.ihl)
    │   |+ field ~name:"tos" uint8 (fun t -> t.tos)
    │   |+ field ~name:"total_length" beuint16 (fun t -> t.total_length)
    │   |+ field ~name:"id" beuint16 (fun t -> t.id)
    │   |+ field ~name:"flags_frag" beuint16 (fun t ->
    │       (t.flags lsl 13) lor t.frag_offset)
    │   |+ field ~name:"ttl" uint8 (fun t -> t.ttl)
    │   |+ field ~name:"protocol" uint8 (fun t -> t.protocol)
    │   |+ field ~name:"checksum" beuint16 (fun t -> t.checksum)
    │   |+ field ~name:"src" beint32 (fun t -> t.src)
    │   |+ field ~name:"dst" beint32 (fun t -> t.dst)
    │   |> sealr
    │ 
    │ let cstruct cs =
    │   let vihl = Cstruct.get_uint8 cs 0 in
    │   let tos = Cstruct.get_uint8 cs 1 in
    │   let total_length = Cstruct.BE.get_uint16 cs 2 in
    │   let id = Cstruct.BE.get_uint16 cs 4 in
    │   let ff = Cstruct.BE.get_uint16 cs 6 in
    │   let ttl = Cstruct.get_uint8 cs 8 in
    │   let protocol = Cstruct.get_uint8 cs 9 in
    │   let checksum = Cstruct.BE.get_uint16 cs 10 in
    │   let src = Cstruct.BE.get_uint32 cs 12 in
    │   let dst = Cstruct.BE.get_uint32 cs 16 in
    │   { version= vihl lsr 4; ihl= vihl land 0x0f; tos; total_length; id
    │   ; flags= ff lsr 13; frag_offset= ff land 0x1fff; ttl; protocol; checksum
    │   ; src; dst }
    └────

  These libraries were driven by the ambition to provide a coherent and
  consistent set of libraries, particularly for working with bigarrays,
  whilst making few compromises in terms of performance. [Several
  attempts] were made to experiment with functors, GADTs, ADTs and even
  higher-kinded polymorphism… (even with capabilities).

  The result is that a _poor man’s functor_ appears to be sufficient,
  along with a few tweaks (notably to avoid a few `caml_apply2' calls),
  to achieve something that is fairly competitive compared to
  hand-written code.

  These libraries also encapsulate what may have been missing and/or
  emerged within the community when it came to working with
  bigstrings. I have personally contributed to improving these libraries
  without being entirely satisfied with them: hence the emergence of
  `bstr' in particular. A considerable amount of effort has been put
  into documenting these libraries and into testing them. Fuzzers are
  also available to verify certain assertions regarding `bin' (such as
  isomorphism).

  These libraries are currently in use, and this version is certainly
  not the final one. Indeed, we will continue to improve them as we use
  them (particularly with regard to the implementation of protocols and
  formats in OCaml).

  If you appreciate our work, you can make a donation [via GitHub] or
  directly to [our charity]. Bighappy hacking!


[`bstr.0.1.0'] <https://github.com/robur-coop/bstr>

[our cooperative] <https://robur.coop>

[bigstringaf] <https://github.com/inhabitedtype/bigstringaf>

[an abstraction]
<https://github.com/robur-coop/bstr/blob/b427711671c1654df37550849efe5265c866ebcc/lib/slice.mli#L1>

[ocaml-cstruct] <https://github.com/mirage/ocaml-cstruct>

[repr] <https://github.com/mirage/repr>

[here]
<https://discuss.ocaml.org/t/buffered-io-bytes-vs-bigstring/8978/3?u=dinosaure>

[this article]
<https://blog.robur.coop/articles/miragevpn-performance.html>

[`bechamel'] <https://github.com/mirage/bechamel>

[Several attempts] <https://github.com/dinosaure/buffet>

[via GitHub] <https://github.com/sponsors/robur-coop>

[our charity] <https://robur.coop/#donate>


OCaml 5.5.1 released
════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-5-5-1-released/18510/1>


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

  We have the pleasure of celebrating the birthday of Giovanni Girolamo
  Saccheri by announcing the release of OCaml version 5.5.1.

  This patch-level release fixes a major type system bug for
  module-dependent functions and also contains two security fixes for
  the runtime: one in the Marshal module, another inside the loading of
  bytecode.

  At a less severe level, this release also fixes two bugs in the
  runtime for concurrent programs, another runtime bug for musl users;
  and a handful of other bugs.

  The release also restores support for cloning the compiler on macOS.

  Overall, we are strongly advising you to switch to OCaml 5.5.1 if you
  were already using OCaml 5.5.0.


  The full list of bug fixes is available below for more details.

  Happy hacking, – Florian Angeletti, for the OCaml team.


Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands:

  ┌────
  │ opam update
  │ opam switch create 5.5.1
  └────

  The source code for the release is also directly available on:

  • GitHub: <https://github.com/ocaml/ocaml/archive/5.5.1.tar.gz>)
  • Inria archive:
    <https://caml.inria.fr/pub/distrib/ocaml-5.5/ocaml-5.5.1.tar.gz>


Changes compared to OCaml 5.5.0
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Type system

  • [14891], [14982]: fix scope error leading to an erroneous
    typechecking for non-dependent application of module-dependent
    function in presence of dependent first-class module types:
    ┌────
    │ module type T = sig module type S end
    │ let f (module M:T) (m: (module M.S)) = m
    │ module type P = sig type 'a t end
    │ let error =
    │   f (module struct module type S = P end) (module List)
    └────
    (Florian Angeletti, report by Hazem ElMasry, review by Gabriel
    Scherer)


  [14891] <https://github.com/ocaml/ocaml/issues/14891>

  [14982] <https://github.com/ocaml/ocaml/issues/14982>


◊ Runtime

  • [14872]: harden loading of bytecode executable files against
    corrupted or malicious files having 2^29 TOC entries or more.
    (Xavier Leroy, review by Nicolás Ojeda Bär)

  • [15019]: `Marshal.from_{string,bytes}': guard against overflow in
    the computation of the total data length.  (Xavier Leroy, report by
    Akshay Singh, review by Nicolás Ojeda Bär and Antonin Décimo)

  • [14933]: Respect `sysconf(_SC_SIGSTKSZ)' when choosing the size for
    the alternate signal stack, avoiding fatal errors when linked
    against musl libc on some Intel CPUs.  (Nat Mote, review by Florian
    Angeletti and Miod Vallat)

  • [14940], fix a memory leak in the OCaml runtime by bounding the size
    of the internal cache of stacks.  (Vesa Karvonen, Florian Angeletti,
    review by Gabriel Scherer)

  • [15029]: Fix a regression on Windows where an OCaml thread that
    never yielded voluntarily would keep the runtime lock forever, so
    that the other threads of its domain never ran. Preemptive switching
    between systhreads had no effect; only explicit calls to
    `Thread.yield' or blocking sections would let other threads run.
    (Nicolás Ojeda Bär, report by Daniel Larraz, review by Antonin
    Décimo)


  [14872] <https://github.com/ocaml/ocaml/issues/14872>

  [15019] <https://github.com/ocaml/ocaml/issues/15019>

  [14933] <https://github.com/ocaml/ocaml/issues/14933>

  [14940] <https://github.com/ocaml/ocaml/issues/14940>

  [15029] <https://github.com/ocaml/ocaml/issues/15029>


◊ Build system

  • [14883], [14884]: fix Windows cross-compilation with older
    mingw32-gcc versions (Brian Ward, review by Antonin Décimo and
    Stefan Muenzel)

  • [14871], [14914]: Ignore OCAMLTOP_INCLUDE_PATH during the build.
    (David Allsopp, report by Andreas Rossberg, review by Florian
    Angeletti)

  • [14901], [14923]: Fix the generated installation script to cope with
    macOS's geriatric version of bash when executing in opam's sandbox.
    (David Allsopp, report by Julian Fondren and Sacha-Élie Ayoun,
    investigation and initial fix by Kate Deplaix, review by Florian
    Angeletti)

  • [14989]: Improve build reproducibility by letting only
    otherlibs/{str,unix} build their own .cmi and .cmx. The generic
    %.cmi/%.cmx rules of the root Makefile were racing with them under
    make -j and recorded a different source path, which changed the
    interface digest (and, through it, most other compiled artefacts) as
    well as the debug info packed into str.a and unix.a.  (Bernhard
    M. Wiedemann, review by David Allsopp and Stefan Muenzel)


  [14883] <https://github.com/ocaml/ocaml/issues/14883>

  [14884] <https://github.com/ocaml/ocaml/issues/14884>

  [14871] <https://github.com/ocaml/ocaml/issues/14871>

  [14914] <https://github.com/ocaml/ocaml/issues/14914>

  [14901] <https://github.com/ocaml/ocaml/issues/14901>

  [14923] <https://github.com/ocaml/ocaml/issues/14923>

  [14989] <https://github.com/ocaml/ocaml/issues/14989>


◊ User interface

  • [14881], [14882]: fix printing of external types that are subject to
    module constraints.  (Stefan Muenzel, review by Florian Angeletti)


  [14881] <https://github.com/ocaml/ocaml/issues/14881>

  [14882] <https://github.com/ocaml/ocaml/issues/14882>


◊ Runtime events library

  • [14966]: add the missing EV_MINOR_EPHE_CLEAN constructor to
    Runtime_events.runtime_phase, introduced in [13643]. The runtime has
    emitted this phase since 5.4, when a minor collection has to clean
    locked ephemerons, but the OCaml type had no constructor for it, so
    consumers were handed an out-of-range value and crashed when
    matching on it.  (Tim McGilchrist, review by Florian Angeletti)

  • [14969]: Fix the units of the runtime events counter
    EV_C_MINOR_ALLOCATED_WORDS to report as the number of words of minor
    heap consumed, including headers.  (Tim McGilchrist, review by
    Nicolás Ojeda Bär)


  [14966] <https://github.com/ocaml/ocaml/issues/14966>

  [13643] <https://github.com/ocaml/ocaml/issues/13643>

  [14969] <https://github.com/ocaml/ocaml/issues/14969>


Slipshow!
═════════

  Archive: <https://discuss.ocaml.org/t/ann-slipshow/16337/29>


Continuing this thread, Paul-Elliot announced
─────────────────────────────────────────────

  Another release was just [merged] in opam!

  Did you notice the trembling glass of water? That's the next release
  of Slipshow that I'm announcing:


[merged] <https://github.com/ocaml/opam-repository/pull/30652>

Slipshow 0.13.0: Juraslip Park
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  While digging in decades-old software, I found bugs that contained the
  DNA of the now extinct Keynoplodocus, Googloslideraptor, and last but
  not least, Powerpointaurus Rex.

  By merging it in Slipshow's own DNA, I was able to bring back to life
  features long forgotten by every modern software (like Slipshow): the
  ability to place elements in your presentation using the mouse.

  <https://github.com/user-attachments/assets/2330aab5-ee28-4248-b215-66920cb1c7ff>

  The main new attraction of this release is the "GUI mode".

  Until now, Slipshow placed every element for you, based on what it is
  (a title, a paragraph, a block) with CSS as escape hatch. This is the
  "What You See Is What You Mean" model. In "What You See Is What You
  Get", by contrast, you directly edit the rendered content and lay your
  elements out there, usually with the mouse.

  The best of both (Jurassic) worlds would be "What You See Is What You
  Want": deciding per element which of the two modes you prefer.

  Just as some frogs can change sex in a single-sex environment, a
  Slipshow element can now turn from WYSIWYM to WYSIWYG and be placed
  with the mouse, with a single `gui' attribute:

  ┌────
  │ {gui}
  │ Drag me, resize me.
  └────

  Other notable improvements include Ctrl+clicking on the rendered
  content to get to the source, the addition of the [Tachyons] CSS
  framework, more consistent shortcuts, and some quality of life
  improvements in the drawing editor.

  As usual, I thank all [contributors] 💚, my [sponsor] ❤️, and [NLnet
  for a generous grant] 💝 that made all this work possible!

  Here is the full changelog:


[Tachyons] <https://tachyons.io/>

[contributors]
<https://github.com/panglesd/slipshow/graphs/contributors?from=5%2F30%2F2026>

[sponsor] <https://github.com/sponsors/panglesd/>

[NLnet for a generous grant] <https://nlnet.nl/project/Slipshow/>


Added
╌╌╌╌╌

  • "What You See Is What You Want": positions any "GUI" element
    absolutely, by dragging it in the preview! Supports moving,
    redimensioning and scaling elements. (#270)
  • "Go to source" by ~Ctrl~+clicking (or ~Cmd~+clicking on Mac)
    anywhere in the preview. (#270)
  • Added [tachyons] support (#278)


[tachyons] <https://tachyons.io/>


Changed
╌╌╌╌╌╌╌

  • Improved toolbar and shortcut consistency, notably in recording
    manager mode, `Shift+R' now closes the recording manager (previously
    it started a recording). `Shift+S' is used to start a
    recording. (#270)
  • Diagnostics on `slipshow compile' are sorted by location (#277)
  • Improve location of "Wrong Type" diagnostic (#277)
  • Hint that step counter and toc entries are clickable. (#278)
  • Pressing play in drawing editor when the cursor is at the end of the
    recording now replays from the beginning. (#278)
  • Round sub-millisecond time precision in drawing editor. (#278)


Fixed
╌╌╌╌╌

  • LSP:
    • Respect UTF-16 position encoding when it is the only one supported
      by the editor. (#270)
    • Fix a bug in detection of element at cursor, and one in locations
      of "glued" attribute, in effect improving hover and highlight
      reliability. (#270)
    • Fix `go_next' / `go_previous' doing nothing in "refresh on save"
      mode. (#270)
    • Fix frontmatter error sometimes not being reported (#277)
  • Fix locations reported for frontmatter `attributes:'. (#271)
  • Fix drawings being drawn behind positioned elements. (#270)
  • Fixed standalonity of html by embedding mono fonts (#272)
  • Resolution of css and js files in frontmatter are now relative to
    the file they are in (and not to the root file). (#271)
  • LSP: correctly refresh on changes on files mentioned in frontmatter
    (such as css and js files). (#271)
  • Improve uri vs local path detection. (#271)
  • Improve locations of errors in `css:' and `js:' frontmatter
    fields. (#271)
  • Allow spaces and tabs after frontmatter delimiters. (#275)
  • Fix drawing replay in editor stuck on a pause. (#278)
  • Fix last point of a stroke not being displayed when the recording
    ends at this time. (#278)
  • Group a slide's entrance with its own heading in the table of
    contents (#273)


Docs
╌╌╌╌

  • Added documentation on the new GUI mode (#270)


ocp-indent 1.10.0
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocp-indent-1-10-0/18513/1>


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

  Here at OCamlPro we're happy to announce the release of
  `ocp-indent.1.10.0'.

  The full release notes are available [here] if you want the detailed
  version.

  The main feature of this release is the support for new OCaml language
  features from 5.3 effect patterns to 5.5 `let type' or `let
  class'. All new syntax introduced in the last 3 minor compiler
  releases are now properly supported.

  It also comes with new yet long awaited features such as a `--check'
  mode which simply verifies whether the input file is correctly
  indented and a complementary `--strict' flag which makes `ocp-indent'
  warnings fatal, both intended for CI use.

  As usual there's also a bunch of bug fixes: `-' is now correctly
  accepted as a positional argument for `<stdin>' input, `strict_with'
  behaviour has been improved to be consistent across types and type
  extensions and starred comments are now correctly indented.

  We'd like to thank Ahrefs who's funded this release through their
  [grant program]!

  May your .ml files be properly indented :pray:


[here] <https://github.com/OCamlPro/ocp-indent/releases/tag/1.10.0>

[grant program]
<https://discuss.ocaml.org/t/ahrefs-grant-program-for-ocaml/17604>


Intel ISA specification interpreter/compiler is written in OCaml
════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/intel-isa-specification-interpreter-compiler-is-written-in-ocaml/18515/1>


Edwin Török announced
─────────────────────

  Intel has recently published a beta executable specification for its
  ISA:
  <https://intel.github.io/SDM/announcement/2026/08/20/announce-preview.html>
  . Although approximations for an ISA specification have existed before
  (e.g. in [ACL2 or SAIL]), they were constructed based on the manual in
  prose form (which [had bugs in the past]). Having the specification
  published in an executable language (and hopefully tested!) by the
  vendor itself is a welcome improvement.

  Even better, I just noticed that the [interpreter/compiler] for the
  specification language is written in OCaml!


[ACL2 or SAIL] <https://github.com/rems-project/sail-x86-from-acl2>

[had bugs in the past] <https://github.com/zwegner/x86-sat>

[interpreter/compiler] <https://github.com/IntelLabs/isa-tools>


TyXML 5.0.0
═══════════

  Archive: <https://discuss.ocaml.org/t/ann-tyxml-5-0-0/18516/1>


Vincent Balat announced
───────────────────────

  We are happy to announce *TyXML 5.0.0*, a major release. TyXML builds
  HTML and SVG documents whose validity is checked by the OCaml type
  system: an element the specification does not allow in a given
  position does not typecheck. The library now follows the current
  specifications, the WHATWG living standard for HTML and SVG 2 with the
  Filter Effects module, where SVG support had not moved since SVG 1.1.

  Highlights:

  • *HTML*: popover, invoker commands, microdata, declarative shadow DOM
     and CSS shadow parts, `loading~/~decoding~/~fetchpriority',
     `blocking', the new elements `s', `bdi', `search', `data', `slot'
     and `track', the event handler attributes that were missing (the
     pointer family, clipboard, `ontoggle', `onscrollend' and friends),
     and content models brought in line with the standard.
  • *SVG*: `mask' was declared in `Svg_types' but the element itself was
     missing, `feMerge' could be given no child because `feMergeNode'
     did not exist, and about thirty presentation attributes had a type
     tag but no function to produce them. All of those are in, together
     with the SVG 2 additions, ARIA support, the SVG 2 link attributes,
     and content models widened to SVG 2.
  • *The PPX and JSX syntaxes*: no camel case SVG attribute was
     recognised, so `viewBox', `stdDeviation', `preserveAspectRatio' and
     most others were rejected, which means most real SVG could not be
     written with the PPX at all. Whitespace between SVG tags is also
     ignored now where the content model does not accept text, so
     indented SVG typechecks.
  • *Constructs that no program could actually use* are fixed: `area'
     had no `href' and its tag was in no content model, so a `map'
     containing areas fitted nowhere; `symbol' accepted no core
     attributes, hence no `id' and no way to reference it; the `li'
     children of `menu' could not be built. Several attribute names were
     also emitted misspelled, which is worse than a compile error since
     the output looks fine. Breaking changes worth knowing about:
     `hidden' and `contenteditable' take an enumerated argument, the
     URL-valued attributes go through `Xml.uri', SVG documents are
     printed without the SVG 1.1 doctype, `Wrapped_functions' has four
     new functions for implementers of the functorial interface, and the
     build requires OCaml 4.08, dune 3.18 and ppxlib 0.36.

  ┌────
  │ opam install tyxml
  └────

  • Blog post with the details:
    <https://ocsigen.org/blog/posts/tyxml-5.0.0.html>
  • Changelog: <https://github.com/ocsigen/tyxml/blob/master/CHANGES.md>
  • Manual and API: <https://ocsigen.org/tyxml/latest/>

  Thanks to everyone who contributed to this release, in particular Hugo
  Heuzard, Martin Bodin, toastal, Sylvain Boilard, rand00, Sora
  Morimoto, Patrick Ferris and Gabriel Radanne. Bug reports and pull
  requests are welcome on <https://github.com/ocsigen/tyxml>.


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

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

             reply	other threads:[~2026-09-08 13:21 UTC|newest]

Thread overview: 309+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 13:20 Alan Schmitt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2026-09-01  9:14 Alan Schmitt
2026-08-25  7:36 Alan Schmitt
2026-08-18  6:56 Alan Schmitt
2026-08-11 12:25 Alan Schmitt
2026-08-04  7:44 Alan Schmitt
2026-07-28 12:44 Alan Schmitt
2026-07-21 16:02 Alan Schmitt
2026-07-14  7:16 Alan Schmitt
2026-07-07 13:29 Alan Schmitt
2026-06-30 13:25 Alan Schmitt
2026-06-23 10:07 Alan Schmitt
2026-06-16 10:51 Alan Schmitt
2026-06-09  7:39 Alan Schmitt
2026-06-02  9:01 Alan Schmitt
2026-05-26  7:36 Alan Schmitt
2026-05-19  8:52 Alan Schmitt
2026-05-12  7:28 Alan Schmitt
2026-05-05  9:35 Alan Schmitt
2026-04-28  7:59 Alan Schmitt
2026-04-21  9:34 Alan Schmitt
2026-04-14  9:50 Alan Schmitt
2026-04-07  9:32 Alan Schmitt
2026-03-31  6:10 Alan Schmitt
2026-03-24  9:58 Alan Schmitt
2026-03-17 14:39 Alan Schmitt
2026-03-10 13:30 Alan Schmitt
2026-03-03 13:54 Alan Schmitt
2026-02-24 13:36 Alan Schmitt
2026-02-17 13:47 Alan Schmitt
2026-02-10 10:36 Alan Schmitt
2026-02-03 10:04 Alan Schmitt
2026-01-27 12:41 Alan Schmitt
2026-01-20  9:19 Alan Schmitt
2026-01-13  8:27 Alan Schmitt
2026-01-06 13:14 Alan Schmitt
2025-12-30  9:33 Alan Schmitt
2025-12-23 11:00 Alan Schmitt
2025-12-16 13:30 Alan Schmitt
2025-12-09 15:04 Alan Schmitt
2025-12-02 10:39 Alan Schmitt
2025-11-25 13:49 Alan Schmitt
2025-11-18 14:01 Alan Schmitt
2025-11-11  9:49 Alan Schmitt
2025-11-04 13:21 Alan Schmitt
2025-10-28 13:30 Alan Schmitt
2025-10-21  9:17 Alan Schmitt
2025-10-14  9:56 Alan Schmitt
2025-10-07 12:22 Alan Schmitt
2025-09-30 13:12 Alan Schmitt
2025-09-23 13:23 Alan Schmitt
2025-09-16 11:52 Alan Schmitt
2025-09-09 12:30 Alan Schmitt
2025-09-02 12:23 Alan Schmitt
2025-08-26 12:34 Alan Schmitt
2025-08-19 12:20 Alan Schmitt
2025-08-12 15:32 Alan Schmitt
2025-08-05  8:17 Alan Schmitt
2025-07-29  9:36 Alan Schmitt
2025-07-22 12:07 Alan Schmitt
2025-07-15 17:14 Alan Schmitt
2025-07-08 12:45 Alan Schmitt
2025-07-01 11:16 Alan Schmitt
2025-06-24 14:02 Alan Schmitt
2025-06-17  6:44 Alan Schmitt
2025-06-10 13:36 Alan Schmitt
2025-06-03  9:19 Alan Schmitt
2025-05-27  9:22 Alan Schmitt
2025-05-20 11:52 Alan Schmitt
2025-05-13  9:40 Alan Schmitt
2025-05-06  7:24 Alan Schmitt
2025-04-29  8:39 Alan Schmitt
2025-04-22 11:50 Alan Schmitt
2025-04-15  9:51 Alan Schmitt
2025-04-08 13:14 Alan Schmitt
2025-04-01  9:12 Alan Schmitt
2025-03-25  8:06 Alan Schmitt
2025-03-18 10:18 Alan Schmitt
2025-03-11 15:00 Alan Schmitt
2025-03-04 14:01 Alan Schmitt
2025-02-25 10:36 Alan Schmitt
2025-02-18 14:33 Alan Schmitt
2025-02-11  7:17 Alan Schmitt
2025-02-04 12:05 Alan Schmitt
2025-01-28 13:24 Alan Schmitt
2025-01-21 15:47 Alan Schmitt
2025-01-14  8:20 Alan Schmitt
2025-01-07 17:26 Alan Schmitt
2024-12-31  8:03 Alan Schmitt
2024-12-24  8:55 Alan Schmitt
2024-12-17 13:05 Alan Schmitt
2024-12-10 13:48 Alan Schmitt
2024-12-03 14:44 Alan Schmitt
2024-11-26  8:30 Alan Schmitt
2024-11-19  6:52 Alan Schmitt
2024-11-12 15:00 Alan Schmitt
2024-11-05 13:22 Alan Schmitt
2024-10-29 13:30 Alan Schmitt
2024-10-22 12:42 Alan Schmitt
2024-10-15 13:31 Alan Schmitt
2024-10-08 10:56 Alan Schmitt
2024-10-01 13:37 Alan Schmitt
2024-09-24 13:18 Alan Schmitt
2024-09-17 14:02 Alan Schmitt
2024-09-10 13:55 Alan Schmitt
2024-09-03  8:24 Alan Schmitt
2024-08-27  9:02 Alan Schmitt
2024-08-20  9:29 Alan Schmitt
2024-08-13 13:21 Alan Schmitt
2024-08-06  9:00 Alan Schmitt
2024-07-30 13:26 Alan Schmitt
2024-07-23 13:30 Alan Schmitt
2024-07-16  6:24 Alan Schmitt
2024-07-09  9:19 Alan Schmitt
2024-07-02  7:30 Alan Schmitt
2024-06-25 13:58 Alan Schmitt
2024-06-18 13:05 Alan Schmitt
2024-06-11 15:04 Alan Schmitt
2024-06-04 13:26 Alan Schmitt
2024-05-28  9:07 Alan Schmitt
2024-05-21 13:07 Alan Schmitt
2024-05-14 13:25 Alan Schmitt
2024-05-07  7:30 Alan Schmitt
2024-04-30  7:22 Alan Schmitt
2024-04-23 12:17 Alan Schmitt
2024-04-16 12:00 Alan Schmitt
2024-04-09  9:15 Alan Schmitt
2024-04-02 14:31 Alan Schmitt
2024-03-26  6:32 Alan Schmitt
2024-03-19 15:09 Alan Schmitt
2024-03-12 10:31 Alan Schmitt
2024-03-05 14:50 Alan Schmitt
2024-02-27 13:53 Alan Schmitt
2024-02-20  9:12 Alan Schmitt
2024-02-13  8:42 Alan Schmitt
2024-02-06 15:14 Alan Schmitt
2024-01-30 14:16 Alan Schmitt
2024-01-23  9:45 Alan Schmitt
2024-01-16 10:01 Alan Schmitt
2024-01-09 13:40 Alan Schmitt
2024-01-02  8:59 Alan Schmitt
2023-12-26 10:12 Alan Schmitt
2023-12-19 10:10 Alan Schmitt
2023-12-12 10:20 Alan Schmitt
2023-12-05 10:13 Alan Schmitt
2023-11-28  9:09 Alan Schmitt
2023-11-21  7:47 Alan Schmitt
2023-11-14 13:42 Alan Schmitt
2023-11-07 10:31 Alan Schmitt
2023-10-31 10:43 Alan Schmitt
2023-10-24  9:17 Alan Schmitt
2023-10-17  7:46 Alan Schmitt
2023-10-10  7:48 Alan Schmitt
2023-10-03 13:00 Alan Schmitt
2023-09-19  8:54 Alan Schmitt
2023-09-12 13:21 Alan Schmitt
2023-09-05  9:00 Alan Schmitt
2023-08-29 13:04 Alan Schmitt
2023-08-22  9:20 Alan Schmitt
2023-08-15 16:33 Alan Schmitt
2023-08-08  8:53 Alan Schmitt
2023-08-01  7:13 Alan Schmitt
2023-07-25  8:45 Alan Schmitt
2023-07-11  8:45 Alan Schmitt
2023-07-04  9:18 Alan Schmitt
2023-06-27  8:38 Alan Schmitt
2023-06-20  9:52 Alan Schmitt
2023-06-13  7:09 Alan Schmitt
2023-06-06 14:22 Alan Schmitt
2023-05-30 15:43 Alan Schmitt
2023-05-23  9:41 Alan Schmitt
2023-05-16 13:05 Alan Schmitt
2023-05-09 11:49 Alan Schmitt
2023-05-02  8:01 Alan Schmitt
2023-04-25  9:25 Alan Schmitt
2023-04-18  8:50 Alan Schmitt
2023-04-11 12:41 Alan Schmitt
2023-04-04  8:45 Alan Schmitt
2023-03-28  7:21 Alan Schmitt
2023-03-21 10:07 Alan Schmitt
2023-03-14  9:52 Alan Schmitt
2023-03-07  9:02 Alan Schmitt
2023-02-28 14:38 Alan Schmitt
2023-02-21 10:19 Alan Schmitt
2023-02-14  8:12 Alan Schmitt
2023-02-07  8:16 Alan Schmitt
2023-01-31  6:44 Alan Schmitt
2023-01-24  8:57 Alan Schmitt
2023-01-17  8:37 Alan Schmitt
2022-11-29 14:53 Alan Schmitt
2022-09-27  7:17 Alan Schmitt
2022-09-20 14:01 Alan Schmitt
2022-09-13  8:40 Alan Schmitt
2022-08-23  8:06 Alan Schmitt
2022-08-16  8:51 Alan Schmitt
2022-08-09  8:02 Alan Schmitt
2022-08-02  9:51 Alan Schmitt
2022-07-26 17:54 Alan Schmitt
2022-07-19  8:58 Alan Schmitt
2022-07-12  7:59 Alan Schmitt
2022-07-05  7:42 Alan Schmitt
2022-06-28  7:37 Alan Schmitt
2022-06-21  8:06 Alan Schmitt
2022-06-14  9:29 Alan Schmitt
2022-06-07 10:15 Alan Schmitt
2022-05-31 12:29 Alan Schmitt
2022-05-24  8:04 Alan Schmitt
2022-05-17  7:12 Alan Schmitt
2022-05-10 12:30 Alan Schmitt
2022-05-03  9:11 Alan Schmitt
2022-04-26  6:44 Alan Schmitt
2022-04-19  5:34 Alan Schmitt
2022-04-12  8:10 Alan Schmitt
2022-04-05 11:50 Alan Schmitt
2022-03-29  7:42 Alan Schmitt
2022-03-22 13:01 Alan Schmitt
2022-03-15  9:59 Alan Schmitt
2022-03-01 13:54 Alan Schmitt
2022-02-22 12:43 Alan Schmitt
2022-02-08 13:16 Alan Schmitt
2022-02-01 13:00 Alan Schmitt
2022-01-25 12:44 Alan Schmitt
2022-01-11  8:20 Alan Schmitt
2022-01-04  7:56 Alan Schmitt
2021-12-28  8:59 Alan Schmitt
2021-12-21  9:11 Alan Schmitt
2021-12-14 11:02 Alan Schmitt
2021-11-30 10:51 Alan Schmitt
2021-11-16  8:41 Alan Schmitt
2021-11-09 10:08 Alan Schmitt
2021-11-02  8:50 Alan Schmitt
2021-10-19  8:23 Alan Schmitt
2021-09-28  6:37 Alan Schmitt
2021-09-21  9:09 Alan Schmitt
2021-09-07 13:23 Alan Schmitt
2021-08-24 13:44 Alan Schmitt
2021-08-17  6:24 Alan Schmitt
2021-08-10 16:47 Alan Schmitt
2021-07-27  8:54 Alan Schmitt
2021-07-20 12:58 Alan Schmitt
2021-07-06 12:33 Alan Schmitt
2021-06-29 12:24 Alan Schmitt
2021-06-22  9:04 Alan Schmitt
2021-06-01  9:23 Alan Schmitt
2021-05-25  7:30 Alan Schmitt
2021-05-11 14:47 Alan Schmitt
2021-05-04  8:57 Alan Schmitt
2021-04-27 14:26 Alan Schmitt
2021-04-20  9:07 Alan Schmitt
2021-04-06  9:42 Alan Schmitt
2021-03-30 14:55 Alan Schmitt
2021-03-23  9:05 Alan Schmitt
2021-03-16 10:31 Alan Schmitt
2021-03-09 10:58 Alan Schmitt
2021-02-23  9:51 Alan Schmitt
2021-02-16 13:53 Alan Schmitt
2021-02-02 13:56 Alan Schmitt
2021-01-26 13:25 Alan Schmitt
2021-01-19 14:28 Alan Schmitt
2021-01-12  9:47 Alan Schmitt
2021-01-05 11:22 Alan Schmitt
2020-12-29  9:59 Alan Schmitt
2020-12-22  8:48 Alan Schmitt
2020-12-15  9:51 Alan Schmitt
2020-12-01  8:54 Alan Schmitt
2020-11-03 15:15 Alan Schmitt
2020-10-27  8:43 Alan Schmitt
2020-10-20  8:15 Alan Schmitt
2020-10-06  7:22 Alan Schmitt
2020-09-29  7:02 Alan Schmitt
2020-09-22  7:27 Alan Schmitt
2020-09-08 13:11 Alan Schmitt
2020-09-01  7:55 Alan Schmitt
2020-08-18  7:25 Alan Schmitt
2020-07-28 16:57 Alan Schmitt
2020-07-21 14:42 Alan Schmitt
2020-07-14  9:54 Alan Schmitt
2020-07-07 10:04 Alan Schmitt
2020-06-30  7:00 Alan Schmitt
2020-06-16  8:36 Alan Schmitt
2020-06-09  8:28 Alan Schmitt
2020-05-19  9:52 Alan Schmitt
2020-05-12  7:45 Alan Schmitt
2020-05-05  7:45 Alan Schmitt
2020-04-28 12:44 Alan Schmitt
2020-04-21  8:58 Alan Schmitt
2020-04-14  7:28 Alan Schmitt
2020-04-07  7:51 Alan Schmitt
2020-03-31  9:54 Alan Schmitt
2020-03-24  9:31 Alan Schmitt
2020-03-17 11:04 Alan Schmitt
2020-03-10 14:28 Alan Schmitt
2020-03-03  8:00 Alan Schmitt
2020-02-25  8:51 Alan Schmitt
2020-02-18  8:18 Alan Schmitt
2020-02-04  8:47 Alan Schmitt
2020-01-28 10:53 Alan Schmitt
2020-01-21 14:08 Alan Schmitt
2020-01-14 14:16 Alan Schmitt
2020-01-07 13:43 Alan Schmitt
2019-12-31  9:18 Alan Schmitt
2019-12-17  8:52 Alan Schmitt
2019-12-10  8:21 Alan Schmitt
2019-12-03 15:42 Alan Schmitt
2019-11-26  8:33 Alan Schmitt
2019-11-12 13:21 Alan Schmitt
2019-11-05  6:55 Alan Schmitt
2019-10-15  7:28 Alan Schmitt
2019-09-03  7:35 Alan Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2cxun516y.fsf@mac-03220211.irisa.fr \
    --to=alan.schmitt@polytechnique.org \
    --cc=caml-list@inria.fr \
    --cc=lwn@lwn.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox