caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Alan Schmitt <>
To: "lwn" <>, "cwn"  <>,,
Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
Date: Tue, 08 Sep 2020 15:11:17 +0200	[thread overview]
Message-ID: <> (raw)

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


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

Table of Contents

OCaml 4.11.1: early bugfix release
textmate-language 0.1.0
Batteries v3.1.0
Job offer in Paris - Be Sport
Some SIMD in your OCaml
A PPX Rewriter approach to ocaml-migrate-parsetree
telltime - when is when exactly?
Ocamlunit emacs minor-mode
Sihl 0.1.0
promise_jsoo 0.1.0
Other OCaml News

OCaml 4.11.1: early bugfix release


octachron announced

  A serious bug has been discovered last week in OCaml 4.11.0: explicit
  polymorphic annotations are checked too permissively.  Some incorrect
  programs (possibly segfaulting) are accepted by the compiler in

  Programs accepted by OCaml 4.10 are unchanged.

  We are thus releasing OCaml 4.11.1 as an early bugfix version.  You
  are advised to upgrade to this new version if you were using OCaml

  It is (or soon will be) available as a set of OPAM switches with
  │ opam switch create 4.11.1

  and as a source download here:

  This bug was introduced when making polymorphic recursion easier to
  use. We are working on making the typechecker more robust and more
  exhaustively tested to avoid such issues in the future.

