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 540835D5 for ; Tue, 27 Jul 2021 08:54:57 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.84,272,1620684000"; d="scan'208,217";a="521689333" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 27 Jul 2021 10:54:53 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 18431E008A; Tue, 27 Jul 2021 10:54:53 +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 B5924E006A for ; Tue, 27 Jul 2021 10:54:47 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=Pass smtp.pra=alan.schmitt@polytechnique.org; spf=Pass smtp.mailfrom=SRS0=qUU4=MT=polytechnique.org=alan.schmitt@bounces.m4x.org; spf=Pass smtp.helo=postmaster@mx1.polytechnique.org IronPort-PHdr: =?us-ascii?q?A9a23=3Ayq/aaxSM/tzeyD1/kHO5kuMF7tpsoueZAWYlg6H?= =?us-ascii?q?Pa5pwe6iut67vIFbYra00ygOTBcOHtbkV2qL/iOPJYSQ4+5GPsXQPItRndiQur?= =?us-ascii?q?oEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZ?= =?us-ascii?q?vJuTyB4Xek9m72/q99pHNfwlEnjWwbLJ9IBiyqQjaq9Ubj5ZlJqst0BXCv2FGe?= =?us-ascii?q?/5RxWNmJFKTmwjz68Kt95N98Cpepuws+ddYXar1Y6o3Q7pYDC87M28u/83kqQP?= =?us-ascii?q?DTQqU6XQCVGgdjwdFDBLE7BH+WZfxrzf6u+9g0ySUIcH6UbY5Uiml4Kl2VR/ok?= =?us-ascii?q?z8HOCAl/2HLhMJwi6dbrwigpxx53oXYZI6YOf57cq7bfd8URmxBXthQVyxaA4O?= =?us-ascii?q?zdI8PAPQcNudWqIn9vUYBrQCjDgWoCu7j1jpEi3nr1qM4zushCxnL0gw+EdwTv?= =?us-ascii?q?nrar9r6O7sJXO+v0KXF1y/OY+9K1Tr/7oXDbxAvoeuLXbJ1acfc1U0vGBnDjl6?= =?us-ascii?q?NtILqIzOV1uEMs2iH8+prSOWihHQjqw5rpDij3NwshZXJhoIQy1DE6Tl5zZ0tJ?= =?us-ascii?q?d2/TE56YcKkH4VMuCGaMYt2Q9oiQ3x2tyogzb0Go5G7cTEMxZ86yBHRd+aJfJK?= =?us-ascii?q?U4hL/SumROzF4iWprdb+jhBu8/1WtxOPhW8So0VtHoC5In9jQun0T2RLd5ceKR?= =?us-ascii?q?/ph80u91zuDyRze5O5aLUwpm6TWN5EszqIsm5cdt0nIAyH4mELzjKCMd0Uk/PC?= =?us-ascii?q?l6/z5bbX6p5+cK5F7ihn5MqQrn8ywH/40Mg4QUGiH4ei806Hs8lf8QLVOlPE2l?= =?us-ascii?q?bPZsJ/CKcQUp665Hw9V0ps45BqlEzim19EYkWEILFJEZBKHj5XpNErULPD5Cve?= =?us-ascii?q?zm1OsnytxyPDDOr3hBo/CIWPYkLv7fLZ97FZQyBY9zNBe+5JUFq8OIOjpVkDts?= =?us-ascii?q?9zYCwc1MxC6wubmFNVyyoMeVXiTAq+HKK/SsEKH5+IrI+mIfoMVvyz9K/cj6vX?= =?us-ascii?q?zjnE5gUcQcbS30ZYTcny0A+hqLkqDbXfintsNC2kHswUmQOHulVGOSyNfanSsU?= =?us-ascii?q?64m+z02Cp6qAZ3dSo2jjrGM2jqwEIdMaWBcEF+MFG/ld4WaVPcIbyKfOsphkzM?= =?us-ascii?q?ZWbS7U48h0hWutQ/my7V5MuXU+isYtZP61Nho+eLfjxYy9SZ7D8iF0mGNSX97n?= =?us-ascii?q?n8QSjMrwqxypVZxxkqf3aV3mfBVG8Bf6+lHXwo1LZLcyvZ1C9H2WgLPZNeJT1O?= =?us-ascii?q?mT827Dz8tU9w938cDY19zFNqsgR3Oxy2kDaENmryTA5w09qLd32TvKMlhy3bG0?= =?us-ascii?q?qghj0A7QsRRL2GmgbR/9wfLCoHTl0WWjaCqeb4H3CHR9GeDyGuOvF1EUANrSqr?= =?us-ascii?q?FWm0fZk3Kotvn/UPOVbquBLsoMwdbzs6CMKRKZsXzjVpaXPfjJMjeY2WplmisH?= =?us-ascii?q?xmIw7eMYJPue2UcxyXdFFMJkxsT/HaDLQgxHD2to2PYDDx0FFLgeVng8edkqCD?= =?us-ascii?q?zckhhhQWVaQcpg76q/DYRmvraTf4PiPZM8iw+rX88VAK2wNT+D9ubuxEnfalNZ?= =?us-ascii?q?dd7501IgyaRvAV4OtmkLrt+rl8YaQV++U30hDttDYAVuMwjqjsRxwp3KL6EmAd?= =?us-ascii?q?Iczqem4v7OrjWNnXa5BererLb0VHY0c+L9+EI8vtu+Aarhx2gCkd3qyYv6NJSy?= =?us-ascii?q?XbJucSi5OU6W5XsVE067F5/+6GcZTMytdq8PZhEKa6woyPP0NIvBfI4x1CnZdg?= =?us-ascii?q?Nacts9Sf3A5RcH8+qOfAnkFivbwsZMaZV7qFmZqub?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ap+Qmy6GESFIfnDMkpLqEwceALOsnbusQ8zAX?= =?us-ascii?q?PhhKOHlomszxra+TdYcgpHvJYVcqKQodcL+7Scq9qB/nmKKdgrNhR4tKPjOW2l?= =?us-ascii?q?dARbsKheCJ/9SKIUPDH5tmtZuIBJIeNDSfNzRHZI3BkW6F+p4bsb+6GLbBv5am?= =?us-ascii?q?855Cd3ATV51d?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpAgA9yf9gfSIeaIFaEwEBg3BTRwFfB?= =?us-ascii?q?VcWJCcKAoRFiQSIX4MohXOGVYd3hBCBEQNPEAEDAQ0qAQUOAQIEAQGEBFQCgn0?= =?us-ascii?q?CHgYBBTMTAgQVAQEFAQEBAgEDAwQBEwEBDxkISIVoDYI1DAwDA4N3ARgBCAplI?= =?us-ascii?q?wMUAQYDAhEBFwEUCgMBEwESFAYBgleDBwQBAweMY5wKgTKBAYNNAQMDDQMBDgk?= =?us-ascii?q?mhCOBEVINAhSBABeFblNIAYJqCINwAicQgVVEgRWCJFFugVIxSAwLAQEBAQEXg?= =?us-ascii?q?REBEQIBCBQNLYJhF4JNBIJNDgszAQEGKgwjLgsfAQEFGwIkEi0HBAEKGREVCgQ?= =?us-ascii?q?sHgEKOAIDjhSCdDEeB4wDgy+HBYJPkWosB4MpgTEGC4dggRWHOoUDboVsgR2DY?= =?us-ascii?q?0GBBooYlyEhlWqCHIZSCIECCYIzgz2DKIxnBwQEDoUagU0qgQ0/HgwHMxowQ4I?= =?us-ascii?q?1ATMJYA6OCSIWg0+CZIF1O4Jdgm8/MgIBAQENJgIGAQoBAQMJdQEBBRMLAYl0A?= =?us-ascii?q?QE?= X-IPAS-Result: =?us-ascii?q?A0BpAgA9yf9gfSIeaIFaEwEBg3BTRwFfBVcWJCcKAoRFiQS?= =?us-ascii?q?IX4MohXOGVYd3hBCBEQNPEAEDAQ0qAQUOAQIEAQGEBFQCgn0CHgYBBTMTAgQVA?= =?us-ascii?q?QEFAQEBAgEDAwQBEwEBDxkISIVoDYI1DAwDA4N3ARgBCAplIwMUAQYDAhEBFwE?= =?us-ascii?q?UCgMBEwESFAYBgleDBwQBAweMY5wKgTKBAYNNAQMDDQMBDgkmhCOBEVINAhSBA?= =?us-ascii?q?BeFblNIAYJqCINwAicQgVVEgRWCJFFugVIxSAwLAQEBAQEXgREBEQIBCBQNLYJ?= =?us-ascii?q?hF4JNBIJNDgszAQEGKgwjLgsfAQEFGwIkEi0HBAEKGREVCgQsHgEKOAIDjhSCd?= =?us-ascii?q?DEeB4wDgy+HBYJPkWosB4MpgTEGC4dggRWHOoUDboVsgR2DY0GBBooYlyEhlWq?= =?us-ascii?q?CHIZSCIECCYIzgz2DKIxnBwQEDoUagU0qgQ0/HgwHMxowQ4I1ATMJYA6OCSIWg?= =?us-ascii?q?0+CZIF1O4Jdgm8/MgIBAQENJgIGAQoBAQMJdQEBBRMLAYl0AQE?= X-IronPort-AV: E=Sophos;i="5.84,272,1620684000"; d="scan'208,217";a="389065180" X-MGA-submission: =?us-ascii?q?MDF7uu7H81lpCsyrSOrgV2d/o++yqY3EZKUOLV?= =?us-ascii?q?G4SttsUCI1B9Nn5/JaGqxodCATD+Sb9q921jVubkXMNycaQW75M7nIvn?= =?us-ascii?q?iR4iKEWzgf6dhig0ONXC7OXsr9VyNZs6FRVSEikvmaOwBIayPczRqRpL?= =?us-ascii?q?xQYzEZcfAAEHWzcahCavy48w=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; 27 Jul 2021 10:54:45 +0200 Received: from set (91-172-170-233.subs.proxad.net [91.172.170.233]) (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 1AA7E564825; Tue, 27 Jul 2021 10:54:42 +0200 (CEST) From: Alan Schmitt To: "lwn" , "cwn" , caml-list@inria.fr Date: Tue, 27 Jul 2021 10:54:41 +0200 Message-ID: <87fsw06sry.fsf@m4x.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Jul 27 10:54:44 2021 +0200 (CEST)) X-Spam-Flag: No, tests=bogofilter, spamicity=0.312683, queueID=0CDC156486C 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: 18544 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 July 20 to 27, 2021. 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 pyre-ast: full-fidelity Python parser in OCaml OCaml+Opam Images for Docker for Windows Borns a stream talking about OCaml/Reason & ReScript language An Update on the State of the PPX Ecosystem and `ppxlib''s Transition How to send email from Dream Old CWN pyre-ast: full-fidelity Python parser 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=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: Jia Chen 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 I am happy to announce the initial opam release of [`pyre-ast'], a Python parsing library. The library features its full-fidelity to the official Python spec. Apart from a few technical edge cases, as long as a given file can be parsed/rejected by the CPython interpreter, `pyre-ast' will be able to parse/reject it as well. Furthermore, abstract syntax trees obtained from `pyre-ast' is guaranteed to 100% match the results obtained by Python's own `ast.parse' API, down to every AST node and every line/column number. Another notable feature of this library is that it represents the Python syntax using the *tagless-final style*. This style typically offers more flexibility and extensibility for the downstream consumers of the syntax, and allow them to build up their analysis without explicitly constructing a syntax tree. That said, for developers who are less familiar with the tagless-final approach, we also offer alternative interfaces that operates on traditional syntax tree represented as algebraic data types. Documentation of the library can be found [here]. The reason why we can can claim full-conformance with CPython is really simple: the library is, under the hood, merely an OCaml wrapper around the parsing logic in CPython source code. The project was initially motivated to replace the custom `menhir'-based parser currently used in the Pyre type checker (hence the name), but I figured that it would be useful to release this as a standalone `opam' package to the community so other static Python analyzers or other DSLs with Python-based syntax can leverage it as well. The library has yet to be put into production for Pyre (I'm working on it though) so please do expect bugs/jankiness at times. Feedback and bug reports are very welcomed. Happy parsing! [`pyre-ast'] [here] OCaml+Opam Images for Docker for Windows =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: Antonin D=C3=A9cimo 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 glad to announce the availability of OCaml and opam [native Windows Container][windows-containers] images for Docker for Windows. This is the result of my hard work at Tarides, with precious help from @dra27, @talex5, @avsm, and the rest of the team. They can be found under the [ocaml/opam][hub] repository in the Docker Hub. Try them with [Docker for Windows][docker-for-windows]! Be sure to [switch Docker to Native Windows Containers][enable-native]. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 docker run -it ocaml/opam:windows-mingw =E2=94=82 docker run -it ocaml/opam:windows-msvc =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 We provide images for the mingw-w64 (from OCaml 4.02 to 4.12) and the MSVC (from OCaml 4.06 to 4.12) ports. They are based on each release of Windows 10 amd64 currently supported by [Microsoft on the Docker Hub][mcr]. The images use opam 2.0, and we plan to update to opam 2.1 when it's released. The images also ship a [Cygwin][cygwin] installation, [Git for Windows][git-for-windows], and the [winget package manager][winget]. We use @fdopen's [OCaml for Windows][ocaml-for-windows] distribution and opam-repository fork. As it is getting deprecated at the end of August 2021, we'll transition to opam 2.1 and the standard opam-repository when that happens. In order to get the correct environment for any `RUN' command involving OCaml or opam, prefix the command with =E2=80=A2 `ocaml-env exec --64 --' if based on mingw-w64; or =E2=80=A2 `ocaml-env exec --64 --ms=3Dvs2019 --' if based on MSVC. The images are built at , using an [OCurrent][ocurrent] pipeline that [builds Docker images][docker-base-images]. You can rebuild them yourself using the [OCluster][ocluster] set of tools that I have ported to Windows. We provide a comprehensive set of tags (replace _port_ with either _mingw_ or _msvc_): =E2=80=A2 `windows-port': the latest version of OCaml for each Windows version; =E2=80=A2 `windows-port-winver': the latest version of OCaml for Windows = 10 _winver_; =E2=80=A2 `windows-port-ocaml-mlver': OCaml version _mlver_ for each Wind= ows version; =E2=80=A2 `windows-port-winver-ocaml-mlver': OCaml version _mlver_ for Wi= ndow 10 _winver_. When the Windows version is not specified in the tag, the image is a multiarch image that will work on every supported version of Windows 10. Docker automatically selects the appropriate one based on the host version. We will be using these images in the upcoming `ocaml-ci' and `opam-repo-ci' for Windows. Further work on these include the transition to opam 2.1, and we'll provide the Cygwin port of OCaml when it's fixed upstream and available in the Cygwin package repository. Happy hacking! Borns a stream talking about OCaml/Reason & ReScript language =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=E2=95=90=E2= =95=90=E2=95=90=E2=95=90 Archive: David Sancho 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 I'm very excited to announce starting a new show in Twitch to bring OCaml, Reason and ReScript community best brains to casually talk. It's called emelleTV It's made by [@fakenickels] and myself [@davesnx], and we will try to do our best! Our first guest is [@___zth___] We go live on [http://twitch.tv/emelletv] next Wednesday. Subscribe to not miss it! Thanks for reading, hope to see you there! [@fakenickels] [@davesnx] [@___zth___] [http://twitch.tv/emelletv] An Update on the State of the PPX Ecosystem and `ppxlib''s Transition =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=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: Sonja Heinze 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 I hope you're all having a nice summer (or a nice whichever season you're in, of course)! We've set up a new [wiki page on the ppxlib repository] containing a status overview of the current `ppxlib' transition, which aims at keeping the PPX ecosystem always up-to-date. We'll keep that wiki page up-to-date, as well. @jeremiedimino and @NathanReb have already explained our three-part plan for this transition in different posts here on discuss. Nothing has changed in that plan, but it has been a while since we [last posted about the overall transition] and even longer since we [last posted about the `Astlib' transition in detail]. So if you want, you can refresh your memory about that transition and get updated about its current state (in more detail than the new wiki page) by reading this post. [wiki page on the ppxlib repository] [last posted about the overall transition] [last posted about the `Astlib' transition in detail] Which Issues `ppxlib' was Facing =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=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 With `ocaml-migrate-parsetree' (`OMP'), the PPX ecosystem became cross-compiler-compatible. With `ppxlib', the latest compiler features were supported more easily and broadly within the PPX ecosystem, while `ppxlib' also brought along other improvements such as the one in performance and the clear composition semantics when using several PPXs. With that, both `OMP' and `ppxlib' have taken away several maintenance burdens from the PPX maintainers and have created a more homogeneous and up-to-date PPX ecosystem. However, we were facing the following issues: 1. To keep the PPX ecosystem cross-compiler compatible 1. `ppxlib' was handling parts of the unstable `compiler-libs' API to abstracting them away; 2. the `OMP~/~ppxlib' maintainers needed to keep the AST migration information up-to-date by coordination with the compiler devs. 2. To guarantee new feature support, `ppxlib' needed to bump the `ppxlib' AST to the newest version. 3. Bumping the AST implies a breaking change. That was an issue for a homogeneous and up-to-date PPX ecosystem. 4. Not all PPXs migrated from `OMP' to `ppxlib'. That was also an issue for a homogeneous and up-to-date PPX ecosystem. Some time ago, there was the very ambitious plan of tackling Issues 1, 2, and 3 all at once by writing a stable AST abstraction and upstreaming it to the compiler. That plan has been put on ice for now. Instead we're currently on track with a more down-to-earth plan, outlined below. Tackling the Issues in Three Parts =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=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=E2=95=8C=E2= =95=8C The plan we're currently following contains three simultaneous parts. It approaches three of the four issues I've pointed out above. However, it leaves the need to bump the AST (Issue 2) untouched. Part One: `Astlib' as an Interface between `ppxlib' and the Compiler =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84= =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84= =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84 The first part works towards continuous cross-compiler compatibility (Issue 1 above) while making the situation of still having PPXs based on `OMP' (Issue 4 above) even more of a problem. It consists of implementing an interface module called `Astlib' between `ppxlib' and the compiler, then upstreaming it to the compiler. As long as `Astlib' is stable and up-to-date, the rest of `ppxlib' won't be affected by any compiler changes=E2=80=94neither by new AST versions nor by compiler library changes. The first step of this part of the plan was moving the `OMP' driver and other `OMP' features from `OMP' to `ppxlib'. That was done in August 2020, and it introduced `OMP2'. Since the PPX driver has to be unique, this was the start of having the PPX ecosystem split into the two incompatible worlds of `OMP1' PPXs on one hand and `ppxlib' PPXs on the other hand. By now, we have written [`Astlib' as an internal `ppxlib' library] and have reduced `ppxlib''s compiler library usage as much as possible to keep `Astlib' minimal. As you can see, it contains a minimal compiler library sub-API in addition to the former `OMP' modules of our supported ASTs and the migration information between them. We will upstream `Astlib' to the compiler asking for it to be kept stable and up-to-date, while also keeping our local copy for old compiler support. [`Astlib' as an internal `ppxlib' library] Part Two: Sending Patch PRs when Bumping the AST =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84= =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84 So, thanks to Part One of the plan, `ppxlib' will always be compatible with the development compiler _OCaml trunk_ and the newest compiler version. However, to also support the newest compiler features, we need to bump the internal `ppxlib' AST to the newest version. That modifies some of the AST nodes and so it breaks any PPX that rewrites one of those nodes (Issue 3 above). Usually just a handful of PPXs are affected, but we still want them to be up-to-date. Our current plan doesn't provide a solution for that problem, but it does make handling the problem more efficient and, once again, it takes away the burden from the PPX maintainers. Since the AST bump to `4.10', whenever we bump the AST, we send patch PRs to the PPXs we break. Not much has changed since February, when @NathanReb last [explained our workflow of sending patch PRs] in detail. To some it up: we create a workspace with all `ppxlib' reverse dependencies on opam fulfilling a certain standard, which we call the _ppx-universe_. We then fix the PPXs that break all at once and open the PRs. Lately, the _ppx-universe_ has also proven very useful to make well-founded decisions regarding our API by having an easy look at our reverse dependencies. You can find a [_ppx-universe_ snapshot], currently from March, on our repo. In our experience, once the _ppx-universe_ is created and "builds up to the expected breakages," writing a couple of patches takes very little time, so we plan to make the tooling that creates and interacts with the workspace more sophisticated. [explained our workflow of sending patch PRs] [_ppx-universe_ snapshot] Part Three: Porting PPXs to Put an End to the "Split-World Situation" =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84= =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84= =E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2= =94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94=84=E2=94= =84=E2=94=84=E2=94=84 As explained above, Part One split the PPXs into the two incompatible worlds of `OMP1' PPXs on one hand and `ppxlib' PPXs on the other hand. That made the fact that some PPXs were still based on `OMP' (Issue 4 above) even more of a problem. For some PPX maintainers, the reason to avoid porting their PPXs to `ppxlib' was that `ppxlib' depended on `base' and `stdio', so we decided to tackle this situation by three means: =E2=80=A2 Dropping the `base' and the `stdio' dependencies, which was don= e in August last year. Now, all dependencies are the very basic `ocaml', `dune', `ocaml-compiler-libs', `stdlib-shims', `sexplib0' and `ppx_derivers'. =E2=80=A2 Porting and reviewing some of the most important PPXs ourselves= . So far we've ported `js_of_ocaml', `bisect_ppx', and `tyxml' with the help of the respective maintainers, and we've also reviewed several ports. =E2=80=A2 Spreading the word about the need to port PPXs and asking for h= elp. About a year ago, we made a non-exhaustive [list of PPXs that needed to be ported]. Since then, this community has proven to be awesome and there has been an amazing porting effort by a lot of people. So by now, all packages on that list have been ported with the exception of one(*). So hopefully the "split world" situation can soon be considered past. :tada: By the way, thanks to all involved in porting PPXs to `ppxlib'! It has been a great joint effort so far. :heart: And if anyone still has or comes across a project somewhere that needs porting and wants to port it, that's awesome! You can find the full list of opam packages that are still stuck in the `OMP1' world by [filtering for them in opam's health check pipeline]. However, notice that that's a generated list, so it also contains libraries that intrinsically form part of the `OMP1' ecosystem (such as `ppx_tools_versioned'), PPXs that have already been ported but haven't relesed their port on opam yet (such as `graphql_ppx'), deprecated PPXs that aren't marked as deprecated yet (such as `mirage-dns'), and several PPXs that only transitively depend on `OMP1'. (*) `ppx_import' has a PR for a port to `ppxlib', but it's not quite ready to be merged just yet. [list of PPXs that needed to be ported] [filtering for them in opam's health check pipeline] How to send email from Dream =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: Joe Thomas 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 I=E2=80=99ve written a short [blog post ] about what I learned building s= imple email features for a web server written in the Dream framework. The accompanying source code is available here: I=E2=80=99m interested in adding more examples and tutorials to the OCaml ecosystem and would be happy to get your feedback, positive or negative, on this write-up (here or via email/github/discord). [blog post ] 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<= /a> Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of July 20 to 27, 2021.

