[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Oct 12 05:36:38 PDT 2021
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.lindley at 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.schmitt at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20211012/9ad0ce7d/attachment-0001.html>
More information about the caml-news-weekly
mailing list