Hello Here is the latest OCaml Weekly News, for the week of October 05 to 12, 2021.
Table of Contents ───────────────── Release of ocaml-sf/learn-ocaml:0.13.0 Release of odoc 2.0.0 The road to OCaml 5.0 Become an Outreachy Mentor: support the growth and diversity of the OCaml community Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0) first release of osh: <https://osh.ocamlpro.com> first release of pyast Multiple open positions (postdoc, PhD, intern) on runtime verification at CEA LIST, France Postdoc position in Effect Handler Oriented Programming OCaml compiler development newsletter, issue 3: June-September 2021 Odig 0.0.7, lookup documentation of installed OCaml packages OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central) Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0! Alcotest 1.5.0 Other OCaml News Old CWN Release of ocaml-sf/learn-ocaml:0.13.0 ══════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-ocaml-sf-learn-ocaml-0-13-0/8577/1> Erik Martin-Dorel announced ─────────────────────────── We are very pleased to announce the immediate availability of the latest stable release of [Learn-OCaml], version `0.13.0'. Many thanks to all users and developers that reported bugs, contributed features or patches ✨ and in particular, special thanks go to @yurug and @AltGr for their precious advice and help during the preparation of this release. A (mostly) comprehensive list of the features, fixes, and enhancements offered by this release is available in [the Release Notes]. Beyond this list of changes, note that: • We now switch to *semantic versioning*, so that this version is git-tagged `v0.13.0' and not just `0.13'. • The REST API did *not* change (between the previous stable version 0.12 and version 0.13.0). • The *"exodir" format* has been slightly extended (but the [documentation online] of these changes is not yet up-to-date), keeping a strong focus on backward-compatibility (see e.g. [PR #397] for related remarks). • All the main *binaries of Learn-OCaml* (`learn-ocaml-client', `learn-ocaml', and the native `learn-ocaml-server') are now statically built and available in the [*Release page*], for Linux and macOS. • The whole codebase of Learn-OCaml has been ported to *OCaml 4.12* (including the toplevel environment that is exposed to students). • We now *relax the coupling between client/server*, and commit to *keeping backward-compatibility* for the latest `learn-ocaml-client' w.r.t. the previous versions (so, `learn-ocaml-client.0.13.0' can interact with servers `learn-ocaml.{0.12, 0.13.0}' smoothly − see [PR #426] for context). • The `learn-ocaml-client' CLI API did not change, except that a command *`learn-ocaml-client server-version'* has been added, to distinguish between the server version and the (possibly more recent) `learn-ocaml-client --version' (see [PR #429] for details). • Docker images are still available on [*Docker Hub*], e.g., to easily spin a local server from a repository exercises, you can do: ┌──── │ sudo docker run --name=server-test -v "$PWD/demo-repository:/repository:ro" \ │ -p 8080:8080 ocamlsf/learn-ocaml:0.13.0 └──── More details on the Docker setup can be found in [How to deploy a learn-ocaml instance]. • (If you migrate from `0.12' to `0.13.0' in your deployments, beware that the mere bump of OCaml's version may cause some of your graders to fail.) • A [dedicated PR] has also been opened in *opam-repository*. • As noted above, several architectural changes have been done about the `learn-ocaml-client' as this tool plays a key "pivot" role, for students that would like to use *Tuareg+Merlin+[learn-ocaml-mode]* and interact with a Learn-OCaml server backend directly from Emacs (and thus benefit from the advantages of both Merlin and Learn-OCaml's exercise grading feature). We hope to be able to release 0.14.0 soon, specifically to integrate the pending PR [#372] that will solve a [long-running issue] with auto-`Sync' and students-code overwriting; and we also plan to extend learn-ocaml's backend and REST API soon to further enhance the UX of *learn-ocaml.el*, at least to lift [this limitation] (for which we have a working proof-of-concept to be refined). If need be, feel free to open issues in the [Learn-OCaml bug tracker (GH)] or post in this thread to share thoughts or experience-feedback. [Learn-OCaml] <https://github.com/ocaml-sf/learn-ocaml> [the Release Notes] <https://github.com/ocaml-sf/learn-ocaml/releases/tag/v0.13.0> [documentation online] <https://ocaml-sf.org/learn-ocaml/tutorials/step-0.html> [PR #397] <https://github.com/ocaml-sf/learn-ocaml/pull/397> [*Release page*] <https://github.com/ocaml-sf/learn-ocaml/releases/> [PR #426] <https://www.github.com/ocaml-sf/learn-ocaml/issues/426> [PR #429] <https://github.com/ocaml-sf/learn-ocaml/pull/429> [*Docker Hub*] <https://hub.docker.com/r/ocamlsf/learn-ocaml> [How to deploy a learn-ocaml instance] <https://ocaml-sf.org/learn-ocaml/howto-deploy-a-learn-ocaml-instance.html> [dedicated PR] <https://github.com/ocaml/opam-repository/pull/19698> [learn-ocaml-mode] <https://github.com/pfitaxel/learn-ocaml.el> [#372] <https://github.com/ocaml-sf/learn-ocaml/pull/372> [long-running issue] <https://github.com/ocaml-sf/learn-ocaml/issues/316> [this limitation] <https://github.com/pfitaxel/learn-ocaml.el/blob/master/README.md#known-limitations> [Learn-OCaml bug tracker (GH)] <https://github.com/ocaml-sf/learn-ocaml/issues/new/choose> Release of odoc 2.0.0 ═════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-of-odoc-2-0-0/8582/1> Jon Ludlam announced ──────────────────── Hot on the heels of the OCaml 4.13 announcement(s!), the `odoc' team is pleased to announce the release of `odoc 2.0.0'! *tl;dr:* The new version produces [much better output] than [the old version], it's the engine at the core of the package docs in [v3.ocaml.org], and it also has a [new website]. This release has been a long time coming – years! – and contains several notable improvements over the `odoc 1.5' series: a new language model, a new rendering layer allowing output in several formats, and improved control over the output structure. [much better output] <https://ocaml-doc.github.io/odoc-examples/core_kernel/Core_kernel/Bigbuffer/index.html> [the old version] <https://ocaml.janestreet.com/ocaml-core/latest/doc/core_kernel/Core_kernel/Bigbuffer/index.html> [v3.ocaml.org] <https://v3.ocaml.org/packages> [new website] <https://ocaml.github.io/odoc> New Features ╌╌╌╌╌╌╌╌╌╌╌╌ New Language Model ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ The internal library used by `odoc' that models the OCaml module system has been completely rewritten over a multi-year effort by @jonludlam and @Julow, according to a design by @lpw25. The rewrite gives `odoc' a much better understanding of the module system compared to the original implementation. This library is used for two main processes: 1. To perform _expansions_, which is the process where `odoc' takes complex module type expressions like [this one from tyxml]: ┌──── │ module Make │ (Xml : Xml_sigs.T with type ('a, 'b) W.ft = 'a -> 'b) │ (Svg : Svg_sigs.T with module Xml := Xml) │ : Html_sigs.Make(Xml)(Svg).T │ with type +'a elt = Xml.elt │ and type +'a attrib = Xml.attrib └──── Then turns it into an [output page] containing the correct types, values, modules, includes, and documentation. 2. To perform *resolutions*, which is where `odoc' handles complex paths found in OCaml source in order to calculate the correct definition link. For example, in the following snippet: ┌──── │ module type A = sig │ module M : sig module type S end │ module N : M.S │ end │ │ module B : sig module type S = sig type t end end │ │ module C : A with module M = B with type N.t = int │ │ type t = C.N.t └──── resolution is the process by which `odoc' determines which documentation page to take you when you click on `C.N.t'. The new model has logic to handle many features of the OCaml language, as can be explored [here]. A particularly important improvement is in handling canonical modules (explained in the link above). The upshot of this is that there should never be any more odd double underscores leaking into your docs! For some more info on this, as well as the new output renderers, see [our talk at the OCaml workshop last year] [this one from tyxml] <https://ocaml.github.io/odoc/deps/tyxml/Html_f/index.html#module-Make> [output page] <https://ocaml.github.io/odoc/deps/tyxml/Html_f/Make/index.html> [here] <http://ocaml.github.io/odoc/features.html> [our talk at the OCaml workshop last year] <https://watch.ocaml.org/videos/watch/2acebff9-25fa-4733-83cc-620a65b12251> New Output Renderers ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ @Drup put a considerable amount of work into replacing the `odoc 1.5' custom HTML generator with a new rendering layer. This features a new intermediate format allowing new output formats to be added far more easily than before. Included in `odoc 2.0' are renderers for HTML and man pages (both contributed by @Drup) and LaTeX (contributed by @Octachron). The LaTeX renderer has already been integrated into the OCaml build process to generate docs (see <https://github.com/ocaml/ocaml/pull/9997> and related PRs). @jonludlam also made an alternative HTML renderer designed specifically for [v3.ocaml.org]. Finally, a new markdown renderer is being prepared by @lubega-simon and should land in the next release. We look forward to many new renderers being created for the varied use cases present in the community! [v3.ocaml.org] <https://v3.ocaml.org/packages> Output Structure ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ `odoc 2.0' introduces a new mechanism to specify the structure of the files produced. Although it's a relatively simple new feature, it nevertheless has enabled `odoc' to be used in new ways. In particular, it has allowed `odoc' to construct the package documentation for the new OCaml website, [v3.ocaml.org]. There is also an [example driver], showing how `odoc' can be used to construct a stand-alone website for an OCaml package that contains fully-linked documentation for a package and all of its dependencies. This has been used to create `odoc''s [new website]. [v3.ocaml.org] <https://v3.ocaml.org/packages> [example driver] <https://ocaml.github.io/odoc/driver.html> [new website] <https://ocaml.github.io/odoc> New Drivers ┄┄┄┄┄┄┄┄┄┄┄ Like the OCaml compiler itself, running `odoc' on your code requires careful sequencing of the invocations to produce the correct result. Fortunately both `dune' and `odig' understand how to do this, so most users don't need to know the details. If you want more than these tools provide though, we've written a simple [reference driver], documenting exactly what's necessary to use `odoc' to produce rich documentation. A more complete (and more complex) example is the tool [voodoo], which is being used to create the docs for [v3.ocaml.org]. [reference driver] <https://ocaml.github.io/odoc/driver.html> [voodoo] <https://github.com/ocaml-doc/voodoo> [v3.ocaml.org] <https://v3.ocaml.org/packages> [v3.ocaml.org] ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ As previously posted, the new version of the OCaml website has been under development for some time now, and an important new feature is the integration of package listings, including documentation for every version of every package. More has been written about this elsewhere, but it's important to note that the new OCaml.org website required a preview version of `odoc 2.0' to work. We've made a few bug fixes since then, so we will update the pipeline to use the released version very soon. For more info on the pipeline to build the docs, see [our recent talk] at this year's OCaml Workshop. [v3.ocaml.org] <https://v3.ocaml.org> [our recent talk] <https://watch.ocaml.org/videos/watch/9bb452d6-1829-4dac-a6a2-46b31050c931> New Website ╌╌╌╌╌╌╌╌╌╌╌ The website for `odoc' has been improved with guides for [documentation authors], [integrators], and [contributors]. This site is intended to grow over time with more content to help people write docs for their packages. [documentation authors] <https://ocaml.github.io/odoc/odoc_for_authors.html> [integrators] <https://ocaml.github.io/odoc/driver.html> [contributors] <https://ocaml.github.io/odoc/contributors.html> OCamldoc? ╌╌╌╌╌╌╌╌╌ This release, particularly because of the new output renderers, puts `odoc' in a place where it supercedes OCamldoc in most respects. There are a few features we're missing (see [the comparison] in the docs), including most notably that we don't render the source (OCamldoc's `--keep-code' argument), and that there is no support for custom tags. If `odoc' is lacking features that you're currently relying on in OCamldoc, we'd love to hear from you! [the comparison] <https://ocaml.github.io/odoc/ocamldoc_differences.html> More Docs! ╌╌╌╌╌╌╌╌╌╌ Finally, I'd like to use this opportunity to launch an invitation. With [v3.ocaml.org] now showing all the package docs in their current state, I'd like to invite all our package authors, maintainers, contributors, and users to take a look over their favourite packages and see what the documentation looks like. Good documentation is one of the [most important requests] from the previous OCaml developer surveys, and with [v3.ocaml.org] as a new documentation hub, now is a great time to be making improvements where they're required. With this new release of `odoc', previewing your docs should be as simple as `dune build @doc'. Some packages already have great docs - a few examples are: • [brr] • [lwt] • [mimic] • [streaming] • [uucp] many others have more patchy docs. Let's fix that! We're also looking for more contributors to `odoc'. It's much improved now, but there's still [plenty more to do]. Come and join the fun! [v3.ocaml.org] <https://v3.ocaml.org/packages> [most important requests] <https://discuss.ocaml.org/t/suggestions-from-the-ocaml-survey-result/6791> [v3.ocaml.org] <https://v3.ocaml.org/> [brr] <https://v3.ocaml.org/p/brr/0.0.1/doc/ffi_manual.html> [lwt] <https://v3.ocaml.org/p/lwt/5.4.2/doc/index.html> [mimic] <https://v3.ocaml.org/p/mimic/0.0.3/doc/index.html> [streaming] <https://v3.ocaml.org/p/streaming/0.8.0/doc/index.html> [uucp] <https://v3.ocaml.org/p/uucp/13.0.0/doc/index.html> [plenty more to do] <https://github.org/ocaml/odoc/issues> The road to OCaml 5.0 ═════════════════════ Archive: <https://discuss.ocaml.org/t/the-road-to-ocaml-5-0/8584/1> octachron announced ─────────────────── With the convergence between the multicore and standard runtime across OCaml 4.10.0 to 4.13.0, the development of OCaml multicore has reached a point where further integration into OCaml's main branch requires fully committing to a switch to OCaml multicore. The OCaml team has decided that the time has come for such a commitment. The new major version, OCaml 5, will be a multicore version of OCaml. Moreover, OCaml 4.14 will be the last minor release of the 4.x series of OCaml. Multicore Minimum Viable Product ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The first version of OCaml multicore, code-named OCaml 5.0, will be a Minimum Viable Product focused on: • x86-64 • Linux, MacOS, Windows mingw-w64 • Parallelism through Domains [1] • Concurrency through Effect Handlers [2] (without syntactic support and exposed as functions from the standard library) Our plan is to integrate the multicore branch into the main branch during the next 6 months. Hopefully, OCaml 5.0 will then be released between March and April 2022. Note that OCaml 5.0 focuses on minimal (solid) support for the multicore runtime system, and will not provide stable user-facing concurrency and parallelism libraries. There has been a lot of experimentation ([3],[4]) in the last few years, and some work remains to offer long-term, user-facing concurrent and parallel programming abstractions. OCaml 5.0 will be a great time to start adding concurrency and parallelism to your OCaml programs, but the libraries will still be in flux. Long term support for OCaml 4.14 ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ While OCaml 5 is stabilising, we plan to extend the support period for OCaml 4.14 by publishing minor bugfix releases whenever needed. In particular, OCaml 4.14 will be supported until all tier-1 architectures and operating systems are available in OCaml 5, and OCaml 5 sequential performance is close enough to that of OCaml 4. The sequential glaciation ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ To ensure that maintainers can concentrate on Multicore integration, and avoid any rebase work for the Multicore developers, the trunk branch will be feature-frozen starting from November 2021. All non-bugfix non-multicore contributions will be delayed to after the Multicore integration. We are calling this period the "sequential glaciation". We understand that this may be frustrating for our contributors, and apologize for the delay in getting your nice work reviewed and merged into the codebase. We hope that the sequential glaciation will be a good opportunity to help with the Multicore integration, review and testing, and/or focus on non-core-compiler efforts and the rest of the OCaml ecosystem. With this early feature-freeze, we also plan to release OCaml 4.14.0 in advance, between January and February 2022, reducing the concurrency between the OCaml 5.0 and OCaml 4.14.0 releases. References ╌╌╌╌╌╌╌╌╌╌ • [1] "Retrofitting Parallelism onto OCaml", ICFP 2020, <https://arxiv.org/abs/2004.11663> • [2] "Retrofitting Concurrency onto OCaml", PLDI 2021, <https://arxiv.org/abs/2104.00250> • [3] Domainslib – Parallel Programming over Multicore OCaml, <https://github.com/ocaml-multicore/domainslib> • [4] eio – Effects-based Parallel IO for OCaml, <https://github.com/ocaml-multicore/eio> Become an Outreachy Mentor: support the growth and diversity of the OCaml community ═══════════════════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/become-an-outreachy-mentor-support-the-growth-and-diversity-of-the-ocaml-community/8213/14> Deep in this thread, Jon Ludlam announced ───────────────────────────────────────── I've also submitted a project for the winter session: "Create a tool to show differences in the output of odoc." The idea is to produce a tool to work on the output of the [ocaml-docs-ci pipeline] to find differences between different versions of the same package. We're aiming for it to eventually be used in the docs pages to highlight differences between versions in [v3.ocaml.org]. Just one of the neat things we've got in mind for the docs pages on the new website! As @tmattio points out, you don't have to be a mentor to contribute to the process - so let the odoc team know if you're interested in lending a hand. [ocaml-docs-ci pipeline] <https://github.com/ocurrent/ocaml-docs-ci> [v3.ocaml.org] <https://v3.ocaml.org/> Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0) ════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-windows-friendly-ocaml-4-12-distribution-2nd-preview-release-0-2-0/8488/2> jbeckford announced ─────────────────── 0.2.2 is now released. Some of the bigger changes: • (Bug Fixes) Many problems with Visual Studio have been resolved, especially for non-English installations. • (Features) Pre-alpha support for macOS and Windows 32-bit, in addition to the existing Windows 64-bit support. • (Reliability) There is now an [internal GitHub Actions CI system] that builds Windows 32-bit, Windows 64-bit and macOS (x64). In the future GitHub Actions will be offered to anyone who needs to test their own 32-bit and 64-bit Windows packages. • (Reliability) The Windows MinGW Opam repository vended by fdopen is still used but has been drastically pruned. Now the thousands of MinGW and DKML (MSVC) patches are pinned, and those pinned package versions are tested with the GitHub Actions CI system. To upgrade, just follow the [Two Step installation instructions] and then upgrade any of your Local Projects like `diskuv-ocaml-starter' with `./makeit build-dev' . The [v0.2.2 release notes] has a detailed list of changes. [internal GitHub Actions CI system] <https://github.com/diskuv/diskuv-ocaml-starter-ghmirror/actions/runs/1318976472> [Two Step installation instructions] <https://diskuv.gitlab.io/diskuv-ocaml/#two-step-installation-instructions> [v0.2.2 release notes] <https://gitlab.com/diskuv/diskuv-ocaml/-/releases/v0.2.2#022-2021-10-07> first release of osh: <https://osh.ocamlpro.com> ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-osh-https-osh-ocamlpro-com/8594/1> zapashcanon announced ───────────────────── I'm pleased to announce the first release of [osh], a website providing an API to generate SVG badges. E.g. this url: `https://osh.ocamlpro.com/badge?label=build&color=green&status=passing' will give the following result: [build passing]. We also have special support for GitHub actions, using `https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml' will give you the following: [build passing]. Even when using the special GitHub action endpoint, you can override any parameter, e.g. `https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml?color=blue' will give you the following: [build passing]. We're willing to add any other special endpoint if someone is interested. :) The [source code is available on OCamlPro's Gitlab], it's made with [ocb] for the badge generation part, [dream], [ezcurl], [omd], [crunch] and [Yojson]. There's also an [opam package] in case you want to host your own instance. Enjoy ! [osh] <https://osh.ocamlpro.com> [build passing] <https://osh.ocamlpro.com/badge?label=build&color=green&status=passing> [build passing] <https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml> [build passing] <https://osh.ocamlpro.com/badge/github/workflow/status/OCamlPro/swhid/build.yml?color=blue> [source code is available on OCamlPro's Gitlab] <https://gitlab.ocamlpro.com/OCamlPro/osh> [ocb] <https://github.com/OCamlPro/ocb> [dream] <https://github.com/aantron/dream> [ezcurl] <https://github.com/c-cube/ezcurl> [omd] <https://github.com/ocaml/omd> [crunch] <https://github.com/mirage/ocaml-crunch> [Yojson] <https://github.com/ocaml-community/yojson> [opam package] <https://opam.ocaml.org/packages/osh> first release of pyast ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-pyast/8596/1> Thierry Martinez announced ────────────────────────── I have the pleasure to announce the first release of [pyast], a library provides versioned abstract syntax tree for all Python versions from Python 2.5 to Python 3.10. Available on opam: `opam install pyast' The purpose of this library is very close to [pyre-ast], namely being able to give access from OCaml programs to the Python own parser and to the ASTs it builds. There are two main differences: • `pyre-ast' exposes the AST of Python 3.10 whereas `pyast' exposes the ASTs of all Python versions from Python 2.5 to Python 3.10 (in versioned modules _à la_ ocaml-migrate-parsetree), providing converters between them. The AST of the latest version of Python (currently, 3.10) is provided in `Pyast.Latest'. • `pyre-ast' embeds its own version of the Python interpreter, whereas `pyast' uses the Python interpreter available on the machine (via [pyml]), converting the AST to the expected version if necessary. The development of `pyast' was motivated when some handwritten code using [pyml] to access the Python parser broke after a Python upgrade because of a change in the AST! [pyast] <https://github.com/thierry-martinez/pyast/> [pyre-ast] <https://github.com/grievejia/pyre-ast> [pyml] <https://github.com/thierry-martinez/pyml/> Multiple open positions (postdoc, PhD, intern) on runtime verification at CEA LIST, France ══════════════════════════════════════════════════════════════════════════════════════════ Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2021-10/msg00010.html> Julien Signoles announced ───────────────────────── The Software Safety and Security Lab at CEA LIST (Université Paris-Saclay, France) is opening 2 postdoc, 1 PhD, and 1 internship positions in the area of runtime verification for code safety and security: • postdoc: Designing Compilation Techniques for Improving Efficiency of E-ACSL, a Runtime Assertion Checker for C Programs <https://julien-signoles.fr/positions/postdoc-eacsl.pdf> • postdoc: Control Flow Integrity for Remote Attestation <https://julien-signoles.fr/positions/postdoc-cfi.pdf> • PhD: Outline Runtime Assertion Checking (possibly preceded by an internship on the same topic if needed) <https://julien-signoles.fr/positions/phd-outline-rac.pdf> • internship: C Function Synthesis from Axiomatic Definitions (in French, please ask for an English version) <https://julien-signoles.fr/positions/master_axiomatics.pdf> The candidates will: • solve challenging research problems; • implement their results in Frama-C, an industrial-strength open-source framework for analyses of C code; • evaluate their solutions on concrete benchmarks or/and use cases; • publish their results in international conferences and journals. Strong knowledge in at least one of the following areas is always appreciated: • programming: OCaml and C, semantics of programming languages, … • formal verification: runtime verification, static analysis, … • compilation: code generation, program transformation, type system, … Interested applicants should send a CV and a motivation letter to Julien Signoles (julien dot signoles at cea dot fr) as soon as possible. Postdoc position in Effect Handler Oriented Programming ═══════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/job-postdoc-position-in-effect-handler-oriented-programming/8597/1> Daniel Hillerström announced ──────────────────────────── We have an opening for a post-doctoral research position at The University of Edinburgh on Effect Handler Oriented Programming (EHOP) funded by a UKRI Future Leaders Fellowship. Candidates should have a background in programming languages with experience of functional programming, formal semantics, and type theory. Some experience with effect handlers and algebraic effects is desirable, but not essential. The role will involve theory (e.g. developing and reasoning about novel effect type systems and algebraic theories) and practice (e.g. designing, implementing, and evaluating implementations and applications of effect handlers), and ample opportunity to engage with our project partners (several of whom are deeply involved with the development of OCaml). The position is for three years starting in February 2022. The EHOP project: <https://effect-handlers.org/> Job application details: <https://elxw.fa.em3.oraclecloud.com/hcmUI/CandidateExperience/en/sites/CX_1001/job/2087/> If you are interested then feel free to contact [Sam Lindley] (application deadline: 1 November 2021). [Sam Lindley] <mailto:sam.lind...@ed.ac.uk> OCaml compiler development newsletter, issue 3: June-September 2021 ═══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-3-june-september-2021/8598/1> gasche announced ──────────────── I’m happy to publish the third issue of the “OCaml compiler development newsletter”. (This is by no means exhaustive: many people didn’t end up having the time to write something, and it’s fine.) Feel free of course to comment or ask questions! If you have been working on the OCaml compiler and want to say something, please feel free to post in this thread! If you would like me to get in touch next time I prepare a newsletter issue (some random point in the future), please let me know by email at (gabriel.scherer at gmail). Previous issues: • [OCaml compiler development newsletter, issue 2: May 2021] • [OCaml compiler development newsletter, issue 1: before May 2021] [OCaml compiler development newsletter, issue 2: May 2021] <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-2-may-2021/7965> [OCaml compiler development newsletter, issue 1: before May 2021] <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-1-before-may-2021/7831> Nicolás Ojeda Bär (@nojb) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Channels in the standard library ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#10545] Add modules `In_channel' and `Out_channel' to the standard library. (merged) • [#10538] Add~Out_channel.set_buffered~ and `Out_channel.is_buffered' to control and query the buffering mode of output channels. (merged) • [#10596] Add `In_channel.input_all', `In_channel.with_open_{bin,text,gen}' and `Out_channel.with_open_{bin,text,gen}'. (under review) [#10545] <https://github.com/ocaml/ocaml/pull/10545> [#10538] <https://github.com/ocaml/ocaml/pull/10538> [#10596] <https://github.com/ocaml/ocaml/pull/10596> Compiler user-interface ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#10654] Propose an approach to enable use of debug info in bytecode binaries compiled with `-output-complete-exe'. (waiting for review) This is the second iteration on work that could have important impact on usability of self-contained bytecode binaries – bring `-output-complete-exe' to feature parity with `-custom', and deprecate the latter, more fragile approach. • [#10555] Improve and clean up the AST locations stored associated to "punned" terms (eg `{x; y}' or `< x; y >'). (merged) • [#10560] The compiler now respects the `NO_COLOR' environment variable. (merged) [#10654] <https://github.com/ocaml/ocaml/pull/10654> [#10555] <https://github.com/ocaml/ocaml/pull/10555> [#10560] <https://github.com/ocaml/ocaml/pull/10560> Internal changes ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ • [#10624] Apply a fix for a compile-time regression introduced in 4.08 (the fix was suggested by Leo White). (merged) • [#10606] Clean up the implementation of the `non-unit-statement' and `ignored-partial-application' warnings. (merged) [#10624] <https://github.com/ocaml/ocaml/pull/10624> [#10606] <https://github.com/ocaml/ocaml/pull/10606> David Allsopp (@dra27) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ • Relocatable Compiler. I worked on the patchset in August and September. There's a prototype for both Windows and Unix rebased to 4.12 and 4.13. With these patches, if you have multiple versions of the compiler lying around (i.e. opam!), it is now virtually impossible for a bytecode executable to load the wrong C stubs library (e.g. `dllunix.so') or invoke the wrong version of `ocamlrun'. Furthermore, from the compiler's perspective at least, a local opam switch can now be moved to a new location. The major thing this enables is the cloning of an existing compiler in order to create a new opam switch without any binary rewriting. With these patches, fresh local switches are building in 5-10 seconds (a lot of which is spent by opam, which has more incentive to be improved, now!). • 4.13 includes the first parts of work to reduce the use of scripting languages in the build system which improves the stability of the build system and also its portability. The Cygwin distribution recently stopped distributing the `iconv' command by default, which broke all the Windows builds of OCaml (see [#10451]. There's more work to go on this, but the rest of it is likely to be stalled until post OCaml 5.00. With the use of scripting vastly reduced, it was possible to get quite a long way through the build using _native Windows_-compiled GNU make (i.e. `make.exe' with no other dependencies) and no Cygwin/MSYS2/WSL. • 4.13 includes a full overhaul of the FlexDLL bootstrap and detection (mentioned in my April update); hopefully gone are the days of randomly picking up the wrong flexlink or suddenly finding that FlexDLL is missing. The Windows build should also be appreciably faster when bootstrapping FlexDLL (which is what opam's source builds have to do). • There's some ongoing work at "modernising" our use of POSIX to remove some older compatibility code in the Unix Library in [#10505]. It's always nice to _remove_ code! • Gradually completing and closing down some of my more aged PRs, often replacing them with simpler implementations. It's funny how returning to PRs can often result in realising simpler approaches; like letting tea brew! :tea: [#10451] <https://github.com/ocam to a new location./ocaml/pull/10451> [#10505] <https://github.com/ocaml/ocaml/pull/10505> Xavier Leroy (@xavierleroy) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I worked on an old issue with the handling of tail calls by the native-code compiler: if there are many arguments to the call and they don't all fit in the processor registers reserved for argument passing, the remaining arguments are put on the stack, and a regular, non-tail call is performed. This limitation had been with us since day 1 of OCaml. I tried several times in the past to implement proper tail calls in the presence of arguments passed on stack, but failed because of difficulties with the stack frame descriptors that are used by the GC to traverse the stack. In [#10595], generalizing an earlier hack specific to the i386 port of OCaml, I developed a simpler approach that uses memory from the "domain state" structure instead of the stack. Once the registers available for passing function arguments are exhausted, the next 64 arguments are passed in a memory area that is part of the domain state. This argument passing is compatible with tail calls, so we get guaranteed tail calls up to 70 arguments at least. The domain state structure, introduced in preparation for merging Multicore OCaml, is a per-execution-domain memory area that is efficiently addressable from a register. Hence, passing arguments through the domain state is safe w.r.t. parallelism and about as efficient as passing them through the stack. Enjoy your 70-arguments tail calls! [#10595] <https://github.com/ocaml/ocaml/pull/10595> Constructor unboxing (Nicolas Chataing @nchataing, Gabriel Scherer @gasche) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Nicolas Chataing's internship on constructor unboxing (mentioned in the [last issue] finished at the end of June. We have been working on-and-off, at a slower rate, to get the prototype to the state we can submit a PR. The first step was to propose our specification (which is different from Jeremy Yallop's original proposal), which is now posted [as an RFC comment]. Hacking on this topic produced a stream of small upstream PRs, mostly cleanups and refactorings that make our implementation easier, and some documentation PRs for subtle aspects of the existing codebase we had to figure out reading the code: [#10500], [#10512] (not yet merged, generating interesting discussion), [#10516], [#10637], [#10646]. [last issue] <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-2-may-2021/7965> [as an RFC comment] <https://github.com/ocaml/RFCs/pull/14#issuecomment-920643103> [#10500] <https://github.com/ocaml/ocaml/pull/10500> [#10512] <https://github.com/ocaml/ocaml/pull/10512> [#10516] <https://github.com/ocaml/ocaml/pull/10516> [#10637] <https://github.com/ocaml/ocaml/pull/10637> [#10646] <https://github.com/ocaml/ocaml/pull/10646> Vincent Laviron (@lthls(github)/@vlaviron(discuss)) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Léo Boitel's internship on detection and simplification of identity functions finished in June (find the corresponding blog post [at OCamlPro] and the discussion [on Discuss]). Pushing the results upstream isn't a priority right now, but I'm planning to build on that work and integrate it either in the main compiler or in the Flambda 2 branch at some point in the future. Apart from that, I've documented the abstract domains that we use for approximations in the Flambda 2 simplification pass (you can find the result [here]), and I've worked with Keryan Dider (@Keryan-dev) on an equivalent to the `-Oclassic' mode for Flambda 2. I've also proposed and reviewed a number of small fixes both on the upstream and Flambda 2 repos, from fixes for obscure bugs (like [this Flambda bug]) to small improvements to code generation. [at OCamlPro] <https://www.ocamlpro.com/2021/07/16/detecting-identity-functions-in-flambda/> [on Discuss] <https://discuss.ocaml.org/t/detecting-identity-functions-in-flambda/8180> [here] <https://github.com/ocaml-flambda/flambda-backend/blob/main/middle_end/flambda2/docs/types.md> [this Flambda bug] <https://github.com/ocaml/ocaml/pull/10611> Jacques Garrigue (@garrigue) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Continued to work with Takafumi Saikawa (@t6s) on strengthening the datatypes used in the unification algorithm. • [#10337] Make type nodes abstract, ensuring one always sees normal forms. Merged in June. • [#10474] Same thing for polymorphic variants rows. Merged in September. • [#10627] Same thing for polymorphic variant field kinds. • [#10541] Same thing for object field kinds and function commutation flags. Also continued the work on creating a backend generating Coq code [GitHub - COCTI/ocaml at ocaml_in_coq]. This now works with many examples. [#10337] <https://github.com/ocaml/ocaml/pull/10337> [#10474] <https://github.com/ocaml/ocaml/pull/10474> [#10627] <https://github.com/ocaml/ocaml/pull/10627> [#10541] <https://github.com/ocaml/ocaml/pull/10541> [GitHub - COCTI/ocaml at ocaml_in_coq] <https://github.com/COCTI/ocaml/tree/ocaml_in_coq> Odig 0.0.7, lookup documentation of installed OCaml packages ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-odig-0-0-7-lookup-documentation-of-installed-ocaml-packages/8600/1> Daniel Bünzli announced ─────────────────────── It's my pleasure to announce the release `0.0.7' of [`odig']. Odig is a command line tool to lookup documentation of installed OCaml packages. Once it has made it to the repo, install with `opam install ocaml-manual odig' and consult the [manual] (or via `odig doc odig'). This release provides support for `odoc' 2.0.0. The [release notes] have all the details. [`odig'] <https://erratique.ch/software/odig> [manual] <https://erratique.ch/software/odig/doc/index> [release notes] <https://github.com/b0-system/odig/blob/master/CHANGES.md#v007-2021-10-09-zagreb> OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central) ════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-cafe-wed-oct-13-1pm-u-s-central/8610/1> Michael Bacarella announced ─────────────────────────── *Note!* This is not our usual time! Past meetups have been at 7pm (U.S. Central). This one is happening at 1pm (U.S. Central). This meetup should be easier for people in Europe to attend. Please join us at the next OCaml Cafe, a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Bring your code and we’ll be happy to review it, assist with debugging, and provide recommendations for improvement. This month, David Allsop of OCaml Labs and the University of Cambridge will present on OPAM, the OCaml package manager. After introducing OPAM, David will discuss the new features of OPAM 2.1, just released at the beginning of August. Following David's talk, we will open the discussion to all things OCaml-related. Full meeting details, including Zoom link, here: <https://www.meetup.com/ocaml-cafe/events/281344155/> Multicore OCaml: September 2021, effect handlers will be in OCaml 5.0! ══════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/multicore-ocaml-september-2021-effect-handlers-will-be-in-ocaml-5-0/8554/16> Deep in this thread, Bikal Lem announced ──────────────────────────────────────── The multicore [eio] lib has now been migrated to the *syntax-free* version. This is the version of effects which will be available in the upcoming OCaml 5.0.0. PR : <https://github.com/ocaml-multicore/eio/pull/82> [eio] <https://github.com/ocaml-multicore/eio/pull/82> Alcotest 1.5.0 ══════════════ Archive: <https://discuss.ocaml.org/t/ann-alcotest-1-5-0/8613/1> Craig Ferguson announced ──────────────────────── I’m pleased to announce the release of [Alcotest ] 1.5.0, now available on Opam. This release includes: • *JavaScript compatibility* ([#326]), via `js_of_ocaml.3.11.0'. Projects that build with `js_of_ocaml' can now use the regular `alcotest' package to test their JavaScript-compatible libraries. For users of `dune', this is as easy as adding `(modes ... js)' to your `test' stanzas (to build the JavaScript targets) and a corresponding `rule' to run the output: ┌──── │ (test │ (name main) │ (modes native js) │ (libraries alcotest)) │ │ (rule │ (alias runtest-js) │ (action │ (run node %{dep:main.bc.js}))) └──── To depend on a version of `js_of_ocaml' that is supported by Alcotest, add a dependency on the the virtual package `alcotest-js'. Many thanks @hhugo and @smorimoto for this excellent contribution! • *Backtrace collection by default* ([#317]). The Alcotest runner now enables backtrace collection by default, ensuring that failing native tests always come with backtraces without any need to set `OCAMLRUNPARAM=b'. • *A stable `Alcotest.V1' module* ([#306]). This module is very similar to the existing top-level `Alcotest' module, but provides some stability guarantee across major versions. It's intended to provide a migration path for an eventual "Alcotest 2" to make improvements on the existing API. The full changelog is available [here]. [Alcotest ] <https://github.com/mirage/alcotest/> [#326] <https://github.com/mirage/alcotest/pull/326> [#317] <https://github.com/mirage/alcotest/pull/317> [#306] <https://github.com/mirage/alcotest/pull/306> [here] <https://github.com/mirage/alcotest/releases/tag/1.5.0> Other OCaml News ════════════════ >From the ocamlcore planet blog ────────────────────────────── Here are links from many OCaml blogs aggregated at [OCaml Planet]. • [The New Replaying Benchmark in Irmin] [OCaml Planet] <http://ocaml.org/community/planet/> [The New Replaying Benchmark in Irmin] <https://tarides.com/blog/2021-10-04-the-new-replaying-benchmark-in-irmin> 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 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] <mailto:alan.schm...@polytechnique.org> [the archive] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/>
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly
