From: Alan Schmitt <alan.schmitt@polytechnique.org>
To: "lwn" <lwn@lwn.net>, "cwn" <cwn@lists.idyll.org>,
caml-list@inria.fr, comp@lists.orbitalfox.eu
Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
Date: Tue, 27 Oct 2020 09:43:50 +0100 [thread overview]
Message-ID: <87wnzchxdl.fsf@m4x.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 18183 bytes --]
Hello
Here is the latest OCaml Weekly News, for the week of October 20 to 27,
2020.
Table of Contents
─────────────────
Bisect_ppx, the coverage tool, now has excellent integration with Dune
Js_of_ocaml in the VSCode OCaml Platform
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
Set up OCaml 1.1.2
Set up OCaml 1.1.3
First release of FSML
Qrc 0.1.0, a QR code encoder
cumulus 0.0.1
Brr 0.0.1, a toolkit for programming browsers
Old CWN
Bisect_ppx, the coverage tool, now has excellent integration with Dune
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/bisect-ppx-the-coverage-tool-now-has-excellent-integration-with-dune/6634/1>
Anton Bachin announced
──────────────────────
[*Bisect_ppx*], the coverage tool, has just had its [2.5.0] release,
in which the main addition is a very neat integration with Dune:
┌────
│ dune runtest --instrument-with bisect_ppx --force
└────
This uses the new [instrumentation support] added in Dune 2.7.0, and
is a considerable improvement over the dubious methods Bisect and its
users were previously forced to rely on :)
It is no longer necessary to edit `dune' files for a release, as
Bisect only becomes a dependency of your project when
`--instrument-with bisect_ppx' is supplied on the Dune command line,
which is only during development and in CI. This makes projects ready
for release from any commit. Dune also now knows to rebuild affected
files when instrumentation is turned on or off, so you don't have to
manually run `dune clean' in between. Everything just works the way it
should.
See the updated [instructions] for all the details on how to use this
integration.
I've also adapted [Lambda Soup] as a simple full-project example. See
its [`opam'], [`dune-project'], [`dune'], and [`Makefile'].
Bisect_ppx still supports all the older integrations, so if you have
an existing setup, you don't have to edit it. Support may eventually
be removed in the future, however, so I encourage users to gradually
update.
See the full [changelog] for information on bugs fixed by the release.
Thanks to the Dune team for adding `--instrument-with', to @undu for
supporting it on the Bisect side, and to all the Bisect_ppx users and
contributors!
Happy testing!
<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>
<https://github.com/aantron/bisect_ppx>
[*Bisect_ppx*] <https://github.com/aantron/bisect_ppx>
[2.5.0] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
[instrumentation support]
<https://dune.readthedocs.io/en/stable/instrumentation.html?highlight=instrument-with>
[instructions] <https://github.com/aantron/bisect_ppx#Dune>
[Lambda Soup] <https://github.com/aantron/lambdasoup>
[`opam']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/lambdasoup.opam#L17-L22>
[`dune-project']
<https://github.com/aantron/lambdasoup/blob/master/dune-project#L1>
[`dune']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/src/dune#L7>
[`Makefile']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/Makefile#L15>
[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>
Js_of_ocaml in the VSCode OCaml Platform
════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/js-of-ocaml-in-the-vscode-ocaml-platform/6635/1>
Max LANTAS announced
────────────────────
I just finished a write-up about [vscode-ocaml-platform]'s recent
transition to Js_of_ocaml:
<https://mnxn.github.io/blog/ocaml/vscode-jsoo/>
I can answer any questions here.
This is also my first technical blog post, so any constructive
criticism or comments about my writing would be very helpful.
[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform/>
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
═════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2020-10/msg00018.html>
Laurène Gibaud announced
────────────────────────
At OCamlPro, we will be organizing 2 cross-company training sessions
in French. Both sessions interleave theory and practice. You'll have
time to ask your specific questions and get personalized feedback on
your programs.
• Our Beginner session will allow developers to build upon their
experience of other programming languages (such as C, C++, Python,
C# or Java) to program confidently in OCaml. Feel free to share the
info with your coworkers or your network!
• Our “Expert OCaml” training will allow you to master OCaml’s
advanced features such as its type-system, OCaml’s open source tools
and libraries, and how to write compact and efficient code.
More info on the program and prerequisites on
<http://www.ocamlpro.com/training-ocamlpro/> or ask away (answer this
email or write at contact@ocamlpro.com).
When? The Beginner session is scheduled for November 23-24, 2020. The
Expert session will be on November 25-26, 2020.
Where? Paris 14, in OCamlPro's office.
How? Register on:
<https://www.ocamlpro.com/pre-inscription-a-une-session-de-formation-inter-entreprises/>
We can also organize custom and on-site sessions upon request.
Set up OCaml 1.1.2
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-2/6643/1>
Sora Morimoto announced
───────────────────────
This release contains these changes:
• Add the Cygwin setup to a known location for later steps
• Check if the switch exists before creating the switch
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.2>
Set up OCaml 1.1.3
══════════════════
Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-3/6644/1>
Sora Morimoto announced
───────────────────────
This release contains these changes:
• Update the `@actions/core' package to address [CVE-2020-15228]
<https://github.com/avsm/setup-ocaml/releases/tag/v1.1.3>
[CVE-2020-15228] <https://github.com/advisories/GHSA-mfwh-5m23-j46w>
First release of FSML
═════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-first-release-of-fsml/6645/1>
jserot announced
────────────────
This is to announce the first public release of FSML, an OCaml library
for describing and describing synchronous finite state machines.
FSML is a simplified version of the library provided in the [Rfsm]
package for which
• the system is composed of a single FSM
• this FSM has a single, implicit, triggering event (typically called
the *clock* , hence the term *synchronous* used in the description)
The FSML library provides
• a type `Fsm.t' for describing FSMs
• possibly having *local variables*
• for which *transitions* , implicitely triggered by a clock, are
defined by a set of *boolean guards* and a set of *actions*
• a set of PPX extensions for building values of type `Fsm.t'
• functions for producing and viewing graphical representations of
FSMs in the `.dot' format
• functions for saving and reading FSM representations in files using
the JSON format
• functions for performing single or multi-step simulations of FSMs
and generating trace files in the `.vcd' format to be viewed by VCD
viewers such as [gtkwave]
• functions for generating C or VHDL code from a FSM representation
(for integration into existing
code and/or simulation)
FSML is available from [Github] or as an [OPAM package].
[Rfsm] <http://github.com/jserot/rfsm>
[gtkwave] <http://gtkwave.sourceforge.net/>
[Github] <https://github.com/jserot/fsml>
[OPAM package] <https://opam.ocaml.org/packages/fsml>
Qrc 0.1.0, a QR code encoder
════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qrc-0-1-0-a-qr-code-encoder/6647/1>
Daniel Bünzli announced
───────────────────────
QR codes are unsightly – a mirror of their specification. But they
enable all sorts of neat tricks now that scanners for them are in many
pockets.
Qrc generate them:
Qrc encodes your data into QR codes. It has built-in QR
matrix renderers for SVG, ANSI terminal and text.
Qrc is distributed under the ISC license. It has no
dependencies.
Homepage: <https://erratique.ch/software/qrc>
API docs: <https://erratique.ch/software/qrc/doc/> or `odig doc qrc'
Install: `opam install qrc'
cumulus 0.0.1
═════════════
Archive: <https://discuss.ocaml.org/t/ann-cumulus-0-0-1/6655/1>
Petter A. Urkedal announced
───────────────────────────
I would like to announce a new FRP library built on the React library.
The purpose of [cumulus] is to help organize code which work on
differential updates. The main type is the *cumulus signal*, which is
analogous to a react signal, except that information about the
difference from the previous value is provided to consumers along with
the new value, when the cumulus signal changes.
So, why does a cumulus signal provide both the state and the
difference to downstream signals? That is, what is the difference
between the following:?
┌────
│ type t1 = state * change React.E (* initial value and even of changes *)
│ type t2 = (state, change) Cumulus.t (* the cumulus signal *)
└────
The former type presumes that after the consumer has received the
initial state, it will only need to know what changes on successive
updates. This seems quite natural. It works well if, for instance,
we want to reconstruct a signal holding a set of strings, given an
initial set and a series of additions and removals:
┌────
│ module String_set = Set.Make (String)
│
│ type 'a set_patch = [`Add of string | `Remove of string]
│ type 'a update = 'a -> 'a
│
│ let patch_string_set : string set_patch -> String_set.t update = function
│ | `Add x -> String_set.add x
│ | `Remove x -> String_set.remove x
│
│ let integrate_strings (init, changes) =
│ React.E.fold (fun l p -> patch_string_set p l) init changes
└────
But what if we want to maintain a signal holding the intersection of
two sets of strings? If we try to lift the intersection operation to
work on patches, we discover that learning about the addition of an
element to left-hand set is not sufficient to determine whether the
element shall the added to the resulting set; we also need to know
whether the element is a member of the right-hand set. So, in this
case we would instead use cumulus signals:
┌────
│ let cu : (String_set.t, string set_patch) Cumulus.t = ...
│ let cv : (String_set.t, string set_patch) Cumulus.t = ...
│ let cuv =
│ let init u v = String_set.inter u v in
│ let patch (u, du) (v, dv) r' =
│ (match du, dv with
│ | None, Some x when String_set.mem x u ->
│ Cumulus.Patch (String_set.add x r', `Add1 x)
│ ...)
│ in
│ Cumulus.l2 ~init ~patch cu cv
└────
For the complete example, using integers instead of strings, see
[`test_isecn.ml'] from the testsuite.
(Footnote: If consumers know how to integrate the states they depend
on, they could in principle keep their own record of the full states
of the arguments. But this would be inefficient if there are many
consumers, and there is also a simplification of code and possibly
improved abstraction in letting the producer maintain its own state.)
Formally, we can understand the difference between `t1' and `t2' in
terms of calculus. For instance, the differential of a product
`d(x·y) = dx·y + x·dy' contains a mix of both the differentials and
values of the two variables. But if the expression is linear, only
differentials will will occur: `d(a·x + b·y + c) = a·dx + b·dy'. So,
when `t1' is sufficient, we are dealing with the analogue of a linear
function. The above example could be turned into a linear one by
making `Labels.t' a multiset type and considering the multiset union
operation.
Thus far we only considered purely functional code, but a cumulus
signal may chose to modify and return the same physical state during
an update. Also note when designing the differential component of the
cumulus signal, that we may exploit the fact the consumers also may
inspect the corresponding new state. Combining these two points, a
cumulus signal holding an array might have the type `('a array, [`Set
of int | `Resize of int])'. Here the state may be reused for ``Set'
and replaced for ``Resize'.
On a related not, there is also the [reactiveData] library which deals
with (linear) patching of containers.
I must also mention that there there is an [OCaml project with the
same name] (except casing). Sorry for not checking thoroughly in
advance. I hope it is not an issue in practise, otherwise there is
still time to rename while the library is fresh.
[cumulus] <https://github.com/paurkedal/ocaml-cumulus/>
[`test_isecn.ml']
<https://github.com/paurkedal/ocaml-cumulus/blob/master/tests/test_isecn.ml>
[reactiveData] <https://github.com/ocsigen/reactiveData>
[OCaml project with the same name] <https://github.com/Cumulus/Cumulus>
Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/5>
Continuing this thread, Yoann Padioleau asked Daniel Bünzli replied
───────────────────────────────────────────────────────────────────
What are the differences with the default bindings
provided in js_of_ocaml to the browser APIs (e.g., js.mli,
dom.mli, etc.)?
I'm not sure exactly what you are asking but:
1. If you are asking about the way API are exposed: `brr' does not
type JavaScript's objects as phantom types. It simply relies on
OCaml's abstract data types and plain functions. More about this
can be found in brr's [FFI manual] and [FFI cookbook].
2. If you are asking about binding coverage, you should be able to get
a sense of what is bound in `brr' [here].
Regarding 2. `brr''s coverage of more recent browser APIs is broader
and more consistent than in `js_of_ocaml' – Promise support, Fetch,
Service workers, Media capture APIs, WebGL2, Webcrypto, WebAudio,
etc. Conversly older APIs supported in `js_of_ocaml' may not supported
in `brr' (e.g. XMLHTTPRequest). Besides `brr''s coverage of some of
the DOM *element-specific* interfaces may be shallower than in
`js_of_ocaml'. There is however good coverage for the
[`HTMLMediaElement'], [`HTMLCanvasElement'], [`HTMLFormElement'] and
[`HTMLInputElement'] interfaces. For the rest the [attribute and
property API] and the occasional trivial FFI method binding should be
able to get you a long way.
[FFI manual] <https://erratique.ch/software/brr/doc/ffi_manual.html>
[FFI cookbook] <https://erratique.ch/software/brr/doc/ffi_cookbook.html>
[here] <https://erratique.ch/software/brr/doc/index.html#supported_apis>
[`HTMLMediaElement']
<https://erratique.ch/software/brr/doc/Brr_io/Media/index.html#el>
[`HTMLCanvasElement']
<https://erratique.ch/software/brr/doc/Brr_canvas/Canvas/index.html>
[`HTMLFormElement']
<https://erratique.ch/software/brr/doc/Brr_io/Form/index.html>
[`HTMLInputElement']
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ifaces>
[attribute and property API]
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ats_and_props>
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
[online].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <http://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>
[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>
[Alan Schmitt] <http://alan.petitepomme.net/>
[-- Attachment #2: Type: text/html, Size: 35020 bytes --]
next reply other threads:[~2020-10-27 8:44 UTC|newest]
Thread overview: 236+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 8:43 Alan Schmitt [this message]
-- strict thread matches above, loose matches on Subject: below --
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-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=87wnzchxdl.fsf@m4x.org \
--to=alan.schmitt@polytechnique.org \
--cc=caml-list@inria.fr \
--cc=comp@lists.orbitalfox.eu \
--cc=cwn@lists.idyll.org \
--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