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, 23 Jul 2024 15:30:57 +0200	[thread overview]
Message-ID: <m2ed7k44mm.fsf@mac-03220211.irisa.fr> (raw)

[-- Attachment #1: Type: text/plain, Size: 17749 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of July 16 to 23,
2024.

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

A Tour of the Living Library – A Safer FFI
first release of rpmfile
Dune dev meeting
Fighting Mutation with Mutation in Living
A small extension of Bigarray.Genarray adding iteration, mapping and folding
cudajit: Bindings to the `cuda' and `nvrtc' libraries
Rpmfile 0.2.0 - changelog
Exploring the Docusaurus+Odoc combo
Mopsa 1.0 – Modular Open Platform for Static Analysis
OCaml 5 performance
Other OCaml News
Old CWN


A Tour of the Living Library – A Safer FFI
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-a-tour-of-the-living-library-a-safer-ffi/14981/1>


Matt Walker announced
─────────────────────

  I've written a new blog post on the `living' library I announced a few
  days ago.  Please give it a read if you're interested in safe use of
  Ctypes, or otherwise need lifetime management in OCaml.

  Would love to hear your views in this thread!

  <https://fizzixnerd.com/blog/2024-07-17-touring-the-living-library/>


first release of rpmfile
════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985/1>


Mikhail announced
─────────────────

  I'm happy to announce the first release of [rpmfile], a small library
  for reading meta information from RPM packages (version 3.0). It uses
  the Angstrom combinator parser library, which allows it to perform
  streaming parsing using Lwt or Async.

  How to get a package summary:
  ┌────
  │ module Rpm_reader = Rpmfile.Reader (Rpmfile.Selector.All)
  │ 
  │ let metadata = Rpm_reader.of_file_exn "hello-2.12.1-1.7.x86_64.rpm"
  │ 
  │ Rpmfile.summary metadata
  │ (* - : string = "A Friendly Greeting Program" *)
  └────

  The default reader module can read from a string or file, but has poor
  performance. It needs a selector module to select the tags to
  parse. The example uses `Selector.All' to parse all tags.

  I am developing this library for my pet project to create a
  self-hosted RPM repository management solution.

  Thank you for your attention!


[rpmfile] <https://github.com/dx3mod/rpmfile>


Dune dev meeting
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/1>


maiste announced
────────────────

  We are organizing a new public Dune dev meeting on *Wednesday, July,
  24th at 10am CET*. It will be one hour long.

  Whether you are a maintainer, a regular contributor, a new joiner or
  just curious, feel free to join! The goal of these meetings is to
  provide a place to discuss the ongoing work together :smile: Below,
  you can find the agenda for this meeting:


:scroll: Agenda
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Quick presentation about the attendees.
  • Presentation about the ongoing work in Dune.
  • Questions and Answers.
  • Information discussions


:chains: Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Meeting link: [zoom]
  • Calendar event: [google calendar]
  • Wiki with information and previous notes: [GitHub Wiki]


[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>

[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>

[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>


Fighting Mutation with Mutation in Living
═════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/blog-fighting-mutation-with-mutation-in-living/15003/1>


Matt Walker announced
─────────────────────

  New blog post about fixing the mistakes in the `living' library.
  Please take a look if you're interested in interfacing ocaml with
  external resources.

  <https://fizzixnerd.com/blog/2024-07-21-fixing-living/>

  In particular, I think the library comes good with its guarantees now
  that
  1. if every function is properly dependent, and
  2. you only `unsafe_free' values that are disjoint from their
     dependencies, then
  you will obtain a sound program when using the Ctypes ffi, in terms of
  there being no use-after-free errors.

  Please let me know if you disagree!


A small extension of Bigarray.Genarray adding iteration, mapping and folding
════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-a-small-extension-of-bigarray-genarray-adding-iteration-mapping-and-folding/15005/1>


NAlec announced
───────────────

  I needed a few functions which were missing in the [OCaml library :
  Bigarray.Genarray], and decided to write them for my own purpose :
  • Iteration on genarrays
  • mapping on genarrays
  • folding on genarrays

  Today I believe this can be usefull for others, and may suffer a code
  inspection as I am not that experienced in OCaml. I am ready to have
  this piece of code evolve if it is usefull so even (and maybe first) a
  feedback on the usefullness of such code is welcome.

  The only alternative I was given was the famous Owl library, which was
  way to heavy for my needs, and not easily usable (if not
  understandable). This extension is very simple, it is its
  strenght. Ultimately, it could be merged in the standard library …
  maybe after some work indeed : you tell me.

  There is a clean documentation I guess, hope this can help :
  [GenArrayIter]

  Looking forward to hearing from you all.


[OCaml library : Bigarray.Genarray]
<https://ocaml.org/manual/5.2/api/Bigarray.Genarray.html>

[GenArrayIter] <https://github.com/Heyji2/GenArrayIter>


cudajit: Bindings to the `cuda' and `nvrtc' libraries
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-cudajit-bindings-to-the-cuda-and-nvrtc-libraries/15010/1>


Lukasz Stafiniak announced
──────────────────────────

  Hi! I'm happy to share cudajit 0.4.0: manually-selected bindings for
  Nvidia GPU programming. cudajit should soon propagate to the opam
  repository.  [Bindings to the `cuda' and `nvrtc' libraries with a
  unified interface] [API documentation] Currently supported:

  • Compiling a kernel with conversion to PTX, launching a kernel.
  • Synchronous and asynchronous memory copying.
  • Contexts and streams.
  • (GPU) device attributes.

  Currently not supported:

  • Events.
  • CUDA graph features.
  • Cooperative kernel launch.

  Let me know your needs so I can prioritize. PRs are also welcome!


[Bindings to the `cuda' and `nvrtc' libraries with a unified interface]
<https://github.com/lukstafi/ocaml-cudajit>

[API documentation]
<https://lukstafi.github.io/ocaml-cudajit/cudajit/Cudajit/index.html>


Rpmfile 0.2.0 - changelog
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985>


Mikhail announced
─────────────────

  Hello again, everyone. :wave: Today I want to tell you about what has
  changed in a new version of my [rpmfile] library ([previous topic])
  for reading meta-information from RPM packages.Should I post this in
  the forum? I'm sorry.


[rpmfile] <https://github.com/dx3mod/rpmfile>

[previous topic]
<https://discuss.ocaml.org/t/ann-first-release-of-rpmfile/14985>

Changes
╌╌╌╌╌╌╌

  • Fixed incorrect string parsing. I just forgot to make `advance'
    after `take_till' ([commit]);
  • `angstrom-unix' is used by default to read files in the `Reader'
    module functions. Previously, a RPM package was read entirely into
    memory;
  • Optimized partial parsing of [header sections]. Reduced unnecessary
    memory allocations ([commit]);
  • Decoding integers (int8/int16/int32/int64) to *native int* in access
    functions[^1] (like `Rpmfile.payload_size'). You can also use `get'
    to get "raw" values;
  • Improved compatibility with 4.0 version of RPM format by using
    *native int*;
  • Added a module `Selector.Base' to select only basic package info
    ([commit]);
  • Some new access functions and output fields of the CLI utility.


[commit]
<https://github.com/dx3mod/rpmfile/commit/3b01a3436a15d497ea2e4b94611108555189ff3b>

[header sections]
<https://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/pkgformat.html#AEN26581>

[commit]
<https://github.com/dx3mod/rpmfile/commit/2121190f59fc80cfedea9043ad13b440aa60f0d0>

[commit]
<https://github.com/dx3mod/rpmfile/commit/c4baf2fcc72965936bf2dea13abd1a096826b67d>


rpmfile vs rpm -qi
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Not a real "benchmark" for parsing 1.5 GB packages.

  ┌────
  │ $ time rpm -qi repo/*.rpm
  │ Executed in  226.82 millis    fish           external
  │    usr time  212.74 millis    1.06 millis  211.68 millis
  │    sys time   13.23 millis    0.00 millis   13.23 millis
  │ 
  │ $ time rpmfile repo/*.rpm
  │ Executed in  153.97 millis    fish           external
  │    usr time  116.74 millis    0.00 millis  116.74 millis
  │    sys time   30.65 millis    1.47 millis   29.18 millis
  └────

  Rpmfile doesn't verify signatures, which is why it is "faster".


What's next?
╌╌╌╌╌╌╌╌╌╌╌╌

  This is enough for my tasks, so there probably won't be a next release
  :cold_face:

  To-Do: functionality to work with signatures, read payload, implement
  writer module for create packages.

  Thank you for your attention!

  P.S. I also want to apologize for my terrible English.

  [^1]: The access function gets and decodes values from a `metadata'
  record.


Exploring the Docusaurus+Odoc combo
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/exploring-the-docusaurus-odoc-combo/15012/1>


Mathieu Barbin announced
────────────────────────

  To OCaml & Docusaurus enthusiasts out there :camel:+ :sauropod:

  Some time ago, I shared my experience using Docusaurus to document an
  OCaml project, highlighting the integration between Docusaurus,
  ocaml-mdx, and the dune workflow (previous post [here]).

  Today I wanted to share that I've resumed this exploration in
  documentation tools to try and integrate odoc-generated pages into
  Docusaurus, with the aim of creating a somewhat minimal
  template/example for this.

  I've published my experiment here:
  [https://mbarbin.github.io/doc-experiment-docusaurus/].

  Integrating odoc posed challenges - I've written about the (pragmatic)
  approach I took [here]. I'm linking this [odoc issue] too, for
  reference about exploring more native solutions for this interop.

  Have you too tried this "magic combo" of Docusaurus, Odoc, and OCaml
  tools? And if so, how did you approach it? Do you have insights or
  suggestions? If this sparks your curiosity, please don't hesitate to
  engage with the repository.


[here]
<https://discuss.ocaml.org/t/using-docusaurus-to-document-an-ocaml-project/13359>

[https://mbarbin.github.io/doc-experiment-docusaurus/]
<https://mbarbin.github.io/doc-experiment-docusaurus/>

[here] <https://mbarbin.github.io/doc-experiment-docusaurus/docs/odoc/>

[odoc issue] <https://github.com/ocaml/odoc/issues/121>


Mopsa 1.0 – Modular Open Platform for Static Analysis
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mopsa-1-0-modular-open-platform-for-static-analysis/15013/1>


Raphaël Monat announced
───────────────────────

  On behalf of all its developers, I am glad to announce the release of
  [Mopsa 1.0]! You can just `opam install mopsa'.

  Mopsa stands for Modular and Open Platform for Static Analysis. It
  aims at easing the development and use of static analyzers. More
  specifically, Mopsa is a generic framework for building sound static
  analyzer based on the theory of abstract interpretation. Mopsa is
  independent of language and abstraction choices. Developers are free
  to add arbitrary abstractions (numeric, pointer, memory, etc.) and
  syntax iterators for new languages. Mopsa encourages the development
  of independent abstractions which can cooperate or be combined to
  improve precision.

  Mopsa currently support the analysis of Python, C and Python+C
  programs. It reports run-time errors on C programs and uncaught
  exceptions on Python programs. Our benchmarks provide an illustrative
  overview of what Mopsa can currently analyze. All analyses currently
  provided are flow and context-sensitive (i.e, control-flow operators
  are taken into account by the analysis, and functions are analyzed by
  virtual inlining). The C analysis is actively developed and
  maintained. The Python and Python+C analyses work on real-world
  examples, but are not actively developed.

  Please note that Mopsa is an academic tool under development. Feel
  free to submit [issues] if you encounter any bug!

  Additional resources:
  • [user manual]
  • [demo of our abstract debugger]
  • [academic overview of Mopsa], and [in a PhD thesis]
  • [coreutils benchmarks on which Mopsa can run]


[Mopsa 1.0] <https://gitlab.com/mopsa/mopsa-analyzer/>

[issues]
<https://gitlab.com/mopsa/mopsa-analyzer/-/issues/?sort=created_date&state=opened&first_page_size=50>

[user manual] <https://mopsa.gitlab.io/mopsa-analyzer/user-manual/>

[demo of our abstract debugger]
<https://rmonat.fr/talk/240606_csv/#interactive-engine-demo>

[academic overview of Mopsa]
<https://hal.sorbonne-universite.fr/hal-02890500v1/document>

[in a PhD thesis]
<https://rmonat.fr/data/pubs/2021/thesis_monat.pdf#page=61>

[coreutils benchmarks on which Mopsa can run]
<https://gitlab.com/mopsa/benchmarks/coreutils-benchmarks>


OCaml 5 performance
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-5-performance/15014/1>


Thomas Leonard announced
────────────────────────

  I've been trying out some tools to investigate performance problems in
  my OCaml programs and I've written up my experiences here in case
  other people find it useful:

  • <https://roscidus.com/blog/blog/2024/07/22/performance/>
  • <https://roscidus.com/blog/blog/2024/07/22/performance-2/>

  The first post examines a case of slow IO in a concurrent Eio program,
  and the second looks at poor GC performance in a multicore app.

  In particular, it seems that minor GC performance is very sensitive to
  other work running on the machine, since any domain being late will
  trigger the others to sleep, e.g.

  <https://global.discourse-cdn.com/business7/uploads/ocaml/original/2X/e/e821895b934f9519f84d0e52f28057bb30274092.png>

  I'd be interested to know if others can shed more light on this, or
  have other profiling tools they've found useful.


Other OCaml News
════════════════

From the ocaml.org blog
───────────────────────

  Here are links from many OCaml blogs aggregated at [the ocaml.org
  blog].

  • [OCaml 5 performance part 2]
  • [OCaml 5 performance problems]
  • [OCaml Compiler Manual HTML Generation]


[the ocaml.org blog] <https://ocaml.org/blog/>

[OCaml 5 performance part 2]
<https://roscidus.com/blog/blog/2024/07/22/performance-2/>

[OCaml 5 performance problems]
<https://roscidus.com/blog/blog/2024/07/22/performance/>

[OCaml Compiler Manual HTML Generation]
<https://tarides.com/blog/2024-07-17-ocaml-compiler-manual-html-generation>


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

             reply	other threads:[~2024-07-23 13:31 UTC|newest]

Thread overview: 236+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 13:30 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-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=m2ed7k44mm.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