[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt
2022-01-11T08:21:08Z

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

Hello

Here is the latest OCaml Weekly News, for the week of January 04 to 11,
2022.

Table of Contents
─────────────────

New release of PPrint (20220103)
Bogue, the OCaml GUI
Cohttp 5.0.0 and 2.5.6
Multicore OCaml: December 2021 and the Big PR
Set up OCaml 2.0.0-beta12
Old CWN

New release of PPrint (20220103)
════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-new-release-of-pprint-20220103/9097/1>

François Pottier announced
──────────────────────────

I am pleased to announce a new release of PPrint, the pretty-printing
library, with [improved documentation].

The documentation can also be viewed offline:

┌────
│ opam update
│ opam install pprint.20220103
│ opam install odig
│ odig odoc # this may take some time
│ odig doc pprint # this opens the doc in your browser
└────

Happy pretty-printing!

[improved documentation]
<http://cambium.inria.fr/~fpottier/pprint/doc/pprint/>

Bogue, the OCaml GUI
════════════════════

Archive: <https://discuss.ocaml.org/t/ann-bogue-the-ocaml-gui/9099/1>

sanette announced
─────────────────

I'm happy to announce a brand new version of [Bogue], a GUI (Graphical
User Interface) library entirely written in `ocaml', using SDL2 for
hardware accelerated graphics.

The doc can be found [here], it will be enriched over time.

Install with `opam install bogue'

In addition to the library, this installs an executable `boguex' to
showcase about 50 useful constructions, see `boguex -h' for the list.

Some screenshots of a demo compiled with the latest version:

<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/6/619a6b3c5d7a9860e4c24df7d8b931815e9b95a1.png>

<https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/3/3e5e04d1db0022d4070b7fd3dab45f4399828e90.png>

Note that many widgets are not shown in this demo: tables, menus,
drop-down select lists, knob buttons,… I will add more images to the
doc when I have some time!

[Bogue] <https://github.com/sanette/bogue>

[here] <http://sanette.github.io/bogue/Principles.html>

Cohttp 5.0.0 and 2.5.6
══════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-cohttp-5-0-0-and-2-5-6/9109/1>

Marcello Seri announced
───────────────────────

We are glad to announce the release of version [5.0.0] and [2.5.6] of
cohttp and its dependent packages.

The latter is a bug fix release that in particular backports the
compatibility with the upcoming release 0.15 of core and async.

The first introduces the breaking changes [announced in the previous
release]. I append the changelog below, which explains in details the
changes and emphasizes the breaking changes:

[5.0.0]
<https://github.com/ocaml/opam-repository/pull/20246#issue-1080986510>

[2.5.6]
<https://github.com/ocaml/opam-repository/pull/20245#issue-1080822215>

[announced in the previous release]
<https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537>

