From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 2979E5D3 for ; Tue, 22 Sep 2020 07:27:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.77,289,1596492000"; d="scan'208,217";a="468877732" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 22 Sep 2020 09:27:35 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 9E3ABE67F6; Tue, 22 Sep 2020 09:27:35 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 4F60BE67F2 for ; Tue, 22 Sep 2020 09:27:28 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=Pass smtp.pra=alan.schmitt@polytechnique.org; spf=Pass smtp.mailfrom=SRS0=90hC=C7=polytechnique.org=alan.schmitt@bounces.m4x.org; spf=Pass smtp.helo=postmaster@mx1.polytechnique.org IronPort-PHdr: =?us-ascii?q?9a23=3AzyfsdRMeL/X3tA6EcF0l6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0K/j5o8bcNUDSrc9gkEXOFd2Cra4d1KyP6Ou5AzRIoc7Y9ixbLtoUD15NoP?= =?us-ascii?q?5VtjRoONSCB0z/IayiRA0BN+MGamVY+WqmO1NeAsf0ag6aiHSz6TkPBke3blIt?= =?us-ascii?q?daz6FYHIksu4yf259YHNbAVUnjq9Zq55IAmroQnLucQanIlvJrwsxhbHrXdEZv?= =?us-ascii?q?payX91Ll6Xgxrw+9288ZF+/ylRof4t69JMXaDndKkkULJUCygrPXoo78PxrxnD?= =?us-ascii?q?SgWP5noYUmoIlxdDHhbI4hLnUJrvqyX2ruVy1jWUMs3wVrA0RC+t77x3Rx/yiS?= =?us-ascii?q?cILCA2/WfKgcFtlq1boRahpxtiw47IZYyeKfRzcr/Bcd4cWGFOWdtfVzFaAoOk?= =?us-ascii?q?cYQAE/YBM+hfr4n4vVQOrB2+DhSoCO7gzjJEg3n70a053eQnDwHG3RcgH9MVv3?= =?us-ascii?q?TQstr+KakTUeevzKbV1jXIcvda1Dnh5ITNdB0qvPOCUq9qccfJyUchCR7LgFuT?= =?us-ascii?q?p4PqIzyYzf4Cv3SB4ud6Se6jl2wqpgdsqTav3McsjYzJi5oJx1DA7yp5xps+K8?= =?us-ascii?q?CkR057ZN6kEYdQtz2HPIZxWMwiR3tnuCAgxr0dpZG7fC0KyJU7xx7DcPGHa4+I?= =?us-ascii?q?4hbjVeaNPzh3mHJleLS+hxar7Eiv1PfwVs6u0FZFtydIlMTHuX8R2RLJ8MeHVu?= =?us-ascii?q?d98Vm72TaJzw3e5eVJLEQ7m6fGJJMszb09m5oXvErDACL7mUv7gqCWe0k69Oal?= =?us-ascii?q?6ebqb6jiq5KBNIJ5hQ/zP6oyl8GiAOk1PBUDUm6G8uqy073j+Ff2QLRMjvAuiq?= =?us-ascii?q?nWrozaJcUHpqGnGw9V1YMj6xOhADu81tQXg2UHIEpCeB2blYfpPlXOLOr/Dfel?= =?us-ascii?q?jFSgiDhrx/HaPr3hH5XCNWLPn6vmfbZ480JT1Q0zwsxc551KELENOu78Wkj0tN?= =?us-ascii?q?DAAR85MhC0w+b6CNpmzI8eWGWPDreCP6PTrV+I/f4vI/ONZI8TtzbxMeMl5/ng?= =?us-ascii?q?jX8ll14SZ7Op0oUPZHC5A/tnI0GZYX72jtcGC2cKsRIyTOz2iF2eST5feXOyX7?= =?us-ascii?q?845jEnCYKpEYDDRpqzj7Ob2ie0A5hWaXpGC1+XD3jnbYOEVO0QaCKTPM9ujDsE?= =?us-ascii?q?WqS7RI8k0RGutQr6y6JjLuXK/y0Xq5Tj1MRv6O3PlBEy8jp0D8CH3GGRUW50hH?= =?us-ascii?q?kERz4z3K15vEdzyU+D3LBlj/BGEdFf/e5FXhs1OJLGweF2F8r+VwzOc9uRSlur?= =?us-ascii?q?Qc+qDS8+Q94v2dMCfklwF8+/gh3MwyanBaIemaaRC5wu6K3c2mD8J8ZjxHbC06?= =?us-ascii?q?ksl1wmQ8RSOWG8nq5/8AzTBo7Vk0qHi6mqdaIc3C/U9Gee02WCpkZYUBR/Uand?= =?us-ascii?q?XHAfYFXZrcjh60/fUbOjDa4rPhZdxcONMKdHZMHlgU9ISfrsINjeZni+m2a0BR?= =?us-ascii?q?aG3LOMa4/qdn0A0ivBFUYIjxge8HKaOQg+GCqsu3zTAT52GFL3ZEPs9el/qG+l?= =?us-ascii?q?QUAozwGKaUxh16Oo+hELn/CcTOkT3r0ctSg7rzV7BlC908jNC9WcpwpheaRcYc?= =?us-ascii?q?8h4Fpczm3ZsBF9Ppq8IK98nV4SaQF3skzh1hltDYVAi8cqoGswzAVuMaKYzE9B?= =?us-ascii?q?dzSA0J/sILLXL23y8Amra67XwVHezM2b+rwP6fQ9s1XsphulFksk83V90tlayW?= =?us-ascii?q?GQ5pvQDFlabZWkGEIo8VIy87XFZAE5+IWS03BwZ+38+DTd3ZhhTL8u1RCIe9ZE?= =?us-ascii?q?LLjCFQPjF8lcANKhfqhikFGsalcAPftO3K8yJcKvMfWcnOagO+N4tDanlnhcpo?= =?us-ascii?q?dn2EOQ/i5yTf6O0otW7euf216uUz76xGyqssX2hZwMMTgWF2z50iPkAY9NeoVq?= =?us-ascii?q?eoIaFWqlI8u238hzwZn3VCgLpxaYG1oa1ZrxKlKpZFvn0FgPhB1K80ziojOxyn?= =?us-ascii?q?lPqx9srqeb23aVkeHyLVwfPWpaWGRpjVHtOJW5ydcAUxrxNlR7pF6e/U//gpNj?= =?us-ascii?q?iuFnNWCKEBVQeCznM2xpUq2xr6ePJclV58Fx6HQFYKGHeVmfD4XFjV4f2iLnEX?= =?us-ascii?q?FZwWlkJTutp5Pykgc8jT6NanFpoyiAdA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqBQCupmlffSIeaIFfg3tSRgFeVjIsh?= =?us-ascii?q?DqBXYcli1OFQpFjgWQQAQMBDRgBDAcBAgQBAYFWgUBxRAKCJQIdBgEFMxMCEAE?= =?us-ascii?q?BBQEBAQIBAwMEARMBAQsUCIYMDII3DAwDA4MlAQwMCQo4LSMDFAEGAwIRARcBF?= =?us-ascii?q?AoXARIaAYMMgnwEAQqZdJt7gTKEOwETAwEOCSaEG4FCDQITgRaFTUuDA4NrJg+?= =?us-ascii?q?BTT+Dc2yCRQwLAQEBAQGBHhwBAQhOgmGCYASPfQ4BCgICJQKKE4kpkisTSyoHg?= =?us-ascii?q?mqBDQQLhlqBAYsChnaDDIEniFKTfSGSXIF3hgN9gWqGCIpnhFSBQSqBZwwHMxo?= =?us-ascii?q?wgywJYA2NfCwag06CZIF1O4Fhg2M/MwIBATMCBgEJAQEDCXUBAQUTCwGNRAEB?= X-IPAS-Result: =?us-ascii?q?A0BqBQCupmlffSIeaIFfg3tSRgFeVjIshDqBXYcli1OFQpF?= =?us-ascii?q?jgWQQAQMBDRgBDAcBAgQBAYFWgUBxRAKCJQIdBgEFMxMCEAEBBQEBAQIBAwMEA?= =?us-ascii?q?RMBAQsUCIYMDII3DAwDA4MlAQwMCQo4LSMDFAEGAwIRARcBFAoXARIaAYMMgnw?= =?us-ascii?q?EAQqZdJt7gTKEOwETAwEOCSaEG4FCDQITgRaFTUuDA4NrJg+BTT+Dc2yCRQwLA?= =?us-ascii?q?QEBAQGBHhwBAQhOgmGCYASPfQ4BCgICJQKKE4kpkisTSyoHgmqBDQQLhlqBAYs?= =?us-ascii?q?ChnaDDIEniFKTfSGSXIF3hgN9gWqGCIpnhFSBQSqBZwwHMxowgywJYA2NfCwag?= =?us-ascii?q?06CZIF1O4Fhg2M/MwIBATMCBgEJAQEDCXUBAQUTCwGNRAEB?= X-IronPort-AV: E=Sophos;i="5.77,289,1596492000"; d="scan'208,217";a="359675856" X-MGA-submission: =?us-ascii?q?MDHXqI8ZAr38RhPIiHdpGy5oRGfKslbepju+9o?= =?us-ascii?q?EcldQRISgth5cERLUonKp7eF3ilXsNVeC8slzkRZa4w8+/YuHazu3GBj?= =?us-ascii?q?v+UqdTXADdvsxxYmTYAsGlLpaitCOrcjQBx2YcvwCoBmV4hppReY40+x?= =?us-ascii?q?3QCS/OAqOrxHGGqGOhykc1Mw=3D=3D?= Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 09:27:26 +0200 Received: from set (cbg35-2-78-242-14-140.fbx.proxad.net [78.242.14.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id B87F5564F0A; Tue, 22 Sep 2020 09:27:24 +0200 (CEST) From: Alan Schmitt To: "lwn" , "cwn" , caml-list@inria.fr, comp@lists.orbitalfox.eu Date: Tue, 22 Sep 2020 09:27:24 +0200 Message-ID: <87mu1i6zkz.fsf@m4x.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Sep 22 09:27:25 2020 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.000000, queueID=4F422564F54 X-Org-Mail: alan.schmitt.1995@polytechnique.org Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Reply-To: Alan Schmitt X-Loop: caml-list@inria.fr X-Sequence: 18246 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Here is the latest OCaml Weekly News, for the week of September 15 to 22, 2020. Table of Contents =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 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 Old CWN Liquidsoap 1.4.3 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Romain Beauxis announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90 Archive: Mika Illouz announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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: =E2=80=A2 github: [https://github.com/barko/simple63] =E2=80=A2 documentation: [https://barko.github.io/simple63/] Feedback and bug reports welcome. [https://github.com/barko/simple63] [https://barko.github.io/simple63/] bentov v1: streaming estimation of 1D histograms =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Mika Illouz announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 This is to announce bentov, a opam package that implements a 1D histogram-sketching algorithm. For more details: =E2=80=A2 github: [https://github.com/barko/bentov] =E2=80=A2 documentation: [https://barko.github.io/bentov] Feedback and bug reports welcome. [https://github.com/barko/bentov] [https://barko.github.io/bentov] opam-compiler 0.1.0 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90 Archive: Etienne Millon announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 % opam compiler create '#9921' =E2=94=82 Opam plugin "compiler" is not installed. Install it on the curr= ent switch? [Y/n] y =E2=94=82=20 =E2=94=82 ... =E2=94=82=20 =E2=94=82 <><> Carrying on to "opam compiler create #9921" ><><><><><><><= ><><><><><><><><> =E2=94=82=20 =E2=94=82 [ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised = from =E2=94=82 git+https://github.com/gasche/ocaml#Atomic.create =E2=94=82 ocaml-variants is now pinned to git+https://github.com/gasche/o= caml#Atomic.create (version =E2=94=82 4.12.0+trunk) =E2=94=82 % opam switch =E2=94=82 ... =E2=94=82 =E2=86=92 ocaml-ocaml-9921 =E2=94=82 [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Ato= mic.make into Atomic.create =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Jason Nielsen announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: vds announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 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 function. 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'. Changelog =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C =E2=81=83 merlin binary =E2=80=A2 fix completion of pattern matchings with exception patterns (#1169) =E2=80=A2 delegate configuration reading to external programs via a sim= ple protocol and create a new package `dot-merlin-reader' with a binary that reads `.merlin' files. (#1123, #1152) gRPC server and client in OCaml =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: blandinw announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80 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. [blandinw/ocaml-grpc-envoy] Yawar Amin asked and blandinw replied =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80 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 connection. Bitstring (and ppx_bitstring) 4.0.0 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90 Archive: xrguerin announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80 Features =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C =E2=80=A2 Add support for let bindings introduced in 4.08 =E2=80=A2 Switch to PPXLIB Deprecations =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C As PPXLIB requires `ocaml >=3D 4.04' support for earlier versions has been dropped. Breaking changes =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C 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 =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80 The project is hosted [here] for those who are interested.There's also some excellent [docs] [here] [docs] Old CWN =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 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]. [Alan Schmitt] [send me a message] [the archive] [RSS feed of the archives] [online] [Alan Schmitt] --=-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable OCaml Weekly News

