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, 22 Sep 2020 09:27:24 +0200	[thread overview]
Message-ID: <> (raw)

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


Here is the latest OCaml Weekly News, for the week of September 15 to
22, 2020.

Table of Contents

Liquidsoap 1.4.3
Simple63 v1: compression of integer sequences
bentov v1: streaming estimation of 1D histograms
opam-compiler 0.1.0
lua_parser 1.0.0
Merlin 3.4.0 : introducing external configuration readers
gRPC server and client in OCaml
Bitstring (and ppx_bitstring) 4.0.0

Liquidsoap 1.4.3

  Archive: <>

Romain Beauxis announced

  I'm happy to announce that liquidsoap `1.4.3' is out at:

  This is the 3rd bugfix release for the `1.4.x' branch. It contains
  important fixes and a couple of new minor features. Update is
  recommended and should be fairly safe.

  Along we this release, we have now added builds for `arm64' debian
  packages and docker-ready production images for `amd64' and `arm64'
  architectures available at:

  Again, we would like to warmly thank all users, contributors and
  reporters for helping us bring liquidsoap to the next step!

  Also, please note that a couple of issues had to be left out to make
  sure that the release comes out on time. These are listed [here] and
  will be tackled as soon as possible.

  Next for liquidsoap, we will focus on getting the current `2.x' branch
  finalized and polished. We already have support for encoded content
  and ffmpeg raw frames. We need to write a couple of inline encoders
  and decoders and we'll have 90% of the features ready. This will be a
  major update for us!

[here] <>

Simple63 v1: compression of integer sequences


Mika Illouz announced

  This is to announce Simple63, an opam package for compression of
  integer sequences; similar to Anh and Moffat's Simple-8b. More details
  found in:

  • github: []
  • documentation: []

  Feedback and bug reports welcome.

[] <>

[] <>

bentov v1: streaming estimation of 1D histograms


Mika Illouz announced

  This is to announce bentov, a opam package that implements a 1D
  histogram-sketching algorithm. For more details:

  • github: []
  • documentation: []

  Feedback and bug reports welcome.

[] <>

[] <>

opam-compiler 0.1.0

  Archive: <>

Etienne Millon announced

  On behalf of the opam maintainers, I'd like to announce the first
  release of opam-compiler, a plugin to work with compiler variants,
  branches and forks.

  This can cover a pretty wide range of use cases, so the first version
  is starting small with a single command to create a switch from a
  branch or github PR:

  │ % opam compiler create '#9921'
  │ Opam plugin "compiler" is not installed. Install it on the current switch? [Y/n] y
  │ ...
  │ <><> Carrying on to "opam compiler create #9921" ><><><><><><><><><><><><><><><>
  │ [ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised from
  │ git+
  │ ocaml-variants is now pinned to git+ (version
  │ 4.12.0+trunk)
  │ % opam switch
  │ ...
  │ →  ocaml-ocaml-9921
  │           [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Atomic.make into Atomic.create

  You can also override the arguments passed to `--configure'.

  As you can see in the above snippet, it's an opam plugin so it will
  auto-install if needed (assuming you ran `opam update' recently) and
  will be available across all switches. Its sources and issue tracker
  are available [here].

  For the next releases, our plan is to add a user-friendly way to setup
  a switch based on a local git clone, so that it's easy to test your
  compiler fork with opam packages. You can find the other features we'd
  like to add in the future in [the relevant part of the opam roadmap].

  Thanks and have fun compiling compilers!

[here] <>

[the relevant part of the opam roadmap]

lua_parser 1.0.0

  Archive: <>

Jason Nielsen announced

  I've release [lua_parser] which is now up on opam.  It is a parser and
  pretty-printer for lua 5.2.  Actually it was developed with luajit in
  mind which is lua 5.1 plus goto/labels (which syntactically for the
  purposes of parsing and pretty-printing is lua 5.2).

[lua_parser] <>

Merlin 3.4.0 : introducing external configuration readers


vds announced

  I am glad to announce, on behalf of the Merlin team, the release of
  Merlin `3.4.0' which brings some major changes in the way
  configuration is handled.

  As you might know, Merlin reads its configuration from the closest
  `.merlin' file to the source file being edited. These files tell
  merlin where to find other source files and build artifacts, but also
  which flags should be passed to the compiler, which syntax extensions
  are enabled and which packages are used by the project.

  In this setting the configuration is the same for all the source files
  of a folder, regardless of their specificities. In other words, the
  configuration loaded for a single source file contains the union of
  the dependencies of this file and of all its siblings which is not an
  optimal behavior.

  Starting with version `3.4.0' merlin will ship with two packages:
  `merlin' and `dot-merlin-reader' which, as the name suggests, reads
  configuration from `.merlin' files. Both are necessary for proper

  When a `.merlin' file is present in the source folder the Merlin
  server will start a `dot-merlin-reader' process and communicate with
  it via standard input and output following a simple protocol. These
  processes are halted with the server.

  *This change should not have any visible impact on users' workflows as
  long as the `dot-merlin-reader' binary is correctly installed and in
  the path*. (which should be the case in opam-based setups)

  This change in itself will not solve the granularity problem mentioned
  earlier, but it paves the way for such improvements: in a near-future
  Dune will stop generating `.merlin' files and Merlin will obtain
  file-based configuration directly from the build system using the same
  protocol as the one used by `dot-merlin-reader'.


  ⁃ merlin binary
    • fix completion of pattern matchings with exception patterns
    • delegate configuration reading to external programs via a simple
      protocol and create a new package `dot-merlin-reader' with a
      binary that reads `.merlin' files. (#1123, #1152)

gRPC server and client in OCaml


blandinw announced

  TL;DR <>

  Hey, I'm new to OCaml after writing some Clojure, C++ and Haskell in
  various contexts, including working at FB (relevant below).

  After browsing this forum and Reddit for a bit, the assumption seems
  to be that OCaml is not a good fit for gRPC, since there's no pure
  implementation today. Now, this is something I have experience with,
  so I thought I'd try and challenge this assumption.

  As you may know, services inside FB use Thrift (both the format and
  protocol) to communicate. The Thrift team worked primarily in C++ (for
  good reasons), causing support for other languages to lag behind
  despite their best efforts. Now, the interchange format (equivalent to
  Protobuf) does not change very often so it's fine to have a
  per-language implementation, but the client and server (equivalent to
  HTTP2 + gRPC) frequently receive new features, optimizations and
  fixes. After a valiant and continued effort to support most languages
  used internally, the Thrift team came up with an idea. Instead of
  maintaining multiple implementations and dealing with obscure FFI
  bugs, ~FingerprintTrustManagerFactory~s and whatnot, they would focus
  solely on the C++ implementation and provide a daemon to be ran
  alongside whatever code you were trying to run. You could then use
  simple IPC to exchange Thrift (the format) messages with that daemon,
  and it would handle all the nitty-gritty of running a service at scale
  (load balancing, connection pooling, service discovery, security,
  retries, timeouts, network stats, hot restarts, etc.). Needless to
  say, it worked remarkably well even at very high scale and everybody
  was much happier.

  I wanted to replicate this idea with OCaml and gRPC. We already have
  support for protobuf thanks to the excellent `ocaml-protoc'. All we
  need is a way to exchange protobuf messages reliably on the wire.
  Instead of having an OCaml implementation that will have to stay
  up-to-date and have its own set of bugs (the official `grpc/grpc-java'
  repo has 4450 commits and 2400 issues at the moment), can we reuse
  existing infra with already massive support and production time?

  Fortunately, the people at Lyft built just that, open-sourced it and
  contributed it to the Cloud Native Computing Foundation in late
  2017. It is called Envoy and it is bliss.

  I demonstrate how to fit these pieces together at
  [blandinw/ocaml-grpc-envoy] to build a simple KV store, including a
  gRPC client and server in 200 lines of OCaml code. The idea is to
  spawn an Envoy process that will handle all gRPC communication for our
  OCaml code. We use HTTP/1.1 to exchange Protobuf messages with it,
  using for example `httpaf' and `Lwt'. This solution has the added
  benefit that it is highly scalable from the start, allowing you for
  instance to spawn one OCaml process per core and load balance between
  them. You can also use Envoy (with proper config!) as your web reverse
  proxy instead of say, nginx.

  At the very least, this solution allows us to start writing gRPC code
  today, and gracefully evolve towards HTTP/2, Multicore and maybe a
  native OCaml implementation later.

  I'm curious to hear your perspective on the future of building
  services with OCaml, or your past experience like what went well, what
  was missing, etc.