Cohttp.Header: new implementation (lyrm #747)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

• New implementation of Header modules using an associative list
instead of a map, with one major semantic change (function `get',
see below), and some new functions (`clean_dup', `get_multi_concat')
• More Alcotest tests as well as fuzzing tests for this particular
module.

Purpose
┄┄┄┄┄┄┄

The new header implementation uses an associative list instead of a
map to represent headers and is focused on predictability and
intuitivity: except for some specific and documented functions, the
headers are always kept in transmission order, which makes debugging
easier and is also important for [RFC7230§3.2.2] that states that
multiple values of a header must be kept in order.

Also, to get an intuitive function behaviour, no extra work to enforce
RFCs is done by the basic functions. For example, RFC7230§3.2.2
requires that a sender does not send multiple values for a non
list-value header. This particular rule could require the `Header.add'
function to remove previous values of non-list-value headers, which
means some changes of the headers would be out of control of the
user. With the current implementation, an user has to actively call
dedicated functions to enforce such RFCs (here `Header.clean_dup').

[RFC7230§3.2.2] <https://tools.ietf.org/html/rfc7230#section-3.2.2>

Semantic changes
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

Two functions have a semantic change : `get' and `update'.

get
┈┈┈

`get' was previously doing more than just returns the value
associated to a key; it was also checking if the searched header could
have multiple values: if not, the last value associated to the header
was returned; otherwise, all the associated values were concatenated
and returned. This semantics does not match the global idea behind the
new header implementation, and would also be very inefficient.

⁃ The new `get' function only returns the last value associated to the
searched header.
⁃ `get_multi_concat' function has been added to get a result similar
to the previous `get' function.

update
┈┈┈┈┈┈

`update' is a pretty new function (#703) and changes are minor and
related to `get' semantic changes.

⁃ `update h k f' is now modifying only the last occurrences of the
header `k' instead of all its occurrences.
⁃ a new function `update_all' function has been added and work on all
the occurrences of the updated header.

New functions :
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

⁃ `clean_dup' enables the user to clean headers that follows the
[RFC7230§3.2.2] (no duplicate, except `set-cookie')
⁃ `get_multi_concat' has been added to get a result similar to the
previous `get' function.

[RFC7230§3.2.2] <https://tools.ietf.org/html/rfc7230#section-3.2.2>

Cohttp.Header: performance improvement (mseri, anuragsoni #778)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

*Breaking* the headers are no-longer lowercased when parsed, the
headers key comparison is case insensitive instead.

cohttp-lwt-unix: Adopt ocaml-conduit 5.0.0 (smorimoto #787)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

*Breaking* `Conduit_lwt_unix.connect''s `ctx' param type chaged from
`ctx' to `ctx Lazy.t'

other changes
╌╌╌╌╌╌╌╌╌╌╌╌╌

• cohttp-mirage: fix deprecated fmt usage (tmcgilchrist #783)
• lwt_jsoo: Use logs for the warnings and document it (mseri #776)
• lwt: Use logs to warn users about leaked bodies and document it
(mseri #771)
• lwt, lwt_unix: Improve use of logs and the documentation, fix bug in
the Debug.enable_debug function (mseri #772)
• lwt_jsoo: Fix exception on connection errors in chrome (mefyl #761)
• lwt_jsoo: Fix `Lwt.wakeup_exn' `Invalid_arg' exception when a js
stack overflow happens in the XHR completion handler (mefyl #762).
• lwt_jsoo: Add test suite (mefyl #764).

We wish to thank to all the users and the contributors for their help
leading to this release.

Multicore OCaml: December 2021 and the Big PR
═════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/multicore-ocaml-december-2021-and-the-big-pr/9115/1>

Anil Madhavapeddy announced
───────────────────────────

Welcome to the December 2021 [Multicore OCaml] monthly report! The
[previous updates] along with this update have been compiled by
myself, @ctk21, @kayceesrk and @shakthimaan.

Well, it's finally here! @kayceesrk opened the [Multicore OCaml
PR#10831] to the main OCaml development repository that represents the
"minimum viable" implementation of multicore OCaml that we decided on
in [November's core team review]. The branch pushes the limits of
GitHub's rendering capability, with around 4000 commits.

Once the PR was opened just before Christmas, the remaining effort has
been for a number of developers to pore over [the diff] and look for
any unexpected changes that crept in during multicore development. A
large number of code changes, improvements and fixes have been merged
into the ocaml-multicore trees since the PR was opened to facilitate
this upstreaming process. We're expecting to have the PR merged during
January, and then will continue onto the "post-MVP" tasks described
last month, but working directly from ocaml/ocaml from now on. We
therefore remain on track to release OCaml 5.00 in 2022.

In the multicore ecosystem, progress also continued:
• `Eio' continues to improve as the recommended effects-based
direct-style IO library to use with Multicore OCaml.
• A newer `domainslib.0.4.0' has been released that includes bug fixes
and API changes.
• The continuous benchmarking pipeline with further integration
enhancements between Sandmark and current-bench is making progress.

We would like to acknowledge the following external contributors as
well::

• Danny Willems (@dannywillems) for an OCaml implementation of the
Pippenger benchmark and reporting an undefined behaviour.
• Matt Pallissard (@mattpallissard) reported an installation issue
with `Eio' with vendored uring.
• Edwin Torok (@edwintorok) for contributing a PR to `domainslib' to
allow use of a per-channel key.

As always, the Multicore OCaml updates are listed first, which contain
the upstream efforts, improvements, fixes, test suite, and
documentation changes. This is followed by the ecosystem updates to
`Eio', `Tezos', and `Domainslib'. The Sandmark, sandmark-nightly and
current-bench tasks are finally listed for your reference.

/editor’s note: please follow the archive link above for the full
changelog./

[Multicore OCaml] <https://github.com/ocaml-multicore/ocaml-multicore>

[previous updates] <https://discuss.ocaml.org/tag/multicore-monthly>

[Multicore OCaml PR#10831] <https://github.com/ocaml/ocaml/pull/10831>

[November's core team review]
<https://discuss.ocaml.org/t/multicore-ocaml-november-2021-with-results-of-code-review/8934#core-team-code-review-1>

[the diff] <http://github.com/ocaml/ocaml/pull/10831.diff>

Stéphane Lavergne asked and Robin Björklin replied
──────────────────────────────────────────────────

To clarify for relative newbies like myself: this would be
a new way to do concurrent I/O, like Async and Lwt, but
unlike those, it wouldn't require the use of a promise
monad? In other words, does this mean that we'll have the
choice between Async, Lwt and Eio in the near future for
our concurrent I/O needs?

That's correct as far as I can tell. This presentation provides an
introduction to the current state of eio:
<https://watch.ocaml.org/videos/watch/74ece0a8-380f-4e2a-bef5-c6bb9092be89>

Set up OCaml 2.0.0-beta12
═════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-set-up-ocaml-2-0-0-beta12/9123/1>

Sora Morimoto announced
───────────────────────

Fixed
╌╌╌╌╌

• Fallback to the version in which the assets exist if no assets exist
in the latest opam release.
• Instruct Cygwin setup to use "sys" symlinks during setup (partial
workaround for bug with native symlinks in Cygwin setup - some
depexts may still be affected)

<https://github.com/ocaml/setup-ocaml/releases/tag/v2.0.0-beta12>

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@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/>

[-- Attachment #2: Type: text/html, Size: 25652 bytes --]