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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- 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 --]