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, 26 Nov 2019 09:33:35 +0100	[thread overview]
Message-ID: <> (raw)

[-- Attachment #1.1.1: Type: text/plain, Size: 28861 bytes --]


Here is the latest OCaml Weekly News, for the week of November 19 
to 26,

Table of Contents

tiny_httpd 0.1
v0.13 release of Jane Street packages
opam2nix (v1)
GitHub Actions for OCaml / opam now available
OCurrent 0.1 (CI/CD pipeline eDSL)
New pages for OCaml API
Irmin 2.0.0 release
Tail cascade: a new indentation style for some OCaml constructs

tiny_httpd 0.1

  Archive: <>

Simon Cruanes announced

  Hello and good morning, I'm pleased to announce that 
  [tiny_httpd] 0.1
  has been released and is on opam.

  The goal is to emulate python's standard `http.server' by 
  providing a
  0-dependencies, minimalist, simple HTTP server for embedding in
  applications that are not primarily a website, with very basic 
  (thanks to `Scanf'). A binary `http_of_dir' is also distributed 
  can be used to serve a directory, with optional upload of files.

[tiny_httpd] <>


  Archive: <>

Simon Cruanes announced


  │ let b =
  │   let open PrintBox in
  │   PrintBox_unicode.setup();
  │   frame @@ grid_l [
  │     [text "subject"; text_with_style Style.bold "announce: 
  printbox 0.3"];
  │     [text "explanation";
  │     frame @@ text {|PrintBox is a library for rendering nested 
  │     trees, and similar structures in monospace text or 
  │     [text "github";
  │     text_with_style Style.(bg_color Blue) 
  │     [text "contributors";
  │      vlist_map (text_with_style Style.(fg_color Green)) 
  ["Simon"; "Guillaume"; "Matt"]];
  │     [text "dependencies";
  │     tree empty
  │       [tree (text "mandatory")
  │ 	 [text "dune"; text "bytes"];
  │        tree (text "optional")
  │ 	 [text "uutf"; text "uucp"; text "tyxml"]]];
  │     [text "expected reaction"; text "🎉"];
  │   ]
  │ let () = print_endline @@ PrintBox_text.to_string b

  ([actual link to the release])

[actual link to the release]

v0.13 release of Jane Street packages


Xavier Clerc announced

  We are pleased to announce the v0.13 release of Jane Street 

  This release comes with 14 new packages, and a number of fixes 
  enhancements. The documentation for this release is available on 


  The remainder of this mail highlights the main changes since the 
  release; we hope it will be useful to developers in the process 
  migrating to the new version. A comprehensive changelog is 
  at the end.

Notable changes

  • Changed `Base', `Core_kernel', and `Core' functions to raise
    `Not_found_s' instead of `Not_found'.  `Hashtbl.find_exn' and
    `Map.find_exn' now include the key in their error message.

  • Changed `Core' and `Core_kernel' to export `int' comparison 
    than polymorphic comparison.

  • Removed the "robust" float comparison operators (`>.', `=.', 
    from the default namespace.

  • Replaced `sexp_*' types (`sexp_list', `sexp_option', 
    …) with preprocessor attributes (`[@sexp.list]', 
    `[@sexp.opaque]', …).

  • Changed `let%map' syntax from `let%map.Foo.Let_syntax' to

  • Added to `match%optional' support for specifying a path, so 
  you can
    write `match%optional.Foo foo_option' rather than `let open
    Foo.Optional_syntax in match%optional foo_option'.

  • Improved `Base.Backtrace' so that it enables recording of 
    in more situations, specifically when `OCAMLRUNPARAM' is 
    defined but
    doesn't mention the backtrace flag, `b'.

  • Added javascript support for `Zarith', `Bigint', `Bignum', and

  • Changed `Hashtbl.create''s default `size' from 128 to 0.

  • Changed `Core_kernel.Command' so that all commands accept 
    dash flags: `--help', `--version', and `--build-info'.

New packages

  • async_udp (<>): UDP 
    for Async.

  • async_websocket 
  (<>): A
    library that implements the websocket protocol on top of 

  • bonsai (<>): A library for
    building dynamic webapps, using Js_of_ocaml.

  • postgres_async 
    OCaml/async implementation of the postgres protocol (i.e., 
    does not
    use C-bindings to libpq).

  • ppx_cold (<>): Expands
    `[@cold]' into `[@inline never][@specialise never][@local 

  • ppx_pattern_bind 
    A ppx for writing fast incremental bind nodes in a pattern 

  • ppx_python (<>):
    `[@@deriving]' plugin to generate Python conversion functions.

  • ppx_yojson_conv 
    `[@@deriving]' plugin to generate Yojson conversion functions.

  • ppx_yojson_conv_lib
    (<>): Runtime 
    for `ppx_yojson_conv'.

  • pythonlib (<>): A 
  library to
    help writing wrappers around OCaml code for python.

  • sexp_select (<>): A 
    to use CSS-style selectors to traverse sexp trees.

  • timezone (<>): Time-zone

  • toplevel_backend 
    Shared backend for setting up toplevels.

  • zarith_stubs_js 
    Javascript stubs for the Zarith library.

Deprecations / Removals


  • Deprecated monadic `ignore' functions in favor of `ignore_m'.


  • Deleted `Array.replace' and `replace_all' functions, which 
  have been
    deprecated since before the last public release.

  • Deprecated `Result.ok_unit'; use `Ok ()'.

  • Removed the `Monad' and `Applicative' interfaces' `all_ignore'
    function; it was previously deprecated and replaced by 

  • Removed `List.dedup', which has been deprecated since 2017-04.

  • Removed `String' mutation functions, which have been 
  deprecated in
    favor of `Bytes' since 2017-10.

  • Deprecated `Array.truncate', `Obj_array.unsafe_truncate', and

  • Deprecated `Sys.argv', which has been superseded by 
    which is a function, reflecting the fact that `argv' can 
    change (as
    of OCaml 4.09).


  • Removed `Core_kernel.Std', which had been deprecated for a 

  • Deprecated type `Command.Spec.param' in favor of 

  • Removed `Hashtbl' functions that had been deprecated for 

  • Removed `Float.to_string_round_trippable', which has been 
    in favor of `to_string' since 2017-04.

  • Deprecated `Fqueue' functions where one should use `Fdeque' 
    `bot', `bot_exn', and `enqueue_top'.

  • Deleted `Bus.unsubscribes', which will be obviated by a 
    improvement to `Bus.unsubscribe'.


  • Removed the `alarm_upper_bound' function, which has been 
    for 6 months, and superseded by `max_allowed_alarm_time'.



  • Moved `Bounded_int_table' to a standalone library.

  • Moved the `Pool' and `Tuple_type' modules to a standalone 


  • Moved `Unix.Fd.replace' into a `Private' submodule.


  Please visit

opam2nix (v1)

  Archive: <>

Tim Cuthbertson announced

  Anouncing opam2nix (v1)

  [opam2nix] generates [nix] expressions from the [opam] OCaml 
  repository. It works similarly to [bundix], [node2nix], etc:

  You run an (impure) command to resolve all transitive dependency
  versions using the current opam repository, generating a .nix 
  that locks down the exact package sources and versions. Then 
  this file
  can be imported to provide `buildInputs' for building your ocaml
  project in nix.

  *What is nix and why would I care?* Well, that's a long story 
  but the
   headline benefits of nix are:

  • reproducible builds (if it builds for me, it builds for you)
  • stateless (you don't set up switches and then install 
  packages, each
    expression specifies everything it needs, and anything you 
    have is fetched/built on demand)
  • language agnostic (takes care of non-ocaml dependencies)

  It's sadly not a shallow learning curve, but those benefits are 
  to find elsewhere, so I obviously think it's worthwhile. So if 
  you use
  nix (or would like to), please give it a try and provide
  feedback. I'll (slowly) start working on upstreaming it into 

[opam2nix] <>

[nix] <>

[opam] <>

[bundix] <>

[node2nix] <>

GitHub Actions for OCaml / opam now available


Anil Madhavapeddy announced

  I was in the [GitHub Actions] beta program and forward ported my 
  to the latest version that just went public.  It's a pretty 
  simple way
  to get your OCaml code tested on Linux, macOS and Windows, 
  requiring an external CI service.  The action attempts to 
  provide a
  homogenous interface across all three operating systems, so 
  'opam' from subsequent actions should "just work".

  You can find it here:
  • In the GitHub Marketplace at
  • Source code on <>
  • Hello World usage on
  • Usage in ocaml-yaml:
    • An [example ocaml-yaml run]

  This should be considered fairly experimental as GH Actions is 
  so new.
  If you do use it, then consider [updating this issue with your 
  It does not current supporting caching yet, but is pretty fast 
  bootstrap (~4minutes).

  It also doesn't have any higher level purpose other than to set 
  up an
  opam environment, since most of the additional functionality 
  such as
  revdeps testing is planned for addition to the [ocurrent DSL].
  Nevertheless, this GH feature will hopefully be useful for 
  projects without a lot of computational requirements.  Let me 
  know how
  it goes!

  Windows is currently supported through @fdopen's excellent fork 
  uses Cygwin.  As Windows support is being mainlined into opam 
  at the moment, I'm hoping that we will gradually move over to 
  That should eventually remove the need for two separate
  opam-repositories, so I won't be adding any features that are 
  Linux or
  macOS-specific and do not work on the Cygwin version.

[GitHub Actions] <>

[example ocaml-yaml run]

[updating this issue with your usage]

[ocurrent DSL]

OCurrent 0.1 (CI/CD pipeline eDSL)


Thomas Leonard announced

  [OCurrent] 0.1 has just been released to opam-repository.

  OCurrent is an OCaml eDSL intended for writing build/test/deploy
  pipelines. It is being used as the engine for [ocaml-ci] and the
  [docker-base-images] builder (used to build the OCaml Docker 
  such as `ocurrent/opam:alpine-3.10-ocaml-4.08'). Other good uses 
  be building and redeploying a Docker service or a unikernel 
  its source repository changes. It can be run locally as a single 

  An OCurrent pipeline is written as an OCaml program, but the 
  engine ensures that it is kept up-to-date by re-running stages 
  their inputs change. A web UI is available so you can view your
  pipeline and see its current state.

  OCurrent can statically analyse the pipelines before they have 
  allowing it to run steps in parallel automatically and to 
  display the
  whole pipeline. It does this using a light-weight alternative to
  arrows, which doesn't require programming in an awkward 
  style. See [CI/CD Pipelines: Monad, Arrow or Dart?] for more 

  The basic functionality can be extended using "plugins" (just 
  OCaml libraries). Plugins are available for interacting with 
  Git, GitHub and Slack. These are in separate packages
  (e.g. `current_github') to avoid having the base package pull in 
  many dependencies).

  There is also an optional Cap'n Proto RPC interface, in the
  `current_rpc' opam package. This is used, for example, by 
  [citty] to
  provide a TTY interface to ocaml-ci.

  [The OCurrent wiki] contains examples, and documentation on the
  various plugins.

  Here's an example pipeline (from the base image builder):


[OCurrent] <>

[ocaml-ci] <>


[CI/CD Pipelines: Monad, Arrow or Dart?]

[citty] <>

[The OCurrent wiki] <>

Anil Madhavapeddy then added

  For those curious about the relation to the existing CI used in
  opam-repository, then it is no coincidence that @talex5 is the 
  of both :-)

  This DSL is the next iteration of the [datakit-ci], but 
  specialised to
  be faster and simpler for extending with OCaml and more complex
  workflows that our OCaml Platform tools need these days (like
  ocamlformat linting, or dune expect promotion, or odoc
  cross-referenced doc generation).  We are planning a smooth 
  next year over to the new system, but wanted to release this 
  early to
  show you some of the pieces going into this new iteration.  I am
  particularly excited about the new tty-based interface that 
  saves an
  awful lot of clicking around on web UIs for CI results…

[datakit-ci] <>

New pages for OCaml API


Continuing this thread, sanette announced

  I have uploaded a new version (same link
  • background color for links in the TOC @Maelan
  • more indentation for value descriptions @Maelan, @grayswandyr
  • word wrapping long `<pre>' codes @grayswandyr
  • type table: remove `(*' and `*)', give more space to code wrt
    comments, diminish comment's color @grayswandyr

  searching is not ready yet… please wait suggestions for dark 

sanette later added

  I have just uploaded a new version with a basic search engine.
  • for each page, you can search values/modules
  • in the general index page, the search includes also the 
  • search results are ranked by relevance

  the downside is that each page now comes with an index of about 
  in the form of an index.js file. I'm kind of hoping that the 
  will cache this, but I'm not sure. It would be maybe better to 
  load the index file on demand.

Irmin 2.0.0 release


Thomas Gazagnaire announced

  On behalf of the Irmin development team, I am very happy to 
  the release of Irmin 2.0.0, a major release of the Git-like
  distributed branching and storage substrate that underpins
  [MirageOS]. We began the release process for all the components 
  make up Irmin [back in May 2019], and there have been close to 
  commits since Irmin 1.4.0 released back in June 2018. To 
  this milestone, we have a new logo and opened a dedicated 

  More details here: 

[MirageOS] <>

[back in May 2019]

[] <>

Tail cascade: a new indentation style for some OCaml constructs


gasche announced

  I recently decided to change my indentation style for certain 
  constructs in a way that I'm going to describe below. I just 
  coined a
  name for this approach, "tail cascade". I'm creating this topic 
  convince everyone that this is a cool idea you should adopt as
  well. Or at least tolerate it when you review other people's 


  Programs that heavily use `match' often see a shift to the right 
  to nested indentation.

  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │   match bar x with
  │   | FooBar -> ...
  │   | Blah y ->
  │     match f y with
  │     | Some z ->
  │       ...

  Another problem with this style is that it suffers from the 
  bar" issue: if you try to add a new case for one of the exterior
  `match', it is parsed as belonging to the innermost `match'. 
  have been recommending (rightly) to use `begin match .. end' for 
  nested match constructs to avoid this issue.

  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │   begin match bar x with
  │   | FooBar -> ...
  │   | Blah y ->
  │     begin match f y with
  │     | None -> ...
  │     | Some z ->
  │       ...
  │     end
  │   (* now this is safe *)
  │   | FooBlah -> ...
  │   end

  But still the unpleasant shift to the right remains.

Proposal: cascading tail case

  We should in general use `begin match .. end' for nested 
  matches. But
  the "cascading tail case" proposal is to *not* do it for the 
  case of the pattern-matching, and instead *de-indent* (dedent) 
  last case – tail case.

  │ match foo with
  │ | Foo -> ...
  │ | Bar x ->
  │ match bar x with
  │ | FooBar -> ...
  │ | Blah y ->
  │ match f y with
  │ | None -> ...
  │ | Some z ->
  │ ...

  Note that with this indentation style, the "dangling match" 
  problem is
  also avoided: unlike with the original, non `end'-protected 
  the indentation makes it immediately obvious that any further 
  will be attached to the innermost match, and not any of the 

  A program using this "cascading tail" approach should always use
  `begin match .. end' for nested matches, except for a nested 
  returned within the last branch of an outer match, which can
  (optionally) be dedented instead.

  The choice to dedent the last case corresponds to encouraging a
  sequential reading of the program, where the other cases are
  "auxiliary cases" checked first and dispatched quickly, and the 
  case is the "main part" where the "rest" of the logic of the 
  lies. This pattern is typical of nested pattern-matching on the
  `option' or `result' type for example:

  │ match foo x with
  │ | Error err ->
  │   fail_foo_error err
  │ | Ok y ->
  │ match bar y with
  │ | Error err ->
  │   fail_bar_error err
  │ | Ok () ->
  │ ...

  Remark: it is *not* always the case that the `Error' constructor 
  the auxiliary case, and the `Ok' constructor is the main case;
  sometimes we implement fallback logic like "if `foo' work then 
  we are
  good, but otherwise we have to do this and that", and the error 
  is the most salient (and longer) part of the program logic. I 
  recommend being mindful, when you write code, of whether there 
  is a
  most convincing way to "sequentialize" it (distinguish auxiliary 
  main/tail case), and avoid using cascading tails when there is 
  clear sequentialization choice.

  Remark: some cases of tail cascades can be linearized by using a 
  definition of "bind" and a monadic style. This tends to be very
  limited however: it fixes one of the constructors to always be 
  "tail" constructor (always `Some', always `Ok'), and it only 
  when the handling of the other constructors is very homogeneous
  (typically: return directly). In real code, many situations 
  where the monadic style doesn't fit the problem, but tail 
  cascade does
  help writing a readable program.

Generalization: tail cascade

  While I have never seen cascading tail cases in real-world OCaml 
  before (I'm happy to be given pointers; I think that the idea is 
  new, but I'm not aware of previous attempts to give it a catchy 
  and spread the cascade love), this is in fact a new (to me) 
  of a common technique that is used for other OCaml constructs:

  │ if foo x then ...
  │ else if bar x then ...
  │ else ... (* this `tail else` was dedented *)
  │ let x = foo in
  │ let y = bar in (* this `tail let` was dedented *)
  │ ...            (* and the rest as well *)
  │ bind foo @@ fun x ->
  │ bind bar @@ fun y -> (* this "tail function body" was dedented 
  │ ...                  (* and the rest as well *)

  I would call "tail cascade" (or maybe: "cascading tail") the 
  idea of
  dedenting the "rest" of an OCaml expression (compared to a 
  tree-nesting-based approach) when it morally describes the 
  "rest" of
  the expression. I use the name "tail" because those expressions 
  almost always in tail-position in the sense of tail-calls.

  This general approach legitimizes some styles that I have seen, 
  sometimes used, in the wild, while at the same time considering 
  that I
  may have been doing something improper, for example:

  │ if foo then blah else
  │ ... (* dedented *)
  │ Fun.protect
  │   ~finally:(...)
  │ @@ fun () ->
  │ ... (* dedented *)
  │ try simple_approach with exn ->
  │ ... (* dedented *)
  │ 1 +
  │ 2 + (* dedented *)
  │ ... (* dedented *)

  Remark: after a `then' or `else', many people share the 
  view that any expression containing imperative constructs (`foo; 
  should be enclosed in a `begin .. end' block to avoid
  surprising-precedence issue. Just as for nested `match', this
  recommendation should be lifted for "tail else" constructs.

  Remark: The last example is a case where the dedented 
  expressions are
  *not* in tail-position from a runtime-evaluation point of view. 
  I am
  not sure as whether the two notions should be made to coincide 
  strongly, but in any case I'm not fond of the style in this 
  example, I prefer to move the infix operator to the beginning of 
  next line instead, following a different style and 

  The possibility this "cascading tail" style today crucially 
  relies on
  the nesting properties of open-ended syntactic constructs, 
  `let' (commonly cascaded), and now `match' and `if
  ... else'. Proposals to transition to a syntax where `match' and
  `else' are forced to take a closing marker are incompatible with 
  cascading style. I have not made my mind on whether this should 
  considered a blocker for those proposals, but at least it shows 
  having the open-ended form available has value for certain 

Louis Gesbert then said

  @gasche I prototyped a dedicated option in `ocp-indent', if 
  interested in trying it out :)
  │ opam pin 
  │ echo "match_tail_cascade=true" >> ~/.ocp-indent


  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 

  [Alan Schmitt]

[send me a message] <>

[the archive] <>

[RSS feed of the archives] 

[online] <>

[Alan Schmitt] <>

[-- Attachment #1.1.2: Type: text/html, Size: 50844 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

             reply	other threads:[~2019-11-26  8:33 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-26  8:33 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-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-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).