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