pyre-ast: full-fidelity Python parser in OCaml

Archive: https://discuss.ocaml.org/t/ann-pyre-ast-ful= l-fidelity-python-parser-in-ocaml/8177/1

Jia Chen announced

I am happy to announce the initial opam release of pyre-ast= , a Python parsing library.

The library features its full-fidelity to the official Python spec. Apart f= rom a few technical edge cases, as long as a given file can be parsed/rejected by the= CPython interpreter, pyre-ast will be able to parse/reject it as well.= Furthermore, abstract syntax trees obtained from pyre-ast is guaranteed to 100% match the r= esults obtained by Python's own ast.parse API, down to every AST node and every line/colum= n number.

Another notable feature of this library is that it represents the Python sy= ntax using the tagless-final style. This style typically offers more flexibility an= d extensibility for the downstream consumers of the syntax, and allow them to build up their analys= is without explicitly constructing a syntax tree. That said, for developers who are le= ss familiar with the tagless-final approach, we also offer alternative interfaces that opera= tes on traditional syntax tree represented as algebraic data types.

Documentation of the library can be found here.

The reason why we can can claim full-conformance with CPython is really sim= ple: the library is, under the hood, merely an OCaml wrapper around the parsing logic in CPy= thon source code. The project was initially motivated to replace the custom menhir-based parser currently used in the Pyre type checker (hence the name), but I figured that it would= be useful to release this as a standalone opam package to the community so = other static Python analyzers or other DSLs with Python-based syntax can leverage it as well.

The library has yet to be put into production for Pyre (I'm working on it t= hough) so please do expect bugs/jankiness at times. Feedback and bug reports are very welcom= ed.

Happy parsing!

OCaml+Opam Images for Docker for Windows

Archive: https://discuss.ocaml.org/t/ann-ocaml-opam-images= -for-docker-for-windows/8179/1

Antonin D=C3=A9cimo announced

I'm glad to announce the availability of OCaml and opam [native Windows Container][windows-containers] images for Docker for Windows. This is the r= esult of my hard work at Tarides, with precious help from @dra27, @talex5, @avsm, and the re= st of the team.

They can be found under the [ocaml/opam][hub] repository in the Docker Hub.= Try them with [Docker for Windows][docker-for-windows]! Be sure to [switch Docker to Nati= ve Windows Containers][enable-native]. 

docker run -it ocaml/opam:windows-mingw
docker run -it ocaml/opam:windows-msvc

We provide images for the mingw-w64 (from OCaml 4.02 to 4.12) and the MSVC = (from OCaml 4.06 to 4.12) ports. They are based on each release of Windows 10 amd64 currentl= y supported by [Microsoft on the Docker Hub][mcr]. The images use opam 2.0, and we plan to= update to opam 2.1 when it's released. The images also ship a [Cygwin][cygwin] installatio= n, [Git for Windows][git-for-windows], and the [winget package manager][winget].

We use @fdopen's [OCaml for Windows][ocaml-for-windows] distribution and op= am-repository fork. As it is getting deprecated at the end of August 2021, we'll transiti= on to opam 2.1 and the standard opam-repository when that happens.

In order to get the correct environment for any RUN command in= volving OCaml or opam, prefix the command with

  • ocaml-env exec --64 -- if based on mingw-w64; or
  • ocaml-env exec --64 --ms=3Dvs2019 -- if based on MSVC.

The images are built at https= ://base-images.ocamllabs.io/, using an [OCurrent][ocurrent] pipeline that [builds Docker images][docker-base-images]. You can rebuild t= hem yourself using the [OCluster][ocluster] set of tools that I have ported to Windows.

We provide a comprehensive set of tags (replace p= ort with either mingw or msvc):

  • windows-port: the latest version of OCaml for each Windows= version;
  • windows-port-winver: the latest version of OCaml for Windo= ws 10 winver;
  • windows-port-ocaml-mlver: OCaml version mlver for each Windows version;
  • windows-port-winver-ocaml-mlver: OCaml version mlver for Window 10 winver<= /span>.

When the Windows version is not specified in the tag, the image is a multia= rch image that will work on every supported version of Windows 10. Docker automatically se= lects the appropriate one based on the host version.

We will be using these images in the upcoming ocaml-ci and opam-repo-ci for Windows.

Further work on these include the transition to opam 2.1, and we'll provide= the Cygwin port of OCaml when it's fixed upstream and available in the Cygwin package repos= itory.

Happy hacking!

Borns a stream talking about OCaml/Reason & ReScript langu= age

Archive: https://discuss.ocaml.org/t/an= n-borns-a-stream-talking-about-ocaml-reason-rescript-language/8185/1

David Sancho announced

I'm very excited to announce starting a new show in Twitch to bring OCaml, = Reason and ReScript community best brains to casually talk. It's called emelleTV

It's made by @fakenickels a= nd myself @davesnx, and we will try to do= our best!

Our first guest is @___zth___

3D=

We go live on http://twitch.tv/emelle= tv next Wednesday. Subscribe to not miss it!

Thanks for reading, hope to see you there!

An Update on the State of the PPX Ecosystem and ppxlib's Transition

Archive: https://discuss.ocaml.org/= t/an-update-on-the-state-of-the-ppx-ecosystem-and-ppxlib-s-transition/8200/= 1

Sonja Heinze announced

I hope you're all having a nice summer (or a nice whichever season you're i= n, of course)! We've set up a new wiki page on the ppxlib repository containing a status overview of the current ppxlib transition,= which aims at keeping the PPX ecosystem always up-to-date. We'll keep that wiki page up-to-date, as w= ell.

@jeremiedimino and @NathanReb have already explained our three-part plan fo= r this transition in different posts here on discuss. Nothing has changed in that plan, but i= t has been a while since we last posted about the overall transition and even longer since we last posted about the Astlib transition in detail. So if you want, you can refresh your memory about that transition and get updated about its cur= rent state (in more detail than the new wiki page) by reading this post.

Which Issues ppxlib was Facing

With ocaml-migrate-parsetree (OMP), the PPX ecosy= stem became cross-compiler-compatible. With ppxlib, the latest compiler features were supported more = easily and broadly within the PPX ecosystem, while ppxlib also brought along other improveme= nts such as the one in performance and the clear composition semantics when using several PPXs. Wi= th that, both OMP and ppxlib have taken away several maintenanc= e burdens from the PPX maintainers and have created a more homogeneous and up-to-date PPX ecosystem. However, we w= ere facing the following issues:

  1. To keep the PPX ecosystem cross-compiler compatible
    1. ppxlib was handling parts of the unstable compiler-l= ibs API to abstracting them away;
    2. the OMP~/~ppxlib maintainers needed to keep the AST migrat= ion information up-to-date by coordination with the compiler devs.
  2. To guarantee new feature support, ppxlib needed to bump th= e ppxlib AST to the newest version.
  3. Bumping the AST implies a breaking change. That was an issue for a homo= geneous and up-to-date PPX ecosystem.
  4. Not all PPXs migrated from OMP to ppxlib. Tha= t was also an issue for a homogeneous and up-to-date PPX ecosystem.

