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 --]
next 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