Yawar Amin asked and blandinw replied

        Fantastic idea. So if I understand correctly, the only
        thing that Envoy (server-side) is doing is translating the
        Protobuf from gRPC HTTP2 transport to HTTP1, and
        forwarding these Protobuf objects over HTTP1 to the OCaml
        server? Envoy doesn't know to know about the actual gRPC
        schema, because it doesn't touch the Protobuf objects
        themselves, right?

  That's correct. Envoy is only concerned with transporting bytes (along
  with load balancing, routing, etc, etc). Only OCaml knows about the
  Protobuf schemas.

  In the OCaml server case, Envoy listens for HTTP/2 gRPC requests,
  accesses the bytes payload with no knowledge of the actual
  schema/layout and repackages these same bytes in a HTTP/1.1 request
  that OCaml can process. OCaml then responds with bytes (an encoded
  Protobuf response message) that Envoy sends back on the original HTTP2

Bitstring (and ppx_bitstring) 4.0.0


xrguerin announced


  • Add support for let bindings introduced in 4.08
  • Switch to PPXLIB


  As PPXLIB requires `ocaml >= 4.04' support for earlier versions has
  been dropped.

Breaking changes

  This release splits the library from the PPX to reduce runtime
  dependencies. Projects using the PPX from bitstring will need to also
  depends on ppx_bitstring from now on.

Rudi Grinberg added

  The project is hosted [here] for those who are interested.There's also
  some excellent [docs]

[here] <>

[docs] <>


  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: 28846 bytes --]

             reply	other threads:[~2020-09-22  7:27 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-22  7:27 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-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:

* 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).