Some time ago, there was the very ambitious plan of tackling Issues 1, 2, a= nd 3 all at once by writing a stable AST abstraction and upstreaming it to the compiler. Tha= t plan has been put on ice for now. Instead we're currently on track with a more down-to-ea= rth plan, outlined below.

Tackling the Issues in Three Parts

The plan we're currently following contains three simultaneous parts. It ap= proaches three of the four issues I've pointed out above. However, it leaves the need to bump= the AST (Issue 2) untouched.

Part One: Astlib as an Interface between= ppxlib and the Compiler

The first part works towards continuous cross-compiler compatibility (Issue= 1 above) while making the situation of still having PPXs based on OMP (Issue = 4 above) even more of a problem. It consists of implementing an interface module called Astli= b between ppxlib and the compiler, then upstreaming it to the compiler. As long as Astlib<= /code> is stable and up-to-date, the rest of ppxlib won't be affected by any compil= er changes=E2=80=94neither by new AST versions nor by compiler library changes.

The first step of this part of the plan was moving the OMP dri= ver and other OMP features from OMP to ppxlib. That was done in August 2020,= and it introduced OMP2. Since the PPX driver has to be unique, this was the start of having the PPX ecosystem spl= it into the two incompatible worlds of OMP1 PPXs on one hand and ppxlib<= /code> PPXs on the other hand.