OCaml Weekly News

Previous Week Up Next Week

Hello

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

Liquidsoap 1.4.3

Archive: https://discuss.ocaml.org/t/ann-liquidsoap-1-4-3/6429/1

Romain Beauxis announced

I'm happy to announce that liquidsoap 1.4.3 is out at: https= ://github.com/savonet/liquidsoap/releases/tag/v1.4.3

This is the 3rd bugfix release for the 1.4.x branch. It cont= ains 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 de= bian packages and docker-ready production images for amd64 and arm64 archite= ctures available at: htt= ps://hub.docker.com/repository/docker/savonet/liquidsoap

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 t= hat 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 b= e a major update for us!

Simple63 v1: compression of integer sequences

Archive: https://discuss.ocaml.org/t/ann-simple63-v1-c= ompression-of-integer-sequences/6431/1

Mika Illouz announced

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

Feedback and bug reports welcome.

bentov v1: streaming estimation of 1D histograms

Archive: https://discuss.ocaml.org/t/ann-bentov-v1-= streaming-estimation-of-1d-histograms/6434/1

Mika Illouz announced

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

Feedback and bug reports welcome.

opam-compiler 0.1.0

Archive: https://discuss.ocaml.org/t/ann-opam-compiler-0-1-0/6442/1

Etienne Millon announced