Bug fixes:

  • [#9856], [#9857]: Prevent polymorphic type annotations from
    generalizing weak polymorphic variables. (Leo White, report by
    Thierry Martinez, review by Jacques Garrigue)

  • [#9859], [#9862]: Remove an erroneous assertion when inferred
    function types appear in the right hand side of an explicit :>
    coercion (Florian Angeletti, report by Jerry James, review by Thomas

[#9856] <>

[#9857] <>

[#9859] <>

[#9862] <>

Rwmjones then said

  We've now got 4.11.1 in Fedora 33 & Fedora 34.  No apparent problems
  so far.

textmate-language 0.1.0


dosaylazy announced

  I am pleased to announce [textmate-language 0.1.0]. Textmate-language
  is a library for tokenizing code using TextMate grammars. Therefore,
  it may be useful for implementing syntax highlighters. Please report
  any bugs or API inconveniences you find.

[textmate-language 0.1.0]

Batteries v3.1.0

  Archive: <>

UnixJunkie announced

  OCaml Batteries Included is a community-maintained extended standard
  library for OCaml.

  The latest API can be found here:

  This minor release adds support for OCaml 4.11.  It has been available
  in opam for some days.

  Special thanks to all the contributors!

  The changelog follows:

  • Compatibility fixes for OCaml-4.11 [#962] (Jerome Vouillon)
  • BatEnum: added combination [#518] (Chimrod, review by hcarty)
  • fix benchmarks [#956] (Cedric Cellier)
  • BatFile: added count_lines [#953] (Francois Berenger, review by
    Cedric Cellier)
  • BatArray: use unsafe_get and unsafe_set more often [#947] (Francois
    Berenger, review by Cedric Cellier)
  • fix some tests for ocaml-4.10.0 [#944] (kit-ty-kate)
  • BatResult: BatPervasives.result is now equal to Stdlib.result
    instead of sharing constructors without being the same type [#939],
    [#957] (Clément Busschaert, Cedric Cellier).









Job offer in Paris - Be Sport


Vincent Balat announced

  Be Sport is looking to hire an OCaml developer with skills in

  • Mobile/web feature design
  • Team management
  • Use of Social networks

  She/he will take part in the development of our Web and mobile apps,
  entirely written in OCaml with Ocsigen, and participate in reflections
  on features.

  Please contact me for more information or send an email to

Some SIMD in your OCaml

  Archive: <>

Anmol Sahoo announced

  Fresh from a weekend of hacking, I would like to share some results of
  an experiment I conducted of creating a library for exposing Intel
  AVX2 intrinsics to OCaml code. AVX2 is an instruction set subset that
  adds data-parallel operations in hardware.

  I chose to fork the amazing [bigstringaf] library and modified it. You
  can find the additions to the code here - [bigstringaf_simd].

[bigstringaf] <>



  Given a type `Bigstring.t' (1 dimensional byte arrays) there now exist
  functions such as -
  │ val cmpeq_i8 : (t * int) -> (t * int) -> (t * int) -> unit
  So `cmpeq_i8 (x,o1) (y,o2) (z,03)' will compare 32 bytes starting at
  `o1' and `o2' from `x' and `y' respectively and store the result in
  `z' at `o3'.


  This was mainly an exercise in curiosity. I just wanted to learn
  whether something like this is viable.  I also want to see if adding
  some type-directed magic + ppx spells can let us write data parallel
  code much more naturally similar to what `lwt / async' did for async

  At the same time, you might ask - why not use something like Owl
  (which already has good support for data-parallel operations)? Apart
  from the fact that such libraries are oriented towards numerical code,
  I would also like to explore if we can operate directly on OCaml types
  and cast them into data parallel algorithms. Like how `simdjson'
  pushed the boundaries of JSON parsing, it would be nice to port
  idiomatic code to data-parallel versions in OCaml. Can we, at some
  point, have generic traversals of data-types, which are actually
  carried out in a data-parallel fashion?

Does it work?

  Given the limitation of the current implementation (due to foreign
  function calls into C), I still found some preliminary results to be
  interesting! Implementing the `String.index' function, which returns
  the first occurence of a char, the runtime for finding an element at
  the `n-1' position in an array with `320000000' elements is -
  │ serial: 1.12 seconds
  │ simd: 0.72 seconds (1.5x)
  I still have to do the analysis what the overhead of the function call
  into C is (even with `[@@noalloc]'!

Future directions

  It would be interesting to see, if we can create a representation
  which encapsulates the various SIMD ISA's such as AVX2, AVX512, NEON,
  SVE etc. Further more, it would be really interesting to see if we can
  use ppx to automatically widen `map` functions to operate on blocks of
  code, or automatically cast data types in a data parallel


  This was mostly a hobby project, so I cannot promise completing any
  milestones or taking feature requests etc. I definitely do not
  recommend using this in production, because of the lack of testing

A PPX Rewriter approach to ocaml-migrate-parsetree


Chet Murthy announced


  Based on `camlp5' and the `pa_ppx' PPX rewriters, I've written a new
  one, `pa_deriving_plugins.rewrite', that automates almost all the work
  of writing a migration from one version of OCaml's AST to another.
  1. It took a few days (b/c of laziness) to write the initial PPX
  2. A day to get 4.02->4.03 AST migration working
  3. a couple of hours to get 4.03->4.02 working
  4. and a few more hours to get 4.03<->4.04 and 4.04<->4.05 working

  At this point, I fully expect that the other version-pairs will not be

  You can find this code [warning: very much a work-in-progress] at

  The file `pa_deriving.plugins/' contains the
  source for the PPX rewriter.

  The directory `pa_omp' contains the migrations, typically named

A slightly longer-winded explanation

  If you think about it, `' isn't so different from what
  we need for `ocaml-migrate-parsetree'.  `', from a
  type definition for ~ 'a t~, will automatically generate a function
  │ map_t : ('a -> 'b) -> 'a t -> 'b t
  If you think about it, if we could just substitute our own type for
  the second occurrence of `t' (somehow …. yeah *grin*) then it would be
  almost like what we want for o-m-p, yes?

  With 11 versions of the Ocaml AST so far, maybe it's worth thinking
  about how to automate more of the migration task.  Also, since so much
  of it is type-structure-driven, one would think that it would be an
  excellent opportunity to apply PPX rewriting technology.  *Indeed, one
  might think that a good test of PPX rewriting, is the ability to
  automate precisely such tasks.*

  So what's hard about this migration task?  Here are some issues (maybe
  there are more):
  1. the types are slightly differently-organized in different versions
     of the AST.  Types might move from one module to another.
  2. sometimes new types are introduced and old ones disappear
  3. constructor data-types may get new branches, or lose them
  4. record-types may get new fields, or lose them
  5. sometimes the analogous types in two consecutive versions are just
     really, really different [but this is rare]: we need to supply the
     code directly
  6. when mapping from one version to another, sometimes features are
     simply not mappable, and an error needs to be raised; that error
     ought to contain an indication of where in the source that
     offending feature was found
  7. And finally, when all else fails, we might need to hack on the
     migration code directly

  But morally, the task is really straightforward (with problems listed

  1. use `ppx_import' to copy over types from each of the AST times of
     each Ocaml version
     • `ppx_import' works on `.cmi' files, and those have different
       formats in different versions of Ocaml.  Wouldn't it be nice if
       it worked on `.mli' files, whose syntax (b/c OCaml is
       well-managed) doesn't change much?
  2. build a single OCaml module that has all the AST types in it (from
     all the versions of OCaml)
     • but without the form
       │ type t = M.t = A of .. | B of ....
       that is, without the "type equation" that allows for a new
       type-definition to precisely repeat a previous one.
  3. Then use `ppx_import' against this single module to construct a
     recursive type-declaration list of all the AST types for a
     particular version of OCaml, and apply a "souped-up" version of to it, to map the types to *another* version of
     the AST types.
     • but `' doesn't do this today, and besides, it
       would have to provide a bunch of "escape hatches" for all the
       special-cases I mentioned above.

  But this is in principle doable, and it has the nice feature that all
  the tedious boilerplate is mechanically-generated from
  type-definitions, hence likely to not contain errors (assuming the PPX
  rewriter isn't buggy).

  So I decided to do it, and this little post is a result.


  I think this is a quite viable approach to writing
  `ocaml-migrate-parsetree', and I would encourage the PPX community to
  consider it.  One of the nice things about this approach, is that it
  relies *heavily* on PPX rewriting itself, to get the job done.  I
  think one of the important things we've learned in programming
  languages research, is that our tools need to be largely sufficient to
  allow us to comfortably implement those same tools.  It's a good test
  of the PPX infrastructure, to see if you can take tedious tasks and
  automate them away.

  I'm not going to describe anymore of how this works, b/c I'd rather
  get the rest of the migrations working, start figuring out how to
  test, and get this code integrated with camlp5.

  But for anybody who's interested, I'd be happy to interactively
  describe the code and walk them thru how it works.

Louis Roché then asked

  For a person who hasn't digged into OMP, can you explain how it is
  different from what is done currently? Because the idea I had of OMP
  is basically what you describe, a set of functions transformation an
  AST from vX to vX-1 and vX+1. So I am obviously missing something.

Chet Murthy replied

  Yes, you're right: imagine a series of modules M2…M11.  Each declares
  the same set of types, but with different definitions, yes?  Then
  you'd have migration modules, `migrate_i_j' (j=i+1 or j=i-1) that have
  functions that convert between the analogously-named types.  The
  entire question is: how are these functions implemented?  By hand?
  With significant mechanized support?  They can't be implemented
  fully-mechanically, because there are decisions to be made about how
  to bridge differences in type-definitions.  For instance, look at the
  4.02 type `label' and the 4.03 type `arg_label'.  Sometimes these are
  analogous (and sometimes they're not).  When they're analogous, the
  code that converts between -cannot- be automatically inferred: a human
  has to write it.  But -most- of the code of these migration functions
  can be inferred automatically from the type-definitions themselves.

  And that's really all that my little experiment does: automatically
  infer the migration code (most of the time) with some hints for those
  cases where it's not possible to automatically infer.

  Now, why would one do this?  Well, two reasons:

  1. it should be more maintainable to automatically generate most of
     the code from types, and it should be quicker to bring online a
     migration for a new version of the Ocaml AST.
  2. this should be a good test of PPX rewriting.  That is, if we're
     going to build a macro-preprocessing support system, shouldn't it
     be able to make solving such straightforward, but very tedious,
     problems much, much easier?

Chet Murthy then added

  I forgot to add a third reason why this PPX-rewriter-based approach is

  1. If you look at ocaml-migrate-parsetree "migrations", you'll find
     that they're almost all boilerplate code.  But sprinkled
     here-and-there, is actual logic, actual decisions about how to come
     up with values for new fields, about which fields, when non-trivial
     (e.g. not "[]") should lead to migration-failure, etc.  It is this
     code, that is the actual meat of the migration, and it's not at all
     obvious, when sprinkled thru the mass of mechanically-produclble

  A mechanized production of that boilerplate would mean that we
  retained explicitly only this nontrivial code, and hence for
  maintenance we could focus on it, and make sure it does the right

Josh Berdine asked

  Figuring out ways to make maintaining this stuff more efficient would
  be great! One aspect that isn't clear to me is how this approach
  compares to the process currently used to generate the omp code. I
  haven't done it myself, but at first glance the tools to generate the
  omp code (e.g. gencopy) seem to also accurately be describable as
  heavily using ppx infrastructure in order to implement the map code
  from one version to another. Is there an executive summary that
  compares and contrasts that and this proposal?

Chet Murthy replied

  From the README, gencopy is used to generate a prototype file for each
  migration, and then a human goes in and fixes up the code.  A way to
  put my point is: gencopy should be provided the fixups in some compact
  form, and apply them itself.

telltime - when is when exactly?


Darren announced

  I'm happy to announce release of [telltime] 0.0.1, a small cli tool
  for interacting with Daypack-lib (a schedule, time, time slots
  handling library) components.

  It primarily answers time related queries, with support for union
  (`||'), intersect (`&&') and "ordered select" (`>>', explanation of
  this is at the bottom).

  The query language, time expression, aims to mimic natural language,
  but without ambiguity. The grammar is only documented in the online
  demo [here] at the moment.

  Some examples copied from the README are as follows.

[telltime] <>

[here] <>

Search for time slots matching Daypack time expression

  "Hm, I wonder what years have Febuary 29th?"

  │ $ telltime search --time-slots 5 --years 100 "feb 29 00:00"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 03 19:24:15
  │ Matching time slots (in above time zone):
  │ [2024 Feb 29 00:00:00, 2024 Feb 29 00:00:01)
  │ [2028 Feb 29 00:00:00, 2028 Feb 29 00:00:01)
  │ [2032 Feb 29 00:00:00, 2032 Feb 29 00:00:01)
  │ [2036 Feb 29 00:00:00, 2036 Feb 29 00:00:01)
  │ [2040 Feb 29 00:00:00, 2040 Feb 29 00:00:01)

  "Would be handy to know what this cron expression refers to"
  │ $ telltime search --time-slots 5 "0 4 8-14 * *"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 06 17:39:56
  │ Matching time slots (in above time zone):
  │ [2020 Sep 08 04:00:00, 2020 Sep 08 04:01:00)
  │ [2020 Sep 09 04:00:00, 2020 Sep 09 04:01:00)
  │ [2020 Sep 10 04:00:00, 2020 Sep 10 04:01:00)
  │ [2020 Sep 11 04:00:00, 2020 Sep 11 04:01:00)
  │ [2020 Sep 12 04:00:00, 2020 Sep 12 04:01:00)

  "I have a bunch of time ranges, but some of them overlap, and they are
  not in the right order. If only there is a way to combine and sort
  them easily."

  │ $ telltime search --time-slots 1000 "2020 . jan . 1, 10, 20 . 13:00 to 14:00 \
  │   || 2019 dec 25 13:00 \
  │   || 2019 dec 25 10am to 17:00 \
  │   || 2020 jan 5 10am to 1:30pm \
  │   || 2020 . jan . 7 to 12 . 9:15am to 2:45pm"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 06 18:01:12
  │ Matching time slots (in above time zone):
  │ [2019 Dec 25 10:00:00, 2019 Dec 25 17:00:00)
  │ [2020 Jan 01 13:00:00, 2020 Jan 01 14:00:00)
  │ [2020 Jan 05 10:00:00, 2020 Jan 05 13:30:00)
  │ [2020 Jan 07 09:15:00, 2020 Jan 07 14:45:00)
  │ [2020 Jan 08 09:15:00, 2020 Jan 08 14:45:00)
  │ [2020 Jan 09 09:15:00, 2020 Jan 09 14:45:00)
  │ [2020 Jan 10 09:15:00, 2020 Jan 10 14:45:00)
  │ [2020 Jan 11 09:15:00, 2020 Jan 11 14:45:00)
  │ [2020 Jan 12 09:15:00, 2020 Jan 12 14:45:00)
  │ [2020 Jan 20 13:00:00, 2020 Jan 20 14:00:00)

Get exact time after some duration from now

  │ $ telltime from-now "1 hour"
  │ Now                   : 2020-09-03 15:53:29
  │ Duration (original)   : 1 hour
  │ Duration (normalized) : 1 hours 0 mins 0 secs
  │ Now + duration        : 2020-09-03 16:53:29

  │ $ telltime from-now "1.5 days 2.7 hours 0.5 minutes"
  │ Now                   : 2020-09-03 15:55:43
  │ Duration (original)   : 1.5 days 2.7 hours 0.5 minutes
  │ Duration (normalized) : 1 days 14 hours 42 mins 30 secs
  │ Now + duration        : 2020-09-05 06:38:13

Difference between ordered select and union

  `s1 >> s2' is similar to `s1 || s2', but `>>' picks between s1 and s2
  in a round robin fashion, instead of just picking the smallest between

  One specific differing case would be when the search starts at 4pm
  today, `3pm || 5pm' would return 5pm today and 3pm tomorrow, and so
  on, while `3pm >> 5pm' would return 3pm tomorrow and 5pm tomorrow (a
  5pm is only picked after a 3pm has been picked already).

Ocamlunit emacs minor-mode


Manfred Bergmann announced

  Here is a first version of this plugin that allows running `dune test'
  with an Emacs key stroke.  It shows the test result in a separate
  buffer and a simple colorized status 'message'.


  While it is possible to run `dune' in 'watch' mode I'd like to
  manually run tests.

  I didn't find a way to specify individual test modules in `dune'. Is
  that possible?

Sihl 0.1.0

  Archive: <>

jerben announced

  I am happy to announce this milestone release of Sihl, a web framework
  for OCaml.

  Github: <>
  opam: <>

  Sihl is really just a collection of services that can be plugged into
  each other and a tiny core that knows how to start them. The goal is
  to take care of infrastructure concerns so you can focus on the

  After many iterations, the API is in a shape where we dare to show it
  to you :slight_smile: It is still under heavy development so expect
  breakage without a major version bump. However, we just finished
  migrating a project from Reason on NodeJS to OCaml on Sihl, so we use
  it in production.

  We provide service implementations that were useful to us so far. In
  the future we want to provide many more to cover all kinds of
  needs. (PRs are always welcome!)

  Any feedback is greatly appreciated, thanks! :)

jerben then added

  Here is an example of a tiny Sihl app:

  │ module Service = struct
  │   module Random = Sihl.Utils.Random.Service
  │   module Log = Sihl.Log.Service
  │   module Config = Sihl.Config.Service
  │   module Db = Sihl.Data.Db.Service
  │   module MigrationRepo = Sihl.Data.Migration.Service.Repo.MariaDb
  │   module Cmd = Sihl.Cmd.Service
  │   module Migration = Sihl.Data.Migration.Service.Make (Cmd) (Db) (MigrationRepo)
  │   module WebServer = Sihl.Web.Server.Service.Make (Cmd)
  │   module Schedule = Sihl.Schedule.Service.Make (Log)
  │ end
  │ let services : (module Sihl.Core.Container.SERVICE) list =
  │   [ (module Service.WebServer) ]
  │ let hello_page =
  │   Sihl.Web.Route.get "/hello/" (fun _ ->
  │       Sihl.Web.Res.(html |> set_body "Hello!") |> Lwt.return)
  │ let routes = [ ("/page", [ hello_page ], []) ]
  │ module App = Sihl.App.Make (Service)
  │ let _ = App.(empty |> with_services services |> with_routes routes |> run)

promise_jsoo 0.1.0

  Archive: <>

Max LANTAS announced

  Hello! I am announcing the first release of `promise_jsoo', a library
  for JS promises in Js_of_ocaml.


  The library has bindings to the core `Promise' methods as well as
  helper functions that make it easier to deal with a `Promise' of an
  `option' or `result'. It is also possible to use this library with
  [gen_js_api] to make for an easier JavaScript binding experience

  Inspired by [aantron/promise], this library also uses indirection
  internally when handling nested promises in order to ensure that the
  bindings are type safe.

  This project is part of ongoing work to port [vscode-ocaml-platform]
  to Js_of_ocaml.

  Generated documentation can be found [here].

[gen_js_api] <>




Other OCaml News

>From the ocamlcore planet blog

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Announcing Signals and Threads, a new podcast from Jane Street]

[OCaml Planet] <>

[Announcing Signals and Threads, a new podcast from Jane Street]


  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

  If you also wish to receive it every week by mail, you may subscribe

  [Alan Schmitt]

[send me a message] <>

[the archive] <>

[RSS feed of the archives] <>

[online] <>

[Alan Schmitt] <>

[-- Attachment #2: Type: text/html, Size: 48472 bytes --]

             reply	other threads:[~2020-09-08 13:11 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 13:11 Alan Schmitt [this message]
  -- strict thread matches above, loose matches on Subject: below --
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-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:

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

  git send-email \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).