By now, we have written Astlib as an internal ppxlib library and have reduced ppxlib's compiler library usage as much as possible to keep Astlib mini= mal. As you can see, it contains a minimal compiler library sub-API in addition to the former OMP modules of our supported ASTs and the migration information between them. We will upstream= Astlib to the compiler asking for it to be kept stable and up-to-date, while also keeping= our local copy for old compiler support.

Part Two: Sending Patch PRs when Bumping the AST

So, thanks to Part One of the plan, ppxlib will always be comp= atible with the development compiler OCaml trunk and the newest compil= er version. However, to also support the newest compiler features, we need to bump the internal ppxlib AST to = the newest version. That modifies some of the AST nodes and so it breaks any PPX that rewrites one o= f those nodes (Issue 3 above). Usually just a handful of PPXs are affected, but we still = want them to be up-to-date.

Our current plan doesn't provide a solution for that problem, but it does m= ake handling the problem more efficient and, once again, it takes away the burden from the P= PX maintainers. Since the AST bump to 4.10, whenever we bump the AST, we send = patch PRs to the PPXs we break. Not much has changed since February, when @NathanReb last = ppx-universe. We then fix the PPXs that break all at once and open the PRs.

Lately, the ppx-universe has also proven v= ery useful to make well-founded decisions regarding our API by having an easy look at our reverse dependencies. You c= an find a ppx-universe snapshot, currently from March, on our repo.