On behalf of the opam maintainers, I'd like to announce the first release o= f 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 st= arting 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" ><>&l=
t;><><><><><><><><><&=
gt;<><><><>

[ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised from
git+https://github.com/gasche/ocaml#Atomic.create
ocaml-variants is now pinned to git+https://github.com/gasche/ocaml#Atomic.=
create (version
4.12.0+trunk)
% opam switch
...
=E2=86=92  ocaml-ocaml-9921
          [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Atomic.make int=
o 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-in= stall 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 sw= itch 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!

lua_parser 1.0.0

Archive: https://discuss.ocaml.org/t/ann-lua-parser-1-0-0/6445/1

Jason Nielsen announced

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

Merlin 3.4.0 : introducing external configuration readers

Archive: https://discuss.ocaml.org/t/ann-me= rlin-3-4-0-introducing-external-configuration-readers/6446/1

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 .m= erlin 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 pass= ed to the compiler, which syntax extensions are enabled and which packages are us= ed 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 t= his 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 confi= guration from .merlin files. Both are necessary for proper function.

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 lo= ng 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 earl= ier, but it paves the way for such improvements: in a near-future Dune will stop generating .merlin files and Merlin will obtain file-based con= figuration directly from the build system using the same protocol as the one used by dot-merlin-reader.

Changelog

  • merlin binary
    • fix completion of pattern matchings with exception patterns (#1169)
    • delegate configuration reading to external programs via a simple protoc= ol and create a new package dot-merlin-reader with a binary th= at reads .merlin files. (#1123, #1152)

gRPC server and client in OCaml

Archive: https://discuss.ocaml.org/t/grpc-server-and-client-in-ocaml/64= 65/1

blandinw announced

TL;DR https://git= hub.com/blandinw/ocaml-grpc-envoy/

Hey, I'm new to OCaml after writing some Clojure, C++ and Haskell in variou= s 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 somethin= g 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 protoco= l) 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 clie= nt and server (equivalent to HTTP2 + gRPC) frequently receive new features, optimizations and fixes. Aft= er a valiant and continued effort to support most languages used internally, the Thrift team came up w= ith an idea. Instead of maintaining multiple implementations and dealing with obscure FFI bugs, ~FingerprintTrustManagerFactory~s and whatnot, they would focus solely on t= he 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 suppor= t for protobuf thanks to the excellent ocaml-protoc. All we need is a way to exchange proto= buf 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 24= 00 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 contri= buted 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-gr= pc-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 OCam= l 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 wit= h 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 (se= rver-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 m= essage) that Envoy sends back on the original HTTP2 connection.

Bitstring (and ppx_bitstring) 4.0.0

Archive: https://discuss.ocaml.org/t/ann-bitstring-and-ppx-bitstr= ing-4-0-0/6471/1

xrguerin announced

Features

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

Deprecations

As PPXLIB requires ocaml >=3D 4.04 support for earlier vers= ions 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 d= ocs

Old CWN

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

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

Alan Schmitt

--=-=-=--