OCaml Weekly News

Previous Week Up Next Week


Here is the latest OCaml Weekly News, for the week of October 05 to 12, 2021.

Table of Contents

Release of ocaml-sf/learn-ocaml:0.13.0

Erik Martin-Dorel announced

We are very pleased to announce the immediate availability of the latest stable release of Learn-OCaml, version 0.13.0.

Many thanks to all users and developers that reported bugs, contributed features or patches ✨ and in particular, special thanks go to @yurug and @AltGr for their precious advice and help during the preparation of this release.

A (mostly) comprehensive list of the features, fixes, and enhancements offered by this release is available in the Release Notes.

Beyond this list of changes, note that:

  • We now switch to semantic versioning, so that this version is git-tagged v0.13.0 and not just 0.13.
  • The REST API did not change (between the previous stable version 0.12 and version 0.13.0).
  • The "exodir" format has been slightly extended (but the documentation online of these changes is not yet up-to-date), keeping a strong focus on backward-compatibility (see e.g. PR #397 for related remarks).
  • All the main binaries of Learn-OCaml (learn-ocaml-client, learn-ocaml, and the native learn-ocaml-server) are now statically built and available in the Release page, for Linux and macOS.
  • The whole codebase of Learn-OCaml has been ported to OCaml 4.12 (including the toplevel environment that is exposed to students).
  • We now relax the coupling between client/server, and commit to keeping backward-compatibility for the latest learn-ocaml-client w.r.t. the previous versions (so, learn-ocaml-client.0.13.0 can interact with servers learn-ocaml.{0.12, 0.13.0} smoothly − see PR #426 for context).
  • The learn-ocaml-client CLI API did not change, except that a command learn-ocaml-client server-version has been added, to distinguish between the server version and the (possibly more recent) learn-ocaml-client --version (see PR #429 for details).
  • Docker images are still available on Docker Hub, e.g., to easily spin a local server from a repository exercises, you can do:

    sudo docker run --name=server-test -v "$PWD/demo-repository:/repository:ro" \
      -p 8080:8080 ocamlsf/learn-ocaml:0.13.0

    More details on the Docker setup can be found in How to deploy a learn-ocaml instance.

  • (If you migrate from 0.12 to 0.13.0 in your deployments, beware that the mere bump of OCaml's version may cause some of your graders to fail.)
  • A dedicated PR has also been opened in opam-repository.
  • As noted above, several architectural changes have been done about the learn-ocaml-client as this tool plays a

key "pivot" role, for students that would like to use Tuareg+Merlin+learn-ocaml-mode and interact with a Learn-OCaml server backend directly from Emacs (and thus benefit from the advantages of both Merlin and Learn-OCaml's exercise grading feature).

We hope to be able to release 0.14.0 soon, specifically to integrate the pending PR #372 that will solve a long-running issue with auto-Sync and students-code overwriting; and we also plan to extend learn-ocaml's backend and REST API soon to further enhance the UX of learn-ocaml.el, at least to lift this limitation (for which we have a working proof-of-concept to be refined).

If need be, feel free to open issues in the Learn-OCaml bug tracker (GH) or post in this thread to share thoughts or experience-feedback.

Release of odoc 2.0.0

Jon Ludlam announced

Hot on the heels of the OCaml 4.13 announcement(s!), the odoc team is pleased to announce the release of odoc 2.0.0!

tl;dr: The new version produces much better output than the old version, it's the engine at the core of the package docs in v3.ocaml.org, and it also has a new website.

This release has been a long time coming – years! – and contains several notable improvements over the odoc 1.5 series: a new language model, a new rendering layer allowing output in several formats, and improved control over the output structure.

New Features

New Language Model

The internal library used by odoc that models the OCaml module system has been completely rewritten over a multi-year effort by @jonludlam and @Julow, according to a design by @lpw25. The rewrite gives odoc a much better understanding of the module system compared to the original implementation. This library is used for two main processes:

  1. To perform expansions, which is the process where odoc takes complex module type expressions like this one from tyxml:

    module Make
        (Xml : Xml_sigs.T with type ('a, 'b) W.ft = 'a -> 'b)
        (Svg : Svg_sigs.T with module Xml := Xml)
      : Html_sigs.Make(Xml)(Svg).T
        with type +'a elt = Xml.elt
         and type +'a attrib = Xml.attrib

    Then turns it into an output page containing the correct types, values, modules, includes, and documentation.

  2. To perform resolutions, which is where odoc handles complex paths found in OCaml source in order to calculate the correct definition link. For example, in the following snippet:

    module type A = sig
      module M : sig module type S end
      module N : M.S
    module B : sig module type S = sig type t end end
    module C : A with module M = B with type N.t = int
    type t = C.N.t

    resolution is the process by which odoc determines which documentation page to take you when you click on C.N.t.

The new model has logic to handle many features of the OCaml language, as can be explored here.

A particularly important improvement is in handling canonical modules (explained in the link above). The upshot of this is that there should never be any more odd double underscores leaking into your docs!

For some more info on this, as well as the new output renderers, see our talk at the OCaml workshop last year

New Output Renderers

@Drup put a considerable amount of work into replacing the odoc 1.5 custom HTML generator with a new rendering layer. This features a new intermediate format allowing new output formats to be added far more easily than before.

Included in odoc 2.0 are renderers for HTML and man pages (both contributed by @Drup) and LaTeX (contributed by @Octachron). The LaTeX renderer has already been integrated into the OCaml build process to generate docs (see https://github.com/ocaml/ocaml/pull/9997 and related PRs). @jonludlam also made an alternative HTML renderer designed specifically for v3.ocaml.org. Finally, a new markdown renderer is being prepared by @lubega-simon and should land in the next release.

We look forward to many new renderers being created for the varied use cases present in the community!

Output Structure

odoc 2.0 introduces a new mechanism to specify the structure of the files produced. Although it's a relatively simple new feature, it nevertheless has enabled odoc to be used in new ways. In particular, it has allowed odoc to construct the package documentation for the new OCaml website, v3.ocaml.org. There is also an example driver, showing how odoc can be used to construct a stand-alone website for an OCaml package that contains fully-linked documentation for a package and all of its dependencies. This has been used to create odoc's new website.

New Drivers

Like the OCaml compiler itself, running odoc on your code requires careful sequencing of the invocations to produce the correct result. Fortunately both dune and odig understand how to do this, so most users don't need to know the details. If you want more than these tools provide though, we've written a simple reference driver, documenting exactly what's necessary to use odoc to produce rich documentation. A more complete (and more complex) example is the tool voodoo, which is being used to create the docs for v3.ocaml.org.


As previously posted, the new version of the OCaml website has been under development for some time now, and an important new feature is the integration of package listings, including documentation for every version of every package. More has been written about this elsewhere, but it's important to note that the new OCaml.org website required a preview version of odoc 2.0 to work. We've made a few bug fixes since then, so we will update the pipeline to use the released version very soon. For more info on the pipeline to build the docs, see our recent talk at this year's OCaml Workshop.

New Website

The website for odoc has been improved with guides for documentation authors, integrators, and contributors. This site is intended to grow over time with more content to help people write docs for their packages.


This release, particularly because of the new output renderers, puts odoc in a place where it supercedes OCamldoc in most respects. There are a few features we're missing (see the comparison in the docs), including most notably that we don't render the source (OCamldoc's --keep-code argument), and that there is no support for custom tags. If odoc is lacking features that you're currently relying on in OCamldoc, we'd love to hear from you!

More Docs!

Finally, I'd like to use this opportunity to launch an invitation. With v3.ocaml.org now showing all the package docs in their current state, I'd like to invite all our package authors, maintainers, contributors, and users to take a look over their favourite packages and see what the documentation looks like. Good documentation is one of the most important requests from the previous OCaml developer surveys, and with v3.ocaml.org as a new documentation hub, now is a great time to be making improvements where they're required. With this new release of odoc, previewing your docs should be as simple as dune build @doc.

Some packages already have great docs - a few examples are:

many others have more patchy docs. Let's fix that!

We're also looking for more contributors to odoc. It's much improved now, but there's still plenty more to do. Come and join the fun!

The road to OCaml 5.0

octachron announced

With the convergence between the multicore and standard runtime across OCaml 4.10.0 to 4.13.0, the development of OCaml multicore has reached a point where further integration into OCaml's main branch requires fully committing to a switch to OCaml multicore.

The OCaml team has decided that the time has come for such a commitment. The new major version, OCaml 5, will be a multicore version of OCaml. Moreover, OCaml 4.14 will be the last minor release of the 4.x series of OCaml.

Multicore Minimum Viable Product

The first version of OCaml multicore, code-named OCaml 5.0, will be a Minimum Viable Product focused on:

  • x86-64
  • Linux, MacOS, Windows mingw-w64
  • Parallelism through Domains [1]
  • Concurrency through Effect Handlers [2] (without syntactic support and exposed as functions from the standard library)

Our plan is to integrate the multicore branch into the main branch during the next 6 months. Hopefully, OCaml 5.0 will then be released between March and April 2022.

Note that OCaml 5.0 focuses on minimal (solid) support for the multicore runtime system, and will not provide stable user-facing concurrency and parallelism libraries. There has been a lot of experimentation ([3],[4]) in the last few years, and some work remains to offer long-term, user-facing concurrent and parallel programming abstractions. OCaml 5.0 will be a great time to start adding concurrency and parallelism to your OCaml programs, but the libraries will still be in flux.

Long term support for OCaml 4.14

While OCaml 5 is stabilising, we plan to extend the support period for OCaml 4.14 by publishing minor bugfix releases whenever needed. In particular, OCaml 4.14 will be supported until all tier-1 architectures and operating systems are available in OCaml 5, and OCaml 5 sequential performance is close enough to that of OCaml 4.

The sequential glaciation

To ensure that maintainers can concentrate on Multicore integration, and avoid any rebase work for the Multicore developers, the trunk branch will be feature-frozen starting from November 2021. All non-bugfix non-multicore contributions will be delayed to after the Multicore integration. We are calling this period the "sequential glaciation".

We understand that this may be frustrating for our contributors, and apologize for the delay in getting your nice work reviewed and merged into the codebase. We hope that the sequential glaciation will be a good opportunity to help with the Multicore integration, review and testing, and/or focus on non-core-compiler efforts and the rest of the OCaml ecosystem.

With this early feature-freeze, we also plan to release OCaml 4.14.0 in advance, between January and February 2022, reducing the concurrency between the OCaml 5.0 and OCaml 4.14.0 releases.


Become an Outreachy Mentor: support the growth and diversity of the OCaml community

Deep in this thread, Jon Ludlam announced

I've also submitted a project for the winter session: "Create a tool to show differences in the output of odoc."

The idea is to produce a tool to work on the output of the ocaml-docs-ci pipeline to find differences between different versions of the same package. We're aiming for it to eventually be used in the docs pages to highlight differences between versions in v3.ocaml.org. Just one of the neat things we've got in mind for the docs pages on the new website!

As @tmattio points out, you don't have to be a mentor to contribute to the process - so let the odoc team know if you're interested in lending a hand.

Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0)

jbeckford announced

0.2.2 is now released.

Some of the bigger changes:

  • (Bug Fixes) Many problems with Visual Studio have been resolved, especially for non-English installations.
  • (Features) Pre-alpha support for macOS and Windows 32-bit, in addition to the existing Windows 64-bit support.
  • (Reliability) There is now an internal GitHub Actions CI system that builds Windows 32-bit, Windows 64-bit and macOS (x64). In the future GitHub Actions will be offered to anyone who needs to test their own 32-bit and 64-bit Windows packages.
  • (Reliability) The Windows MinGW Opam repository vended by fdopen is still used but has been drastically pruned. Now the thousands of MinGW and DKML (MSVC) patches are pinned, and those pinned package versions are tested with the GitHub Actions CI system.

To upgrade, just follow the Two Step installation instructions and then upgrade any of your Local Projects like diskuv-ocaml-starter with ./makeit build-dev .

The v0.2.2 release notes has a detailed list of changes.

first release of osh: https://osh.ocamlpro.com

zapashcanon announced

I'm pleased to announce the first release of osh, a website providing an API to generate SVG badges.

E.g. this url: https://osh.ocamlpro.com/badge?label=build&color=green&status=passing will give the following result: build passing.

We also have special support for GitHub actions, using https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml will give you the following: build passing.

Even when using the special GitHub action endpoint, you can override any parameter, e.g. https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml?color=blue will give you the following: build passing.

We're willing to add any other special endpoint if someone is interested. :)

The source code is available on OCamlPro's Gitlab, it's made with ocb for the badge generation part, dream, ezcurl, omd, crunch and Yojson.

There's also an opam package in case you want to host your own instance.

Enjoy !

first release of pyast

Thierry Martinez announced

I have the pleasure to announce the first release of pyast, a library provides versioned abstract syntax tree for all Python versions from Python 2.5 to Python 3.10.

Available on opam: opam install pyast

The purpose of this library is very close to pyre-ast, namely being able to give access from OCaml programs to the Python own parser and to the ASTs it builds. There are two main differences:

  • pyre-ast exposes the AST of Python 3.10 whereas pyast exposes the ASTs of all Python versions from Python 2.5 to Python 3.10 (in versioned modules à la ocaml-migrate-parsetree), providing converters between them. The AST of the latest version of Python (currently, 3.10) is provided in Pyast.Latest.
  • pyre-ast embeds its own version of the Python interpreter, whereas pyast uses the Python interpreter available on the machine (via pyml), converting the AST to the expected version if necessary.

The development of pyast was motivated when some handwritten code using pyml to access the Python parser broke after a Python upgrade because of a change in the AST!

Multiple open positions (postdoc, PhD, intern) on runtime verification at CEA LIST, France

Julien Signoles announced

The Software Safety and Security Lab at CEA LIST (Université Paris-Saclay, France) is opening 2 postdoc, 1 PhD, and 1 internship positions in the area of runtime verification for code safety and security:

The candidates will:

  • solve challenging research problems;
  • implement their results in Frama-C, an industrial-strength open-source framework for analyses of C code;
  • evaluate their solutions on concrete benchmarks or/and use cases;
  • publish their results in international conferences and journals.

Strong knowledge in at least one of the following areas is always appreciated:

  • programming: OCaml and C, semantics of programming languages, …
  • formal verification: runtime verification, static analysis, …
  • compilation: code generation, program transformation, type system, …

Interested applicants should send a CV and a motivation letter to Julien Signoles (julien dot signoles at cea dot fr) as soon as possible.

Postdoc position in Effect Handler Oriented Programming

Daniel Hillerström announced

We have an opening for a post-doctoral research position at The University of Edinburgh on Effect Handler Oriented Programming (EHOP) funded by a UKRI Future Leaders Fellowship.

Candidates should have a background in programming languages with experience of functional programming, formal semantics, and type theory. Some experience with effect handlers and algebraic effects is desirable, but not essential. The role will involve theory (e.g. developing and reasoning about novel effect type systems and algebraic theories) and practice (e.g. designing, implementing, and evaluating implementations and applications of effect handlers), and ample opportunity to engage with our project partners (several of whom are deeply involved with the development of OCaml).

The position is for three years starting in February 2022.

The EHOP project:


Job application details:


If you are interested then feel free to contact Sam Lindley (application deadline: 1 November 2021).

OCaml compiler development newsletter, issue 3: June-September 2021

gasche announced

I’m happy to publish the third issue of the “OCaml compiler development newsletter”. (This is by no means exhaustive: many people didn’t end up having the time to write something, and it’s fine.)

Feel free of course to comment or ask questions!

If you have been working on the OCaml compiler and want to say something, please feel free to post in this thread! If you would like me to get in touch next time I prepare a newsletter issue (some random point in the future), please let me know by email at (gabriel.scherer at gmail).

Previous issues:

Nicolás Ojeda Bär (@nojb)

Channels in the standard library
  • #10545 Add modules In_channel and Out_channel to the standard library. (merged)
  • #10538 Add~Out_channel.set_buffered~ and Out_channel.is_buffered to control and query the buffering mode of output channels. (merged)
  • #10596 Add In_channel.input_all, In_channel.with_open_{bin,text,gen} and Out_channel.with_open_{bin,text,gen}. (under review)
Compiler user-interface
  • #10654 Propose an approach to enable use of debug info in bytecode binaries compiled with -output-complete-exe. (waiting for review) This is the second iteration on work that could have important impact on usability of self-contained bytecode binaries – bring -output-complete-exe to feature parity with -custom, and deprecate the latter, more fragile approach.
  • #10555 Improve and clean up the AST locations stored associated to "punned" terms (eg {x; y} or < x; y >). (merged)
  • #10560 The compiler now respects the NO_COLOR environment variable. (merged)
Internal changes
  • #10624 Apply a fix for a compile-time regression introduced in 4.08 (the fix was suggested by Leo White). (merged)
  • #10606 Clean up the implementation of the non-unit-statement and ignored-partial-application warnings. (merged)

David Allsopp (@dra27)

  • Relocatable Compiler. I worked on the patchset in August and September. There's a prototype for both Windows and Unix rebased to 4.12 and 4.13. With these patches, if you have multiple versions of the compiler lying around (i.e. opam!), it is now virtually impossible for a bytecode executable to load the wrong C stubs library (e.g. dllunix.so) or invoke the wrong version of ocamlrun. Furthermore, from the compiler's perspective at least, a local opam switch can now be moved to a new location. The major thing this enables is the cloning of an existing compiler in order to create a new opam switch without any binary rewriting. With these patches, fresh local switches are building in 5-10 seconds (a lot of which is spent by opam, which has more incentive to be improved, now!).
  • 4.13 includes the first parts of work to reduce the use of scripting languages in the build system which improves the stability of the build system and also its portability. The Cygwin distribution recently stopped distributing the iconv command by default, which broke all the Windows builds of OCaml (see #10451. There's more work to go on this, but the rest of it is likely to be stalled until post OCaml 5.00. With the use of scripting vastly reduced, it was possible to get quite a long way through the build using native Windows-compiled GNU make (i.e. make.exe with no other dependencies) and no Cygwin/MSYS2/WSL.
  • 4.13 includes a full overhaul of the FlexDLL bootstrap and detection (mentioned in my April update); hopefully gone are the days of randomly picking up the wrong flexlink or suddenly finding that FlexDLL is missing. The Windows build should also be appreciably faster when bootstrapping FlexDLL (which is what opam's source builds have to do).
  • There's some ongoing work at "modernising" our use of POSIX to remove some older compatibility code in the Unix Library in #10505. It's always nice to remove code!
  • Gradually completing and closing down some of my more aged PRs, often replacing them with simpler implementations. It's funny how returning to PRs can often result in realising simpler approaches; like letting tea brew! :tea:

Xavier Leroy (@xavierleroy)

I worked on an old issue with the handling of tail calls by the native-code compiler: if there are many arguments to the call and they don't all fit in the processor registers reserved for argument passing, the remaining arguments are put on the stack, and a regular, non-tail call is performed. This limitation had been with us since day 1 of OCaml. I tried several times in the past to implement proper tail calls in the presence of arguments passed on stack, but failed because of difficulties with the stack frame descriptors that are used by the GC to traverse the stack.

In #10595, generalizing an earlier hack specific to the i386 port of OCaml, I developed a simpler approach that uses memory from the "domain state" structure instead of the stack. Once the registers available for passing function arguments are exhausted, the next 64 arguments are passed in a memory area that is part of the domain state. This argument passing is compatible with tail calls, so we get guaranteed tail calls up to 70 arguments at least.

The domain state structure, introduced in preparation for merging Multicore OCaml, is a per-execution-domain memory area that is efficiently addressable from a register. Hence, passing arguments through the domain state is safe w.r.t. parallelism and about as efficient as passing them through the stack.

Enjoy your 70-arguments tail calls!

Constructor unboxing (Nicolas Chataing @nchataing, Gabriel Scherer @gasche)

Nicolas Chataing's internship on constructor unboxing (mentioned in the last issue finished at the end of June. We have been working on-and-off, at a slower rate, to get the prototype to the state we can submit a PR. The first step was to propose our specification (which is different from Jeremy Yallop's original proposal), which is now posted as an RFC comment.

Hacking on this topic produced a stream of small upstream PRs, mostly cleanups and refactorings that make our implementation easier, and some documentation PRs for subtle aspects of the existing codebase we had to figure out reading the code: #10500, #10512 (not yet merged, generating interesting discussion), #10516, #10637, #10646.

Vincent Laviron (@lthls(github)/@vlaviron(discuss))

Léo Boitel's internship on detection and simplification of identity functions finished in June (find the corresponding blog post at OCamlPro and the discussion on Discuss). Pushing the results upstream isn't a priority right now, but I'm planning to build on that work and integrate it either in the main compiler or in the Flambda 2 branch at some point in the future.

Apart from that, I've documented the abstract domains that we use for approximations in the Flambda 2 simplification pass (you can find the result here), and I've worked with Keryan Dider (@Keryan-dev) on an equivalent to the -Oclassic mode for Flambda 2.

I've also proposed and reviewed a number of small fixes both on the upstream and Flambda 2 repos, from fixes for obscure bugs (like this Flambda bug) to small improvements to code generation.

Jacques Garrigue (@garrigue)

Continued to work with Takafumi Saikawa (@t6s) on strengthening the datatypes used in the unification algorithm.

  • #10337 Make type nodes abstract, ensuring one always sees normal forms. Merged in June.
  • #10474 Same thing for polymorphic variants rows. Merged in September.
  • #10627 Same thing for polymorphic variant field kinds.
  • #10541 Same thing for object field kinds and function commutation flags.

Also continued the work on creating a backend generating Coq code GitHub - COCTI/ocaml at ocaml_in_coq. This now works with many examples.

Odig 0.0.7, lookup documentation of installed OCaml packages

Daniel Bünzli announced

It's my pleasure to announce the release 0.0.7 of odig. Odig is a command line tool to lookup documentation of installed OCaml packages.

Once it has made it to the repo, install with opam install ocaml-manual odig and consult the manual (or via odig doc odig).

This release provides support for odoc 2.0.0. The release notes have all the details.

OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central)

Michael Bacarella announced

Note! This is not our usual time! Past meetups have been at 7pm (U.S. Central). This one is happening at 1pm (U.S. Central). This meetup should be easier for people in Europe to attend.

Please join us at the next OCaml Cafe, a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Bring your code and we’ll be happy to review it, assist with debugging, and provide recommendations for improvement.

This month, David Allsop of OCaml Labs and the University of Cambridge will present on OPAM, the OCaml package manager. After introducing OPAM, David will discuss the new features of OPAM 2.1, just released at the beginning of August. Following David's talk, we will open the discussion to all things OCaml-related.

Full meeting details, including Zoom link, here: https://www.meetup.com/ocaml-cafe/events/281344155/

Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0!

Deep in this thread, Bikal Lem announced

The multicore eio lib has now been migrated to the syntax-free version. This is the version of effects which will be available in the upcoming OCaml 5.0.0.

PR : https://github.com/ocaml-multicore/eio/pull/82

Alcotest 1.5.0

Craig Ferguson announced

I’m pleased to announce the release of Alcotest 1.5.0, now available on Opam.

This release includes:

  • JavaScript compatibility (#326), via js_of_ocaml.3.11.0. Projects that build with js_of_ocaml can now use the regular alcotest package to test their JavaScript-compatible libraries. For users of dune, this is as easy as adding (modes ... js) to your test stanzas (to build the JavaScript targets) and a corresponding rule to run the output:

     (name main)
     (modes native js)
     (libraries alcotest))
     (alias runtest-js)
      (run node %{dep:main.bc.js})))

    To depend on a version of js_of_ocaml that is supported by Alcotest, add a dependency on the the virtual package alcotest-js.

    Many thanks @hhugo and @smorimoto for this excellent contribution!

  • Backtrace collection by default (#317). The Alcotest runner now enables backtrace collection by default, ensuring that failing native tests always come with backtraces without any need to set OCAMLRUNPARAM=b.
  • A stable Alcotest.V1 module (#306). This module is very similar to the existing top-level Alcotest module, but provides some stability guarantee across major versions. It's intended to provide a migration path for an eventual "Alcotest 2" to make improvements on the existing API.

The full changelog is available here.

Other OCaml News

From the ocamlcore planet blog

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


If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

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