In our experience, once the ppx-universe i= s created and "builds up to the expected breakages," writing a couple of patches takes very little time, so we plan = to make the tooling that creates and interacts with the workspace more sophisticated.

Part Three: Porting PPXs to Put an End to the "Split-= World Situation"

As explained above, Part One split the PPXs into the two incompatible world= s of OMP1 PPXs on one hand and ppxlib PPXs on the other hand. That made the f= act that some PPXs were still based on OMP (Issue 4 above) even more of a problem. For some = PPX maintainers, the reason to avoid porting their PPXs to ppxlib was that ppxlib depended on base and stdio, so we decided to tackle this situation by three means:

  • Dropping the base and the stdio dependencies,= which was done in August last year. Now, all dependencies are the very bas= ic ocaml, dune, ocaml-compiler-libs,= stdlib-shims, sexplib0 and ppx_derivers.
  • Porting and reviewing some of the most important PPXs ourselves. So far= we've ported js_of_ocaml, bisect_ppx, and = tyxml with the help of the respective maintainers, and we've also re= viewed several ports.
  • Spreading the word about the need to port PPXs and asking for help.

About a year ago, we made a non-exhaustive list of PPXs = that needed to be ported. Since then, this community has proven to be awesome and there has been an a= mazing porting effort by a lot of people. So by now, all packages on that list have been p= orted with the exception of one(*). So hopefully the "split world" situation can soon be c= onsidered past. :tada:

By the way, thanks to all involved in porting PPXs to ppxlib! = It has been a great joint effort so far. :heart: And if anyone still has or comes across a project so= mewhere that needs porting and wants to port it, that's awesome!

You can find the full list of opam packages that are still stuck in the OMP1 world by filtering for them in opam's health check pipeline. However, notice that that's a generated list, so it also contains libraries= that intrinsically form part of the OMP1 ecosystem (such as p= px_tools_versioned), PPXs that have already been ported but haven't relesed their port on opam yet (such a= s graphql_ppx), deprecated PPXs that aren't marked as deprecated yet (such as mirage-= dns), and several PPXs that only transitively depend on OMP1.

(*) ppx_import has a PR for a port to ppxlib, but= it's not quite ready to be merged just yet.

How to send email from Dream

Archive: https://discuss.ocaml.org/t/how-to-send-email-from-dream/8201/1

Joe Thomas announced

I=E2=80=99ve written a short blog post about what I learned building simple email features for a web server written in the Drea= m framework. The accompanying source code is available here:

https://github.= com/jsthomas/dream-email-example

I=E2=80=99m interested in adding more examples and tutorials to the OCaml e= cosystem and would be happy to get your feedback, positive or negative, on this write-up (here or= via email/github/discord).

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 <= a href=3D"https://alan.petitepomme.net/cwn/cwn.rss">RSS feed of the archive= s.

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

--=-=-=--