caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-06 12:33 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-07-06 12:33 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of June 29 to July
06, 2021.

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

LibreRef - LablGtk-based Digital Reference Tool Application
u2f - universal second factor
Reproducible OPAM packages / MirageOS
Dune 2.9.0
Hardcaml MIPS CPU Learning Project and Blog
dune-release 1.5.0
anders 0.7.1
Old CWN


LibreRef - LablGtk-based Digital Reference Tool Application
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-libreref-lablgtk-based-digital-reference-tool-application/8077/1>


Kiran Gopinathan announced
──────────────────────────

  I'm not sure if this is that close to the typical uses of OCaml, but
  posting this here just in case anyone was interested in another
  end-user facing application using LablGtk.

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/b/b72b4bd7838e41dbaed2254350799c5e75245a3d_2_250x250.png>

        LibreRef is a free as in freedom digital referencing tool
        for artists.

  It's written in OCaml using LablGtk and Cairo to implement the GUI.

  You can find the source code at: [gitlab] ([github mirror])

  A picture is worth a thousand words, so before I continue, here are a
  few examples of it in action:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/126997c61b83b700feac41e380b42c560bdf2340.gif>

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/4/49b11ef943e491ba220332d257bc6a15b506ed6b.gif>

  Overall, getting LablGtk to work was fairly straightforward, although
  the documentation was a bit lacking (although the same might be said
  of Gtk itself).

  I was able to piece together the correct uses of most of the API calls
  by relying on either the examples from the repository or by
  translating snippets of code from online back into LablGtk.

  As for deploying it as an application, I found the AppImage &
  LinuxDeploy toolchain to work well with the resulting binary
  (admittedly I've only tested it with two devices so far), and it meant
  that I could publish the program without having to ask people to setup
  the full OCaml & Opam toolchain, which would probably be a large ask.

  As for the implementation, I think it was fairly elegant (if I say so
  myself :slight_smile:), although I may have gone overboard with
  functors (see this higher-order functor in the GUI interface:
  <https://gitlab.com/gopiandcode/libre-ref/-/blob/master/gui.mli#L175>)
  and some aspects of the separation of concerns weren't so well
  established.


[gitlab] <https://gitlab.com/gopiandcode/libre-ref>

[github mirror] <https://github.com/Gopiandcode/LibreRef>


u2f - universal second factor
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-u2f-universal-second-factor/8078/1>


Hannes Mehnert announced
────────────────────────

  it is our pleasure to announce the just released opam package u2f,
  which is a server side implementation of the FIDO standard for
  two-factor authentication using a special device (yubikey etc.). The
  device does challenge-response authentication with the server using
  public key cryptography.

  The implementation is stateless and does not use a specific IO
  library, but only achieves the logic for constructing a registration
  request, verifying a response thereof, and authorization requests with
  responses thereof. Please have a look at
  <https://github.com/roburio/u2f> if you're interested. It is licensed
  under the permissive 2-clause BSD license.

  We use this library in an example server (in the `bin' directory) that
  uses dream. The live server is online at <https://u2f-demo.robur.coop>
  – please let us know if you run into any trouble, or open an issue on
  the GitHub repository.

  One question though: we're unable to generate the documentation from
  the mli – already asked on discord with no result. Anyone with a
  better understanding of odoc etc. can take a look why `dune build
  @doc' outputs a nearly empty file? Thanks a lot :)

  The development was sponsored by skolem.tech.


Reproducible OPAM packages / MirageOS
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/reproducible-opam-packages-mirageos/8079/1>


Hannes Mehnert announced
────────────────────────

  we are pleased to announce reproducible binary images for MirageOS
  unikernels (see the blog post at
  <https://hannes.robur.coop/Posts/Deploy>). The binaries are located at
  <https://builds.robur.coop> (all components are open source and linked
  from the page).

  Additionally, the required tools to achieve reproducible builds are
  released as binary packages for various operating systems as well on
  the same site. They are used by the infrastructure to run daily builds
  (always with the HEAD of opam-repository to not loose any updates /
  new releases). The custom overlay
  <https://git.robur.io/robur/unikernel-repo> is used that adds some
  development packages.

  Happy to hear your thoughts and feedback here. (Earlier post
  <https://discuss.ocaml.org/t/reproducible-builds-with-ocaml-opam-and-mirageos/4877>)

  This work was funded by the [NGI Pointer] project "Funding The Next
  Generation Ecosystem of Internet Architects".


[NGI Pointer] <https://pointer.ngi.eu>


Dune 2.9.0
══════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-2-9-0/8087/1>


Emilio Jesús Gallego Arias announced
────────────────────────────────────

  Dear all, on behalf of the Dune team I'm pleased to announce the
  release of Dune 2.9.0. This is the last release on the Dune 2.x series
  and could be considered a maintenance release as it mostly consists on
  bug fixes and miscellaneous tweaks and features for sites,
  instrumentation, and mdx support.

  Please find the full list of changes below:
  • Add `(enabled_if ...)' to `(mdx ...)'
    (<https://github.com/ocaml/dune/pull/4434>, @emillon)

  • Add support for instrumentation dependencies
    (<https://github.com/ocaml/dune/pull/4210>, fixes
    <https://github.com/ocaml/dune/issues/3983>, @nojb)

  • Add the possibility to use `locks' with the cram tests stanza
    (<https://github.com/ocaml/dune/pull/4480>, @voodoos)

  • Allow to set up merlin in a variant of the default context
    (<https://github.com/ocaml/dune/pull/4145>, @TheLortex, @voodoos)

  • Add `(package ...)' to `(mdx ...)'
    (<https://github.com/ocaml/dune/pull/4691>, fixes
    <https://github.com/ocaml/dune/issues/3756>, @emillon)

  • Handle renaming of `coq.kernel' library to `coq-core.kernel' in Coq
    8.14 (<https://github.com/ocaml/dune/pull/4713>, @proux01)

  • Fix generation of merlin configuration when using `(include_subdirs
    unqualified)' on Windows (<https://github.com/ocaml/dune/pull/4745>,
    @nojb)

  • Fix bug for the install of Coq native files when using
    `(include_subdirs qualified)'
    (<https://github.com/ocaml/dune/pull/4753>, @ejgallego)

  • Allow users to specify install target directories for `doc' and
    `etc' sections. We add new options `--docdir' and `--etcdir' to both
    Dune's configure and `dune install'
    command. (<https://github.com/ocaml/dune/pull/4744>, fixes
    <https://github.com/ocaml/dune/issues/4723>, @ejgallego, thanks to
    @JasonGross for reporting this issue)

  • Fix issue where Dune would ignore `(env ... (coq (flags ...)))'
    declarations appearing in `dune' files
    (<https://github.com/ocaml/dune/pull/4749>, fixes
    <https://github.com/ocaml/dune/issues/4566>, @ejgallego @rgrinberg)

  • Disable some warnings on Coq 8.14 and `(lang coq (>= 0.3))' due to
    the rework of the Coq "native" compilation system
    (<https://github.com/ocaml/dune/pull/4760>, @ejgallego)

  • Fix a bug where instrumentation flags would be added even if the
    instrumentatation was disabled (@nojb,
    <https://github.com/ocaml/dune/pull/4770>)

  • Fix <https://github.com/ocaml/dune/issues/4682>: option `-p' takes
    now precedence on environement variable `DUNE_PROFILE'
    (<https://github.com/ocaml/dune/pull/4730>,
    <https://github.com/ocaml/dune/pull/4774>, @bobot, reported by
    @dra27 <https://github.com/ocaml/dune/issues/4632>)

  • Fix installation with opam of package with dune sites. The
    `.install' file is now produced by a local `dune install' during the
    build phase (<https://github.com/ocaml/dune/pull/4730>,
    <https://github.com/ocaml/dune/pull/4645>, @bobot, reported by
    @kit-ty-kate <https://github.com/ocaml/dune/issues/4198>)

  • Fix multiple issues in the sites feature
    (<https://github.com/ocaml/dune/pull/4730>,
    <https://github.com/ocaml/dune/pull/4645> @bobot, reported by
    @Lelio-Brun <https://github.com/ocaml/dune/issues/4219>, by @Kakadu
    <https://github.com/ocaml/dune/issues/4325>, by @toots
    <https://github.com/ocaml/dune/issues/4415>)


Hardcaml MIPS CPU Learning Project and Blog
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088/1>


"Alexander (Sasha) Skvortsov announced
──────────────────────────────────────

  Tl;dr: I’m [writing a blog] about making a MIPS CPU in Hardcaml.

  Hi! My name is Sasha, and I’m a student at Penn State majoring in CS
  and Math. Last semester, I took a computer engineering class where we
  built a pipelined MIPS CPU in Verilog as a semester-long project. I
  enjoyed the class, but a lot of frustration came from Verilog itself.

  A few months ago, I came across the [Signals and Threads Programmable
  Hardware episode]. I really liked the idea of [Hardcaml]: a library to
  write and test hardware designs in OCaml. Representing circuits as
  functions felt like a good abstraction, and I’ve been wanting to learn
  OCaml for a while.

  So this summer, a friend and I are rewriting the Verilog MIPS CPU we
  made last semester into Hardcaml.  We’re still working on the project,
  but have made some good progress and wanted to share it in case anyone
  finds it interesting / useful. If anyone wants to take a look, it’s
  [up on GitHub].

  We’ve written some blog posts about our project:

  1. [Some more background on what we’re doing and why]
  2. [An ELI5 overview of how hardware, and pipelined CPUs in
     particular, work]
  3. [Another high-level overview of Verilog, hardware design, FPGAs,
     and why I think OCaml might be a great fit for hardware design]
  4. [How to set up a Hardcaml project, including testing and Verilog
     generation]
  5. [How to split Hardcaml circuits into multiple modules]

  There’s also a few more that we’ve written code for, but are still
  drafting blog posts about:

  • How to work with memory in Hardcaml
  • How to design stateful, sequential circuits in Hardcaml
  • A safer design pattern for Hardcaml circuits

  I’m new to both OCaml and blogging, and this has definitely been a fun
  experience so far! Would love to hear any feedback / comments.


[writing a blog] <https://ceramichacker.com/>

[Signals and Threads Programmable Hardware episode]
<https://signalsandthreads.com/programmable-hardware/>

[Hardcaml] <https://github.com/janestreet/hardcaml>

[up on GitHub] <https://github.com/askvortsov1/hardcaml-mips>

[Some more background on what we’re doing and why]
<https://ceramichacker.com/blog/1-1x-hardcaml-mips-intro-what-and-why>

[An ELI5 overview of how hardware, and pipelined CPUs in particular,
work]
<https://ceramichacker.com/blog/2-2x-a-bit-on-computers-hardware-and-cpus>

[Another high-level overview of Verilog, hardware design, FPGAs, and why
I think OCaml might be a great fit for hardware design]
<https://ceramichacker.com/blog/4-3x-verilog-fpgas-and-why-ocaml>

[How to set up a Hardcaml project, including testing and Verilog
generation]
<https://ceramichacker.com/blog/5-4x-ocaml-setup-hardcaml-basics-and-project-plan>

[How to split Hardcaml circuits into multiple modules]
<https://ceramichacker.com/blog/11-5x-multi-module-circuits-in-hardcaml>


dune-release 1.5.0
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-release-1-5-0/8095/1>


Nathan Rebours announced
────────────────────────

  On behalf of the dune-release team I'm pleased to announce that we're
  releasing dune-release.1.5.0.

  It has been quite a while since the last release so there are numerous
  changes and improvements in this one, along with a lot of bug fixes.

  The two main new features in 1.5.0 are:
  • A draft release mode that creates a draft Github release and a draft
    PR to opam-repository. It comes with an `undraft' command that will
    undraft both and update the opam file's `url.src' field
    accordingly. We believe this feature will prove helpful to
    maintainers of tools such as `dune' which releases are often watched
    by distribution maintainers. Draft releases allow you to wait until
    you have opam-repository's CI approval to actually create a GH
    release that will notify anyone watching the repository. This
    feature is still a bit experimental, we have ideas on how to improve
    it but we wanted to get a first version out to collect feedback on
    how it is used and what you folks expect from it.
  • A `check' command that you can run ahead of a release to know if
    dune-release has all the information it needs in the repository,
    along with running the lint, build and test checks it normally runs
    after building the tarball. We're aware that it can be frustrating
    to see dune-release fail right in the middle of the release
    process. We're trying to improve this situation and this is a first
    step in that direction.

  You can see the full changelog [here]

  You'll note we also deprecated a few features such as delegates (as we
  announced in [this post]), opam 1.x and the `--user' option and
  corresponding config file field.  This release is likely to be the
  last 1.x release of `dune-release' except for important bug fixes as
  we'll start working on 2.0 soon.

  Our main goals for 2.0 are to make the experience for github users as
  seemless as possible. We want the tool to do the right thing for those
  users without them having to configure anything. Delegates got in the
  way there and that's why we're removing them.  We do care about our
  non github users and we've worked on making it as configurable as
  possible so that you can integrate it in your release workflow. The
  situation should already have improved quite a bit with this release
  as we fixed several bugs for non github hosted repositories. We want
  to make sure that these users will be happy with dune-release 2.0 as
  well.  Hopefully in the future dune-release will support other release
  workflows such as handling gitlab hosted repositories but we want to
  make sure our main user base is happy with the tool before adding
  this.

  We'll communicate a bit more on our plans for 2.0 in the next few
  months. Our hope is that it will hit opam before the end of this year.

  We hope that you'll like this new version and wish you all successful
  and happy releases!


[here] <https://github.com/ocamllabs/dune-release/releases/tag/1.5.0>

[this post]
<https://discuss.ocaml.org/t/replacing-dune-release-delegates/4767>


anders 0.7.1
════════════

  Archive: <https://discuss.ocaml.org/t/ann-anders-0-7-1/8098/1>


Namdak Tonpa announced
──────────────────────

  The HTS language proposed by Voevodsky exposes two different presheaf
  models of type theory: the inner one is homotopy type system presheaf
  that models HoTT and the outer one is traditional Martin-Löf type
  system presheaf that models set theory with UIP. The motivation behind
  this doubling is to have an ability to express semisemplicial
  types. Theoretical work on merging meta-theoretical and homotopical
  languages was continued in [2LTT] [Anenkov, Capriotti, Kraus,
  Sattler].

  While we are on our road to HTS with Lean-like tactic language,
  currently we are at the stage of regular cubical (HoTT) type checker
  with CHM-style primitives, or more general CCHM type checker. You may
  try it at Github: [groupoid/anders].

  ┌────
  │ $ opam install anders
  │ $ anders
  │ Anders theorem prover [PTS][MLTT][CCHM-4][HTS].
  │ 
  │    invoke = anders | anders list
  │      list = [] | command list
  │   command = check filename     | lex filename
  │           | parse filename     | help
  │           | cubicaltt filename | girard
  │           | trace
  └────

  Anders is idiomatic and educational. We carefully draw the favourite
  Lean-compatible syntax to fit 130 LOC in Menhir, the MLTT core (based
  on Mini-TT) is 500 LOC and pretypes presheaf is another 500 LOC.


[2LTT] <https://arxiv.org/pdf/1705.03307.pdf>

[groupoid/anders] <https://github.com/groupoid/anders>


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: 31723 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-10-19  8:23 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-10-19  8:23 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of October 12 to 19,
2021.

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

Verification for Dummies: SMT and Induction
OCaml Café: Wed, Oct 13 @ 1pm (U.S. Central)
Windows-friendly OCaml 4.12 distribution 2nd preview release (0.2.0)
Release of ocaml-sf/learn-ocaml:0.13.0
Old CWN


Verification for Dummies: SMT and Induction
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/verification-for-dummies-smt-and-induction/8631/1>


OCamlPro announced
──────────────────

  We are pleased to share with you [Verification for Dummies: SMT and
  Induction], a complete and detailed series of blogposts written by
  Adrien Champion about Induction as a formal verification technique.

  The subject is treated with many concrete and executable examples. All
  examples can be (and should be) launched locally by readers thanks to
  small and easy to find tools. Modification and experimentation are
  strongly encouraged!

  Take a look at all the notions covered:

  • introduction to formal logics and formal frameworks;
  • SMT-solving: modern, low-level verification building blocks;
  • declarative transition systems;
  • transition system unrolling;
  • BMC and induction proofs over transition systems;
  • candidate strengthening.

  We hope you enjoy reading and we look forward to your feedback!


[Verification for Dummies: SMT and Induction]
<https://www.ocamlpro.com/2021/10/14/verification-for-dummies-smt-and-induction/>


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


Claude Jager-Rubinson announced
───────────────────────────────

  The video of @dra27's talk on OPAM is now available:
  <https://youtu.be/RHSdlH4el0g>. Thanks so much for the great talk,
  David!  And thanks to everybody who attended!  (The video starts a
  couple of minutes into the talk because yours truly forgot to start
  recording.  D'oh!)

  We already have some ideas for the next meeting but if there's a topic
  that you'd like to hear about or are interested on presenting on,
  please message me.


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


jbeckford announced
───────────────────

  0.2.5 is available. This release brings significant user friendly
  improvements.

  There is a new binary called `with-dkml.exe'. Just plop `with-dkml' in
  front of a Windows command that requires access to Unix scripts
  (ie. `with-dkml opam install') and it should just work.

  There is now a section called **Beyond Basics** in [the Diskuv OCaml
  user documentation] that walks through:
  • the first and second tutorials of [Getting Started - Learn OCaml]
  • the bare Opam essentials you need as a beginner (how to find and
    select an Opam switch, and how to find and install packages using
    `with-dkml opam install'), all without leaving the Command Prompt
  • installing Visual Studio Code with the OCaml plugin

  Huge thanks to @Butanium who lent me much of his time to validate
  usability from the perspective of a newcomer. More feedback is always
  welcome.

  Links:
  • [Installation instructions for the latest version]
  • [Release notes for all versions]

  PS. You won't need `with-dkml' most of the time. The Beyond Basics
  documentation shows how to run Dune and the OCaml native compiler
  directly from the Visual Studio Command Prompt.


[the Diskuv OCaml user documentation]
<https://diskuv.gitlab.io/diskuv-ocaml/index.html>

[Getting Started - Learn OCaml] <https://ocaml.org/learn/tutorials/>

[Installation instructions for the latest version]
<https://diskuv.gitlab.io/diskuv-ocaml/index.html#two-step-installation-instructions>

[Release notes for all versions]
<https://gitlab.com/diskuv/diskuv-ocaml/-/releases>


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


Erik Martin-Dorel announced
───────────────────────────

  Just FYI, a bugfix release learn-ocaml `0.13.1' has just been tagged
  and:

  • [released in GitHub] ← see the Release Notes and binaries-assets
  • [pushed to Docker Hub] ← `ocamlsf/learn-ocaml' being the official
    distribution of Learn-OCaml
  • [submitted to OPAM default repository]


[released in GitHub]
<https://github.com/ocaml-sf/learn-ocaml/releases/tag/v0.13.1>

[pushed to Docker Hub]
<https://hub.docker.com/r/ocamlsf/learn-ocaml/tags>

[submitted to OPAM default repository]
<https://github.com/ocaml/opam-repository/pull/19787>


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: 16445 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-28  6:37 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-09-28  6:37 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of September 21 to
28, 2021.

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

Brr 0.0.2, a toolkit for programming browsers
Become an Outreachy Mentor: support the growth and diversity of the OCaml community
OCaml 4.13.0 (and 4.12.1)
Other OCaml News
Old CWN


Brr 0.0.2, a toolkit for programming browsers
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-brr-0-0-2-a-toolkit-for-programming-browsers/8521/1>


Daniel Bünzli announced
───────────────────────

  It's my pleasure to announce the release `0.0.2' of [`Brr'], a toolkit
  for programming browsers in OCaml with the [`js_of_ocaml'] compiler.

  Once it has made it to the repo, install with `opam install brr' and
  consult the [API docs and manuals] (or via `odig doc brr').

  This release fixes binding bugs, adds a few new bindings and tweaks
  some existing signatures. Thanks to all of those who provided bug
  reports, suggestions and code.

  The [release notes] have all the details.


[`Brr'] <https://erratique.ch/software/brr>

[`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml>

[API docs and manuals] <https://erratique.ch/software/brr/doc/>

[release notes]
<https://github.com/dbuenzli/brr/blob/master/CHANGES.md#v002-2020-09-23-zagreb>


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


Thibaut Mattio announced
────────────────────────

  I've submitted two projects for the winter session:

  • Integrate a package health check in ocaml.org

  To essentially integrate a version of check.ocamllabs.io that can be
  used by opam-repository maintainers and opam users into the next
  version of ocaml.org (<https://v3.ocaml.org>).

  • Support `.eml' files in OCaml's VSCode extension

  To add support for Dream's [`.eml' files] syntax in the extension, and
  eventually have error reporting for these files from OCaml LSP Server.

  I'm more than interested in having co-mentors for these two projects,
  so if you wanted to mentor Outreachy interns but didn't have any
  project ideas, don't hesitate to reach out :slight_smile:

  Another way to help that does not involve mentoring is to find good
  first issues that will help onboard and select candidates for the
  projects. Any help on this effort to identify, create and document
  good first issues for the different projects is more than welcome!


[`.eml' files]
<https://github.com/aantron/dream/tree/master/example/7-template>


OCaml 4.13.0 (and 4.12.1)
═════════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-4-13-0-and-4-12-1/8529/1>


octachron announced
───────────────────

  The OCaml team ha the pleasure of celebrating the 175th anniversary of
  the discovery of Neptune by announcing the joint releases of OCaml
  version 4.13.0 and 4.12.1 .

  Some of the highlights in the 4.13.0 release are:

  • Safe points: a multicore prerequisite that ensures that
    ocamlopt-generated code can always be interrupted.
  • The best-fit GC allocation policy is now the default policy (and
    many other GC improvements).
  • Named existential type variables in pattern matching: `Showable
    (type a) (x, show : a * (a -> string))'.

  • Improved error messages for functor application and functor types.
  • Let-punning for monadic let: `let* x = x in' can be shortened to
    `let* x in'.
  • Module type substitutions: `SIG with module type T = F(X).S'.

  • Many other quality of life improvements
  • Many bug fixes

  The 4.12.1 release is a collection of safe bug fixes, cherry-picked
  from the 4.13.0 development cycle. If you were using OCaml 4.12.0 and
  cannot yet upgrade to 4.13.0, this release is for you.

  The full list of changes can be found in the changelogs
  below. (*Editor note*: as it’s quite long, it is not included
  here. Please follow the link to the original article to read it.)

  Those releases are available as OPAM switches, and as a source
  download here:

  • <https://github.com/ocaml/ocaml/archive/4.13.0.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.13/>

  and there:

  • <https://github.com/ocaml/ocaml/archive/4.12.1.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.12/>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Announcing Tezos’ 8th protocol upgrade proposal: Hangzhou]
  • [Measuring OCaml compilation speed after a refactoring]
  • [Writing Lifters Using Primus Lisp]
  • [Tarides Returns to FIC 2021]
  • [Generating static and portable executables with OCaml]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Announcing Tezos’ 8th protocol upgrade proposal: Hangzhou]
<https://marigold.dev/blog/announcing-hangzhou/>

[Measuring OCaml compilation speed after a refactoring]
<http://gallium.inria.fr/blog/measuring-compilation-time/>

[Writing Lifters Using Primus Lisp]
<http://binaryanalysisplatform.github.io/2021/09/15/writing-lifters-using-primus-lisp/>

[Tarides Returns to FIC 2021]
<https://tarides.com/blog/2021-09-06-tarides-returns-to-fic-2021>

[Generating static and portable executables with OCaml]
<https://www.ocamlpro.com/2021/09/02/generating-static-and-portable-executables-with-ocaml/>


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: 17425 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-21  9:09 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-09-21  9:09 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of September 14 to
21, 2021.

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

opam-grep: search through the sources of all the packages in opam-repository
Hardcaml MIPS CPU Learning Project and Blog
Puzzling through some GADT errors
Parany for multicore OCaml
OCaml 4.13.0, second release candidate
Unicode 14.0.0 update for Uucd, Uucp, Uunf and Uuseg
Set up OCaml 2.0.0-beta4
Become an Outreachy Mentor: support the growth and diversity of the OCaml community
The OCaml 4.13 preview for Merlin is now available
Old CWN


opam-grep: search through the sources of all the packages in opam-repository
════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-opam-grep-search-through-the-sources-of-all-the-packages-in-opam-repository/8434/3>


Kate announced
──────────────

  I've just released opam-grep.0.2.0 with quite a bit of change compared
  to the previous version. Here is the highlight:
  • Complete rewrite from shell script to OCaml, making it more portable
  • Use the faster `ripgrep' and `ugrep' over `grep' when available
    (suggestion by @Engil)
  • Use the `progress' library to show progress instead of a
    non-portable/DIY spinner

  See the [changelog] for the full list of relevant changes.

  *Big thanks to @CraigFe for the `progress' library (such a treat!) and
  to @dbuenzli for `bos' and `cmdliner' in particular, making it easy to
  do such rewrite* :relaxed:


[changelog]
<https://github.com/kit-ty-kate/opam-grep/blob/master/CHANGES.md>


Hardcaml MIPS CPU Learning Project and Blog
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/hardcaml-mips-cpu-learning-project-and-blog/8088/10>


Alexander (Sasha) Skvortsov announced
─────────────────────────────────────

  Hi everyone! We are excited to announce that we have completed this
  project and blog. Progress has been slow these past few months due to
  work, internships, and college, but we’ve now released [v1.0.0 on
  GitHub]. We also published posts on:

  • [Design patterns, conventions, and testing]
  • [How the Always DSL can be used to write safe “pseudo-imperative”
    code in Hardcaml]
  • [Hardcaml’s testing and interactive simulation tools]
  • [A recap of some interesting hardware/CPU features in our design]

  Finally, we published a [conclusion blog post], which wraps up some
  strengths/weaknesses of Hardcaml, as well as some takeaways on OCaml
  and blogging more generally.

  Thank you to @andyman and @fyquah95 for building Hardcaml, and for
  helping us out on GitHub issues! We really appreciate your time and
  suggestions.

  Overall, we’ve come to the conclusion that Hardcaml is a much better
  tool for hardware design than Verilog. This has been a great
  experience, and we walk away with a better understanding of hardware,
  functional programming, and technical writing.


[v1.0.0 on GitHub]
<https://github.com/askvortsov1/hardcaml-mips/releases/tag/v1.0.0>

[Design patterns, conventions, and testing]
<https://ceramichacker.com/blog/14-8x-design-patterns-conventions-and-testing>

[How the Always DSL can be used to write safe “pseudo-imperative” code
in Hardcaml]
<https://ceramichacker.com/blog/15-9x-always-dsl-and-the-control-unit>

[Hardcaml’s testing and interactive simulation tools]
<https://ceramichacker.com/blog/16-10x-testing-and-debugging-hardcaml>

[A recap of some interesting hardware/CPU features in our design]
<https://ceramichacker.com/blog/18-11x-cpu-functionality-wrap-up>

[conclusion blog post]
<https://ceramichacker.com/blog/20-1212-project-conclusion>


Puzzling through some GADT errors
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/puzzling-through-some-gadt-errors/8478/8>


Deep in this thread, gasche said
────────────────────────────────

  Not exactly what you are asking for, but @Octachron wrote an excellent
  [chapter on GADTs] in the OCaml manual, which could be recommended to
  people starting GADT programming. It explains why recursive functions
  on GADT need "explicit polymorphic annotations" in less
  "implementation driven" terms.

  (The chapter also demonstrates the new naming scheme for existential
  type variables introduced by GADT constructors, which can help a lot
  working through type errors, but are still a bit heavy and deserve a
  gentle introduction.)


[chapter on GADTs] <https://ocaml.org/releases/4.12/manual/gadts.html>


octachron then added
────────────────────

  I have only written the nomenclature part and a bit of the explanation
  for recursive functions in this chapter, @garrigue is the author of
  most of this chapter.


Parany for multicore OCaml
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/parany-for-multicore-ocaml/8495/1>


UnixJunkie announced
────────────────────

  There is now an implementation using multicore-OCaml in the 'domains'
  branch.

  <https://github.com/UnixJunkie/parany/tree/domains>

  People are very welcome to give it a try and share the speedup they
  observe, especially compared to fork-based parallelism.

  Thanks to @nilsbecker for having motivated me.


UnixJunkie later added
──────────────────────

  If you don't use the domains branch, then parany is using fork-based
  parallelism.  If you want to use the domains branch, you need to
  install multicore-ocaml first:
  ┌────
  │ opam switch create 4.12.0+domains
  │ eval `opam config env`
  └────


OCaml 4.13.0, second release candidate
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-13-0-second-release-candidate/8496/1>


octachron announced
───────────────────

  The release of OCaml 4.13.0 is expected for next week.

  Since we had a native code generation bug fix and two minor
  configuration tweaks since the first release candidate, we are
  publishing a second release candidate.  If you find any bugs, please
  report them here:

  <https://github.com/ocaml/ocaml/issues>

  Happy hacking, Florian Angeletti for the OCaml team.


Installation instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.13.0~rc2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  If you want to tweak the configuration of the compiler, you can switch
  to the option variant with:

  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.13.0~rc2+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────

  where <option_list> is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and no-flat-float-array switch:
  ┌────
  │ opam switch create 4.13.0~rc2+flambda+nffa
  │ --packages=ocaml-variants.4.13.0~rc2+options,ocaml-option-flambda,ocaml-option-no-flat-float-array
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with "opam search ocaml-option".

  The source code for the release candidate is also available at these
  addresses:

  • <https://github.com/ocaml/ocaml/archive/4.13.0-rc2.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.13/ocaml-4.13.0~rc2.tar.gz>


Changes since the first release candidate
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • [#10626], [#10628]: Wrong reloading of the x86-64 instruction for
    integer multiplication by a constant, causing the assembler to
    reject the ocamlopt-generated code. (Xavier Leroy, report by Dave
    Aitken, review by Vincent Laviron)

  • [#10176], [#10632(new in rc2)]: By default, call the assembler
    through the C compiler driver (Sébastien Hinderer, review by Gabriel
    Scherer, David Allsopp and Xavier Leroy)

  • [#10451], [#10635(new in rc2)]: Replace the use of iconv with a C
    utility to convert $(LIBDIR) to a C string constant on Windows when
    building the runtime. Hardens the generation of the constant on Unix
    for paths with backslashes, double-quotes and newlines. (David
    Allsopp, review by Florian Angeletti and Sébastien Hinderer)


[#10626] <https://github.com/ocaml/ocaml/issues/10626>

[#10628] <https://github.com/ocaml/ocaml/issues/10628>

[#10176] <https://github.com/ocaml/ocaml/issues/10176>

[#10632(new in rc2)] <https://github.com/ocaml/ocaml/issues/10632>

[#10451] <https://github.com/ocaml/ocaml/issues/10451>

[#10635(new in rc2)] <https://github.com/ocaml/ocaml/issues/10635>


Unicode 14.0.0 update for Uucd, Uucp, Uunf and Uuseg
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-unicode-14-0-0-update-for-uucd-uucp-uunf-and-uuseg/8497/1>


Daniel Bünzli announced
───────────────────────

  Unicode 14.0.0 was released on the 14th of september.

  It adds 838 new characters to the standard including, for our friends
  from Central Asia, support for [Old Uyghur].  For information about
  all the other additions, see [the announcement page].

  Accordingly the libraries mentioned at the end of this message had to
  be updated, consult the individual release notes for details. Both
  Uucd and Uucp are incompatible releases sinces new script and block
  enumerants had to be added.

  Best,

  Daniel

  P.S. Though I'm not very fond of the concept, I recently enabled
  sponsors on my github account as an experiment. So I'd like to thanks
  my [github sponsors], @davesnx became the first one monday.


[Old Uyghur]
<https://unicode.org/charts/PDF/Unicode-14.0/U140-10F70.pdf>

[the announcement page]
<http://blog.unicode.org/2021/09/announcing-unicode-standard-version-140.html>

[github sponsors] <https://github.com/sponsors/dbuenzli/>


Set up OCaml 2.0.0-beta4
════════════════════════

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


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

Changed
╌╌╌╌╌╌╌

  • Set `OPAMSOLVERTIMEOUT' to `1000' to avoid a timeout even if the
    opam solver is slow.
  • Increase cache hit ratio by loosening restore keys of opam cache.

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


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


Sonja Heinze announced
──────────────────────

  Hey all, I've just submitted an Outreachy project for the winter
  round. The project is to write the basic ppx_deriving plugins in
  ppxlib; that is, the ones that don't already have a version based on
  ppxlib. I think both, having them available to use, and having their
  code available as simple examples of how to use Ppxlib.Deriving would
  be very nice! And improving ppxlib's documentation and finding simple
  issues on already existing PPXs to prepare for Outreachy, will be
  beneficial as well.

  Of course, it's not clear if someone with the right interest comes
  along for this project, but if we don't find an intern for it this
  round, I can just re-submit the same project next round.


Sonja Heinze
────────────

  Btw, the deadline to submit projects was extended and is now Sept
  23rd. So the timeline in our post above is slightly outdated.


The OCaml 4.13 preview for Merlin is now available
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-the-ocaml-4-13-preview-for-merlin-is-now-available/8436/6>


Continuing this thread, Kate announced
──────────────────────────────────────

  The OCaml 4.13 preview for ocaml-lsp-server is now available as well.

  To install it along with the OCaml 4.13 rc, please refer to the first
  post.

  If you encounter any problems while using ocaml-lsp-server, please
  feel free to report it directly in
  <https://github.com/ocaml/ocaml-lsp/pull/506>


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: 26751 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-09-07 13:23 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-09-07 13:23 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of August 31 to
September 07, 2021.

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

Just reinvented OOP
v3.OCaml.org: A roadmap for OCaml's online presence
Become an Outreachy Mentor: support the growth and diversity of the OCaml community
Generating static and portable executables with OCaml
OCaml quant-developer at Bloomberg. London or New York
HTTP client library
Other OCaml News
Old CWN


Just reinvented OOP
═══════════════════

  Archive: <https://discuss.ocaml.org/t/just-reinvented-oop/8399/1>


Yawar Amin said
───────────────

  ┌────
  │ let ( .![] ) obj f = f obj
  │ 
  │ type person = { id : int; name : string }
  │ 
  │ let id { id; _ } = id
  │ 
  │ let bob = { id = 1; name = "Bob" }
  │ let next_id = bob.![id].![succ]
  └────

  ==> 2


Kiran Gopinathan replied
────────────────────────

  Haha, what a coincidence, just did the same very recently while
  translating a rust library to OCaml:
  <https://github.com/Gopiandcode/ego/blob/5daf312f8a444f9abcde5996c671b9282727a972/lib/generic.ml#L211>
  ┌────
  │ let eclasses = eg.@[eclasses] in
  │ let cost_map = Id.Map.create 10 in
  │ let node_total_cost node =
  │   let has_cost id = Id.Map.mem cost_map (eg.@[find] id) in
  │   if List.for_all has_cost (L.children node)
  │   then let cost_f id = fst @@ Id.Map.find cost_map (eg.@[find] id) in Some (E.cost cost_f
  │ node)
  │   else None in
  │   (* ... *)
  └────
  with `.@[]' defined as:
  ┌────
  │ let (.@[]) self fn = fn self [@@inline always]
  └────

  for bonus(?) points, you can name the first parameter self:
  ┌────
  │ let add_enode self (node: Id.t L.shape) =
  │   let node = self.@[canonicalise] node in
  │   (* ... *)
  └────
  I don't normally write code like this in OCaml, but in this case, it
  made porting from rust easier, because the code mostly looked the
  same.


hyphenrf also replied
─────────────────────

  You can use the multiple-indexing syntax to implement slicing (well,
  technically subs) sugar:
  ┌────
  │ let (.:[;..]) s = function
  │   | [|start; finish|] -> String.sub s start (finish - start)
  │   | _ -> raise (Invalid_argument "slice takes exactly two indexes")
  └────
  ┌────
  │ # "hello world".:[1;5];;
  │ - : string = "ello"
  └────
  The new indexing syntax is quite versatile :>


Kiran Gopinathan added
──────────────────────

  Oh wow, this is perfect! brb, off to reimplement the python slicing
  semantics in OCaml:
  ┌────
  │ let (.@[;..]) ls = function[@warning "-8"]
  │   | [| start; -1 |] ->
  │     List.to_iter ls
  │     |> Iter.zip_i
  │     |> Iter.drop_while (Pair.fst_map ((>) start))
  │     |> Iter.map snd
  │   | [| start; finish |] ->
  │     List.to_iter ls
  │     |> Iter.zip_i
  │     |> Iter.drop_while (Pair.fst_map ((>) start))
  │     |> Iter.take_while (Pair.fst_map ((>) finish))
  │     |> Iter.map snd
  │   | [| start; finish; step |] ->
  │     List.to_iter ls
  │     |> Iter.zip_i
  │     |> Iter.drop_while (Pair.fst_map ((>) start))
  │     |> Iter.take_while (Pair.fst_map ((>) finish))
  │     |> Iter.filter (Pair.fst_map (fun ind -> (ind - start) mod step = 0))
  │     |> Iter.map snd
  └────


v3.OCaml.org: A roadmap for OCaml's online presence
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocamls-online-presence/8368/19>


Continuing this thread, Anil Madhavapeddy replied to many comments
──────────────────────────────────────────────────────────────────

  Many thanks for all the constructive comments and suggestions so far,
  and also for those who have gotten in touch to contribute. Please do
  keep them coming (either on this thread or on the various issue
  trackers that @jonludlam and @patricoferris have pointed to).  I'll
  answer some earlier questions here:

        Having said that, the colors on the [packages landing page
        ] feel very aggressive to me. Might be my setup here, but
        I would like to have a slightly less harsh contrast.

        Also, there is a bit of an overlap in content with
        [https://ocamlverse.github.io/ ] for some things (eg best
        practices, community) but the (to me) most valuable
        feature is missing: The ecosystems overview, where I can
        find packages sorted thematically. Could such a section
        also have a place in the packages subpage somewhere?
        Alternatively, maybe opam can allow to “tag” packages in
        the future so one could see all packages for graphics,
        databases etc.

  The styling of the /packages sub-URL does indeed differ from the main
  design, but this is simply due to a temporary technical detail. The
  majority of the site uses React/NextJS to generate the frontend, and
  this uses the now-trendy medium-contrast colours and also features
  like fast-page-switching that NextJS offers.  However, the
  documentation portion generated around 2.7 million individual pages
  when run across the full opam repository, and so we restored to
  dynamic generation of the content for that. What's going to happen
  next is a rationalisation of the code across the ReScript and OCaml
  frontends so that there will be no observable difference in the colour
  schemes across the full site.

  Regarding creating a categorised list of recommendations, that is
  absolutely in scope for the v3 iteration of the site. However, this
  metadata should ideally live in the opam-repository (for example,
  using `tags' as you suggest, which opam already supports). If anyone
  would like to have a go at this, I'd encourage PRs to the
  opam-repository to add the relevant tag metadata for a
  codex. Meanwhile, @lambda_foo @tmattio and @patricoferris are working
  on the core OCaml Platform workflow information for the guides section
  of the website which will cover opam, merlin, lsp-server, dune and so
  on.

        Do we have access to all of the previous years’ workshops
        to add to [watch.ocaml.org]?  I can see pieces of 2015,
        2017, 2020 and this year. @avsm

        Is it possible to add the ML Workshop as well?

  Absolutely. The watch.ocaml.org has held up nicely after the OCaml
  Workshop, so I think it's in good shape to populate with more
  videos. This needs a volunteer to help us upload the past [nine years]
  of videos from YouTube to watch.ocaml.org. If anyone wants to have a
  go, please message me and I'll create you an account.

        It’s a bit unclear what you meant in this paragraph. Does
        that mean that you plan to kill the ocaml planet ? I would
        find it a little bit sad.

        One of the reason why you may feel it doesn’t work well
        may be that it has been constantly broken in the current
        version of the site…

  I'm not sure why you think the current ocaml.org new feed has been
  broken – it's been working fairly reliably for the past decade. The
  only real problem came up a few times when a feed's domain expired and
  got taken over by domain squatters, at which point we got spam into
  the main page of ocaml.org.

  What I meant with that part of the announcement is that the
  syndication feed should not be mistaken with original news on the
  website. Right now it's difficult to distinguish official
  announcements (such as compiler or opam releases) as they are a little
  scattered (e.g. on opam.ocaml.org). The plan is to combine the
  [platform-blog] with the new website directly. I've also been
  considering just having a special tag on this forum so that nice
  announcement posts could also be syndicated to the website easily (for
  example, @gasche's compiler newsletters).

  My general desire is to _grow_ the planet feed and syndication system,
  but to clearly demarcate them as not being published by ocaml.org and
  to manage them via more modern decentralised techniques that feature
  spam, moderation and archival. PeerTube is a good example of this for
  videos that is working well, and I'd welcome suggestions for Atom/RSS
  (there must be something in this space, ideally ActivityPub-based).

  Depending on how the experiments go, it's very likely that we'll have
  a Matrix homeserver for ocaml.org where CI bots can report status
  information (see this [prototype PR]) for ocaml-ci that will also
  apply to opam-repository. The goal here is to for ocaml.org to publish
  its data using an open protocol, which can then be syndicated into
  whatever technologies are in vogue (e.g. Discord, Slack, Teams, …).

  So if you spot some decentralised syndication system that you think
  might be interesting for OCaml, please do let me know.  Even better,
  if you'd like to develop one to tailor it to our needs, let me know
  even sooner ;-)


[packages landing page ] <https://v3.ocaml.org/packages>

[https://ocamlverse.github.io/ ] <https://ocamlverse.github.io/>

[watch.ocaml.org] <http://watch.ocaml.org>

[nine years] <https://ocaml.org/meetings/ocaml/2012/>

[platform-blog] <https://github.com/ocaml/platform-blog>

[prototype PR] <https://github.com/ocurrent/ocaml-ci/pull/362>


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


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

  There's been a very disappointing response to this call for mentors to
  increase the diversity of our community. Precisely *noone* has been in
  touch for the winter call, leaving the burden of mentorship on the
  same people that did all the work this summer.

  Before making [new calls for programs like GSoC], let's get Outreachy
  onto more sustainable ground please. We are purely limited by
  mentorship time at present. This can be as simple as organising new
  first issues for projects in the ecosystem, and all the way to pair
  programming with a mentee. You can chose how to be involved.


[new calls for programs like GSoC]
<https://discuss.ocaml.org/t/v3-ocaml-org-a-roadmap-for-ocamls-online-presence/8368/16?u=avsm>


Generating static and portable executables with OCaml
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/generating-static-and-portable-executables-with-ocaml/8405/1>


OCamlPro announced
──────────────────

  It has been a few times now that we have been tasked to generate
  portable binaries for different projects. Over time, we have gathered
  quite some know-how and, seeing the question frequently arise in the
  community, we decided to share this experience.

  You can find the article written by Louis Gesbert on[ the OCamlPro
  blog]


        Distributing OCaml software on opam is great (if I dare
        say so myself), but sometimes you need to provide your
        tools to an audience outside of the OCaml community, or
        just without recompilations or in a simpler way.

        However, just distributing the locally generated binaries
        requires that the users have all the required shared
        libraries installed, and a compatible libc. It's not
        something you can assume in general, and even if you don't
        need any C shared library or are confident enough it will
        be installed everywhere, the libc issue will arise for
        anyone using a distribution based on a different kind, or
        a little older than the one you used to build.

        There is no built-in support for generating static
        executables in the OCaml compiler, and it may seem a bit
        tricky, but it's not in fact too complex to do by hand,
        something you may be ready to do for a release that will
        be published. So here are a few tricks, recipes and advice
        that should enable you to generate truly portable
        executables with no external dependency whatsoever. Both
        Linux and macOS will be treated, but the examples will be
        based on Linux unless otherwise specified.

  Don't hesitate to share your thoughts with us, have a good reading!


[ the OCamlPro blog]
<https://www.ocamlpro.com/2021/09/02/generating-static-and-portable-executables-with-ocaml/>


OCaml quant-developer at Bloomberg. London or New York
══════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-quant-developer-at-bloomberg-london-or-new-york/8409/1>


Philip Craig announced
──────────────────────

  Extend a financial contracts DSL that is implemented in OCaml.

  It's London or New York based. It's not a remote position.

  Please see details and/or apply at
  (<https://careers.bloomberg.com/job/detail/93825>)


HTTP client library
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-http-client-library/8428/1>


Hannes Mehnert announced
────────────────────────

  we just released to the opam-repository the [`http-lwt-client']
  package, which consists of both a library doing HTTP requests and a
  binary (`hurl') that does HTTP requests.

  The code is based on [HTTP/AF] and [H2], and uses [tls] for HTTPS
  connections. Both HTTP/1(.1) and HTTP/2 protocols are supported. The
  motivation behind this package is to have a http client that has a
  reasonably small dependency cone, is purely implemented in OCaml, and
  uses the asynchronous task library lwt.

  This package uses [happy-eyeballs] to connect to a remote host via
  IPv4 and IPv6, as proposed by IETF [RFC 8305]: on any computer with
  either IPv4 or IPv6 connectivity, a remote IPv6 or IPv4 server will be
  connected. Preference is given to IPv6.

  If a https url is provided, the server certificate is verified using
  the [ca-certs] package.

  If you experience any issues or have further needs for this package,
  please report an issue on the GitHub issue tracker.

  The installation is just an `opam install http-lwt-client' away :)


[`http-lwt-client'] <https://github.com/roburio/http-lwt-client>

[HTTP/AF] <https://github.com/inhabitedtype/httpaf>

[H2] <https://github.com/anmonteiro/ocaml-h2>

[tls] <https://github.com/mirleft/ocaml-tls>

[happy-eyeballs] <https://github.com/roburio/happy-eyeballs>

[RFC 8305] <https://tools.ietf.org/html/rfc8305>

[ca-certs] <https://github.com/mirage/ca-certs>


Hannes Mehnert later added
──────────────────────────

  now [0.0.2] is released that unifies the response type and API
  (previously it was a variant and clients had to write code for both
  HTTP1 and HTTP2). Now, a single record and Status/Headers/Version
  module aliases are provided (very close to HTTP/AF). Enjoy.


[0.0.2] <https://github.com/ocaml/opam-repository/pull/19410>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Goodbye Core_kernel]
  • [Tarides Engineers to Present at ICFP 2021]
  • [Benchmarking OCaml projects with current-bench]
  • [What the interns have wrought, 2021 edition]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Goodbye Core_kernel] <https://blog.janestreet.com/goodbye-Core_kernel/>

[Tarides Engineers to Present at ICFP 2021]
<https://tarides.com/blog/2021-08-26-tarides-engineers-to-present-at-icfp-2021>

[Benchmarking OCaml projects with current-bench]
<https://tarides.com/blog/2021-08-26-benchmarking-ocaml-projects-with-current-bench>

[What the interns have wrought, 2021 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2021/>


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: 34198 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-24 13:44 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-08-24 13:44 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of August 17 to 24,
2021.

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

routes v1.0.0 released
Feather 0.3.0
Release of GopCaml-mode (0.0.3) and GopCaml-mode-Merlin (0.0.4) - Wizardry release
Share my experience about running OCaml on WebAssembly
Old CWN


routes v1.0.0 released
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-routes-v1-0-0-released/8319/1>


Anurag Soni announced
─────────────────────

  I'd like to announce release of version 1.0.0 of [routes]. The PR to
  opam repository has been merged, and the new release should be
  available via opam once the package cache refreshes.

  *Routes* provides a DSL for bi-directional URI dispatch. It allows
  writing route definitions that can be used for both matching, and
  printing URI paths.

  Changes since the last opam release:

  • Support for merging two routers by adding a union operation ([#115],
    [@Chattered])
  • Support for wildcard parameters ([#118], [#129], [@Lupus]) ->
    Compile time checks ensure that wildcard parameters can only be
    defined at the end of a route
  • Support `map' operation for path parameter definitions, and support
    defining path prefixes that can be pre-prended to other routes
    ([#121], [@Chattered])
  • Addition of a `ksprintf' style function for routes. ([#123],
    [@Chattered])

  Examples of how to use the library are available in the [tests] and in
  a [small demo]

  Documentation can be found [here]

  *Edit*

  1.0.0 is available via opam now -
  <http://opam.ocaml.org/packages/routes/routes.1.0.0/>


[routes] <https://github.com/anuragsoni/routes/>

[#115] <https://github.com/anuragsoni/routes/pull/115>

[@Chattered] <https://github.com/Chattered>

[#118] <https://github.com/anuragsoni/routes/pull/118>

[#129] <https://github.com/anuragsoni/routes/pull/129>

[@Lupus] <https://github.com/Lupus>

[#121] <https://github.com/anuragsoni/routes/pull/121>

[#123] <https://github.com/anuragsoni/routes/pull/123>

[tests]
<https://github.com/anuragsoni/routes/blob/b9bb8a0f50b7bd9fbd0c79113142ea82830ce2bb/test/routing_test.ml>

[small demo]
<https://github.com/anuragsoni/routes/blob/b9bb8a0f50b7bd9fbd0c79113142ea82830ce2bb/example/no_http.ml>

[here] <https://anuragsoni.github.io/routes/>


Feather 0.3.0
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-feather-0-3-0/8322/1>


Charles announced
─────────────────

  I'm happy to announce Feather 0.3.0! Feather is a minimal library for
  bash-like scripting and process execution.  ([github/tutorial],
  [documentation]) This release adds two major features:


[github/tutorial] <https://github.com/charlesetc/feather>

[documentation]
<https://www.charlesetc.com/feather/feather/Feather/index.html>

1. A new interface for collecting the exit status, stdout, and stderr of a Feather command.
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  For example, you can easily print a process's stderr if it exits
  non-zero:

  ┌────
  │ open Feather;;
  │ let stderr, status =
  │   process "ls" [ "/tmp/does-not-exist" ] |> collect stderr_and_status
  │ in
  │ if status <> 0 then failwith ("ls failed with stderr:\n" ^ stderr)
  └────
  where the types are

  ┌────
  │ val process : string -> string list -> cmd
  │ 
  │ type 'a what_to_collect
  │ val stderr_and_status : (string * int) what_to_collect
  │ 
  │ val collect :
  │   ?cwd:string ->
  │   ?env:(string * string) ->
  │   'a what_to_collect ->
  │   cmd ->
  │   'a
  └────

  as you can imagine, we expose several of these
  `what_to_collect''s. Here's the full set:

  ┌────
  │ val stdout : string what_to_collect
  │ val stderr : string what_to_collect
  │ val status : int what_to_collect
  │ 
  │ val stdout_and_stderr : (string * string) what_to_collect
  │ val stdout_and_status : (string * int) what_to_collect
  │ val stderr_and_status : (string * int) what_to_collect
  │ 
  │ type everything = { stdout : string; stderr : string; status : int }
  │ val everything : everything what_to_collect
  └────
  We considered different design approaches here. I think what we landed
  on keeps the call site readable and the types of the interface simple.

  It should be noted: the simplest way to run a command without
  collecting anything is to use [Feather.run].


[Feather.run]
<https://www.charlesetc.com/feather/feather/Feather/index.html#val-run>


2. The ability to wait on background processes and collect their output.
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Starting with Feather 0.1.0, you were able to start processes in the
  background, but the only way to wait for them to complete was to use
  Feather's [async wrapper].  For those wanting an async-less,
  direct-style interface, we now expose new methods to do this properly:

  ┌────
  │ type 'a background_process
  │ 
  │ val run_in_background :
  │   ?⁠cwd:string ->
  │   ?⁠env:(string * string) Base.list ->
  │   cmd ->
  │   unit background_process
  │ 
  │ val collect_in_background :
  │   ?cwd:string ->
  │   ?env:(string * string) list ->
  │   'a what_to_collect ->
  │   cmd ->
  │   'a background_process
  │ 
  │ val wait : 'a background_process -> 'a
  │ val wait_all : unit -> unit
  └────
  where an example use might be

  ┌────
  │ let server_process =
  │    process "my-server.exe" [] |> collect_in_background stdout_and_status
  │ in
  │ ... do other things ...
  │ match Feather.wait server_process with
  │ | (stdout, 0) -> ...
  │ | (_, 1) -> ...
  └────

  Thanks again to @Firobe and @tmarti2 for their contributions to this
  release! I think we've made a lot of progress here and I'm excited to
  see where things go :slight_smile:


[async wrapper]
<https://www.charlesetc.com/feather/feather_async/Feather_async/index.html>


Release of GopCaml-mode (0.0.3) and GopCaml-mode-Merlin (0.0.4) - Wizardry release
══════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-3-and-gopcaml-mode-merlin-0-0-4-wizardry-release/8333/1>


Kiran Gopinathan announced
──────────────────────────

  I'm pleased to announce the latest version of *GopCaml-mode* (0.0.3),
  and the new release of *GopCaml-mode-Merlin* (0.0.4).

  GopCaml-mode-Merlin is a brand *new!* variant of GopCaml-mode that
  uses the Merlin parser rather than the OCaml compiler-libs one, and
  thus has some level of robustness to invalid syntax:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/a/a09586b9db3bf19667b6969c701a40f0791a2a9d.gif>

  If that's piqued your interest, I'd recommend checking out the release
  posts for the previous versions for more details on what GopCaml can
  do, and how to get it: [0.0.2 release], [0.0.1 release]

  The Merlin parser seems to assign text-regions for syntactic
  constructs slightly more liberally than the standard OCaml parser, so
  the overlays can feel a bit weird if you're used to the normal GopCaml
  overlays, but the benefit is that all your favorite structural
  movement/transformation operations work even when you're dealing with
  ill-formed programs, allowing for a more fluid editing experience:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/9/9f2976b47018e2d892b9cea09da913d07f8c1f00.gif>


[0.0.2 release]
<https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-2-unicode-compatibility-update/7425>

[0.0.1 release]
<https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310>

Detailed Changelog
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • *new!* [for GopCaml-mode-Merlin] *Robustness to ill-formated syntax*
    • Vendored a copy of Merlin to reuse its parser and thereby gain
      it's robustness to invalid syntax.
  • *new!* *Added support for customisable verbosity*
    • Customise the Emacs variable `gopcaml-messaging-level` to change
      the level of messages that are output by GopCaml. Set it to
      `'none` to disable messages entirely.
  • *new!* *Fixed bug when starting zipper mode at the start of a file.*
    • Zipper mode selects the immediately prior byte position to avoid
      inconsistencies when the cursor is just on the edge of an
      expression, but when the cursor is at position 1, this causes an
      error as 0 is not a valid point.
  • *new!* *Special casing of shebangs*
    • Added support for handling shebangs at the start of a buffer.
    • Implemented as part of a larger library for preprocessing
      buffertext before running the parser on it - could be extended to
      support additional preprocessing in the future.
    • Another possible direction for extension is to use an Emacs
      callback to modify the text, although this may not be ideal, as
      the parsing has to be as fast as possible.


Get Gopcaml-mode
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Its as easy as 1, 2, 3!

  1. Install from opam (either `gopcaml-mode` xor
     `gopcaml-mode-merlin`):

     ┌────
     │ opam install gopcaml-mode
     └────
     or
     ┌────
     │ opam install gopcaml-mode-merlin
     └────

  2. Compile your emacs with support for dynamic modules
  3. Load gopcaml-mode in your init.el:
     ┌────
     │ (let ((opam-share (ignore-errors (car (process-lines "opam" "var" "share")))))
     │     (when (and opam-share (file-directory-p opam-share))
     │       ;; Register Gopcaml mode
     │       (add-to-list 'load-path (expand-file-name "emacs/site-lisp" opam-share))
     │ 	(autoload 'gopcaml-mode "gopcaml-mode" nil t nil)
     │ 	(autoload 'tuareg-mode "tuareg" nil t nil)
     │ 	(autoload 'merlin-mode "merlin" "Merlin mode" t)
     │       ;; Automatically start it in OCaml buffers
     │       (setq auto-mode-alist
     │       (append '(("\\.ml[ily]?$" . gopcaml-mode)
     │ 	  ("\\.topml$" . gopcaml-mode))
     │ 	auto-mode-alist))
     │       ))
     └────

  See the [release post ] for version 0.0.1 for detailed instructions on
  how you can install it.


[release post ]
<https://discuss.ocaml.org/t/introducing-gopcaml-mode-structural-ocaml-editing/5310>


Contribute
╌╌╌╌╌╌╌╌╌╌

  • Github: [GitHub - Gopiandcode/gopcaml-mode: [MIRROR] Ultimate Ocaml
    Editing Mode]
  • Gitlab: [Kiran Gopinathan / gopcaml-mode · GitLab ]


[GitHub - Gopiandcode/gopcaml-mode: [MIRROR] Ultimate Ocaml Editing
Mode] <https://github.com/Gopiandcode/gopcaml-mode>

[Kiran Gopinathan / gopcaml-mode · GitLab ]
<https://gitlab.com/gopiandcode/gopcaml-mode>


Share my experience about running OCaml on WebAssembly
══════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/share-my-experience-about-running-ocaml-on-webassembly/8343/1>


Vincent Chan announced
──────────────────────

  In the last two weeks, I was working on migrating OCaml to
  WebAssembly. I wrote an article to share my experience.

  [Run OCaml in the browser by WebAssembly | by Vincent Chan | Aug, 2021
  | Medium]


[Run OCaml in the browser by WebAssembly | by Vincent Chan | Aug, 2021 |
Medium]
<https://okcdz.medium.com/run-ocaml-in-the-browser-by-webassembly-31ce464594c6>


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: 27625 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-17  6:24 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-08-17  6:24 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of August 10 to 17,
2021.

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

http-multipart-formdata v3.0.1 released
Call for participation: ML Family Workshop 2021
Coq-of-ocaml to translate OCaml to Coq
Old CWN


http-multipart-formdata v3.0.1 released
═══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v3-0-1-released/8261/2>


Continuing the thread from last week, Hannes Mehnert asked
──────────────────────────────────────────────────────────

  Thanks for your work on that. I'm curious about the different
  "multipart" libraries now available for OCaml – anyone has a brief
  comparison of them?

  • [http-multipart-formdata] as announced above
  • [multipart_form] by @dinosaure
  • [multipart-form-data] by cryptosense

  Are there functional differences? Correctness? Performance? Or just a
  matter of style and co-development?


[http-multipart-formdata]
<https://github.com/lemaetech/http-multipart-formdata>

[multipart_form] <https://github.com/dinosaure/multipart_form/>

[multipart-form-data]
<https://github.com/cryptosense/multipart-form-data>


Bikal Lem replied
─────────────────

  One obvious difference among the three is `http-multipart-formdata'
  doesn't depend on any IO/Promise libraries, such as lwt or async. so
  you may find it easier to integrate in your project.

  `mulitpart-form-data' exposes a callback based streaming api, whereas
  http-multipart-formdata exposes a non-callback, non-blocking based API
  streaming api.

  The API surface of `http-multipart-formdata' is kept as low as
  possible, primarily 3 API calls - `boundary, reader' and `read' call.

  The dependency list of `http-multipart-formdata' is the thinnest. This
  may or may not be an issue depending on your aesthetics. However,
  relatively/comparatively the less your dependencies, the easier it is
  to integrate the lib with other OCaml libs and environments such as
  various OSes.


Bikal Lem added
───────────────

  I should also add `http-multipart-formdata' has been implemented with
  zero-copy streaming and minimal allocation in mind.


Call for participation: ML Family Workshop 2021
═══════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-08/msg00005.html>


Jonathan Protzenko announced
────────────────────────────

  We are happy to announce that the ML Family Workshop is back for its
  2021 edition, which we will be held online on Thursday August 26th, in
  conjunction with ICFP 2021. We invite you to subscribe to, and attend
  the workshop, in addition to the main ICFP conference.

  We are thrilled to announce that Don Syme will give this year's
  keynote: "Narratives and Lessons from The Early History of F#". Please
  join us!

  The program features 14 exciting submissions, including 4 short talks.
  The workshop will be held online in the 6pm-3am time band (Seoul
  Time).  Talks will be pre-recorded and uploaded online for those who
  cannot attend.

  • Program:
    <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#program>
  • Keynote:
    <https://icfp21.sigplan.org/details/mlfamilyworkshop-2021-papers/15/Keynote-Narratives-and-Lessons-from-The-Early-History-of-F>-
  • ICFP home: <http://icfp21.sigplan.org/home>


Program committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Danel Ahman (University of Ljubljana)
  • Robert Atkey (University of Strathclyde)
  • Frédéric Bour (Tarides)
  • Ezgi Çiçek (Facebook London)
  • Youyou Cong (Tokyo Institute of Technology)
  • Richard A. Eisenberg (Tweag I/O)
  • Martin Elsman (University of Copenhagen, Denmark)
  • Ohad Kammar (University of Edinburgh)
  • Naoki Kobayashi (University of Tokyo, Japan)
  • Benoît Montagu (Inria)
  • Jonathan Protzenko (Microsoft Research) (Chair)
  • Kristina Sojakova (INRIA Paris)
  • Don Syme (Microsoft)
  • Matías Toro (University of Chile)
  • Katsuhiro Ueno (Tohoku University)


Coq-of-ocaml to translate OCaml to Coq
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/coq-of-ocaml-to-translate-ocaml-to-coq/8288/1>


Guillaume Claret announced
──────────────────────────

  I am pleased to present the [coq-of-ocaml] project, to translate a
  subset of OCaml to the [Coq] proof assistant. The aim is to do formal
  verification on OCaml programs. The idea is to generate a Coq
  translation as close as possible to the original code in terms of
  intent but using the Coq syntax. As a short example, if we take the
  following OCaml code and run `coq-of-ocaml':
  ┌────
  │ type 'a tree =
  │ | Leaf of 'a
  │ | Node of 'a tree * 'a tree
  │ 
  │ let rec sum tree =
  │   match tree with
  │   | Leaf n -> n
  │   | Node (tree1, tree2) -> sum tree1 + sum tree2
  └────
  we get the following Coq file:
  ┌────
  │ Require Import CoqOfOCaml.CoqOfOCaml.
  │ Require Import CoqOfOCaml.Settings.
  │ 
  │ Inductive tree (a : Set) : Set :=
  │ | Leaf : a -> tree a
  │ | Node : tree a -> tree a -> tree a.
  │ 
  │ Arguments Leaf {_}.
  │ Arguments Node {_}.
  │ 
  │ Fixpoint sum (tree : tree int) : int :=
  │   match tree with
  │   | Leaf n => n
  │   | Node tree1 tree2 => Z.add (sum tree1) (sum tree2)
  │   end.
  └────

  We support the following OCaml features:
  • the core of OCaml (functions, let bindings, pattern-matching,…)
  • type definitions (records, inductive types, synonyms, mutual types)
  • monadic programs
  • modules as namespaces
  • modules as polymorphic records (signatures, functors, first-class
    modules)
  • multiple-file projects (thanks to Merlin)
  • both `.ml' and `.mli' files
  • existential types (we use impredicative sets option in Coq)

  We also have some support for the GADTs, the polymorphic variants, and
  the extensible types.  We are in particular working on having an
  axiom-free translation of the GADTs to Coq. We do not support:
  • side-effects outside of a monad (references, exceptions, …);
  • object-oriented programming;
  • various combinations of OCaml features for which `coq-of-ocaml'
    should generate a warning.

  Our main example and use case is the [coq-tezos-of-ocaml]
  project. This contains a translation of most of the [economic
  protocol] of the [Tezos] blockchain (around 30.000 lines of OCaml
  translated to 40.000 lines of Coq). For example, we verify the
  comparison functions defined in
  [src/proto_alpha/lib_protocol/script_comparable.ml] with
  [src/Proto_alpha/Proofs/Script_comparable.v].

  We are looking for the application to other projects too.

  We think the best way to use `coq-of-ocaml' is to continue developing
  in OCaml and run `coq-of-ocaml' to keep a synchronized translation in
  Coq. Having a working Coq translation (as compiling in Coq) forces us
  to avoid some OCaml constructs. We believe these constructs would
  probably be hard to verify anyway. Then, on the Coq side, we can
  verify some important or easy to catch properties. If there is a
  regression in the OCaml code, re-running `coq-of-ocaml' should make
  the proofs break.


[coq-of-ocaml] <https://clarus.github.io/coq-of-ocaml/>

[Coq] <https://coq.inria.fr/>

[coq-tezos-of-ocaml]
<https://nomadic-labs.gitlab.io/coq-tezos-of-ocaml/>

[economic protocol]
<https://gitlab.com/tezos/tezos/-/tree/master/src/proto_alpha/lib_protocol>

[Tezos] <https://tezos.com/>

[src/proto_alpha/lib_protocol/script_comparable.ml]
<https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/script_comparable.ml>

[src/Proto_alpha/Proofs/Script_comparable.v]
<https://nomadic-labs.gitlab.io/coq-tezos-of-ocaml/docs/proofs/script_comparable>


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: 20527 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-08-10 16:47 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-08-10 16:47 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of August 03 to 10,
2021.

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

Lwt 5.4.2
OCaml Workshop 2021: Call for Volunteers
opam 2.1.0!
containers 3.5
Short contract job for OCaml/C++ programmer
http-multipart-formdata v3.0.1 released
wtr (Well Typed Router) v2.0.0 released
New playlist just dropped
Other OCaml News
Old CWN


Lwt 5.4.2
═════════

  Archive: <https://discuss.ocaml.org/t/ann-lwt-5-4-2/8248/1>


Raphaël Proust announced
────────────────────────

  We are glad to announce the release of version 5.4.2 of Lwt: a
  bugfix-only release.

  <https://github.com/ocsigen/lwt/releases/tag/5.4.2>

  You can update to this version in `opam' :

  ┌────
  │ opam update
  │ opam upgrade lwt
  └────

  Thanks to the contributors for finding and fixing the bugs, leading to
  this release. Check out the release notes (link above) for a full
  list.


OCaml Workshop 2021: Call for Volunteers
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-workshop-2021-call-for-volunteers/8253/1>


Frédéric Bour announced
───────────────────────

  The OCaml Workshop will be held virtually, just like last year. We are
  looking for volunteers to fill the role of session host.


[Session Hosts]
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  On August 27, the session hosts will assist session chairs in
  streaming the pre-recorded videos as well as helping and moderating
  the Q&A sessions. They will also be responsible for security and be
  ready to react to potential threats and wrongdoers.

  This year there will be only one broadcast for each session, but the
  workshop day will be quite long. There will be six sessions, lasting
  one hour and a half, as well as a one hour keynote.


[Session Hosts]
<https://icfp20.sigplan.org/home/ocaml-2020#session-hosts>

[Duties]
┄┄┄┄┄┄┄┄

  • Moderating the text chats
  • Controlling microphones in the video-conferencing
  • Watching for the time
  • Performing sound checks
  • Welcoming and otherwise guiding participants


[Duties] <https://icfp20.sigplan.org/home/ocaml-2020#duties>


opam 2.1.0!
═══════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0/8255/1>


R. Boujbel announced
────────────────────

  We are happy to announce two opam releases: the freshly new [2.1.0] &
  the LTS support [2.0.9].


[2.1.0] <https://github.com/ocaml/opam/releases/tag/2.1.0>

[2.0.9] <https://github.com/ocaml/opam/releases/tag/2.0.9>

What's new in opam 2.1.0?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Integration of system dependencies (formerly the `opam-depext`
    plugin), increasing their reliability as it integrates the solving
    step
  • Creation of lock files for reproducible installations (formerly the
    `opam-lock` plugin)
  • Switch invariants, replacing the _"base packages"_ in opam 2.0 and
    allowing for easier compiler upgrades
  • Improved options configuration (see the new `option` and expanded
    `var` sub-commands)
  • CLI versioning, allowing cleaner deprecations for opam now and also
    improvements to semantics in future without breaking
    backwards-compatibility
  • opam root readability by newer and older versions, even if the
    format changed
  • Performance improvements to opam-update, conflict messages, and many
    other areas

  You'll find these features presentation in the [blog post] ; and for a
  full complete you can take a look [pre-releases changelogs].


[blog post] <https://opam.ocaml.org/blog/opam-2-1-0>

[pre-releases changelogs] <https://github.com/ocaml/opam/releases>


What's in 2.0.9
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This 2.0.9 version contains back-ported fixes, you can find more
  information in this [blog post], especially for fish users & sandbox
  updates.

  *Tremendous thanks to all involved people, all those who've tested,
   re-tested, tested again, given feedback, commented on issues, tested,
   tested, tested again…!*

  /The opam team/ 🐪


[blog post] <https://opam.ocaml.org/blog/opam-2-0-9>


containers 3.5
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-containers-3-5/8257/1>


Simon Cruanes announced
───────────────────────

  I'm glad to announce that version 3.5 of [containers] has just been
  released. There's a bugfix for bitvectors, and a tasteful assortment
  of new functions (see changelog). I want to thank all the
  contributors, among whom first time contributor @favonia.

  The release and changelog can be found [here]


[containers] <https://github.com/c-cube/ocaml-containers>

[here] <https://github.com/c-cube/ocaml-containers/releases/tag/v3.5>


Short contract job for OCaml/C++ programmer
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/short-contract-job-for-ocaml-c-programmer/8260/1>


Ashish Agarwal announced
────────────────────────

  We have a small project (possibly only days of work) for an
  experienced OCaml and C++ programmer. If you are available for a short
  engagement as a contractor, please DM me. Thank you.


http-multipart-formdata v3.0.1 released
═══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v3-0-1-released/8261/1>


Bikal Lem announced
───────────────────

  I am pleased to announce v3.0.1 of `http-multipart-formdata'. This
  release follows a major overhaul of the parser as well as the design
  of the library. Here is the summary of changes:

  1. Flatten module `Part_header' to `part_header'
  2. Implement reader/pull based parser to retrieve multipart parts,
     i.e. implement a `streaming' design. This is very useful if the
     HTTP file upload is large.
  3. Implement push-based incremental input model, i.e. the library is
     now a non-blocking multipart parser
  4. Remove dependency on IO based libs such as `lwt, async' since it is
     no longer needed due to point 3 above.

  Github repo: [http-multipart-formdata]

  API doc : [API manual]


[http-multipart-formdata]
<https://github.com/lemaetech/http-multipart-formdata>

[API manual]
<https://lemaetech.co.uk/http-multipart-formdata/http-multipart-formdata/Http_multipart_formdata/index.html>


wtr (Well Typed Router) v2.0.0 released
═══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-wtr-well-typed-router-v2-0-0-released/8262/1>


Bikal Lem announced
───────────────────

  I am pleased to announce v2.0.0 release of `wtr (Well Typed
  Router)'. `wtr' is a trie-based router for OCaml HTTP web
  applications.

  v2.0.0 release adds support for specifying and matching HTTP methods
  in a router. So now we can do the following;
  ┌────
  │ Wtr.(
  │     create
  │       [ {%wtr| get,post,head,delete  ; /home/about/  |} about_page
  │       ; {%wtr| head                  ; /home/:int/   |} prod_page
  │       ]
  └────
  Note: we can specify single or multiple HTTP methods supported by a
  route.

  The release also features a pretty-printer - `Wtr.pp' - for a `Wtr.t'
  type. This has proven to be very useful when diagnosing/understanding
  routing issues. Sample output below,
  ┌────
  │ POST
  │   /home
  │     /about
  │       /
  │     /:float
  │       /
  │ HEAD
  │   /home
  │     /about
  │       /
  │     /:int
  │       /
  └────

  The manual has also been improved in this release.

  • [wtr API]
  • [CoHTTP demo]
  • [CLI demo]
  • [Changes v2.0.0]


[wtr API] <https://lemaetech.co.uk/wtr/wtr/Wtr/index.html>

[CoHTTP demo]
<https://github.com/lemaetech/wtr/blob/main/examples/cohttp.ml>

[CLI demo] <https://github.com/lemaetech/wtr/blob/main/examples/demo.ml>

[Changes v2.0.0]
<https://github.com/lemaetech/wtr/blob/main/CHANGES.md#v200-2021-08-02>


New playlist just dropped
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/new-playlist-just-dropped/8272/1>


Rahul announced
───────────────

  Haven't watched them all yet, but these look like they'd be a great
  resource for anyone wanting to learn OCaml:
  <https://www.youtube.com/watch?v=MUcka_SvhLw&list=PLre5AT9JnKShBOPeuiD9b-I4XROIJhkIU>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [opam 2.1.0 is released!]
  • [opam 2.0.9 release]


[OCaml Planet] <http://ocaml.org/community/planet/>

[opam 2.1.0 is released!]
<https://www.ocamlpro.com/2021/08/05/opam-2-1-0-is-released/>

[opam 2.0.9 release]
<https://www.ocamlpro.com/2021/08/05/opam-2-0-9-release/>


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: 22895 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-27  8:54 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-07-27  8:54 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

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

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

pyre-ast: full-fidelity Python parser in OCaml
OCaml+Opam Images for Docker for Windows
Borns a stream talking about OCaml/Reason & ReScript language
An Update on the State of the PPX Ecosystem and `ppxlib''s Transition
How to send email from Dream
Old CWN


pyre-ast: full-fidelity Python parser in OCaml
══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-pyre-ast-full-fidelity-python-parser-in-ocaml/8177/1>


Jia Chen announced
──────────────────

  I am happy to announce the initial opam release of [`pyre-ast'], a
  Python parsing library.

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

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

  Documentation of the library can be found [here].

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

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

  Happy parsing!


[`pyre-ast'] <https://github.com/grievejia/pyre-ast>

[here] <https://grievejia.github.io/pyre-ast/doc/pyre-ast/>


OCaml+Opam Images for Docker for Windows
════════════════════════════════════════

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


Antonin Décimo announced
────────────────────────

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

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

  ┌────
  │ docker run -it ocaml/opam:windows-mingw
  │ docker run -it ocaml/opam:windows-msvc
  └────

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

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

  In order to get the correct environment for any `RUN' command
  involving OCaml or opam, prefix the command with

  • `ocaml-env exec --64 --' if based on mingw-w64; or
  • `ocaml-env exec --64 --ms=vs2019 --' if based on MSVC.

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

  We provide a comprehensive set of tags (replace _port_ with either
  _mingw_ or _msvc_):
  • `windows-port': the latest version of OCaml for each Windows
    version;
  • `windows-port-winver': the latest version of OCaml for Windows 10
    _winver_;
  • `windows-port-ocaml-mlver': OCaml version _mlver_ for each Windows
    version;
  • `windows-port-winver-ocaml-mlver': OCaml version _mlver_ for Window
    10 _winver_.

  When the Windows version is not specified in the tag, the image is a
  multiarch image that will work on every supported version of Windows
  10. Docker automatically selects the appropriate one based on the host
  version.

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

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

  Happy hacking!


Borns a stream talking about OCaml/Reason & ReScript language
═════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-borns-a-stream-talking-about-ocaml-reason-rescript-language/8185/1>


David Sancho announced
──────────────────────

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

  It's made by [@fakenickels] and myself [@davesnx], and we will try to
  do our best!

  Our first guest is [@___zth___]

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/e9f08607687aeb843968a430e4e9082541cf87c2_2_1380x690.jpeg>

  We go live on [http://twitch.tv/emelletv] next Wednesday.  Subscribe
  to not miss it!

  Thanks for reading, hope to see you there!


[@fakenickels] <https://twitter.com/fakenickels>

[@davesnx] <https://twitter.com/davesnx>

[@___zth___] <https://twitter.com/___zth___>

[http://twitch.tv/emelletv] <http://twitch.tv/emelletv>


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

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


Sonja Heinze announced
──────────────────────

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

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


[wiki page on the ppxlib repository]
<https://github.com/ocaml-ppx/ppxlib/wiki/The-State-of-the-PPX-Transition>

[last posted about the overall transition]
<https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296>

[last posted about the `Astlib' transition in detail]
<https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231>

Which Issues `ppxlib' was Facing
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  With `ocaml-migrate-parsetree' (`OMP'), the PPX ecosystem became
  cross-compiler-compatible.  With `ppxlib', the latest compiler
  features were supported more easily and broadly within the PPX
  ecosystem, while `ppxlib' also brought along other improvements such
  as the one in performance and the clear composition semantics when
  using several PPXs. With that, both `OMP' and `ppxlib' have taken away
  several maintenance burdens from the PPX maintainers and have created
  a more homogeneous and up-to-date PPX ecosystem. However, we were
  facing the following issues:
  1. To keep the PPX ecosystem cross-compiler compatible
     1. `ppxlib' was handling parts of the unstable `compiler-libs' API
        to abstracting them away;
     2. the `OMP~/~ppxlib' maintainers needed to keep the AST migration
        information up-to-date by coordination with the compiler devs.
  2. To guarantee new feature support, `ppxlib' needed to bump the
     `ppxlib' AST to the newest version.
  3. Bumping the AST implies a breaking change. That was an issue for a
     homogeneous and up-to-date PPX ecosystem.
  4. Not all PPXs migrated from `OMP' to `ppxlib'. That was also an
     issue for a homogeneous and up-to-date PPX ecosystem.

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


Tackling the Issues in Three Parts
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

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


Part One: `Astlib' as an Interface between `ppxlib' and the Compiler
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

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

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

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


[`Astlib' as an internal `ppxlib' library]
<https://github.com/ocaml-ppx/ppxlib/tree/master/astlib>


Part Two: Sending Patch PRs when Bumping the AST
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

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

  Our current plan doesn't provide a solution for that problem, but it
  does make handling the problem more efficient and, once again, it
  takes away the burden from the PPX maintainers.  Since the AST bump to
  `4.10', whenever we bump the AST, we send patch PRs to the PPXs we
  break. Not much has changed since February, when @NathanReb last
  [explained our workflow of sending patch PRs] in detail.  To some it
  up: we create a workspace with all `ppxlib' reverse dependencies on
  opam fulfilling a certain standard, which we call the
  _ppx-universe_. We then fix the PPXs that break all at once and open
  the PRs.

  Lately, the _ppx-universe_ has also proven very useful to make
  well-founded decisions regarding our API by having an easy look at our
  reverse dependencies. You can find a [_ppx-universe_ snapshot],
  currently from March, on our repo.

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


[explained our workflow of sending patch PRs]
<https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296>

[_ppx-universe_ snapshot] <https://github.com/ocaml-ppx/ppx_universe>


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

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

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

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

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

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

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


[list of PPXs that needed to be ported]
<https://github.com/ocaml-ppx/ppxlib/issues?q=is%3Aissue+label%3Aport-to-ppxlib+>

[filtering for them in opam's health check pipeline]
<http://check.ocamllabs.io:8080/?comp=4.12&available=4.12&show-latest-only=true&sort-by-revdeps=true&maintainers=&logsearch=ocaml-migrate-parsetree%5C.1%5C.8%5C.0&logsearch_comp=4.12>


How to send email from Dream
════════════════════════════

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


Joe Thomas announced
────────────────────

  I’ve written a short [blog post ] about what I learned building simple
  email features for a web server written in the Dream framework. The
  accompanying source code is available here:

  <https://github.com/jsthomas/dream-email-example>

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


[blog post ] <https://jsthomas.github.io/ocaml-email.html>


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: 30858 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-07-20 12:58 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-07-20 12:58 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

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

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

Writing a REST API with Dream
OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library
soupault: a static website generator based on HTML rewriting
OCaml 4.13.0, second alpha release
OCamlFormat 0.19.0
OCaml Café: Wed, Aug 4 @ 7pm (U.S. Central)
Old CWN


Writing a REST API with Dream
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/writing-a-rest-api-with-dream/8150/1>


Joe Thomas announced
────────────────────

  I've written a short [blog post] about the positive experience I had
  using Dream to build a REST API. The accompanying source code is
  available here:

  <https://github.com/jsthomas/sensors>

  I'm interested in adding more examples and tutorials to the OCaml
  ecosystem and would be happy to get your feedback on this writeup
  (here or via email/github).


[blog post] <https://jsthomas.github.io/ocaml-dream-api.html>


OTOML 0.9.0 — a compliant and flexible TOML parsing, manipulation, and pretty-printing library
══════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-otoml-0-9-0-a-compliant-and-flexible-toml-parsing-manipulation-and-pretty-printing-library/8152/1>


Daniil Baturin announced
────────────────────────

  I don't really like to base a release announcement on bashing another
  project, but this whole project is motivated by my dissatisfaction
  with [To.ml]—the only TOML library for OCaml, so here we go. OTOML is
  a TOML library that you (hopefully) can use without writing long rants
  afterwards. ;)

  In short:

  • [TOML 1.0-compliant] (To.ml is not).
  • Good error reporting.
  • Makes it easy to look up nested values.
  • Bignum and calendar libraries are pluggable via functors.
  • Flexible pretty-printer with indentation.

  OPAM: <https://opam.ocaml.org/packages/otoml/> GitHub:
  <https://github.com/dmbaturin/otoml>

  Now let's get to details.

  TOML is supposed to be human-friendly so that people can use it as a
  configuration file format. For that, both developer and end-user
  experience must be great. To.ml provides neither. I've been using
  To.ml in my projects for a long time, and


[To.ml] <https://opam.ocaml.org/packages/toml/>

[TOML 1.0-compliant] <https://toml.io/en/v1.0.0>

Standard compliance
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  TOML is neither minimal nor obvious really, it's much larger than the
  commonly used subset and the spec is not consistent and not easy to
  read, but To.ml fails at rather well-known things, like dotted keys,
  arrays of tables and heterogeneous arrays.

  OTOML passes all tests in the [test suite], except the tests related
  to bignum support. Those tests fail because the default implementation
  maps integers and floats to the native 31/63-bit OCaml types. More on
  that later.


[test suite] <https://github.com/BurntSushi/toml-test>


Error reporting
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Let's look at error reporting. To.ml's response to any parse error is
  a generic error with just line and column numbers.

  ┌────
  │ utop # Toml.Parser.from_string "foo = [" ;;
  │ - : Toml.Parser.result =
  │ `Error
  │   ("Error in <string> at line 1 at column 7 (position 7)",
  │    {Toml.Parser.source = "<string>"; line = 1; column = 7; position = 7})
  └────

  Menhir offers excellent tools for error reporting, so I took time to
  make descriptive messages for many error conditions (there _are_
  generic "syntax error" messages still, but that's better than nothing
  at all).

  ┌────
  │ utop # Otoml.Parser.from_string_result "foo = [" ;;
  │ - : (Otoml.t, string) result =
  │ Error
  │  "Syntax error on line 1, character 8: Malformed array (missing closing square bracket?)\n"
  │ 
  │ utop # Otoml.Parser.from_string_result "foo = {bar " ;;
  │ - : (Otoml.t, string) result =
  │ Error
  │  "Syntax error on line 1, character 12: Key is followed by end of file or a malformed TOML construct.\n"
  └────


Looking up nested values
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Nested sections are common in configs and should be easy to work
  with. This is how you do it in OTOML:

  ┌────
  │ utop # let t = Otoml.Parser.from_string "[this.is.a.deeply.nested.table]
  │ answer=42";;
  │ val t : Otoml.t =
  │   Otoml.TomlTable
  │    [("this",
  │      Otoml.TomlTable...
  │ 
  │ utop # Otoml.find t Otoml.get_integer ["this"; "is"; "a"; "deeply"; "nested"; "table"; "answer"] ;;
  │ - : int = 42
  └────

  For comparison, this is how it was done in To.ml:

  ┌────
  │ utop # let toml_data = Toml.Parser.(from_string "
  │ [this.is.a.deeply.nested.table]
  │ answer=42" |> unsafe);;
  │ val toml_data : Types.table = <abstr>
  │ 
  │ utop # Toml.Lenses.(get toml_data (
  │   key "this" |-- table
  │   |-- key "is" |-- table
  │   |-- key "a" |-- table
  │   |-- key "deeply" |-- table
  │   |-- key "nested" |-- table
  │   |-- key "table" |-- table
  │   |-- key "answer"|-- int ));;
  │ - : int option = Some 42
  └────


Extra dependencies
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The TOML spec includes first-class RFC3339 dates, for better or
  worse. The irony is that most uses of TOML (and, indeed, most
  configuration files in the world) don't need that, so it's arguably a
  feature bloat—but if we set out to support TOML as it's defined, that
  question is academic.

  The practical implication is that if the standard library of a
  language doesn't include a datetime type, a TOML library has to decide
  how to represent those values. To.ml makes ISO8601 a hard dependency,
  so if you don't use dates, you end up with a useless dependency. And
  if you prefer another library (or need functionality no present in
  ISO8601), you end up with two libraries: one you chose to use, and one
  more forced on you.

  Same goes for the arbitrary precision arithmetic. Most configs won't
  need it, but the standard demands it, so something needs to be done.

  Luckily, in the OCaml land we have functors, so it's easy to make all
  these dependencies pluggable. So I made it a functor that takes three
  modules.

  ┌────
  │ module Make (I : TomlInteger) (F : TomlFloat) (D : TomlDate) :
  │   TomlImplementation with type toml_integer = I.t and type toml_float = F.t and type toml_date = D.t
  └────

  This is how to use Zarith for big integers and keep the rest
  unchanged:

  ┌────
  │ (* No signature ascription:
  │    `module BigInteger : Otoml.Base.TomlInteger` would make the type t abstract,
  │    which is inconvenient.
  │  *)
  │ module BigInteger = struct
  │   type t = Z.t
  │   let of_string = Z.of_string
  │   let to_string = Z.to_string
  │   let of_boolean b = if b then Z.one else Z.zero
  │   let to_boolean n = (n <> Z.zero)
  │ end
  │ 
  │ module MyToml = Otoml.Base.Make (BigInteger) (Otoml.Base.OCamlFloat) (Otoml.Base.StringDate)
  └────


Printing
╌╌╌╌╌╌╌╌

  To.ml's printer can print TOML at you, that's for certain. No
  indentation, nothing to help you navigate nested values.

  ┌────
  │ utop # let toml_data = Toml.Parser.(from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |> unsafe) |>
  │ Toml.Printer.string_of_table |> print_endline;;
  │ [foo.bar]
  │ baz = false
  │ [foo.quux]
  │ xyzzy = [1, 2]
  └────

  We can do better:

  ┌────
  │ utop # let t = Otoml.Parser.from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |>
  │ Otoml.Printer.to_channel ~indent_width:4 ~collapse_tables:false stdout;;
  │ 
  │ [foo]
  │ 
  │ [foo.bar]
  │     baz = false
  │ 
  │ [foo.quux]
  │     xyzzy = [1, 2]
  │ val t : unit = ()
  │ 
  │ utop # let t = Otoml.Parser.from_string "[foo.bar]\nbaz=false\n [foo.quux]\n xyzzy = [1,2]" |>
  │ Otoml.Printer.to_channel ~indent_width:4 ~collapse_tables:false ~indent_subtables:true stdout;;
  │ 
  │ [foo]
  │ 
  │     [foo.bar]
  │ 	baz = false
  │ 
  │     [foo.quux]
  │ 	xyzzy = [1, 2]
  │ val t : unit = ()
  └────


Maintenance practices
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Last but not least, good maintenance practices are also important, not
  just good code. To.ml is at 7.0.0 now. It has a [CHANGES.md] file, but
  I'm still to see the maintainers document what the breaking change is,
  who's affected, and what they should do to make their code compatible.

  For example, in 6.0.0 the breaking change was a rename from
  `TomlLenses' to `Toml.Lenses'. In an earlier release, I remember the
  opposite rename. Given the standard compatibility problems going
  unfixed for years, that's like rearranging furniture when the roof is
  leaking.

  I promise not to do that.


[CHANGES.md]
<https://github.com/ocaml-toml/To.ml/blob/master/CHANGES.md>


Conclusion
╌╌╌╌╌╌╌╌╌╌

  I hope this library will help make TOML a viable configuration file
  format for OCaml programs.

  It's just the first version of course, so there's still room for
  improvement. For example, the lexer is especially ugly: due to TOML
  being highly context-sensitive, it involves massive amounts of lexer
  hacks for context tracking.  Maybe ocamllex is a wrong tool for the
  job abd it should be replaced with something else (since I'm using
  Menhir's incremental API anyway, it's not tied to any lexer API).

  The printer is also less tested than the parser, so there may be
  unhandled edge cases. It also has some cosmetic issues like newlines
  between parent and child tables.

  Any feedback and patches are welcome!


soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/15>


Daniil Baturin announced
────────────────────────

  [soupault 3.0.0] is now available.

  It now uses the new [OTOML] library for loading the configs, which has
  some positive side effects, e.g. keys in the output of `soupault
  --show-effective-config' (that shows your config plus default values
  you didn't set explicitly) now come in the same order as in your
  config file.

  It also provides TOML and YAML parsing functions to Lua plugins and
  has colored log headers (can be disabled with NO_COLOR environment
  variables).


[soupault 3.0.0] <https://soupault.app/blog/soupault-3.0.0-release/>

[OTOML] <https://opam.ocaml.org/packages/otoml/>


OCaml 4.13.0, second alpha release
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-13-0-second-alpha-release/8164/1>


octachron announced
───────────────────

  The release of OCaml 4.13.0 is approaching. We have released a second
  alpha version to help fellow hackers join us early in our bug hunting
  and opam ecosystem fixing fun (see below for the installation
  instructions). You can see the progress on this front at
  <https://github.com/ocaml/opam-repository/issues/18791> .

  Beyond the usual bug fixes (see the full list below), this second
  alpha integrates a new feature for native code: poll points. Those
  poll points currently fixes some issues with signals in non-allocating
  loops in native code. More importantly, they are prerequisite for the
  multicore runtime.

  Another change is the removal of the removal of interbranch
  propagation of type information.  The feature, already postponed from
  4.12, has been removed to focus for now on better error message in the
  `-principal' mode.

  If you find any bugs, please report them here:

  <https://github.com/ocaml/ocaml/issues>

  The first beta release may follow soon since the opam ecosystem is in
  quite good shape; and we are on track for a full release in September.

  Happy hacking, Florian Angeletti for the OCaml team.


Installation instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.13.0~alpha2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────

  If you want to tweak the configuration of the compiler, you can switch
  to the option variant with:

  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.13.0~alpha2+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where <option_list> is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and no-flat-float-array switch:
  ┌────
  │ opam switch create 4.13.0~alpha2+flambda+nffa
  │ --packages=ocaml-variants.4.13.0~alpha2+options,ocaml-option-flambda,ocaml-option-no-flat-float-array
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with "opam search ocaml-option".

  If you want to test this version, it is advised to install the alpha
  opam repository

  <https://github.com/kit-ty-kate/opam-alpha-repository>

  with
  ┌────
  │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
  └────
  This alpha repository contains various fixes in the process of being
  upstreamed.

  The source code for the alpha is also available at these addresses:

  • <https://github.com/ocaml/ocaml/archive/4.13.0-alpha2.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.13/ocaml-4.13.0~alpha2.tar.gz>


Changes since the first alpha release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

New feature
┄┄┄┄┄┄┄┄┄┄┄

  • [10039]: Safepoints Add poll points to native generated code. These
    are effectively zero-sized allocations and fix some signal and
    remembered set issues. Also multicore prerequisite.  (Sadiq Jaffer,
    Stephen Dolan, Damien Doligez, Xavier Leroy, Anmol Sahoo, Mark
    Shinwell, review by Damien Doligez, Xavier Leroy, and Mark Shinwell)


[10039] <https://github.com/ocaml/ocaml/issues/10039>


New bug fixes
┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [10449]: Fix major GC work accounting (the GC was running too
    fast). (Damien Doligez, report by Stephen Dolan, review by Nicolás
    Ojeda Bär and Sadiq Jaffer)

  • [10454]: Check row_more in nondep_type_rec.  (Leo White, review by
    Thomas Refis)

  • [10468]: Correctly pretty print local type substitution, e.g. type t
    := …, with -dsource (Matt Else, review by Florian Angeletti)

  • [10461], [10498]: `caml_send*' helper functions take derived
    pointers as arguments.  Those must be declared with type Addr
    instead of Val. Moreover, poll point insertion must be disabled for
    `caml_send*', otherwise the derived pointer is live across a poll
    point. (Vincent Laviron and Xavier Leroy, review by Xavier Leroy and
    Sadiq Jaffer)

  • [10478]: Fix segfault under Windows due to a mistaken initialization
    of thread ID when a thread starts. (David Allsopp, Nicolás Ojeda
    Bär, review by Xavier Leroy)

  • [9525], [10402]: ocamldoc only create paragraphq at the toplevel of
    documentation comments (Florian Angeletti, report by Hendrik Tews,
    review by Gabriel Scherer)

  • [10206]: Split labels and polymorphic variants tutorials Splits the
    labels and polymorphic variants tutorial into two. Moves the GADTs
    tutorial from the Language Extensions chapter to the tutorials.
    (John Whitington, review by Florian Angeletti and Xavier Leroy)


[10449] <https://github.com/ocaml/ocaml/issues/10449>

[10454] <https://github.com/ocaml/ocaml/issues/10454>

[10468] <https://github.com/ocaml/ocaml/issues/10468>

[10461] <https://github.com/ocaml/ocaml/issues/10461>

[10498] <https://github.com/ocaml/ocaml/issues/10498>

[10478] <https://github.com/ocaml/ocaml/issues/10478>

[9525] <https://github.com/ocaml/ocaml/issues/9525>

[10402] <https://github.com/ocaml/ocaml/issues/10402>

[10206] <https://github.com/ocaml/ocaml/issues/10206>


Removed feature
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [ *breaking change* ] [9811]: remove propagation from previous
    branches Type information inferred from previous branches was
    propagated in non-principal mode. Revert this for better
    compatibility with -principal mode. For the time being, infringing
    code should result in a principality warning. (Jacques Garrigue,
    review by Thomas Refis and Gabriel Scherer)

  The up-to-date list of changes for OCaml 4.13 is available at
  <https://github.com/ocaml/ocaml/blob/4.13/Changes> .


[9811] <https://github.com/ocaml/ocaml/issues/9811>


OCamlFormat 0.19.0
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-19-0/8167/1>


Guillaume Petiot announced
──────────────────────────

  We are happy to announce the release of [OCamlFormat 0.19.0].

  OCamlformat is an auto-formatter for OCaml code, writing the parse
  tree and comments in a consistent style, so that you do not have to
  worry about formatting it by hand, and to speed up code review by
  focusing on the important parts.

  OCamlFormat is beta software. We expect the program to change
  considerably before we reach version 1.0.0. In particular, upgrading
  the `ocamlformat` package will cause your program to get
  reformatted. Sometimes it is relatively pain-free, but sometimes it
  will make a diff in almost every file. We are working towards having a
  tool that pleases most usecases in the OCaml community, please bear
  with us!

  To make sure your project uses the last version of ocamlformat, please
  set

  ┌────
  │ version=0.19.0
  └────

  in your `.ocamlformat' file.

  Main changes in `ocamlformat.0.19.0' are:
  • OCaml 4.13 features are supported
  • `ppxlib' dependency has been dropped
  • A new `line-endings={lf,crlf}' option has been added for windows
    compatibility

  Here is the [full list of changes].

  We encourage you to try ocamlformat, that can be installed from opam
  directly ( `opam install ocamlformat' ), but please remember that it
  is still beta software. We have a [FAQ for new users ] that should
  help you decide if ocamlformat is the right choice for you.


[OCamlFormat 0.19.0] <https://github.com/ocaml-ppx/ocamlformat>

[full list of changes]
<https://github.com/ocaml-ppx/ocamlformat/releases/tag/0.19.0>

[FAQ for new users ]
<https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users>


Nicolás Ojeda Bär then added
────────────────────────────

        A new `line-endings={lf,crlf}' option has been added for
        windows compatibility

  Just to expand a bit on this feature: previously, `ocamlformat' would
  use the system EOL convention (ie LF on Unix-like OSs and CRLF on
  Windows). This meant that if you applied `ocamlformat' on systems with
  different EOL conventions, you would get a diff on every line on every
  file purely due to the changed newlines. Furthermore, this meant
  `ocamlformat' was hard to use if your project used LF on Windows (a
  common usage).

  With the new option, `ocamlformat' enforces a given EOL
  convention. The system EOL convention is no longer used for any
  purpose and the EOL convention used is the one specified in
  `ocamlformat''s config (LF by default).


OCaml Café: Wed, Aug 4 @ 7pm (U.S. Central)
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-cafe-wed-aug-4-7pm-u-s-central/8169/1>


Michael Bacarella announced
───────────────────────────

  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, OCaml Café will consist of two parts. First, Rudi Grinberg
  of [OCaml Labs] will present an informal introduction to [Dune], the
  OCaml build system. Learn about Dune from one the people developing
  it. Following Rudi’s presentation, we will open the discussion to all
  things OCaml-related.

  Full [Zoom meeting details here].
  • Add to your [Google Calendar]
  • Add to your [iCal]


[OCaml Labs] <https://ocamllabs.io/>

[Dune] <https://dune.build/>

[Zoom meeting details here]
<https://hfpug.org/event/ocaml-cafe-introduction-to-dune-and-open-forum/>

[Google Calendar]
<https://www.google.com/calendar/event?action=TEMPLATE&text=OCaml+Caf%C3%A9%3A+Introduction+to+Dune+and+Open+Forum&dates=20210804T190000/20210804T210000&details=OCaml+Caf%C3%A9+offers+a+friendly%2C+low+stakes+opportunity+to+ask+questions+about+the+OCaml+language+and+ecosystem%2C+work+through+programming+problems+that+you%E2%80%99re+stuck+on%2C+and+get+feedback+on+your+code.+Especially+geared+toward+new+and+intermediate+users%2C+experienced+OCaml+developers+will+be+available+to+answer+your+questions.%C2%A0+Bring+your+code+and+we%26%238217%3Bll+be+happy+to+review+it%2C+assist+with+debugging%2C+and+provide+recommendations+for+improvement.+%0AThis+month%2C+OCaml+Caf%C3%A9+will+consist+of+two+parts.%C2%A0+First%2C+Rudi+Grinberg+of+OCaml+Labs+will+present+an+informal+introduction+to+Dune%2C+the+OCaml+build+system.%C2%A0+Learn+about+Dune+from+one+the+people+developing+it.%C2%A0+Following+Rudi%26%238217%3Bs+presentation%2C+we+will+open+the+discussion+to+all+things+OCaml-related.+%0AWhether+you%E2%80%99re+still+trying+to+make+sense+of+currying+or+can+spot+non-tail-recursive+code+from+across+the+room%2C+we+hope+that+you%E2%80%99ll+join+us+with+your+questions+about+OCaml%2C+or+just+to+hang+out+with+the+OCaml+community.+%0A%0AClaude+Ru+%28View+Full+Event+Description+Here%3A+https%3A%2F%2Fhfpug.org%2Fevent%2Focaml-cafe-introduction-to-dune-and-open-forum%2F%29&location=Zoom&trp=false&sprop=website:https://hfpug.org&ctz=America%2FChicago>

[iCal]
<https://hfpug.org/event/ocaml-cafe-introduction-to-dune-and-open-forum/?ical=1>


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: 44538 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-29 12:24 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-06-29 12:24 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of June 22 to 29,
2021.

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

wasicaml - a code emitter for OCaml targeting WebAssembly
opam 2.1.0~rc2
Set up OCaml 2.0.0-beta2
Any OCaml bindings to Apache Arrow?
Compiler engineer for OCaml and WebAssembly, Germany
v3.0.0 release of reparse, reparse-lwt, reparse-lwt-unix
Progress 0.2.0
http-multipart-formdata v2.0.0
Old CWN


wasicaml - a code emitter for OCaml targeting WebAssembly
═════════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-06/msg00017.html>


Gerd Stolpmann announced
────────────────────────

  I'd like to announce a new project to develop a code generator that
  emits WebAssembly:

  <https://github.com/remixlabs/wasicaml>

  With the support of RemixLabs I could already create a very first
  version that takes the OCaml bytecode as input and translates it to
  WebAssembly.  While this approach probably doesn't lead to the fastest
  code, it is easy to accomplish, and it demonstrates the challenge (and
  already shows how to solve many of the part problems along the road).

  To be precisely, the target of the translator is wasm32-unknown-wasi,
  i.e.  the WASI ABI. This ABI is still in early development, but
  provides already the syscalls (or better, host calls) to access files,
  to get the current time, and to read the environment. This is almost
  enough to run a compiler - I only had to add system() so that ocamlc
  can start external preprocessors.  Also, due to the fact that the
  current wasm implementations still lack exception handling, I had to
  assume the presence of a host emulation of exceptions (which is easy
  to provide if the host environment is Javascript, but not necessarily
  for other environments).

  The translator takes the OCaml bytecode as input, i.e. you first
  create an excecutable

  ┌────
  │ $ ocamlc -o myexec ...
  └────

  and then make wasm out of it:

  ┌────
  │ $ wasicaml -o myexec.wasm myexec
  └────

  If you omit the .wasm suffix, wasicaml will put a preamble in front of
  the wasm code that starts the execution:

  ┌────
  │ $ wasicaml -o myexec_wasm myexec
  │ $ ./myexec_wasm
  └────

  Because of this trick, many problems of cross-compiling can be
  avoided.

  You may ask what the benefits of yet another "Web" language are. We
  already have two emitters targeting Javascript - isn't that enough?
  Well, two answers here.

  First, WASI is a proper LLVM target. Because of this, you can link
  code from other languages with your executable (e.g. C or Rust). So
  you are not limited to OCaml but can use any language that also
  targets the WASI ABI. E.g. you can do

  ┌────
  │ $ wasicaml -o myexec.wasm myexec -ccopt -lfoo
  └────

  to also link in libfoo.a (which must also be compiled to wasm). So it
  is multi-lingual from the beginning.

  Second, WebAssembly can be used outside the web, too. WASI targets
  more the command-line, and server plugins, and generally any
  OS-independent environments. For example, imagine you have an Electron
  app with a great UI, but for some special functionality you need to
  include some OCaml code, too. You don't want to give up the
  OS-independence, and WASI gives you now a natural option to add the
  OCaml code. And you still have access to the filesystem without
  hassle. - Another example is edge computing, i.e. when the cloud is
  extended by computers outside the data center, and the code should be
  in a form so that it can be run on as many platforms as possible. -
  All in all, WASI plays well when you need to combine OS-independence
  with a classic way of organizing the code as command or as server
  function, and you also need predictable performance.

  The challenge of translating OCaml to wasm is mainly the garbage
  collector.  Wasm doesn't permit many of the tricks ocamlopt is using
  to know in which memory (or register) locations OCaml values are
  stored. In wasm, there are no registers but the closest vehicle are
  local variables. Now, it is not possible to scan these variables from
  the GC function, making it practically impossible to put OCaml values
  there while a function is called that might trigger a GC. There is
  also no really cheap way of obtaining a stack descriptor.

  Wasicaml inherits the stack from the bytecode interpreter and uses it
  as its own shadow stack for OCaml values. As wasicaml bases on the
  bytecode representation of the code, the bytecode instructions already
  ensure that values always live in this stack when the GC might
  run. Wasicaml additionally tries to identify values that don't need
  this special treatment (like ints and bools) and that are preferably
  stored in local variables, giving the wasm executor freedom to put
  these into registers or other high-speed locations. (Unfortunately,
  most of the type information is already erased in the bytecode, and
  this is definitely one of the deficiencies of the bytecode approach.)

  In order to maximize the performance, it is probably best to avoid the
  stack whenever possible. The current approach of transforming the
  bytecode hasn't brought to an end yet with respect to such
  optimizations. For example, there could be more analyses that figure
  out when GC runs are actually possible and when it is safe to use
  local variables.

  Another problem of the bytecode basis is that all function calls are
  indirect, preventing the wasm executor from inlining functions.

  As a project, I'd like to see wasicaml progressing in two directions.
  First, make the current approach as good as possible - although basing
  it on the bytecode representation has its downsides, it is easy to
  understand and it is possible to figure out what the necessary
  ingredients for fast code are. Second, get an idea where a possible
  real wasm backend would fit into the OCaml compiler (maybe it is c–
  but maybe this doesn't give us much and you start better with lambda).

  Anyway, welcome to the new world of WebAssembly!

  Gerd

  PS. If you are interested in WebAssembly and like to work with me on
  another Wasm port for some time, there is a position:
  <https://www.mixtional.de/recruiting/2021-01/index.html>

  PPS. Wasicaml is a project of Figly, Inc., commonly known as
  RemixLabs, developing a reactive low-code and code collaboration
  platform.  <https://remixlabs.com/>


opam 2.1.0~rc2
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0-rc2/8042/1>


David Allsopp announced
───────────────────────

  The opam team has great pleasure in announcing opam 2.1.0~rc2!

  The focus since beta4 has been preparing for a world with more than
  one released version of opam (i.e.  2.0.x and 2.1.x). The release
  candidate extends CLI versioning further and, under the hood, includes
  a big change to the opam root format which allows new versions of opam
  to indicate that the root may still be read by older versions of the
  opam libraries. A plugin compiled against the 2.0.9 opam libraries
  will therefore be able to read information about an opam 2.1 root
  (plugins and tools compiled against 2.0.8 are unable to load opam
  2.1.0 roots).

  Please do take this release candidate for a spin! It is available in
  the Docker images at ocaml/opam on [Docker Hub] as the opam-2.1
  command (or you can `sudo ln -f /usr/bin/opam-2.1 /usr/bin/opam' in
  your `Dockerfile' to switch to it permanently). The release candidate
  can also be tested via our installation script (see the [wiki] for
  more information).

  Thank you to anyone who noticed the unannounced first release
  candidate and tried it out. Between tagging and what would have been
  announcing it, we discovered an issue with upgrading local switches
  from earlier alpha/beta releases, and so fixed that for this second
  release candidate.

  Assuming no showstoppers, we plan to release opam 2.1.0 next week. The
  improvements made in 2.1.0 will allow for a much faster release cycle,
  and we look forward to posting about the 2.2.0 plans soon!


[Docker Hub] <https://hub.docker.com/r/ocaml/opam/tags>

[wiki]
<https://github.com/ocaml/opam/wiki/How-to-test-an-opam-feature#from-a-tagged-release-including-pre-releases>


Set up OCaml 2.0.0-beta2
════════════════════════

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


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

  This release includes changes to address a corner case primarily
  related to multicore OCaml.

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


Any OCaml bindings to Apache Arrow?
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/any-ocaml-bindings-to-apache-arrow/8047/2>


UnixJunkie asked and Laurent Mazare announced
─────────────────────────────────────────────

        Looks interesting:

        <https://arrow.apache.org/>

        <https://arrow.apache.org/overview/>

  I've put together some simple [ocaml-arrow] library. It works
  reasonably well and is quite battle tested but definitely needs a bit
  of cleanup as the bits under src/ are deprecated in favor of the ones
  under c_api/. There is also a ppx to automatically convert ocaml
  records to/from arrow. Some examples using this can be seen in the
  [tests directory].

  If there is some interest, I can certainly push up on cleaning this
  and make an actual opam package.


[ocaml-arrow] <https://github.com/LaurentMazare/ocaml-arrow>

[tests directory]
<https://github.com/LaurentMazare/ocaml-arrow/blob/master/c_api/tests/ppx.ml>


Compiler engineer for OCaml and WebAssembly, Germany
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/compiler-engineer-for-ocaml-and-webassembly-germany/8053/1>


Gerd Stolpmann announced
────────────────────────

  We are developing a compiler for a no-code platform that translates
  our DSL to bytecode and/or WebAssembly. The language is largely of
  functional type but is also able to manage state with a spreadsheet
  model, allowing reactive programming without having to resort to
  libraries. The language is statically typed using a Hindley-Milner
  type checker. The compiler is primarily written in OCaml. Other
  languages of our platform are Go, C, Elm, and Javascript.

  We are looking for a compiler engineer with skills in code generation
  for WebAssembly:

  • Translation of an intermediate representation to WebAssembly
  • Writing runtimes and SDKs targeting WebAssembly
  • Code optimization

  See the full ad here:
  <https://www.mixtional.de/recruiting/2021-01/index.html>


v3.0.0 release of reparse, reparse-lwt, reparse-lwt-unix
════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-v3-0-0-release-of-reparse-reparse-lwt-reparse-lwt-unix/8058/1>


Bikal Lem announced
───────────────────

  I am happy to announce v3.0.0 of `reparse' - an OCaml library for
  constructing various types of parsers in OCaml.

  The release follows a complete overhaul of the internal working of the
  library to achieve the following goals:

  1. Allow construction of efficient, zero-copy parsers. See [String
     parser for example]. The library provides a [Make functor]
     parametrised over a `Promise' and a `Input' type allowing you
     control over both parser memory allocation and copying.

  2. Support usage of async libraries - lwt and async. Following the
     first point the library can now be used together with `lwt' and/or
     `async'. A lwt parse - for example - can now be used seamlessly
     with your other lwt code. The integration is seamless.

  3. Provide `Make_buffered' functor to produce parsers where the input
     type natively doesn't allow random read, for example sockets, lwt
     streams and channels. There is now two new supporting packages
     `reparse-lwt' which provides parsing from `char Lwt_stream.t'
     input type and `reparse-lwt-unix' which provides parsing from
     `Lwt_unix.file_descr' and ~Lwt_unix.input_channel' respectively.

  4. Provide `Make_unbuffered' functor to produce parsers where the
     input type natively supports random read, for example strings,
     bigstrings, bytes.

  5. Introduce function `unsafe_any_char' to allow efficient
     (zero-copy?) parsing.

  6. Prune dependencies by removing `base'.

  P.S. The documentation is bit behind in this release so please bear
  with me while work through the issues in the coming days.

  [Reparse repo]


[String parser for example]
<https://github.com/lemaetech/reparse/blob/master/lib/reparse.mli#L1237>

[Make functor]
<https://github.com/lemaetech/reparse/blob/master/lib/reparse.mli#L1230>

[Reparse repo]
<https://github.com/lemaetech/reparse/blob/master/lib/reparse.ml>


Progress 0.2.0
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-progress-0-2-0/8063/1>


Craig Ferguson announced
────────────────────────

  I'm pleased to announce the 0.2.0 release of [`Progress'], now
  available via Opam.

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/7/727d878b6d17f3c48e6946f4df424bcc59938da3.png>

  `Progress' is an OCaml library for defining and using progress
  bars. It has the following features:

  • allows user-defined progress bar layouts;
  • supports rendering multiple progress bars simultaneously;
  • dynamically responds to changes in terminal size;
  • supports interleaving logging with progress bar rendering.

  This second release contains a much-improved DSL for specifying
  progress bars, alongside improvements and extensions to the rendering
  logic. The bars in the screenshot above are defined as follows:

  ┌────
  │ let bar ~color ~total =
  │   let open Progress.Line in
  │   list
  │     [ spinner ~color:(Progress.Color.ansi ~green) ()
  │     ; brackets (elapsed ())
  │     ; bar ~color total
  │     ; bytes
  │     ; parens (const "eta: " ++ eta total)
  │     ]
  └────

  It also comes with more complete [documentation] and many more
  [examples], including:

  • a Cargo-like progress bar w/ logging of intermediate results:

    <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/4/4b148999f7b6029ac0155b049b6a7cf1fa8b40f1_2_1380x500.png>

  • a Yarn-like stack of spinners:

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

  • a showcase of various progress bar styles:

    <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/d/d4df4a2df07fd161982243251fbee56d52a4afbf_2_1034x538.png>


  The changelog is [here] and the API documentation is [here]. The
  library is not yet feature-complete, but should still be reasonably
  useful :-) Happy hacking!


[`Progress'] <https://github.com/craigfe/progress>

[documentation]
<https://craigfe.github.io/progress/progress/Progress/index.html>

[examples] <https://github.com/CraigFe/progress/tree/main/examples>

[here]
<https://github.com/CraigFe/progress/blob/0.2.0/CHANGES.md#020-2021-06-26>

[here] <https://craigfe.github.io/progress/progress/Progress/index.html>


http-multipart-formdata v2.0.0
══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-http-multipart-formdata-v2-0-0/8064/1>


Bikal Lem announced
───────────────────

  I am pleased to announce v2.0.0 release of
  `http-multpart-formdata'. This release departs from previous in-memory
  representation of http multipart forms to a streaming, memory
  efficient representation. The new streaming mechanism should help when
  processing larg file uploads in your OCaml web applications.

  1. [httpaf sample web app]
  2. [http-multipart-formdata repo]


[httpaf sample web app]
<https://github.com/lemaetech/http-multipart-formdata/blob/master/examples/multipart_httpaf.ml>

[http-multipart-formdata repo]
<https://github.com/lemaetech/http-multipart-formdata>


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: 30089 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-22  9:04 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-06-22  9:04 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of June 15 to 22,
2021.

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

First releases of dirsp-exchange: auditable variant of Signal Protocol and ProScript-to-OCaml translator
Job offer: 3 year research engineer in static analysis of OCaml programs at Inria Rennes
IRC channels available on libera.chat
Set up OCaml 2.0.0-beta
First release of Jsonxt - a set of JSON parsers and writers
mula 0.1.0, ML's radishal Universal Levenshtein Automata library
New release of mlcuddidl, the OCaml interface to the CUDD BDD library
first release of orf: OCaml Random Forests
Old CWN


First releases of dirsp-exchange: auditable variant of Signal Protocol and ProScript-to-OCaml translator
════════════════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-releases-of-dirsp-exchange-auditable-variant-of-signal-protocol-and-proscript-to-ocaml-translator/8008/1>


jbeckford announced
───────────────────

  I'm pleased to announce the first release of [dirsp-exchange],
  available today from the Opam repositories.

  The intent of the *[dirsp]* libraries is to provide software engineers
  with auditable source code that has some level of safety assurance
  (typically proofs) from security researchers.

  The first libraries are:

  • dirsp-exchange-kbb2017 0.1.0 - The KBB2017 protocol for securing a
    two-party conversation. Similar to Signal Protocol v3 and Olm
    Cryptographic Ratchet.
  • dirsp-ps2ocaml 0.1.0 - A ProScript to OCaml translator. ProScript is
    an executable subset of JavaScript that can be formally verified.

  and a couple more supporting libraries.

  `dirsp-exchange-kbb2017' has a build process that generates its own
  OCaml code using `dirsp-ps2ocaml' on formally verified ProScript
  source code.

  The canonical example for `dirsp-exchange-kbb2017' is:

  ┌────
  │ module P       = Dirsp_proscript_mirage.Make()
  │ module ED25519 = P.Crypto.ED25519
  │ module K       = Dirsp_exchange_kbb2017.Make(P)
  │ module U       = K.UTIL
  │ 
  │ (* Alice sends a message to Bob *)
  │ let aliceSessionWithBob = T.newSession (* ... supply some keys you create with ED25519 and U ... *) ;;
  │ let aliceToBobSendOutput = T.send
  │   aliceIdentityKey
  │   aliceSessionWithBob
  │   (P.of_string "Hi Bob!")
  │ 
  │ (* Now you can send the output "aliceToBobSendOutput" from Alice to Bob.
  │    Let's switch to Bob's computer. He gets notified of a new message using a notification library of
  │ your choosing, and then does ...  *)
  │ 
  │ let bobSessionWithAlice = T.newSession (* ... supply some keys ... *);;
  │ let bobFromAliceReceiveOutput = T.recv
  │   bobIdentityKey
  │   bobSignedPreKey
  │   bobSessionWithAlice
  │   theEncryptedMessageBobReceivedFromAlice
  │ assert (bobFromAliceReceiveOutput.output.valid)
  │ Format.printf "Bob just received a new message: %s\n"
  │   (bobFromAliceReceiveOutput.plaintext |> P.to_bytes |> Bytes.to_string)
  └────

  These are early releases, especially `dirsp-ps2ocaml'.

  Online docs are at <https://diskuv.github.io/dirsp-exchange>

  Feedback, contributions and downloads are very welcome!


[dirsp-exchange] <https://github.com/diskuv/dirsp-exchange#readme>


Job offer: 3 year research engineer in static analysis of OCaml programs at Inria Rennes
════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-offer-3-year-research-engineer-in-static-analysis-of-ocaml-programs-at-inria-rennes/8012/1>


Benoit Montagu announced
────────────────────────

  as part of a project between Inria and Nomadic Labs, we are offering a
  3 year research engineer position, to work on static analysis for
  OCaml programs.  The position will start in October in the Celtique
  Inria research team, in the vibrant city of Rennes, France.  If you
  are a talented OCaml programmer, if you are interested in static
  analysis, or if you simply want to know more about this project,
  please contact me!

  The detailed job description is here:
  <https://jobs.inria.fr/public/classic/fr/offres/2021-03821>

  Please feel free to transfer this announce to people that you think
  could be interested.


IRC channels available on libera.chat
═════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-06/msg00014.html>


Deep in this thread, Romain Calascibetta announced
──────────────────────────────────────────────────

  Just to let you know that I spent a time to re-implement the IRC
  protocol in OCaml and to deploy a simple MirageOS as a logger to save
  discussions into a Git repository. The bot is currently deployed, the
  explanation is available here:
  <https://github.com/dinosaure/cri/tree/master/unikernel> And used for
  #mirage@irc.libera.chat

  It's a nice example about MirageOS/unikernel and I may deploy one to
  save #ocaml@irc.libera.chat as whitequark already does with her bot.


Set up OCaml 2.0.0-beta
═══════════════════════

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


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

  Hopefully, this will be the last release before stable 2.0.0. This
  release allows you to add multiple custom repositories, which enables
  testing with multicore and beta repository.

  ┌────
  │ - name: Use Multicore OCaml
  │   uses: ocaml/setup-ocaml@v2
  │   with:
  │     ocaml-compiler: ocaml-variants.4.12.0+domains+effects
  │     opam-repositories: |
  │       multicore: https://github.com/ocaml-multicore/multicore-opam.git
  │       default: https://github.com/ocaml/opam-repository.git
  └────


First release of Jsonxt - a set of JSON parsers and writers
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-jsonxt-a-set-of-json-parsers-and-writers/8018/1>


Stephen Bleazard announced
──────────────────────────

  Jsonxt provides a number of JSON parsers and writers for RFC 8259
  compliant JSON as well as non-standard extensions supported by Yojson.
  Features include
  • RFC 8259 compliant when in strict and basic mode
  • Performance focused especially for files and strings
  • Support for standard and extended JSON tree types:
    • Strict follows a strict interpretation of RFC 8259 with all
      numbers represented as floats.
    • Basic extends the strict type to include convenience types while
      maintaining RFC compliance.  This is compatible with Yojson's
      Basic type
    • Extended adds additional non-standard types including tuples and
      variants and is not RFC compliant. This is compatible with
      Yojson's Safe type
  • A number of different parsers including
    • A standard JSON tree parser for various sources including string,
      file and channel
    • A Stream parser that returns a stream of raw JSON tokens.
    • A monad based parser compatible with async
  • Writers including
    • File and string writers
    • A monad based writer that is compatible with async
    • A stream writer that converts a stream of JSON tokens
  • Support for streaming JSON via the [Stream] module
  • Standard interfaces including Yojson compatibility
  • Support for `ppx_deriving_yojson' and `ppx_yojson_conv' via Yojson
    compatibility

  The package is available via opam, with documentation on [github.io].
  The source can be found at [github/jsonxt]


[Stream] <https://ocaml.org/api/Stream.html>

[github.io]
<https://stevebleazard.github.io/ocaml-jsonxt/jsonxt/index.html>

[github/jsonxt] <https://github.com/stevebleazard/ocaml-jsonxt>


mula 0.1.0, ML's radishal Universal Levenshtein Automata library
════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mula-0-1-0-mls-radishal-universal-levenshtein-automata-library/8021/1>


Ifaz Kabir announced
────────────────────

  I'm happy to announce the release of my library `mula'. The package
  uses Universal Levenshtein Automata (ULA) to not only check if a word
  is within a certain edit distance of another, but to also output what
  the edit distance is! It uses the automata themselves to calculate
  edit distances. A fun use case for this is that we can feed a set of
  words to the automaton and immediately rank the words by their edit
  distance.

  `Mula' supports both the standard Levenshtein edit distance as well as
  the Demarau-Levenshtein distance which counts transpositions of two
  adjacent characters as a single edit. I also support getting live
  error counts, so you can feed part of a string into an automaton, and
  get the minimum number of errors that have occurred so far.

  I currently have matching working using non-deterministic ULA, but I
  have partially started the work toward the deterministic versions. It
  should be possible to pre-compute the DFAs for up to edit distance 3
  and pack it with the library, never needing to be recomputed because
  the Universal Automata are independent of the input strings. But the
  non-deterministic automata support very large edit distances:
  (Sys.int_size - 1)/2, so they have value on their own.

  This library came about from a desire to add a "did you mean" feature
  to a toy compiler, but not wanting to write the kind of dynamic
  programming code that you can find in the OCaml compiler [1] or
  merlin/spelll [2,3].

  You can find the library [here] and the documentation [here].  It's
  not on `opam' yet, but I have submitted a [pull request].

  Happy OCamling!

  References:
  1. Edit distance in the OCaml
     compiler. <https://github.com/ocaml/ocaml/blob/e5e9c5fed56efdd67601e4dbbaebeb134aee361c/utils/misc.ml#L516>.
  2. Edit distance in
     merlin. <https://github.com/ocaml/merlin/blob/444f6e000f6b7dc58dac44d6ac096fc0e09894cc/src/utils/misc.ml#L527>
  3. Edit distance in
     spelll. <https://github.com/c-cube/spelll/blob/3da1182256ff2507a0be812f945a7fe1a19adf9b/src/Spelll.ml#L26>


[here] <https://github.com/ifazk/mula/>

[here] <https://ifazk.github.io/mula/mula/index.html>

[pull request] <https://github.com/ocaml/opam-repository/pull/18895>


Ifaz Kabir then added
─────────────────────

Some details:
╌╌╌╌╌╌╌╌╌╌╌╌╌

  I followed the paper by Touzet [1] as much as possible. If you take a
  look at the code, you'll see a a lot of +1's for 1-indexing. This was
  to keep the implementation as close to the paper as possible! (If you
  do want to check the implementation against the paper, note that the
  paper has a typo in Definition 2). For the Demarau-Levenshtein
  automaton, I adapted Figure 9 from Mitankin's thesis [2]. I'm
  convinced that my adaptation works, but my adaptation of Touzet's
  subsumption relation for Demarau-Levenshtein might be slightly
  sub-optimal. If you have question about the adaptation, feel free to
  ask!

  `mula' does not completely replace c-cube's `spelll' package. In
  particular I don't support any indexs, etc. But there are some
  interesting differences in the automata they use. (`w' stands for the
  base word here)
  1. The `spelll' package creates the Levenshtein Automaton for a single
     string/word (LA_w), `mula' uses Universal Levenshtein Automata
     (ULA).
  2. `Spelll' computes a DFA from a non-deterministic automaton that
     uses eplison transitions. ULA do not have epsilon transitions, but
     for transitions it looks ahead into the base word `w'. Additionally
     the NFA's states/transitions are computable on the fly, so there is
     no need to store the NFA in memory.
  3. `Spelll''s automata transitions using characters. `mula' computes a
     bitvector from an input character to transition from states to
     states. (Computing the bitvector is where the look ahead comes in).
  4. `Spelll''s automata return `true~/~false', and uses a separate
     function to calculate edit distances. `Mula' uses the automaton
     itself to calculate edit distances, the outputs have type `int
     option'. (LA_w can be modified to support this though!)

  References:
  1. On the Levenshtein Automaton and the Size of the Neighborhood of a
     Word. Hélène Touzet
     <https://hal.archives-ouvertes.fr/hal-01360482/file/LATA2016.pdf>
  2. Universal Levenstein Automata: Building and Properties. Petar
     Nikolaev
     Mitankin. <https://store.fmi.uni-sofia.bg/fmi/logic/theses/mitankin-en.pdf>


New release of mlcuddidl, the OCaml interface to the CUDD BDD library
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-new-release-of-mlcuddidl-the-ocaml-interface-to-the-cudd-bdd-library/8028/1>


nberth announced
────────────────

  I'm pleased to write this first release announcement for the
  [mlcuddidl] package.

  These bindings to the CUDD BDD library were initially written by
  Bertrand Jeannet and have been around as an OPAM package for quite
  some time now.  The source code is now hosted on [framagit].

  This release of version 3.0.7 mostly ports the package to OCaml
  versions ≥ 4.10.


[mlcuddidl] <https://opam.ocaml.org/packages/mlcuddidl>

[framagit] <https://framagit.org/nberth/mlcuddidl>


first release of orf: OCaml Random Forests
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-orf-ocaml-random-forests/8034/1>


UnixJunkie announced
────────────────────

  I finished implementing a classifier and regressor using Random
  Forests (seminal paper:
  <https://link.springer.com/article/10.1023/A:1010933404324>):

  <https://github.com/UnixJunkie/orf>

  Some caveats:
  • this is somewhat slow; especially the classifier (and I don’t know
    so much how to accelerate it; probably two orders of magnitude
    slower than sklearn).
  • this is not super generic (int IntMap sparse features only; i.e. a
    sparse vector of integers represents a sample).

  The package is now available in opam (opam install orf).

  Two interfaces are exposed:

  RFC (for classification)
  <https://github.com/UnixJunkie/orf/blob/master/src/RFC.mli>

  RFR (for regression)
  <https://github.com/UnixJunkie/orf/blob/master/src/RFR.mli>

  The test file shows some usage examples:
  <https://github.com/UnixJunkie/orf/blob/master/src/test.ml>

  If you want to help, I tried to flag a few things for the near future:
  <https://github.com/UnixJunkie/orf/issues>

  If you use it and if it is useful to you, I would be happy to know.


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: 31402 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-06-01  9:23 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-06-01  9:23 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of May 25 to June 01,
2021.

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

Dream — a simple, yet feature-complete Web framework
Ocaml developer at Routine, Paris, Remote OK
Feather 0.2.0
BAP 2.3.0 Release
Building Ahrefs codebase with Melange
Lwt 5.4.1
Other OCaml News
Old CWN


Dream — a simple, yet feature-complete Web framework
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dream-a-simple-yet-feature-complete-web-framework/7909/1>


Anton Bachin announced
──────────────────────

  I am pleased to announce [*Dream*], a very easy-to-use Web framework
  with high performance, secure defaults, and thorough documentation!

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

  It is available now from opam, with `opam install dream'.

  Dream offers:

  • [WebSockets] and [GraphQL].
  • A [template syntax], which you can see in the image above.
  • Trivial [HTTPS and HTTP/2 support], allowing simple deployments
    without a proxy.
  • [Sessions] with pluggable [back ends].
  • Easy [secure cookies] and [CSRF-safe forms].

  …and more, yet Dream sticks to a simple programming model:

  • Web apps are just [bare functions] from requests to responses.
  • [Middlewares] are just higher-order wrapper functions.
  • [Routes] tell the [router] which of these functions to call.

  Indeed, for those who like algebra, there is a certain [structure] to
  Dream. However, that's not the point of this post!

  Dream is meant to be very easy to understand. It sticks to base types,
  introducing only a few types of its own, and uses existing languages,
  such as HTML for templates, and URLs for routes. Dream itself is one
  module in one opam package, which lives in a monorepo. The [docs] are
  on one page.

  Dream is loosely coupled. Even though Dream offers many defaults, it
  is unopinionated, and you can quickly configure or replace
  anything. For example, it is easy to [use TyXML] for templates, and
  Dream happily supports such usage with examples.

  Security-sensitive features, such as cookies, are arranged so that
  simple and obvious usage is automatically secure.  Wherever security
  still depends on the Dream app, the docs [highlight] it. Dream has
  selected a modern [cipher] as a default, supports [key rotation], and
  offers suggestions for other purposes, such as password hashing. It
  implements and abstracts away all of the [OWASP] security guidelines
  that are relevant to its level.

  Dream is designed for full internationalization. It has a centralized
  [error handler] that intercepts even lower-level HTTP errors, so that
  you can decorate them with your app's own error template, and leak no
  hardcoded strings. Dream's URL encoders [favor] internationalized
  (UTF-8) URIs, and the router accepts them.

  Finally, Dream is designed for a wide range of applications, including
  with or without a proxy, standalone or embedded in larger binaries,
  and with external static assets or [assets compiled in].


[*Dream*] <https://github.com/aantron/dream>

[WebSockets]
<https://github.com/aantron/dream/tree/master/example/k-websocket#files>

[GraphQL]
<https://github.com/aantron/dream/tree/master/example/w-graphql-subscription#files>

[template syntax]
<https://github.com/aantron/dream/tree/master/example/7-template#files>

[HTTPS and HTTP/2 support]
<https://github.com/aantron/dream/tree/master/example/l-https#files>

[Sessions]
<https://github.com/aantron/dream/tree/master/example/b-session#files>

[back ends] <https://aantron.github.io/dream/#back-ends>

[secure cookies] <https://aantron.github.io/dream/#cookies>

[CSRF-safe forms] <https://aantron.github.io/dream/#forms>

[bare functions] <https://aantron.github.io/dream/#type-handler>

[Middlewares] <https://aantron.github.io/dream/#type-middleware>

[Routes] <https://aantron.github.io/dream/#type-route>

[router] <https://aantron.github.io/dream/#val-router>

[structure] <https://aantron.github.io/dream/#algebra>

[docs] <https://aantron.github.io/dream/>

[use TyXML]
<https://github.com/aantron/dream/tree/master/example/w-tyxml#files>

[highlight]
<https://github.com/aantron/dream/tree/master/example/7-template#security>

[cipher] <https://aantron.github.io/dream/#cryptography>

[key rotation] <https://aantron.github.io/dream/#servers>

[OWASP] <https://cheatsheetseries.owasp.org/>

[error handler]
<https://github.com/aantron/dream/tree/master/example/9-error#files>

[favor] <https://aantron.github.io/dream/#val-to_percent_encoded>

[assets compiled in]
<https://github.com/aantron/dream/tree/master/example/w-one-binary#files>

Documentation
╌╌╌╌╌╌╌╌╌╌╌╌╌

  Dream is very extensively documented. See…

  • [*Examples*], the first several of which make up a tutorial. Each
    example is a complete project.
  • The online [*playground*], which features many of the examples, and
    is itself a [Dream app]!
  • The [*API docs*].

  In particular, see

  • Deployment examples for [Heroku], Digital Ocean [with Docker], and
    Digital Ocean [with systemd], all of which include GitHub Actions
    scripts and instructions.
  • Full-stack examples with [js_of_ocaml], [ReScript], and [Melange].
  • Examples in [Reason syntax].
  • Development [watching] and [live reloading].


[*Examples*]
<https://github.com/aantron/dream/tree/master/example#readme>

[*playground*] <http://dream.as/ocaml>

[Dream app]
<https://github.com/aantron/dream/tree/master/example/z-playground>

[*API docs*] <https://aantron.github.io/dream/>

[Heroku]
<https://github.com/aantron/dream/tree/master/example/z-heroku#files>

[with Docker]
<https://github.com/aantron/dream/tree/master/example/z-docker-esy#files>

[with systemd]
<https://github.com/aantron/dream/tree/master/example/z-systemd#files>

[js_of_ocaml]
<https://github.com/aantron/dream/tree/master/example/w-fullstack-jsoo#files>

[ReScript]
<https://github.com/aantron/dream/tree/master/example/w-fullstack-rescript#files>

[Melange]
<https://github.com/aantron/dream/tree/master/example/r-fullstack-melange#files>

[Reason syntax]
<https://github.com/aantron/dream/tree/master/example#reason>

[watching]
<https://github.com/aantron/dream/tree/master/example/w-fswatch#files>

[live reloading]
<https://github.com/aantron/dream/tree/master/example/w-live-reload#files>


Contributing
╌╌╌╌╌╌╌╌╌╌╌╌

  Dream has already received several very helpful [contributions], and
  more are very welcome! See [`CONTRIBUTING.md']. I must also
  acknowledge all the people working on Dream's [dependecies] and [prior
  art]. In particular, Dream relies heavily on the HTTP and WebSocket
  [servers] primarily by Spiros Eliopoulos (@seliopou) and Antonio Nuno
  Monteiro (@anmonteiro).

  Apart from accepting code, docs, and examples, Dream will happily link
  to:

  • Blogs and articles, as different people learn best from different
    presentations.
  • "Downstream" libraries to use with Dream.

  For example, Thibaut Mattio (@tmattio) is working on
  [dream-livereload], a live-reloading middleware for Dream, similar to
  the [example], which he also contributed! Once dream-livereload is
  slightly more mature, Dream will link to it from its README.

  There is also [dream-serve], a live-reloading static site server based
  on Dream and libuv, which was used to develop the docs.


[contributions] <https://github.com/aantron/dream/graphs/contributors>

[`CONTRIBUTING.md']
<https://github.com/aantron/dream/blob/master/docs/CONTRIBUTING.md>

[dependecies]
<https://github.com/aantron/dream/blob/b79b06dd6add32beba6eee6864ce99413634b7b3/dream.opam#L49-L111>

[prior art] <https://github.com/aantron/dream#acknowledgements>

[servers]
<https://github.com/aantron/dream/tree/b79b06dd6add32beba6eee6864ce99413634b7b3/src/vendor>

[dream-livereload] <https://github.com/tmattio/dream-livereload>

[example]
<https://github.com/aantron/dream/tree/master/example/w-live-reload#files>

[dream-serve] <https://github.com/aantron/dream-serve>


Roadmap
╌╌╌╌╌╌╌

  Dream is currently in an alpha state. It is thought (by me) to be
  internally quite stable. However, there will probably be various API
  tweaks before release 1.0.0.

  My current, rough plan is to release several alphas of Dream over six
  months or so. The releases will address:

  1. Flow control for very large responses, and getting the "advanced"
     part of the I/O API to be as close to zero-copy and non-allocating
     as possible (or reasonable).
  2. Remaining (optional) [security enhancements], such as a [default
     content security policy].
  3. Remaining [session improvements], such as re-keying.
  4. Friction in handling of JSON, database access, etc. This is not
     properly part of or due to Dream, but it should be addressed for a
     better Web development experience.
  5. Multicore and effects support.

  That's all. Let's bring OCaml to the Web! Happy Web programming!


  <https://github.com/aantron/dream>


[security enhancements]
<https://github.com/aantron/dream/issues?q=is%3Aissue+is%3Aopen+label%3Asecurity>

[default content security policy]
<https://github.com/aantron/dream/issues/48>

[session improvements] <https://github.com/aantron/dream/issues/13>


Anton Bachin then added
───────────────────────

  For readers who saw the repo during the earlier ["leak,"] the main
  updates are:

  • A large number of new examples, including [deployment].
  • The [playground], which runs the examples, and itself served as a
    test.
  • An esy-based [quick start] script.

  There have also been very many smaller changes to the code, API, and
  the rest of the docs, but the above changes are the biggest "chunks."
  The rest is too much to detail :)


["leak,"] <https://discuss.ocaml.org/t/7605>

[deployment]
<https://github.com/aantron/dream/tree/master/example#deploying>

[playground] <http://dream.as>

[quick start] <https://github.com/aantron/dream#quick-start>


Ivan Gotovchits asked and Anton Bachin replied
──────────────────────────────────────────────

        I was always wondering how does the source code that uses
        [templates] work with OCaml tooling, in particular with
        merlin, ocp-indent, ocaml-format, tuareg and other editor
        modes?

  It doesn't work well in practice with anything other than syntax
  highlighting. Note that you control the syntax mode with the
  extension. If your template is mostly HTML, you can name it
  `foo.eml.html'.

  The intent is that the templates should contain mostly HTML in a large
  project, and most of them would be in their own `template/'
  subdirectory. OCaml tooling wouldn't be needed for these mostly-HTML
  files. For a still-small, but real example of this, see the
  Playground's [`client.eml.html'].

  The one-file `.ml' projects with templates, where tooling is a
  problem, are mostly good for the very first steps of getting started,
  and examples.

  There is also an issue about this in the repo, [#55 " how to apply
  ocamlformat"].

  Note that, as in the announcement text, you can use Dream with other
  templaters, including [TyXML], which has an [HTML PPX]. In addition,
  if you are using Reason, you can use [TyXML JSX]. Either of these
  options interacts well with tooling, as far as I know.

  I didn't make TyXML the default because it considerably increases the
  Dream learning curve for getting basic tasks done. However, Dream
  still supports the choice of using TyXML with examples and links.


[templates] <https://aantron.github.io/dream/#templates>

[`client.eml.html']
<https://github.com/aantron/dream/blob/fa20aebf36307a07b59c9ea018c25e508415d91a/example/z-playground/client/client.eml.html>

[#55 " how to apply ocamlformat"]
<https://github.com/aantron/dream/issues/55>

[TyXML]
<https://github.com/aantron/dream/tree/master/example/w-tyxml#files>

[HTML PPX]
<https://github.com/aantron/dream/tree/master/example/w-tyxml#html-syntax>

[TyXML JSX]
<https://github.com/aantron/dream/tree/master/example/r-tyxml#files>


Ocaml developer at Routine, Paris, Remote OK
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-ocaml-developer-at-routine-paris-remote-ok/7911/1>


mefyl announced
───────────────

  Routine (<https://routine.co>) is looking for an OCaml developer.

  Routine is a personal productivity assistant. The technological
  revolves heavily around OCaml which represents 90% of the codebase,
  the remaining 10% being the UI in Typescript and Vue.js. We target
  both the browser and desktop through electron, using Js_of_ocaml.

  While the product is "just" a web app, our technological and academic
  background leads us to use designs that, I think, can pique the
  interest of seasoned Ocaml developer. Amongst other things :

  • Type-driven programming based on ppx derivers that produces
    typescript declaration for frontend bindings, JSON schema to expose
    and consume external REST APIs (Google, Notion, …), automatic SQL
    bindings, etc.
  • Angstrom based parsing for the interactive console with highlighting
    and completion.
  • Incremental based state updates to refresh minimal subsets of the
    app.
  • Highly concurrent implementation through Lwt, exception-free design.

  We use state of the art CI/CD and development processes. We plan on
  distributing open sources packages of these utilities (type-driven
  system, Google API bindings, Notion API bindings, …). Future exciting
  subjects could be extending Angstrom with manual rollback to implement
  generic completions or binding Vue in OCaml directly using melange or
  rescript to achieve rock solid typing down to the very frontend code
  (highly prospective teases, don't quote me on this yet :).

  The company is very much a startup, having just completed YC batch W21
  and closed its first round of investment.  Salary is up to market
  standard depending on the profile, plus usual options package, to be
  discussed.

  While we expect great OCaml and general computer science proficiency,
  we're open to most levels of experience.  Thoroughness and a love for
  well rounded, robust and beautiful software design is a must have -
  but that comes bundled with OCaml love, right ?

  Do not hesitate to reach out for any question here, at
  quentin.hocquet@routine.co or refer this to someone who may be
  interested.

  Thanks for your time and happy camel riding !


Feather 0.2.0
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-feather-0-2-0/7916/1>


Charles announced
─────────────────

  I'm happy to announce feather version 0.2.0! Feather is a minimal
  library for bash-like scripting and process execution.  ([github],
  [opam])

  This release fixes some bugs and adds three new functions

  • `val and_ : cmd -> cmd -> cmd' — chain two commands, short
    circuiting if the first fails, akin to bash's `&&' operator.
  • `val or_ : cmd -> cmd -> cmd' — chain two commands, short circuiting
    if the first succeeds, akin to bash's `||' operator.
  • `val sequence : cmd -> cmd -> cmd' — chain two commands regardless
    of exit status.

  We include two new operators `&&.' and `||.' which correspond to
  `and_' and `or_' respectively. They'll be found in the `Feather.Infix'
  module, which has been renamed from `Feather.File_redirection_infix'.

  Many thanks to new contributors @Firobe @juxd and @tmarti2 for making
  this release possible!


[github] <https://github.com/charlesetc/feather>

[opam] <https://opam.ocaml.org/packages/feather/>


BAP 2.3.0 Release
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-bap-2-3-0-release/7926/1>


Ivan Gotovchits announced
─────────────────────────

  We're proud to release the next stable version of Carnegie Mellon
  University Binary Analysis Platform ([BAP]). The full list of changes
  can be found on the [release page] but the most interesting new
  features are highlighted below.


[BAP] <https://github.com/BinaryAnalysisPlatform/bap>

[release page]
<https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.3.0>

The Primus Lisp Frontend
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Now BAP is able to understand not only binary programs but sources
  written in Primus Lisp. In case if you don't know, [Primus Lisp] is
  our DSL for writing analysis and library stubs (e.g., to specify
  semantics of missing library functions). Now, it is possible to reify
  Primus Lisp programs into static representation. For example, we can
  translate the following Lisp program

  ┌────
  │ ;; file demo.lisp
  │ 
  │ (defun example1 (x)
  │   (set R0 1)
  │   (set R1 2)
  │   (set R3 (+ R1 R2 (* R1 R2 3)))
  │   (memory-write R4 (+ R3 R1))
  │   (if (> R0 (* R0 R0))
  │       (exec-addr 0xDEADBEEF)
  │     (set R0 (* R0 R2 R3))))
  └────

  into the BIL (BAP Instruction Language) AST and then pretty print it,
  ┌────
  │ $ bap show --primus-lisp-load=demo --target=armv7+le -obap:bil example1
  │ example1:
  │ "{
  │    R0 := 1
  │    R1 := 2
  │    R3 := R1 + R2 + R1 * R2 * 3
  │    mem := mem with [R4] <- low:8[R3 + R1]
  │    #1 := R0 * R0 < R0
  │    if (#1) {
  │      jmp 0xDEADBEEF
  │    }
  │    else {
  │      R0 := R0 * R2 * R3
  │    }
  │  }"
  └────

  This new feature not only allows us to reify our Lisp stubs into
  static form but also enables the main killer feature. It is now
  possible to specify the semantics of machine instructions in Primus
  Lisp. This feature enables rapid development and experimentation with
  CPU semantics. And this brings us to the next new feature.


[Primus Lisp]
<https://binaryanalysisplatform.github.io/bap/api/master/bap-primus/Bap_primus/Std/Primus/Lisp/index.html>


New Target: RISC-V
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The first application of the Primus Lisp Frontend was writing the
  RISC-V semantics. It took me only one day to write the semantic of the
  [minimal subset] of RISC-V instruction. Well, partially it is because
  RISCV-V is truly RISC, like the `add' instruction just adds,

  ┌────
  │ (defun ADDI (dst rm rn)
  │   (set$ dst (+ rm rn)))
  └────


[minimal subset]
<https://github.com/BinaryAnalysisPlatform/bap/pull/1287>


New Target: ARMv8 (Aarch64)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The next target that we tried was Aarch64, the 64-bit ARM
  architecture. It was a little bit [harder] but still definitely more
  readable than the official ARM semantics.


[harder]
<https://github.com/BinaryAnalysisPlatform/bap/blob/master/plugins/arm/semantics/aarch64.lisp>


Adds namespaces (packages) to Primus Lisp
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Since now we have much more code in Primus Lisp we found ourselves
  struggling with name clashes. The Primus Lisp program model is a set
  of mututally recursive overloaded definitions, so naming things is
  crucial for us. Therefore we implemented namespaces (which are,
  following Common Lisp trandition, named packages). We ended up in a
  very Common Lisp look and fill but without inheriting CL problems,
  like the dependency on the order of inclusion and package
  redefinitions, and so on. Given our model, and that Primus Lisp
  features type inference and Haskell-style type classes for
  overloading, it wasn't that easy to implement :)


Adds the `bap dependencies' command
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The [command] outputs program dependencies such as libraries and
  symbols. The information is collected recursively with various output
  options, including dependency graph, YAML, JSON, and SEXP.

  Much like `nm~+~ldd' on steroids and cross-platform (works on
  PE/ELF/COFF, and on binaries that are not native to the host). So it
  could be quite useful even if you're not doing program analysis, but
  just want to solve a nasty missing library feature or figure our what
  programs use what libraries, e.g.,
  ┌────
  │ $ bap dependencies `which ping` --recursive --ldconfig -ograph | graph-easy --as boxart
  │                      ┌────────────────┐
  │                      │ libresolv.so.2 │ ──────────────────────────────────┐
  │                      └────────────────┘                                   │
  │                        ▲                                                  │
  │                        │                                                  │
  │                        │                                                  │
  │ ┌──────────────┐     ┌──────────────────────────┐     ┌────────────────┐  │
  │ │ libidn.so.11 │ ◀── │           ping           │ ──▶ │ libnettle.so.6 │  │
  │ └──────────────┘     └──────────────────────────┘     └────────────────┘  │
  │   │                    │                 │              │                 │
  │   │                    │                 │              │                 │
  │   │                    ▼                 │              │                 │
  │   │                  ┌────────────────┐  │              │                 │
  │   │                  │  libcap.so.2   │  │              │                 │
  │   │                  └────────────────┘  │              │                 │
  │   │                    │                 │              │                 │
  │   │                    │                 │              │                 │
  │   │                    ▼                 ▼              │                 │
  │   │                  ┌──────────────────────────┐       │                 │
  │   └────────────────▶ │        libc.so.6         │ ◀─────┘                 │
  │                      └──────────────────────────┘                         │
  │                        │                      ▲                           │
  │                        │                      └───────────────────────────┘
  │                        ▼
  │                      ┌────────────────┐
  │                      │ ld-linux.so.2  │
  │                      └────────────────┘
  └────


[command] <https://github.com/BinaryAnalysisPlatform/bap/pull/1294>


What's Next?
╌╌╌╌╌╌╌╌╌╌╌╌

  We are working on decompilation and integrating with Ghidra, so in
  2.4.0 you should expect that bap will output C code for binaries. But
  it is not all, we're even working into turning BAP into a program
  analysis framework that enables analysis of source code programs. And
  even crazier, we're working on adding compilation capabilities to BAP,
  i.e., an ability to compile/recompile the input sources. So soon BAP
  will outlive its name, or we will need to find a new interpretation
  for the BAP acronym, something like the Best Analysis Platform ;)

  We also plan to make BAP more available for non-seasoned OCaml users
  and want to push bap into mainstream Linux distributions and overall
  lower the entrance barrier.  Of course, with the end goal to lure
  users into installing opam))


Questions and Suggestions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Please, do not hesitate to ask questions and provide your suggestions
  and, ideally, join our [community]. Even if you don't plan to work on
  binary analysis, BAP offers lots of opportunities for writing your toy
  programs for learning the language, or maybe even student projects.


[community] <https://gitter.im/BinaryAnalysisPlatform/bap>


Building Ahrefs codebase with Melange
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/building-ahrefs-codebase-with-melange/7941/1>


Javier Chávarri announced
─────────────────────────

  At Ahrefs, we make extensive use of OCaml and ReScript —previously
  [known as BuckleScript]. So we have been following the latest
  developments in the ReScript ecosystem with great interest.

  A few months ago, [António Monteiro] released [Melange], a fork of
  ReScript with an emphasis of keeping compatibility with OCaml
  ecosystem. One of the key features of Melange is that it uses OCaml
  4.12, with all the upsides that that entails (ppxlib, let syntax,
  better errors, …). Besides that, Melange has been modeled recently [as
  just a `compiler-libs' library], so it can be integrated with other
  OCaml code in a single opam switch.

  We decided to give Melange a try recently at Ahrefs, and shared the
  results of this experiment in a blog post:

  <https://tech.ahrefs.com/building-ahrefs-codebase-with-melange-9f881f6d022b>

  We are currently looking into how a deeper integration with Dune would
  look like. If your team or company has tried Melange, or is interested
  on doing so, we would be very interested to hear your use cases and
  share experiences.


[known as BuckleScript]
<https://rescript-lang.org/blog/bucklescript-is-rebranding>

[António Monteiro] <https://discuss.ocaml.org/u/anmonteiro/summary>

[Melange] <https://github.com/melange-re/melange>

[as just a `compiler-libs' library]
<https://github.com/melange-re/melange/pull/107>


Lwt 5.4.1
═════════

  Archive: <https://discuss.ocaml.org/t/ann-lwt-5-4-1/7943/1>


Raphaël Proust announced
────────────────────────

  We are glad to announce the release of version 5.4.1 of Lwt: a
  bugfix-only release.

  <https://github.com/ocsigen/lwt/releases/tag/5.4.1>

  You can update to this version in `opam':

  ┌────
  │ opam update
  │ opam upgrade lwt
  └────

  Thanks to the contributors for finding and fixing the bugs, leading to
  this release. Check out the release notes (link above) for a full
  list.


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Beta release of Frama-C 23.0~rc1 (Vanadium)]
  • [Building Ahrefs codebase with Melange]
  • [Computing an integer using a Grothendieck topos]
  • [ ReScript 9.1]
  • [Tutorial: Format Module of OCaml]
  • [Tarides project SCoP is selected as one of the brightest Data
    Portability projects in Europe!]
  • [Alt-Ergo Users’ Club Annual Meeting (2021)]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Beta release of Frama-C 23.0~rc1 (Vanadium)]
<https://frama-c.com/fc-versions/vanadium.html>

[Building Ahrefs codebase with Melange]
<https://tech.ahrefs.com/building-ahrefs-codebase-with-melange-9f881f6d022b>

[Computing an integer using a Grothendieck topos]
<http://math.andrej.com/2021/05/18/computing-an-integer-using-a-sheaf-topos/>

[ ReScript 9.1] <https://rescript-lang.org/blog/release-9-1>

[Tutorial: Format Module of OCaml]
<https://www.ocamlpro.com/2021/05/06/tutorial-format-module-of-ocaml/>

[Tarides project SCoP is selected as one of the brightest Data
Portability projects in Europe!]
<https://tarides.com/blog/2021-04-30-scop-selected-for-dapsi-initiative>

[Alt-Ergo Users’ Club Annual Meeting (2021)]
<https://www.ocamlpro.com/2021/04/29/alt-ergo-users-club-annual-meeting-2021/>


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: 42545 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-25  7:30 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-05-25  7:30 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of May 18 to 25,
2021.

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

Applied PL research at Jane Street
IRC channels available on libera.chat
B Trees in Ocaml via Fmlib 0.3.0
GitHub Actions for OCaml: now stable and on the ocaml org
Set up OCaml 2.0.0-alpha
FrontC 4.1.0 (Vingt ans après)
Old CWN


Applied PL research at Jane Street
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-applied-pl-research-at-jane-street/7877/1>


Yaron Minsky announced
──────────────────────

  This isn't exactly news, but we're (still) actively looking to hire
  people to do applied PL research, with a particular focus on
  type-level work. Follow this link if you want to see how to apply.

  <https://blog.janestreet.com/applied-PL-research/>

  Please share it around with anyone who you think might be on the
  market!

  *About the job*

  Part of our ambition is to grow OCaml into a language that does an
  ever better job of being convenient and expressive by default, while
  allowing for the kind of precise control you need when building high
  performance systems, where it's needed.

  That's led us to do research on stack-allocation, unboxed types,
  algebraic effects, type-level resource tracking, and more. We think
  it's an exciting direction for the language, and there's a lot of
  challenging and novel work to be done, and the main thing that could
  speed us up is having more of the right people to work on it!

  Jane Street is an excellent laboratory for this kind of work: big
  enough to have serious and demanding use-cases, but small and nimble
  enough to be able to try out new language features, and then back out
  of them or change them in incompatible ways if need be.

  And all the work we do on the compiler is in the open, with the goal
  of getting the final results into a state where they can be
  upstreamed.

  Also, it's a great team! Full of serious experts who have collectively
  contributed a lot to OCaml and PL research over the years, and also a
  really nice set of people to work with. And I think the team has a
  good balance of the practical and theoretical: working hard to do the
  right thing, but also finding practical ideas that can make forward
  progress in the near term.

  *Who are we looking for*

  We're looking for people with a good balance of theoretical and
  engineering backgrounds, since the work is demanding on both fronts.

  We're happy to hire people at a range of experience levels: people who
  have just finished a post-doc or PhD, up to experienced academics and
  people in industry.

  The team has a presence in New York and London, and we're hiring in
  both offices. No remote work, I'm afraid.


IRC channels available on libera.chat
═════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-05/msg00022.html>


Adrien Nader announced
──────────────────────

  Due to the recent troubles on freenode[1][2], I've connected to
  irc.libera.chat early in order to create and register the same
  channels that I know and take care ofa on freenode (i.e. #ocaml and
  #ocaml-fr).

  I am not stating libera.chat is better than freenode.net although the
  amount of staffers moving makes me think freenode.net will not be
  running fine for a much longer time.

  At the moment I believe it is better to keep both channels running and
  to encourage people to connect on libera.chat too. In the future, I
  might force migration by progressively silencing the channel that
  should be abandoned.

  If you maintain a relay bot, can you please add it on libera.chat too?

  As far as I know, there is no Matrix bridge available currently. It
  seems the discussion/process for bridge additions occurs at [3].

  A good news is that I've gotten the full rights on the channel,
  something which was requiring paperwork on freenode (which I had
  already mentioned but never got around to doing and for which I never
  even remotely got time for).

  [1] <https://lwn.net/Articles/856543/> (this still constantly changes)
  [2]
  <https://en.wikipedia.org/wiki/Freenode#2021_ownership_change_and_conflict>
  [3] <https://github.com/matrix-org/matrix-appservice-irc/issues/208>


B Trees in Ocaml via Fmlib 0.3.0
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/b-trees-in-ocaml-via-fmlib-0-3-0/7880/1>


Hbr announced
─────────────

  I am pleased to announce the release (0.3.0) of fmlib, a functional
  library with managed effects.

  The main new feature of release 0.3.0 are B trees. B trees can be used
  to implement finite sets and finite maps. Fmlib's B trees have
  functionality similar to the modules `Set' and `Map' of the standard
  library.

  The modules `Set' and `Map' of the standard library are based on AVL
  trees. B trees offer the same functionality but have on modern
  processors a better cache performance and have better data locality.

  The current B tree implementation in `Fmlib' implements B trees by
  using arrays which are guaranteed to fit into a cache line. The design
  of B trees is described [here]. The API can be found [here].

  The library `Fmlib' has four main components:

  • [Standard Datatypes]: This component offers some modules from
    `Stdlib' with additional functionality. E.g. `Fmlib_std.Array'
    offers functions to insert elements into arrays, remove elements
    from an array and binary search in a sorted array. It has the
    modules `Result' and `Option' which can be used to avoid exceptions
    and use exceptions in a more structured way. The modules `Result'
    and `Option' in `Fmlib' offer a complete monadic interface and offer
    the `let*' operator to write well readable monadic code.

  • [Pretty Printing]: Print tree like structures in a nice way and use
    the library completely functional. The library does not assume a
    specific IO method. The pretty printer generates a lazy stream of
    characteres which can be written by all io functions.

  • [Combinator Parsing]: Easily parse textual input by the use of
    combinators. The library supports indentation sensitivity and can
    therefore be used to parse yaml files, haskell, python,
    etc. Furthermore no input method is assumed. The generated parsers
    are sink of tokens (or characters). You can choose any input method
    and push the tokens/characters into the parsers. The generated
    parsers are fully incremental. Parser can be stored at any position
    of the input stream and in case of interactive editing, parsing can
    be resumed from any point of the stream.

  • [Interface to Javascript]: This components contains primitives to
    interface to javascript via `js_of_ocaml'.

  `Fmlib' can be installed via opam:

  ┌────
  │ opam update
  │ opam install fmlib
  │ opam install fmlib_std
  │ opam install fmlib_pretty
  │ opam install fmlib_parse
  │ opam install fmlib_js
  └────

  The source code of the library is located at [github]


[here] <https://fmlib_ocaml.readthedocs.io>

[here] <https://hbr.github.io/fmlib/odoc/fmlib_std>

[Standard Datatypes] <https://hbr.github.io/fmlib/odoc/fmlib_std>

[Pretty Printing] <https://hbr.github.io/fmlib/odoc/fmlib_pretty>

[Combinator Parsing] <https://hbr.github.io/fmlib/odoc/fmlib_parse>

[Interface to Javascript] <https://hbr.github.io/fmlib/odoc/fmlib_js>

[github] <https://github.com/hbr/fmlib>


GitHub Actions for OCaml: now stable and on the ocaml org
═════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/github-actions-for-ocaml-now-stable-and-on-the-ocaml-org/7889/1>


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

  I [announced a beta] of OCaml/opam support for GitHub Actions back in
  Nov 2019, and the functionality has turned out to be popular. A number
  of projects in our community have been using the Action, and it can be
  found in the [GitHub Marketplace].

  It has been sufficiently popular that it's definitely time to get it
  off my personal GitHub account, and so I have transferred it to its
  new home at <https://github.com/ocaml/setup-ocaml>.  I am also very
  pleased to announce that @smorimoto and @dra27 are also now
  maintainers – they have both made significant improvements to it, and
  @smorimoto in particular has been working with the GitHub ecosystem to
  further improve the efficiency of the Action (such as by adding
  reliable caching).  Thank you to them both and [all the other
  contributors] for your help improving the CI experience around OCaml.

  If anyone else wishes to contribute to improving the action, please do
  get involved on [the issue tracker].  And of course, if you are still
  referencing `avsm/setup-ocaml' in your own workflow definition, this
  is a good time to change it to `ocaml/setup-ocaml'.

  This is probably a good time to note that the other [ci-scripts]
  repository on the ocaml/ GitHub organisation is in sore need of either
  new maintainers (for the Travis CI), or being retired due to lack of
  support (primarily due to the shift to GitHub Actions). I'm immensely
  grateful to Travis CI for the decade of mostly free builds they have
  provided our community to date.


[announced a beta]
<https://discuss.ocaml.org/t/github-actions-for-ocaml-opam-now-available/4745>

[GitHub Marketplace]
<https://github.com/marketplace/actions/set-up-ocaml>

[all the other contributors]
<https://github.com/ocaml/setup-ocaml/graphs/contributors>

[the issue tracker] <https://github.com/ocaml/setup-ocaml/issues>

[ci-scripts] <https://github.com/ocaml/ocaml-ci-scripts>


Set up OCaml 2.0.0-alpha
════════════════════════

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


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

  This is the announcement of the first alpha release of setup-ocaml
  v2. This includes quite a few changes, including reliable cache, as
  described in a recent [post].

  There are so many changes, so I would like to list only the notable
  changes. (The full changelog can be found at the bottom of the post.)


[post]
<https://discuss.ocaml.org/t/github-actions-for-ocaml-now-stable-and-on-the-ocaml-org/7889>

The "ocaml-version" input is now named "ocaml-compiler"
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This was changed because calling it "OCaml Version" is not appropriate
  enough, e.g. to use the new variant naming convention introduced from
  4.12.


32 bits compiler support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌


Semver-style version matching support
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  With the naughty exception of `4.02.2' , point releases are meant to
  be strictly compatible, so once OCaml dev team release a new point
  release, upgrading should be a no-brainer. With that in mind, it's
  obviously not smart to rewrite every workflow every time a new point
  release is released, so you can now specify versions in the style like
  `4.12.x'.


Reliable cache feature
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The action supports not only the compiler cache, but also the [dune
  cache]. However, note that it is not available on the macOS runners
  until opam 2.0.9 is released. The dune cache is actually quite
  powerful for large projects, if you're interested in it, check out the
  comparison section of [ocaml/setup-ocaml#66]. The reliable cache
  feature uses the [@actions/cache] package internally, and I worked
  with the GitHub team to make it fast enough for setup-ocaml to be up
  to 4x faster. For the Ubuntu runners, you can set up your environment
  with cache in about 30~40 seconds at the fastest.


[dune cache] <https://github.com/ocaml/dune/blob/2.8.5/doc/caching.rst>

[ocaml/setup-ocaml#66] <https://github.com/ocaml/setup-ocaml/pull/66>

[@actions/cache]
<https://github.com/actions/toolkit/tree/main/packages/cache>


Automatic pinning and depext handling of local packages
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  For example, if you have a very large number of local packages, like
  the [Irmin] project, it can be quite a pain for a human to have to
  write a script to pin them all in your workflow. The action pins and
  depext the local packages if they exist in the repository by
  default. You can also use the glob pattern to select which local
  packages to handle, as described [here].

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


[Irmin] <https://github.com/mirage/irmin>

[here]
<https://github.com/ocaml/setup-ocaml/blob/master/examples.md#using-glob-patterns-to-filter-local-packages>


FrontC 4.1.0 (Vingt ans après)
══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-frontc-4-1-0-vingt-ans-apres/7906/1>


Ivan Gotovchits announced
─────────────────────────

  More than twenty years after its original release [FrontC] is still
  alive and getting new updates. Mostly it started with my frustration
  with its Makefiles that ended up in switching to menhir and dune and
  adding cram tests that finally enabled us to safely touch the grammar
  definitions and introduce a few c99 … c11 language features as well as
  more GNU extensions. Our end goal is to get a robust and easy-to-use C
  parser that is capable of taking a C program on a modern Linux
  distribution and get it parsed into a C abstract tree. It is not that
  trivial as it may sound as modern C library headers (especially GNU
  libc) use non-standard or standard but very modern C features, and
  most of the OCaml parsers that I have seen are still unable to parse
  them, including parsers from FramaC, C11parser, and even compcert
  parser (mostly they do not handle complex floating-point types and
  various extension types and some GCC attributes).

  Therefore, FrontC is still useful, especially if all that you want is
  to start doing program analysis with minimal initial effort, just do
  (but wait until it is [merged])

  ┌────
  │ opam install FrontC
  └────

  and start hacking!

  With that said, FrontC is mostly maintained at leisure time by
  volunteers, so the pull requests are very welcome.


[FrontC] <https://github.com/BinaryAnalysisPlatform/FrontC>

[merged] <https://github.com/ocaml/opam-repository/pull/18736>


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: 27729 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-11 14:47 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-05-11 14:47 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of May 04 to 11,
2021.

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

Software engineer position at LexiFi (Paris)
Open source editor for iOS, iPadOS and macOS
Backend developer position at Issuu (Copenhagen)
25 years of OCaml
OCaml compiler development newsletter, issue 1: before May 2021
After so many years, I discover 'Str.bounded_full_split regexp str n'
Parser for the Scala programming language?
Old CWN


Software engineer position at LexiFi (Paris)
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-software-engineer-position-at-lexifi-paris/7782/1>


Alain Frisch announced
──────────────────────

  [LexiFi] is hiring! We are looking for a fully-time software engineer
  to join our core development team. The vast majority of our stack is
  implemented in OCaml, and we have plenty of exciting projects on a
  wide range of topics.

  More info on <https://www.lexifi.com/careers/software_engineer/>


[LexiFi] <https://www.lexifi.com>


Open source editor for iOS, iPadOS and macOS
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/open-source-editor-for-ios-ipados-and-macos/7624/15>


Continuing this thread, Nathan Fallet announced
───────────────────────────────────────────────

  Just updated the editor, I redesigned the macOS version, and it just
  looks better and more native

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/6/6b03c462755fb37a2d5018013c3d1c8bd45f53bf_2_1380x766.jpeg>

  What are your first impressions on it?


Backend developer position at Issuu (Copenhagen)
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-backend-developer-position-at-issuu-copenhagen/7793/1>


Dario Teixeira announced
────────────────────────

  We are looking for a Backend Developer with experience in machine
  learning – and preferably also OCaml! – to join our Research &
  Development team. You will help build machine learning research
  prototypes and be responsible for integrating them into new and
  existing products.

  At Issuu, we use OCaml extensively in our production systems. If you
  love OCaml and functional programming in general, Issuu is a great
  place to put your passion into real-world products!

  Please find more information about this position at the following
  link:
  <https://jobs.lever.co/issuu/f502cb20-b216-4c67-8357-d748e1b35178>


Anentropic asked and Dario Teixeira replied
───────────────────────────────────────────

        I would love to hear more about your OCaml backend stack

  Well, we love to talk about our OCaml stack! :slightly_smiling_face:

  We rely on the Jane Street ecosystem a lot, using Core as a Stdlib
  replacement and Async for monadic concurrency.

  AMQP forms the backbone of our messaging system, and therefore we use
  [amqp-client] extensively.

  We use both MySQL and Postgresql databases in production. For the
  former we use [ppx_mysql], and for the latter, [PGOCaml]. (Thanks to
  Docker, we can give PGOCaml compile-time access to the DB without
  having to depend on the actual production DB.)

  We currently use Protobuf for serialisation, but spend a great amount
  of time complaining about it. We rely on [ocaml-protoc-plugin] to
  generate the OCaml code from Protobuf definitions.

  Anyway, that's just the basics of our stack. Do let me know if there's
  something else you'd like to know in more detail!


[amqp-client] <https://github.com/andersfugmann/amqp-client>

[ppx_mysql] <https://github.com/issuu/ppx_mysql>

[PGOCaml] <https://github.com/darioteixeira/pgocaml>

[ocaml-protoc-plugin] <https://github.com/issuu/ocaml-protoc-plugin>


roddy asked and Dario Teixeira replied
──────────────────────────────────────

        Do you use Protobuf for interop with non-OCaml systems? If
        not, I'm curious about whether you've considered
        [bin_prot] as an alternative; it seems like an obvious
        choice if you're using Core/Async.

  Yes, we use Protobuf mainly because we have a heterogeneous stack,
  where besides OCaml we also have services running Python, Kotlin, or
  Elixir.


[bin_prot]
<https://github.com/janestreet/bin_prot/blob/master/README.md>


Tim McGilchrist asked and Dario Teixeira
────────────────────────────────────────

        I'm curious about how you structure the business code (for
        want of a better word), in between the technical layers of
        talking to AMQP or an SQL store. Are there larger scale
        patterns like CQRS or DDD that you use to organise code?

  How do you package up code for deployment? Docker / AWS something.
  We're slowly migrating to a micro-service architecture (the pros and
  cons of which are outside the scope of this thread; that's a can of
  worms I'd rather not open…) whose cast of characters includes
  "entities" (responsible for storing/retrieving data from DBs), generic
  backend services that encapsulate business logic, frontend services,
  and backend-for-frontend services.

  We're using Docker for deployment on AWS (mostly), and slowly
  migrating from Docker Swarm to Kubernetes.


25 years of OCaml
═════════════════

  Archive: <https://discuss.ocaml.org/t/25-years-of-ocaml/7813/1>


Xavier Leroy announced
──────────────────────

  25 years ago, on May 9th 1996, release 1.00 of the Objective Caml
  language and system was announced:
  <https://sympa.inria.fr/sympa/arc/caml-list/1996-05/msg00003.html>

  It was already the consolidation of many years of work, integrating
  Jérôme Vouillon and Didier Rémy's work on objects and classes within
  Caml Special Light, itself a combination of my work on modules and
  native-code compilation with earlier code taken from Caml Light,
  especially Damien Doligez's GC.

  Little did I know that O(bjective) Caml would still be there 25 years
  later!

  A lot happened during this time, including several major evolutions of
  the language, and, much more importantly, the emergence of a community
  of users and an ecosystem of tools and libraries.  But maybe this was
  just the beginning for something even bigger?  We'll see…

  Happy birthday, OCaml!


David Allsopp replied
─────────────────────

  Most pleasingly, with a [very small number of patches], the Windows
  port still works in Visual Studio 2019:

  ┌────
  │ C:\Birthday>ocaml.exe
  │ 	Objective Caml version 1.00
  │ 
  │ #print_endline "Happy 25th Birthday, OCaml!";;
  │ Happy 25th Birthday, OCaml!
  │ - : unit = ()
  │ ##quit;;
  │ 
  │ C:\Birthday>type hooray.ml
  │ let rec hip_hip n =
  │   if n > 0 then
  │     let () = print_endline "hip hip! hooray!" in
  │     hip_hip (pred n)
  │ 
  │ let () = hip_hip 25
  │ C:\Birthday>ocamlopt -o hooray.exe hooray.ml
  │ 
  │ C:\Birthday>hooray
  │ hip hip! hooray!
  │ ...
  └────


[very small number of patches]
<https://github.com/dra27/ocaml/commits/25-years-of-ocaml>


On the OCaml Maling List, Roberto Di Cosmo also replied
───────────────────────────────────────────────────────

  Long live OCaml!

  Thanks Xavier, and to all the brilliant minds that contributed to the
  evolution and adoption of this beautiful language, and system, in this
  past quarter of a century.

  If I may add a personal note, one truly remarkable fact is that some
  rather complex code written in 1998 using OCaml 1.07 [1] could be
  compiled and run last year using OCaml 4.x *without modifications*:
  the only visible changes were the new warnings spotting potential
  issues in the code, thanks to the many improvements to the compiler
  over time.

  For the curious, all the details are here:
  <https://www.dicosmo.org/Articles/2020-ReScienceC.pdf>

  Cheers

  Roberto

  [1] that was the first version including support for marshalling
  closures, added in a fantastic one week-spring in Pisa exactly for
  this code :-)


OCaml compiler development newsletter, issue 1: before May 2021
═══════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-compiler-development-newsletter-issue-1-before-may-2021/7831/1>


gasche announced
────────────────

  I'm happy to introduce the first issue of the "OCaml compiler
  development newsletter". I asked frequent contributors to the OCaml
  compiler codebase to write a small burb on what they have been doing
  recently, in the interest of sharing more information on what people
  are interested in, looking at and working on.

  This is by no means exhaustive: many people didn't end up having the
  time to write something, and it's fine. But hopefully this can give a
  small window on development activity related to the OCaml compiler,
  structured differently from the endless stream of [Pull Requests] on
  the compiler codebase.

  (This initiative is inspired by the excellent Multicore
  newsletter. Please don't expect that it will be as polished or
  consistent :yo-yo: .)

  Note:

  • Feel free of course to comment or ask questions, but I don't know if
    the people who wrote a small blurb will be looking at the thread, so
    no promises.

  • If you have been working on the OCaml compiler and want to say
    something, please feel free to post! 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).


[Pull Requests] <https://github.com/ocaml/ocaml/pulls>

@dra27 (David Allsopp)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Compiler relocation patches now exist. There's still a few left to
  write, and they need splitting into reviewable PRs, but the core
  features are working. A compiler installation can be copied to a new
  location and still work, meaning that local switches in opam may in
  theory be renamed and, more importantly, we can cache previously-built
  compilers in an opam root to allow a new switch's compiler to be a
  copy. This probably won't be reviewed in time for 4.13, although it's
  intended that once merged opam-repository will carry back-ports to
  earlier compilers.

  A whole slew of scripting pain has lead to some possible patches to
  reduce the use of scripts in the compiler build to somewhat closer to
  none.

  FlexDLL bootstrap has been completely overhauled, reducing build time
  considerably. This will be in 4.13 (#[10135])


[10135] <https://github.com/ocaml/ocaml/pull/10135>


@nojb (Nicolás Ojeda Bär)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I am working on #[10159], which enables debug information in
  `-output-complete-exe' binaries. It uses [incbin] under Unix-like
  system and some other method under Windows.


[10159] <https://github.com/ocaml/ocaml/pull/10159>

[incbin] <https://github.com/graphitemaster/incbin>


@gasche (Gabriel Scherer)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I worked on bringing more PRs to a decision (merge or close). The
  number of open PRs has gone from 220-ish to 180, which feels nice.

  I have also contributed to @Ekdohibs' project [camlboot], which is a
  "bootstrap-free" implementation of OCaml able to compile the OCaml
  compiler itself. It currently targets OCaml 4.07 for various
  reasons. We were able to do a full build of the OCaml compiler, and
  check that the result produces bootstrap binaries that coincide with
  upstream bootstraps. This gives extremely strong confidence that the
  OCaml bootstrap is free from "trusting trust" attacks. For more
  details, see our [draft paper].


[camlboot] <https://github.com/Ekdohibs/camlboot>

[draft paper] <http://gallium.inria.fr/~scherer/drafts/camlboot.pdf>

with @Octachron (Florian Angeletti)
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  I worked with Florian Angeletti on deprecating certain command-line
  warning-specifier sequences, to avoid usability issues with (new in
  4.12) warning names. Before `-w -partial-match' disables warning 4,
  but `-w -partial' is interpreted as the sequence `w -p -w a -w r -w t
  -w i -w a -w l', most of which are ignored but `-w a' silences all
  warnings. Now multi-letter sequences of "unsigned" specifiers (`-p' is
  signed, `a' is unsigned) are deprecated. (We first deprecated all
  unsigned specifiers, but Leo White tested the result and remarked that
  `-w A' is common, so now we only warn on multi-letter sequences of
  unsigned specifiers.

  I am working with @Octachron (Florian Angeletti) on grouping signature
  items when traversing module signatures. Some items are "ghost items"
  that are morally attached in a "main item"; the code mostly ignores
  this and this creates various bugs in corner cases. This is work that
  Florian started in September 2019 with #[8929], to fix a bug in the
  reprinting of signatures. I only started reviewing in May-September
  2020 and we decided to do sizeable changes, he split it in several
  smaller changes in January 2021 and we merged it in April 2021. Now we
  are looking are fixing other bugs with his code (#[9774],
  #[10385]). Just this week Florian landed a nice PR fixing several
  distinct issues related to signature item grouping: #[10401].


[8929] <https://github.com/ocaml/ocaml/pull/8929>

[9774] <https://github.com/ocaml/ocaml/pull/9774>

[10385] <https://github.com/ocaml/ocaml/pull/10385>

[10401] <https://github.com/ocaml/ocaml/pull/10401>


@xavierleroy (Xavier Leroy)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I fixed #[10339], a mysterious crash on the new Macs with "Apple
  silicon".  This was due to a ARM (32 and 64 bits)-specific
  optimization of array bound checking, which was not taken into account
  by the platform-independent parts of the back-end, leading to
  incorrect liveness analysis and wrong register allocation.  #[10354]
  fixes this by informing the platform-independent parts of the back-end
  that some platform-specific instructions can raise.  In passing, it
  refactors similar code that was duplicating platform-independent
  calculations (of which instructions are pure) in platform-dependent
  files.

  I spent quality time with the Jenkins continuous integration system at
  Inria, integrating a new Mac Mini M1.  For unknown reasons, Jenkins
  ran the CI script in x86-64 emulation mode, so we were building and
  testing an x86-64 version of OCaml instead of the intended ARM64
  version.  A bit of scripting later (8b1bc01c3) and voilà, arm64-macos
  is properly tested as part of our CI.

  Currently, I'm reading the "safe points" proposal by Sadiq Jaffer
  (#[10039]) and the changes on top of this proposed by Damien Doligez.
  It's a necessary step towards Multicore OCaml, so we really need to
  move forward on this one.  It's a nontrivial change involving a new
  static analysis and a number of tweaks in every code emitter, but
  things are starting to look good here.


[10339] <https://github.com/ocaml/ocaml/pull/10339>

[10354] <https://github.com/ocaml/ocaml/pull/10354>

[10039] <https://github.com/ocaml/ocaml/pull/10039>


@mshinwell (Mark Shinwell)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I did a first pass of review on the safe points PR (#[10039]) and
  significantly simplified the proposed backend changes.  I've also been
  involved in discussions about a new function-level attribute to cause
  an error if safe points (including allocations) might exist within a
  function's body, to make code that currently assumes this robust.
  There will be a design document for this coming in due course.

  I fixed the random segfaults that were occurring on the RISC-V Inria
  CI worker (#[10349]).

  In Flambda 2 land we spent two person-days debugging a problem
  relating to Infix_tag!  We discovered that the code in OCaml 4.12
  onwards for traversing GC roots in static data ("caml_globals") is not
  correct if any of the roots are closures.  This arises in part because
  the new compaction code (#[9728]) has a hidden invariant: it must not
  see any field of a static data root more than once (not even via an
  Infix_tag).  As far as we know, these situations do not arise in the
  existing compiler, although we may propose a patch to guard against
  them.  They arise with Flambda 2 because in order to compile
  statically-allocated inconstant closures (ones whose environment is
  partially or wholly computed at runtime) we register closures directly
  as global roots, so we can patch their environments later.


[10039] <https://github.com/ocaml/ocaml/pull/10039>

[10349] <https://github.com/ocaml/ocaml/pull/10349>

[9728] <https://github.com/ocaml/ocaml/pull/9728>


@garrigue (Jacques Garrigue)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I have been working on a number of PRs fixing bugs in the type system,
  which are now merged:
  • #[10277] fixes a theoretical bug in the principality of GADT type
     inference (#[10383] applies only in -principal mode)
  • #[10308] fixes an interaction between local open in patterns and the
     new syntax for introducing existential type variables
  • #[10322] is an internal change using a normal reference inside of a
     weak one for backtracking; the weak reference was an optimization
     when backtracking was a seldom used feature, and was not useful
     anymore
  • #[10344] fixes a bug in the delaying of the evaluation of optional
     arguments
  • #[10347] cleans up some code in the unification algorithm, after a
     strengthening of universal variable scoping
  • #[10362] fixes a forgotten normalization in the type checking
     algorithm

  Some are still in progress:
  • #[10348] improves the way expansion is done during unification, to
     avoid some spurious GADT related ambiguity errors
  • #[10364] changes the typing of the body of the cases of
     pattern-matchings, allowing to warn in some non-principal
     situations; it also uncovered a number of principality related bugs
     inside the the type-checker

  Finally, I have worked with Takafumi Saikawa (@t6s) on making the
  representation of types closer to its logical meaning, by ensuring
  that one always manipulate a normalized view in #[10337] (large
  change, evaluation in progress).


[10277] <https://github.com/ocaml/ocaml/pull/10277>

[10383] <https://github.com/ocaml/ocaml/pull/10383>

[10308] <https://github.com/ocaml/ocaml/pull/10308>

[10322] <https://github.com/ocaml/ocaml/pull/10322>

[10344] <https://github.com/ocaml/ocaml/pull/10344>

[10347] <https://github.com/ocaml/ocaml/pull/10347>

[10362] <https://github.com/ocaml/ocaml/pull/10362>

[10348] <https://github.com/ocaml/ocaml/pull/10348>

[10364] <https://github.com/ocaml/ocaml/pull/10364>

[10337] <https://github.com/ocaml/ocaml/pull/10337>


@let-def (Frédéric Bour)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  For some time, I have been working on new approaches to generate error
  messages from a Menhir parser.

  My goal at the beginning was to detect and produce a precise message
  for the ‘let ;’ situation:
  ┌────
  │ let x = 5;
  │ let y = 6
  │ let z = 7
  └────
  LR detects an error at the third ‘let’ which is technically correct,
  although we would like to point the user at the ‘;’ which might be the
  root cause of the error. This goal has been achieved, but the
  prototype is far from being ready for production.

  The main idea to increase the expressiveness and maintainability of
  error context identification is to use a flavor of regular
  expressions.  The stack of a parser defines a prefix of a sentential
  form. Our regular expressions are matched against it. Internal details
  of the automaton does not leak (no reference to states), the regular
  language is defined by the grammar alone.  With appropriate tooling,
  specific situations can be captured by starting from a coarse
  expression and refining it to narrow down the interesting cases.

  Now I am focusing on one specific point of the ‘error message’
  development pipeline: improving the efficiency of ‘menhir
  –list-errors’.  This command is used to enumerate sentences that cover
  all erroneous situations (as defined by the LR grammar). On my
  computer and with the OCaml grammar, it takes a few minutes and quite
  a lot of RAM. Early results are encouraging and I hope to have a PR
  for Menhir soon. The performance improvement we are aiming for is to
  make the command almost real time for common grammars and to tackle
  bigger grammars by reducing the memory needs.  For instance, in the
  OCaml case, the runtime is down from 3 minutes to 2–3 seconds and
  memory consumption goes from a few GiB down to 200 MiB.


Daniel Bünzli asked and gasche replied
──────────────────────────────────────

        > […] @Ekdohibs’ project [camlboot ], which is a
          “bootstrap-free”
        > implementation of OCaml able to compile the OCaml
          compiler itself. It currently targets OCaml 4.07 for
          various
        > reasons. We were able to do a full build of the OCaml
          compiler, and check that the result produces bootstrap
        > binaries that coincide with upstream bootstraps. This
          gives extremely strong confidence that the OCaml
          bootstrap is
        > free from “trusting trust” attacks. For more details,
          see our [draft paper].

        Something that is not clear to me (but I read quickly) is
        the impact of `guile` itself being not bootstrapped yet.
        Could there be a *very* elaborate attack (with probability
        0 of existing) on both the guile and ocaml bootstrap or is
        there something in the whole scheme that prevents it ?

  Yes, currently Guile needs to be trusted, and it would be possible
  that a bootstrapping virus in Guile would break our correctness
  result. (It would need to reproduce itself through our compiler and
  interpreter that were written after Guile itself, but I think in
  theory this could be done with an almost-infinitely clever program
  analysis.) Of course, an attack at the source level (inserting
  malicious source, instead of malicious binaries) is also possible
  anywhere in the chain.  Our main reason for using Guile is that this
  is the high-level language community most active on
  debootstrapping-towards-the-metal (through the Guix connection), so we
  believe it is more likely to manage debootstrapping and maintain it in
  the longer run.

  (The seed that Guile depends on is its macro-expander, which is
  written using macros itself. In theory one may perform the
  macro-expansion of the expander, and then manually review the two
  versions to verify the absence of attack there.)


[camlboot ] <https://github.com/Ekdohibs/camlboot>

[draft paper] <http://gallium.inria.fr/~scherer/drafts/camlboot.pdf>


After so many years, I discover 'Str.bounded_full_split regexp str n'
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/after-so-many-years-i-discover-str-bounded-full-split-regexp-str-n/7838/1>


UnixJunkie said
───────────────

  This is so useful and powerful:
  ┌────
  │ #require "str";;
  │ Str.bounded_full_split (Str.regexp "[()]") "toto (titi, tata (et tutu)) vont au parc (en courant)" 1024;;
  │ - : Str.split_result list =
  │ [Str.Text "toto "; Str.Delim "("; Str.Text "titi, tata "; Str.Delim "(";
  │  Str.Text "et tutu"; Str.Delim ")"; Str.Delim ")"; Str.Text " vont au parc ";
  │  Str.Delim "("; Str.Text "en courant"; Str.Delim ")"]
  └────

  Still finding hidden pearls in the stdlib after so many years!
  :slight_smile:


Parser for the Scala programming language?
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/parser-for-the-scala-programming-language/7541/18>


Deep in this thread, Yoann Padioleau announced
──────────────────────────────────────────────

  I ended up porting the recursive descent parser in the Scala compiler
  to OCaml …  I think it was the fastest way to get a working parser
  from OCaml …

  <https://github.com/returntocorp/pfff/blob/develop/lang_scala/parsing/Parser_scala_recursive_descent.ml>


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: 43022 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-05-04  8:57 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-05-04  8:57 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of April 27 to May
04, 2021.

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

Ocaml-solidity, a new OCaml library for Solidity
Release of ocaml-pandoc 0.1.0
Stdlib vs Containers vs Batteries vs Base : Core functions comparison
Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central
ocaml-lsp-server 1.6.0
Other OCaml News
Old CWN


Ocaml-solidity, a new OCaml library for Solidity
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-solidity-a-new-ocaml-library-for-solidity/7746/2>


Continuing the thread from last week, Fabrice Le Fessant announced
──────────────────────────────────────────────────────────────────

  I should add that the project is now available in the opam-repository,
  see [solidity-parser] and [solidity-typechecker].


[solidity-parser] <https://opam.ocaml.org/packages/solidity-parser/>

[solidity-typechecker]
<https://opam.ocaml.org/packages/solidity-typechecker/>


Release of ocaml-pandoc 0.1.0
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-ocaml-pandoc-0-1-0/7759/1>


Samuel Mimram announced
───────────────────────

  I have just released [ocaml-pandoc], a native OCaml library to write
  filters for [pandoc], which is a markdown-to-anything converter. It
  has allowed me to write some simple filters I needed (such as for
  including code snippets, which is not supported natively).

  The support is not complete yet however, I might add more if needed
  (and pull-requests are of course accepted :slight_smile:).


[ocaml-pandoc] <https://github.com/smimram/ocaml-pandoc>

[pandoc] <https://pandoc.org/>


Stdlib vs Containers vs Batteries vs Base : Core functions comparison
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/stdlib-vs-containers-vs-batteries-vs-base-core-functions-comparison/7766/1>


Jp R announced
──────────────

  You want to compare the main core functions found in the OCaml Stdlib
  (v4.12.0), Containers (v3.3), Batteries (v3.3.0) and Base (v0.14.1)
  libraries ?

  Check it out !

  <https://github.com/Fourchaux/ocaml-stdlib-containers-batteries-base-comparisons>


Vladimir Keleshev then added
────────────────────────────

  Someone reading this might be also interested in my (less formal)
  comparison between OCaml Stdlib and Base:
  <https://gist.github.com/keleshev/764edad011a6a7a40da11716b19ddb75>


Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central
═════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/martin-jambon-presentation-on-semgrep-wed-april-21-7pm-central/7709/5>


Claude Jager-Rubinson announced
───────────────────────────────

  The recording of Martin's talk is now available:
  <https://hfpug.org/2021/05/01/martin-jambon-9-languages-how-we-built-semgrep-a-polyglot-static-analysis-tool/>


Martin Jambon then added
────────────────────────

  Thanks Claude! The talk [starts at 1:45].


[starts at 1:45] <https://www.youtube.com/watch?v=H6TgK-LMA4Y&t=105s>


Ryan Slade then said
────────────────────

  [Comby] may also be of interest, it's a similar project also written
  in OCaml.


[Comby] <https://comby.dev/>


ocaml-lsp-server 1.6.0
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-6-0/7774/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the ocaml-lsp team, I'd like to announce version 1.6.0 of
  ocaml-lsp-server. The highlight of this release is the updated version
  of merlin which brings lots of new bug fixes.


1.6.0 (04/30/2020)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Features
┄┄┄┄┄┄┄┄

  • Code action to annotate a value with its type (#397)


Fixes
┄┄┄┄┄

  • Fix interface/implementation switching on Windows (#427)

  • Correctly parse project paths with spaces and other special
    characters that must be escaped.

  • Print types with `-short-paths' even if the project wasn't built yet


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Cryptography updates in OCaml and MirageOS]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Cryptography updates in OCaml and MirageOS]
<https://hannes.nqsb.io/Posts/EC>


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: 17101 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-27 14:26 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-04-27 14:26 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

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

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

docs.ocaml.pro : an OCaml Documentation Hub
Decompress 1.4.0
elliptic curves - maintainable and verified (full stack, from primitives to TLS)
First release of Docteur, an opiniated read-only file-system for MirageOS
Ocaml-solidity, a new OCaml library for Solidity
Migrating to floatarray (blog post)
Old CWN


docs.ocaml.pro : an OCaml Documentation Hub
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-docs-ocaml-pro-an-ocaml-documentation-hub/7718/1>


Fabrice Le Fessant announced
────────────────────────────

  We are pleased to announce that we just published the first version of
  the OCaml Documentation Hub on:

  <https://docs.ocaml.pro>

  The OCaml Documentation Hub can be used to browse the sources and the
  documentations of more than 2000 opam packages, following links
  between them when useful. This is a work-in-progress, and we are
  working on improving it with many more features, such as source
  annotations with types, full-text and type-driven searches,
  improvements in the general readability of documentation, etc.

  The site is generated using an open-source tool called digodoc,
  available on:

  <https://github.com/OCamlPro/digodoc>

  Digodoc is able to build a map of an opam switch, with links between
  files, opam packages, ocaml libraries, meta packages and ocaml
  modules. It is also able to generate documentation using odoc with
  cross-indexes between all these kinds of packages.

  We welcome feedback and contributions!  Enjoy !


Simon Cruanes said and Anil Madhavapeddy added
──────────────────────────────────────────────

  Great work on this site, and I love the domain name as well ;-)

        The cross linking between packages is fantastic.

  As a bit of background on why documentation cross-linking has taken so
  long, there is a lonnnggg history intertwined with many people's
  contributions to opam, build systems (ocamlbuild and dune),
  conventions (findlib and odig) and of course [odoc] itself.  The major
  milestones along the way have been:

  • [odoc 1.0], first began in 2014 as a quick project to pull together
    typing information from cmt[i] files, but which ran into the problem
    that it needs a consistent set of compiled cmt files to actually
    work, and so needs help from external tools to pull that set of
    compiled libraries together.
  • [odig], which pulls together multiple opam packages (and a
    filesystem layout for metadata) and runs odoc on then. This allowed
    for the creation of <https://docs.mirage.io> a few years ago which
    cross-references a smaller number of packages
  • opam-repo itself has had better and better bulk builds over the
    years to ensure that we can actually automatically compile all the
    artefacts needed for docs builds, thanks to efforts like [health
    check] and [ocurrent].
  • odoc 2.0, which featured a multi-year [rewrite] of the OCaml module
    resolver and introduced a new [output IR].  This forthcoming release
    was presented in this [OCaml 2020 talk] by @jonludlam.

  And now with all these pieces in place, the OCaml documentation spring
  has arrived! The OCamlPro one posted here as the first of the "new
  batch" of mass documentation indexers, and I'm aware of concurrent
  efforts by the odoc/ocaml.org maintainer teams to push a central one
  out to ocaml.org, as well as by the MirageOS team who are refreshing
  docs.mirage.io with the latest and greatest.  I'm sure when the dust
  has settled on all these indexers we can look for common pieces, but
  for now it's lovely to see so much innovation happening at pace.

  For the community: now is the time to fix your docstrings in your
  libraries, as there will many cool tools parsing and processing them,
  and rendering them into all kinds of output formats!

  To the [odoc contributors], thank you! The journey to get to this
  documentation site started here seven years ago:

  ┌────
  │ commit ef91571cab31d9ece7af965ed52eaaff57a12efc
  │ Author: Leo White <lpw25@cl.cam.ac.uk>
  │ Date:   Thu Oct 16 19:20:18 2014 +0100
  │ 
  │     Initial commit
  └────

  @lefessan one thing I'm not sure about in your site is the "copyright
  library authors" claim. That's murky legal ground – it's worth
  establishing if the odoc HTML has gone through a compilation process
  and so is no longer copyright the authors (just as a binary output is
  not copyright the original source code). If the output _is_ copyright
  the authors, then they have reasonable grounds to claim that you
  should also reproduce the copyright notice and other license
  restrictions. Personally, I prefer to claim that there is no copyright
  to the original authors in odoc output, and sidestep this issue.


[odoc] <https://github.com/ocaml/odoc>

[odoc 1.0] <https://github.com/ocaml/odoc>

[odig] <https://github.com/dbuenzli/odig>

[health check] <https://github.com/ocurrent/opam-health-check>

[ocurrent] <https://github.com/ocurrent/overview>

[rewrite] <https://github.com/ocaml/odoc/pull/439>

[output IR] <https://github.com/ocaml/odoc/pull/423>

[OCaml 2020 talk] <https://www.youtube.com/watch?v=wVyZ-KveN-w&t=3s>

[odoc contributors] <https://github.com/ocaml/odoc/graphs/contributors>


Fabrice Le Fessant replied
──────────────────────────

  Thanks @avsm , all these projects were indeed important milestones
  towards the creation of this site. However, I wouldn't want this
  history perspective to give the wrong feeling that building this site
  was easy, it is the result of a very good, long and hard work by the
  team at OCamlPro to make it work despite a road paved with many
  obstacles. It also benefited from OCamlPro's long history of
  innovative projects for the OCaml community, that lead for example in
  the past to Opam, [Try-OCaml], Memprof/[Memthol,] [Opam-builder],
  [Learn-OCaml], the Typerex tools (ocp-indent, ocp-index, ocp-build,
  etc.) and more recently [opam-bin] and [drom].

  As I said, this is a work-in-progress, and there are many features
  that we will be adding in the next months to make this website much
  easier to navigate, for users to rapidely reach the information that
  matters for them. We hope it will be inspirational for all the other
  developers who are working on similar projects, and we are looking
  forward to using their projects soon too!


[Try-OCaml] <https://try.ocamlpro.com/>

[Memthol,]
<https://www.ocamlpro.com/2020/12/01/memthol-exploring-program-profiling/>

[Opam-builder] <https://hal.inria.fr/hal-01352008>

[Learn-OCaml] <https://github.com/ocaml-sf/learn-ocaml>

[opam-bin] <https://github.com/OCamlPro/opam-bin>

[drom] <https://github.com/OCamlPro/drom/>


Daniel Bünzli said
──────────────────

  I'd just like to stress that `odig' documents OCaml package installs
  regardless of the package manager used as long the install structure
  follows [these conventions] (which are automatically followed by [dune
  installs]) .

  Also for people using my packages, I'd just like to mention they may
  miss important documentation bits on [https://docs.ocaml.pro] until
  [that issue] is resolved.


[these conventions]
<https://erratique.ch/software/odig/doc/packaging.html>

[dune installs]
<https://dune.readthedocs.io/en/stable/opam.html#odig-conventions>

[https://docs.ocaml.pro] <https://docs.ocaml.pro/>

[that issue] <https://github.com/OCamlPro/digodoc/issues/33>


Much later in the thread, Kiran Gopinathan said
───────────────────────────────────────────────

  It's not quite the same as hoogle, but merlin has a functionality to
  search for functions by type signature - the feature doesn't seem to
  get much attention apparently - probably the interface is a little
  lacking, but with some extra elisp tuning, it can work quite smoothly:

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


Yawar Amin then added
─────────────────────

  The command line for this:

  ┌────
  │ ocamlmerlin single search-by-polarity -position 0 -query '-int +string'
  └────

  (To search for values of type `int -> string'.)


Decompress 1.4.0
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-decompress-1-4-0/7724/1>


Charles Edouard Lecat announced
───────────────────────────────

Greetings everyone,
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I am happy to announce the new release of [decompress 1.4.0],
  available for installation via OPAM. Decompress is a library
  containing a pure OCaml implementation of several compression
  algorithms:
  • RFC1951
  • Zlib
  • Gzip
  • LZO

  It's goal is to provide several algorithms for both the inflation and
  the deflation of objects, in the form of a stream API allowing to call
  the chosen algorithm one bit at a time. Such behavior allows for an
  easy use of decompress in situations where we would not be able to
  have the input in one go, or where we would like to output the result
  in a non blocking way. This new release comes with several
  improvements to the documentation and bug fixes, but even more, with a
  whole new implementation for the rfc 1951 and zlib algorithms.


[decompress 1.4.0]
<https://github.com/mirage/decompress/releases/tag/v1.4.0>


Non-stream implementation for rfc 1951 and zlib
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Up to this day, decompress was used in several projects like
  ocaml-git. However, as time passed by, it appeared that in some cases,
  the current implementation of decompress was not the optimal solution:
  As useful as a stream implementation is, it requires to save a lot of
  information about the state of the compression, in order to resume it
  once we have enough input.

  This is why, in some cases where we would be sure that we have our
  whole input in one go, we might want to avoid all of these side-costs,
  and directly go to the point.


State of the art: libdeflate
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  This new problematic in mind, we have started thinking about the
  existing implementations of these algorithms which were also bypassing
  the stream behavior. One implementation that proved to be a suitable
  example for our problem, was the library `libdeflate', an
  implementation in C. It's main advantages being: a better compression
  ratio than zlib and with faster runtime.

  It was used as the solid base for the OCaml implementation provided by
  this new release.


OCaml version of libdeflate, performances and use cases
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  Inheriting the logic of libdeflate, the new implementation now has a
  better compression ratio, while being slightly faster at it. On the
  other side, the decompression is way faster, with `33% of speed
  increase in most tested cases: On the ~book2' (from the Calgary
  corpus) file:
  • `decompress' (stream): 15 Mb/s (deflation), 76 Mb/s (inflation),
    ratio: 42.46 %
  • `decompress' (non-stream): 17 Mb/s (deflation), 105 Mb/s
    (inflation), ratio: 34.66 %

  Now that this is in place, the users of decompress will be able to
  choose between the two versions, according to their needs. In the case
  of ocaml-git, the vast majority of the git objects are small and will
  be compressed in one go. This is why we updated with the new
  implementation when possible.


Writing optimized code and profiling it
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  One of the biggest concerns of this release was to be able to produce
  optimized code. The base code being coded in C, a lot of sub-optimal
  behavior where ported in the OCaml version: `for' and `while' loops,
  references everywhere, mixes of `struct' and `union.', it needed a lot
  of clean up.

  This is why once the main iteration was done, we have spent several
  weeks profiling the code base, using the OCaml library `landmarks',
  `flamegraph' or simply the linux binary `perf'. This work, sometimes
  tedious, proved to be helpful and healthy for both the harmonization
  of the code and it's performances.


Decompress & MirageOS
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  Compression algorithms are a really important piece in many projects,
  and operating systems do not avoid this.  `decompress' was coded from
  the start with the idea of being used in the much larger project
  MirageOS.

  This release is another opportunity to broaden MirageOS’s reach, by
  providing one more algorithm to it’s stack, allowing us to specialise
  even more the unikernels that would have a need for
  inflation/deflation algorithms. This more restrictive implementation,
  as we need to have the whole input in one go, will allow us to take
  advantage of the situation and give more flexibility for the user.

  The positive aspects of this release will most likely show up soon
  enough, as we make use of decompress to its full potential


elliptic curves - maintainable and verified (full stack, from primitives to TLS)
════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-elliptic-curves-maintainable-and-verified-full-stack-from-primitives-to-tls/7729/1>


Hannes Mehnert announced
────────────────────────

  over the last month I worked on upgrading the cryptography stack for
  OCaml and MirageOS. I just published a [blog post]. Enhancments of
  [OCaml-TLS] ([usenix security paper from 2015]) and [X.509] are in
  place.

  The main achievement after TLS 1.3 support (since May 2020, 0.12.0) is
  that elliptic curve certificates are now supported. Elliptic curve
  cryptography uses [fiat]. The X509 implementation now supports PKCS 12
  (used by browsers and other software (e.g. OpenVPN) to bundle
  certificates and private keys).

  Get mirage-crypto-ec, x509 0.13.0 and tls 0.13.1 (all available in the
  opam-repository). Discussion and feedback appreciated.


[blog post] <https://hannes.robur.coop/Posts/EC>

[OCaml-TLS] <https://github.com/mirleft/ocaml-tls>

[usenix security paper from 2015] <https://usenix15.nqsb.io>

[X.509] <https://github.com/mirleft/ocaml-x509>

[fiat] <https://github.com/mit-plv/fiat-crypto>


First release of Docteur, an opiniated read-only file-system for MirageOS
═════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-docteur-an-opiniated-read-only-file-system-for-mirageos/7743/1>


Calascibetta Romain announced
─────────────────────────────

  I'm glad to announce the first release of [`docteur'], a simple tool
  to make and use (in read-only) a "file-system" for [MirageOS]. As you
  know, with MirageOS, we don't have _sockets_, _kernel space_ or even
  _file-descriptor_. It's not possible to manipulate files
  _standalonely_ and many _primitives_ commonly available with the
  `unix' module don't exists in our space.

  Therefore, it is difficult to imagine making a website that displays
  local files or a database system. But in our spirit of separation of
  services, it becomes possible for your unikernel to communicate over
  the network to a "file system" or a database.

  For quite some time we have been experimenting with a file system
  external to our unikernel called Git. This is the case of [`pasteur']
  which saves the pastes in a Git repository. It is also the case of
  [`unipi'] or [Canopy] which display the content of a Git repository
  and can resynchronize with it using a hook. Or the case of [our
  primary DNS server] whose zone file comes from a Git repository - we
  can then trace all the changes on this file.

  However, we have several limitations:
  1) it requires the Git repository to load into memory in your
     unikernel
  2) it requires a communication (external with GitHub or internal in a
     private network)

  The persistent aspect is very important. We should always be able to
  launch a unikernel and not lose the data if our system shuts down.

  The mutable aspect (modify a file) is useful in some cases but not in
  others. As for `unipi' for example (a simple static web site), the
  difference between resynchronizing with a hook or restarting the
  unikernel with a new version of your filesystem is minor.


[`docteur'] <https://github.com/dinosaure/docteur>

[MirageOS] <https://mirage.io/>

[`pasteur'] <https://github.com/dinosaure/pasteur>

[`unipi'] <https://github.com/roburio/unipi>

[Canopy] <https://github.com/Engil/Canopy>

[our primary DNS server] <https://github.com/roburio/dns-primary-git>

Docteur as a second solution
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This is where Doctor comes in. It solves both of our problems by
  offering the generation of a file system from scratch:
  • a Git repository (local or available on a service)
  • a specific folder

  Doctor is able to create a complete representation of a folder and to
  compress it at such a ratio that a generation of the documentation of
  several OPAM packages with all their versions making 14 Gb is reduced
  to an image of only 280 Mb!

  Such a high compression ratio is in particular due to a double level
  of compression by [`decompress'] and [`duff']. For more details,
  Docteur just generates a slightly modified PACK file with [carton].

  Then, Docteur proposes a simple library which makes available 2 ways
  to manipulate this image for your unikernel:
  1) a way that is fast but with a consequent boot time
  2) a slower way but with no cost to the boot time

  The first way will simply "analyze" the image to re-extract the layout
  of your file system. Then it uses the [ART data-structure] to save
  this layout. So, whenever you want a specific file and according to
  [ART benchmarks], you have access to the content very quickly.

  The problem remains the analysis which takes place at boot time and
  which can take a very long time (it depends essentially on the number
  of files you have). There can also be an impact on memory usage as the
  ART data structure is in memory - the more files there are, the bigger
  the structure is.

  The second method is more "silly". Each time you request a file, we
  will have to rebuild the entire path and therefore deserialize several
  objects (like folders). The advantage is that we don't analyze the
  image and we don't try to maintain a layout of your file system.


[`decompress'] <https://github.com/mirage/decompress>

[`duff'] <https://github.com/mirage/duff>

[carton] <https://github.com/mirage/ocaml-git/tree/master/src/carton>

[ART data-structure] <https://github.com/dinosaure/art>

[ART benchmarks] <https://dinosaure.github.io/art/bench/find.html>


Example
╌╌╌╌╌╌╌

  Docteur is meant to be simple. The generation of the image is done
  very simply by the command `make':
  ┌────
  │ $ docteur.make -b refs/heads/main https://github.com/dinosaure/docteur disk.img
  │ $ docteur.make -b refs/heads/main git@github.com:dinosaure/docteur disk.img
  │ $ docteur.make -b refs/heads/main git://github.com/dinosaure/docteur disk.img
  │ $ docteur.make -b refs/heads/main file://$(pwd)/dev/docteur disk.img
  └────

  Then, Docteur proposes 2 supports: Unix & [Solo5]. For Unix, you just
  have to name explicitly the image file to use. For the case of Solo5
  (and thus of virtualization). You just have to find a name for a
  "block device" and to reuse this name with the Solo5 "tender"
  specifying where the image is.
  ┌────
  │ $ cd unikernel
  │ $ mirage configure -t unix --disk disk.img
  │ $ make depends
  │ $ mirage build
  │ $ ./simple --filename README.md
  └────

  ┌────
  │ $ cd unikernel
  │ $ mirage configure -t hvt --disk docteur
  │ $ make depends
  │ $ mirage build
  │ $ solo5-hvt --block:docteur=disk.img -- simple.hvt --filename README.md
  └────

  Finally, Docteur proposes another tool that checks (and analyzes) an
  image to give you the version of the commit used (if the image comes
  from a Git repository) or the hash of your file system produced by the
  calculation of a [Merkle tree].
  ┌────
  │ $ docteur.verify disk.img
  │ commit	: ad8c418635ca6683177c7ff3b583e1ea5afea78f
  │ author	: "Calascibetta Romain" <romain.calascibetta@gmail.com>
  │ root	: bea10b6874f51e3f6feb1f9bcf3939933b2c4540
  │ 
  │ Merge pull request #11 from dinosaure/fix-tree-expanding
  │ 
  │ Fix how we expand our file-system
  └────


[Solo5] <https://github.com/Solo5/solo5>

[Merkle tree] <https://en.wikipedia.org/wiki/Merkle_tree>


Conclusion
╌╌╌╌╌╌╌╌╌╌

  Many times people ask me for a purpose in MirageOS such as a website
  or a particular service. I think that Docteur shows one essential
  thing about MirageOS, it is a tool and an ecosystem. But it's not an
  endpoint that is concretized in a specific application.

  Docteur is not THE solution to our problems and answers a specific use
  case. What is important to note is not what Docteur does but the
  possibility for our ecosystem and our tools to allow the development
  of Docteur. As it allows the development of a trillion applications!

  As such, I say to those people to "play" with MirageOS if they want to
  learn more. Our goal is not to show you applications that you could
  then deploy easily (even if we are working on this aspect too) but to
  give you the possibility to imagine your OS (independently from our
  vision)!

  And if you try, we'll be happy to help you!


Ocaml-solidity, a new OCaml library for Solidity
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-solidity-a-new-ocaml-library-for-solidity/7746/1>


OCamlPro announced
──────────────────

  We are pleased to announce our new OCaml library, ocaml-solidity !
  [Ocaml-solidity] is a program manipulation library that provides a
  Solidity parser and typechecker.

  Our library is made for developers on Solidity code analysis, it
  builds a typechecked AST that can be analyzed with a provided
  visitor. Please note that our parser and typecheck conforms mostly to
  Solidity 0.7, inline assembly is not supported. Take a look at [our
  documentation].

  You can test it and report bugs just [here]!


[Ocaml-solidity] <https://github.com/OCamlPro/ocaml-solidity>

[our documentation] <https://ocamlpro.github.io/ocaml-solidity/>

[here] <https://github.com/OCamlPro/ocaml-solidity/issues>


Migrating to floatarray (blog post)
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/migrating-to-floatarray-blog-post/7749/1>


Nicolás Ojeda Bär announced
───────────────────────────

  At LexiFi we recently migrated our codebase to use `floatarray' in
  place of `float array' in order to disable the "flat float array" mode
  in the compiler. If you are interested in finding out more about how
  we did it, we wrote a blog post about it
  <https://www.lexifi.com/blog/ocaml/floatarray-migration/>. Enjoy!


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: 38337 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-20  9:07 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-04-20  9:07 UTC (permalink / raw)
  To: lwn, cwn, caml-list

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

Hello

Here is the latest OCaml Weekly News, for the week of April 13 to 20,
2021.

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

Preface (initial release)
OCaml Users and Developers Workshop 2021
Timere 0.1.3 - Dealing with time and time zones has never been easier
Release of `multipart_form.0.2.0'
Engineer position for the development of the Squirrel prover
Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central
Old CWN


Preface (initial release)
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-preface-initial-release/7669/1>


Xavier Van de Woestyne announced
────────────────────────────────

  Hello, @d-plaindoux and @pytre and I are very happy to present
  *Preface*, a project that has occupied part of our free time for
  almost 2 years. We received a lot of help from various people (as
  mentioned in the [CREDITS] page), including some present on this forum
  (@gasche, @octachron and @snowleopard)

        Preface is an opinionated library designed to facilitate
        the handling of recurring functional programming idioms in
        [OCaml]. Many of the design decisions were made in an
        attempt to calibrate, as best as possible, to the OCaml
        language. Trying to get the most out of the module
        language. *The name "preface" is a nod to "Prelude"* .

  • [Github repository]
  • [Online documentation]


[CREDITS]
<https://github.com/xvw/preface/blob/master/CREDITS.md#warm-thanks-and-help>

[OCaml] <https://ocaml.org>

[Github repository] <https://github.com/xvw/preface>

[Online documentation]
<https://ocaml-preface.github.io/preface/Preface/index.html>

About the project, and motivation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  When learning functional programming, one is often confronted with
  constructs derived (or not) from category theory.  Languages such as
  Haskell offer very complete libraries to use them, and thus,
  facilitate their learning. In OCaml, it often happens that these
  abstractions are buried in the heart of certain libraries/projects
  ([Lwt], [Cmdliner], [Bonsai], [Dune] etc.). This is why one of the
  objectives of Preface is to propose tools for concretising these
  abstractions, at least as a pedagogical tool.


[Lwt] <https://ocsigen.org/lwt/latest/manual/manual>

[Cmdliner] <https://erratique.ch/logiciel/cmdliner>

[Bonsai] <https://github.com/janestreet/bonsai>

[Dune] <https://dune.build>


Is Preface useful
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Since OCaml allows for efficient imperative programming, Preface is
  probably not really useful for building software.  However, we (the
  maintainers) think that Preface can be useful for a few things:

  • technical experimentation with abstractions (especially those from
    the Haskell world) that allow programming in a fun style.
  • As an educational tool. Many teaching aids generally only offer the
    minimal interfaces to these abstractions. Preface tries to be as
    complete as possible.
  • It was a lot of fun to make. The last point is obviously the
    lightest but building Preface was really fun! So even if some people
    won't see the point… *we had fun making it*!

  Let's imagine this scenario! Oh, there's this article that seems to
  describe quite precisely how to solve `this complex problem',
  elegantly, using this `collection of abstractions'. After reading, the
  article is clear and I know how to use this `collection of
  abstractions' in practice. I would like to test it. Not having enough
  RAM to install Cabal, I decided to do it in OCaml. But as one
  abstraction leads to another, I am obliged to build an armada of
  things and I abandon my experimentation.

  So now, rather than doing it, locally, for the understanding of an
  article, I add it in Preface.


Additional links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The [README] is quite expansive on motivations and some design
  choices, but we have tried to add some concrete guides:
  • [ Understanding the module breakdown of Preface]
  • [Effect handling using Freer]
  • [Error handling with Result/Validation and a Free Applicative]

  And in addition here is a project, by a friend of ours, that uses
  Preface, to build static blog generators (very original isn't it :P),
  the code is highly documented and can be an entry point into how to
  use it: [Github repository of the project]


[README] <https://github.com/xvw/preface#preface>

[ Understanding the module breakdown of Preface]
<https://github.com/xvw/preface/blob/master/guides/option_instantiation.md>

[Effect handling using Freer]
<https://github.com/xvw/preface/blob/master/guides/freer_effect_handling.md>

[Error handling with Result/Validation and a Free Applicative]
<https://github.com/xvw/preface/blob/master/guides/error_handling.md>

[Github repository of the project]
<https://github.com/xhtmlboi/wordpress>


Conclusion
╌╌╌╌╌╌╌╌╌╌

  Preface does not offer much that is new, but we have tried to make it
  user-friendly and to document as much as possible the code and design
  choices. It's a lot of fun to build… and it will probably be just as
  much fun to maintain.

  *We are extremely open to contributions and feedback.*

  And my last words will be a warm thank you to the OCaml ecosystem that
  has facilitated so much of our development: Testing with [Alcotest]
  and [QCheck] is a pleasure. [Dune] is a fast and pleasant build
  system. [ODoc] has allowed us to have more control over the generation
  of documentation, especially with the `@inline' comment (on includes)
  which allows signatures from different modules to be merged. And [MDX]
  which I did not know at all and which is used extensively for guides.

  I hope you can find interest in this project! Good luck with the rest
  of the containment (for those concerned).


[Alcotest] <https://github.com/mirage/alcotest>

[QCheck] <https://github.com/c-cube/qcheck>

[Dune] <https://dune.build>

[ODoc] <https://github.com/ocaml/odoc>

[MDX] <https://github.com/realworldocaml/mdx>


OCaml Users and Developers Workshop 2021
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-users-and-developers-workshop-2021/7673/1>


Frédéric Bour announced
───────────────────────

  It is my pleasure to invite submissions to the OCaml Users and
  Developers Workshop 2021, which is again co-located with ICFP and will
  be held virtually this year.

  The OCaml Users and Developers Workshop brings together industrial
  users of OCaml with academics and hackers who are working on extending
  the language, type system, and tools. Previous editions have been
  co-located with ICFP 2012 in Copenhagen, ICFP 2013 in Boston, ICFP
  2014 in Gothenburg, ICFP 2015 in Vancouver, ICFP 2016 in Nara, ICFP
  2017 in Oxford, ICFP 2018 in St Louis, ICFP 2019 in Berlin, and was
  virtual for ICFP 2020, following the OCaml Meetings in Paris in 2010
  and 2011.


Important Links
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • [https://icfp21.sigplan.org/home/ocaml-2021 ]
  • [https://ocaml2021.hotcrp.com ]


[https://icfp21.sigplan.org/home/ocaml-2021 ]
<https://icfp21.sigplan.org/home/ocaml-2021>

[https://ocaml2021.hotcrp.com ] <https://ocaml2021.hotcrp.com>


Important dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Thursday 20th May (any time zone): Abstract submission deadline
  • Friday 18th July: Author notification
  • Friday 27th August: OCaml Workshop


Scope
╌╌╌╌╌

  Presentations and discussions focus on the OCaml programming language
  and its community. We aim to solicit talks on all aspects related to
  improving the use or development of the language and its programming
  environment, including, for example (but not limited to):

  • compiler developments, new backends, runtime and architectures
  • practical type system improvements, such as GADTs, first-class
    modules, generic programming, or dependent types
  • new library or application releases, and their design rationales
  • tools and infrastructure services, and their enhancements
  • prominent industrial or experimental uses of OCaml, or deployments
    in unusual situations.


Presentations
╌╌╌╌╌╌╌╌╌╌╌╌╌

  Presentations will be held in the online format. Each presentation
  comprise a prerecorded presentation and an interactive live Q&A
  session after the talk. Each talk will be re-translated three times in
  different time zones.  Session chairs and volunteers will assist the
  authors in preparing and casting the presentation. Each presentation
  will be made available through the ocaml.org website.


Submission
╌╌╌╌╌╌╌╌╌╌

  To submit a presentation, please register a description of the talk
  (about 2 pages long) at <https://ocaml2021.hotcrp.com/> providing a
  clear statement of what will be provided by the presentation: the
  problems that are addressed, the solutions or methods that are
  proposed.

  LaTeX-produced PDFs are a common and welcome submission format. For
  accessibility purposes, we ask PDF submitters to also provide the
  sources of their submission in a textual format, such as .tex
  sources. Reviewers may read either the submitted PDF or the text
  version.


Camera ready presentations
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  A pre-recorded versions of accepted presentation shall be provided
  before August, 13th. Volunteers will provide technical assistance to
  authors as well as provide necessary feedback and ensure that all
  videos match our quality standards.


ML family workshop
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The ML family workshop, held on the previous day, deals with general
  issues of the ML-style programming and type systems, focuses on more
  research-oriented work that is less specific to a language in
  particular. There is an overlap between the two workshops, and we have
  occasionally transferred presentations from one to the other in the
  past. Authors who feel their submission fits both workshops are
  encouraged to mention it at submission time and/or contact the Program
  Chairs.


Program Commitee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Frédéric Bour, Tarides, France
  • Cristina Rosu, Janestreet, UK
  • Hakjoo Oh, Korea University, Korea
  • Hugo Heuzard, Janestreet, UK
  • Jeffrey A. Scofield, Formalsim, USA
  • Jonathan Protzenko, MSR, USA
  • Joris Giovanangeli, Ahrefs, Singapore
  • Jun Furuse, Dailambda, Japan
  • Kihong Heo, KAIST, Korea
  • Kate Deplaix, OCaml Labs, UK
  • Medhi Bouaziz, Nomadic Labs, France
  • Simon Castellan, INRIA, France
  • Ryohei Tokuda, Idein, Japan
  • Vaivaswatha Nagaraj, Zilliqa, India
  • Youyou Cong, Tokyo Institute of Technology, Japan


Questions and contact
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Please contact the PC Chair ([Frédéric Bour]) for any questions.


[Frédéric Bour] <mailto:frederic.bour@lakaban.net>


Timere 0.1.3 - Dealing with time and time zones has never been easier
═════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-timere-0-1-3-dealing-with-time-and-time-zones-has-never-been-easier/7173/2>


Darren announced
────────────────

  Timere 0.2.1 has landed!

  This release adds nanosecond precision support to timere (and
  fractional second support at various places), along with other small
  improvements.


Release of `multipart_form.0.2.0'
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-multipart-form-0-2-0/7704/1>


Calascibetta Romain announced
─────────────────────────────

  I am pleased to announce the release of [`multipart_form']. Throughout
  the development of [mrmime], we have gained a thorough knowledge of
  the RFCs about email. However, these RFCs also describe mechanisms
  that are found in HTTP/1.1.


[`multipart_form'] <https://github.com/dinosaure/multipart_form>

[mrmime] <https://github.com/mirage/mrmime>

Genesis
╌╌╌╌╌╌╌

  More specifically, a lot of work has been done on [RFC 2045] & [RFC
  2046] (see [RFC 7578 § 4]) which describe the `multipart' format
  (found in emails and in `HTTP/1.{0,1}' requests when serializing a
  `<form>').

  From this work (~ 2 years), we decided to extract the parts allowing
  to manipulate a `multipart/form-data' content for `HTTP/1.{0,1}'
  responses (plus [RFC 2183]). This resulted in the creation of
  `multipart_form'.

  This project is a cross between what many users have been waiting for
  (for [CoHTTP] and [http/af]), a knowledge of what exists and its
  limitations, and finally a development in the spirit of MirageOS.

  The result is an API that is _"full stream"_. Indeed. a question arose
  from the beginning, how to manipulate this format while:
  • not having access to a file system (MirageOS)
  • not exploding memory usage for file uploads


[RFC 2045] <https://tools.ietf.org/html/rfc2045>

[RFC 2046] <https://tools.ietf.org/html/rfc2046>

[RFC 7578 § 4] <https://tools.ietf.org/html/rfc7578#section-4>

[RFC 2183] <https://tools.ietf.org/html/rfc2183>

[CoHTTP] <https://github.com/mirage/ocaml-cohttp>

[http/af] <https://github.com/inhabitedtype/httpaf>


Memory bound implementation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  With the help of @Armael and the [`memtrace'] tool, we were able to
  implement and extend `multipart_form' so that it is easier to use and
  really ensures our original assumption about memory consumption.

  So we experimented with use cases like uploading very large
  files. Here is the result that `memtrace' gives us with a 100Mb file:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/92ee2ab6fa1d4da62d894749aa4b161a95b53fb2_2_1034x590.png>

  The application tries to save the games in files. We use [opium] (and
  thus http/af) but tests were also done with CoHTTP. The code is
  available [here] for people who want to reproduce.


[`memtrace']
<https://blog.janestreet.com/finding-memory-leaks-with-memtrace/>

[opium] <https://github.com/rgrinberg/opium>

[here]
<https://gist.github.com/dinosaure/299c421c95cec4255df7b9289eb53815>


Documentation & encoding
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Finally, a major effort has been made in the documentation to explain
  in detail how to use `multipart_form'. Version `0.2.0' also adds a way
  to produce a `multipart/form-data' document (experimental) with the
  same constraints on memory usage.

  I hope this work will be useful to a lot of people. The documentation
  is available [here].


[here]
<https://dinosaure.github.io/multipart_form/multipart_form/index.html>


Engineer position for the development of the Squirrel prover
════════════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-04/msg00022.html>


David Baelde announced
──────────────────────

  We are looking for an engineer to support the development of Squirrel,
  an interactive theorem prover for security protocols. The position
  will be funded by ERC POPSTAR. You may find more details here:

  <https://people.irisa.fr/Stephanie.Delaune/internship/sujet-engineer-squirrel.pdf>

  Skilled OCaml developers would be most welcome!


Martin Jambon presentation on Semgrep, Wed April 21 @ 7pm Central
═════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/martin-jambon-presentation-on-semgrep-wed-april-21-7pm-central/7709/1>


Claude Jager-Rubinson announced
───────────────────────────────

  Please join us this coming Wednesday at 7pm Central when @mjambon will
  talk about Semgrep, an open-source ployglot static analysis tool
  written in OCaml.

  Details and connection info are available at [Houston Functional
  Programmers].


[Houston Functional Programmers] <https://hfpug.org>


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: 30654 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-04-06  9:42 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-04-06  9:42 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of March 30 to April
06, 2021.

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

Ecosystem Engineer and Technical Writer positions
Release of cohttp 4.0.0
Timere-parse 0.0.2, natural language parsing of date, time and duration
agrid 0.1
State of OCaml and web assembly
containers 3.3
New OCaml books?
Old CWN


Ecosystem Engineer and Technical Writer positions
═════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-ecosystem-engineer-and-technical-writer-positions/7571/1>


Celine announced
────────────────

  [Tarides] is hiring an [Ecosystem Engineer] and a [Technical Writer].

  Tarides is a tech startup based in Paris and founded in 2018. We
  develop a software infrastructure platform to deploy secure,
  distributed applications with strict resource contraints and
  low-latency performance requirements.

  We welcome applications from people of all backgrounds. We are working
  hard to create a representative, inclusive and friendly team, because
  we know that different experiences, perspectives and backgrounds make
  for a better place.

  Please, don't hesitate to contact me if you have any question, I'll be
  more than happy to reply! :)


[Tarides] <https://tarides.com/>

[Ecosystem Engineer] <https://tarides.com/jobs/ecosystem-engineer>

[Technical Writer] <https://tarides.com/jobs/technical-writer>


Release of cohttp 4.0.0
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537/2>


Continuing this thread, Calascibetta Romain said
────────────────────────────────────────────────

        The work on the new conduit is steadily progressing and
        will be integrated in a new major release of cohttp in the
        future, once we will be confident that the API is
        settled. If you want to try using it immediately, then it
        is available as the [mimic ] library in ocaml-git.

  I just take the opportunity to show up a tutorial about `mimic' which
  is now available into the distribution of it: see [here]. Thanks for
  your work about the release process.


[mimic ] <https://github.com/mirage/ocaml-git/tree/master/src/mimic>

[here] <https://mirage.github.io/ocaml-git/mimic/index.html>


Timere-parse 0.0.2, natural language parsing of date, time and duration
═══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-timere-parse-0-0-2-natural-language-parsing-of-date-time-and-duration/7532/2>


Continuing this thread, Darren said
───────────────────────────────────

  The demo site has been updated to use Timere-parse, you can now try
  interacting with `Timere_parse.timere' in web browser at
  <https://daypack-dev.github.io/timere-parse-demo/>


agrid 0.1
═════════

  Archive: <https://discuss.ocaml.org/t/ann-agrid-0-1/7587/1>


zapashcanon announced
─────────────────────

  I'm pleased to announce the first release of [agrid].

  Agrid stands for *Adjustable Grid*. Adjustable grids are basically two
  dimensional arrays whose width/height can be changed by adding or
  removing row/column at either end (one at a time).

  Here's a very short example :

  ┌────
  │ let () =
  │   let grid = Agrid.of_list [[1; 2]; [3; 4]] in
  │   let grid = Agrid.snoc_row grid (Flex_array.of_list [5; 6]) in
  │   Agrid.pp Format.pp_print_int Format.std_formatter grid
  │   (* prints:
  │    * 1; 2
  │    * 3; 4
  │    * 5; 6
  │    *)
  └────

  It's based on the great [flex-array] library by [Jean-Christophe
  Filliâtre] and is mainly a wrapper around it to make it easier for the
  special case of two dimensional arrays.

  It's been developped at [OCamlPro] while working on [mosaic] when we
  wanted to ease the dataset input process, switching from a basic
  textarea based input to something which looks like a spreadsheet (this
  work is not yet published on the online version).


[agrid] <https://ocamlpro.github.io/agrid>

[flex-array] <https://github.com/backtracking/flex-array>

[Jean-Christophe Filliâtre] <https://www.lri.fr/~filliatr/>

[OCamlPro] <https://www.ocamlpro.com/>

[mosaic] <https://mosaic.univ-lyon1.fr/>


gasche asked and zapashcanon replied
────────────────────────────────────

        Out of curiosity: In a spreadsheet, I would assume that
        inserting/removing rows or columns in the middle is also a
        useful operation. Would you be able to add this operation?

  It's not really a spreadsheet, it's more something [like this]. I
  don't think it would be really useful in the case of mosaic because
  for big inputs, users are more likely to import the data from a file.

  Anyway, it's possible to add this operation, but I can't think of an
  efficient way to do it. I'll think about it and may add such an
  operation. Actually, if it's added to flex-array, it would be trivial
  to add it to agrid, so I'll probably try to add it there.


[like this] <https://www.zapashcanon.fr/~leo/atable/>


State of OCaml and web assembly
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/state-of-ocaml-and-web-assembly/2725/15>


Deep in this thread, Emilio Jesús Gallego Arias announced
─────────────────────────────────────────────────────────

  Yup, we didn't make it yet the "official" release, but it has been
  used by quite a few people to avoid lack of tail-call optimization in
  jsoo, live versions:
  • <https://jscoq.github.io/wa/>
  • <https://jscoq.github.io/wa/scratchpad.html>

  It literally flies.

  I guess @corwin-of-amber is the right person to comment more on his
  superb efforts.


Shachar Itzhaky then added
──────────────────────────

  Hi there @camarick; ocaml-wasm is very much bleeding-edge but it
  already works surprisingly well and I have used it to run Coq,
  esp. for the purpose of making the interactive version of Vols. I,II
  from the Software Foundations textbook (see
  <https://jscoq.github.io/ext/sf> and
  <https://jscoq.github.io/ext/sf/tools/jscoq-tester.html>).

  Of course @ejgallego is exaggerating when he says that it flies, it
  still runs OCaml bytecode in interpreted mode on top of the WASM
  JIT. Performance is pretty reasonable still, except in the case some
  intensive Coq tactics (in which case this is a third level of
  interpreter… :man_facepalming: ). The main gap right now is the
  standard libraries `str', `unix', and `threads', for which I have
  compiled empty stubs, because dynamic loading of libraries in WASI is
  still immature. I *have* been able to compile `num' and it works
  correctly because it does not depend on anything else. I am currently
  investigating how to build `zarith' (which requires `gmp') because Coq
  8.13 depends on it.

  So yeah, this is not at all the coveted WASM backend for `ocamlc', but
  it's one existing solution and you can hack on it right now. Any help
  or comments are welcome!


containers 3.3
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-containers-3-3/7594/1>


Simon Cruanes announced
───────────────────────

  I'm glad to announce the release of containers 3.3. Containers is an
  extension to OCaml's standard library that strives to be compatible
  with it, with more features and a few additional modules to get
  dynamic arrays, heaps, S-expression parser/printer, etc.

  In this release, we have new support for parsing/printing canonical
  S-expressions (a simple binary-safe format), a code-generation module
  for bitfields, and many improvements to existing modules in particular
  in the interface between maps/set/hashtbl and iterators.

  More details [in the github release].

  Many thanks to the contributors, in particular @Fardale for his work
  on CI and auto-doc-generation.


[in the github release]
<https://github.com/c-cube/ocaml-containers/releases/tag/v3.3>


New OCaml books?
════════════════

  Archive: <https://discuss.ocaml.org/t/new-ocaml-books/5789/6>


Deep in this thread, Damien Guichard announced
──────────────────────────────────────────────

  I’m also working on a free culture book. The preview is at
  <https://damien-guichard.developpez.com/downloads/Algorithmic-with-OCaml.pdf>

  It’s under CC-BY-SA.

  Planned chapters include : Records, Type polymorphism, Modules as
  functions, Conceptual graphs.

  The reason why i don't contribute to @dmbaturin's effort is that my
  main topic is algorithmic, ocaml is more a good way than a goal.


Damien Guichard later added
───────────────────────────

  Sorry, you have to be a member of <https://www.developpez.com/> to
  access this link.

  Here is my 2nd try. I hope you don't need to be a member of
  <https://www.aeriesguard.com/> this time.
  <https://www.aeriesguard.com/media/get/504bfbe34d3f517c8acf37ffbe200f84698aca0c/Algorithmic-with-_OCaml.pdf>


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: 23290 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-30 14:55 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-03-30 14:55 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of March 23 to 30,
2021.

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

Theorem Proving with Coq and Ocaml
ocaml-aws 1.2
Release of `fmlib.0.2.0'
soupault: a static website generator based on HTML rewriting
Timere-parse 0.0.2, natural language parsing of date, time and duration
ocamlnet-4.1.9
Release of cohttp 4.0.0
New Try-Alt-Ergo website
Other OCaml News
Old CWN


Theorem Proving with Coq and Ocaml
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/theorem-proving-with-coq-ocaml/7524/1>


Gregory Malecha announced
─────────────────────────

  I lead the formal methods team at Bedrock Systems
  (<https://bedrocksystems.com>) and we are looking to hire a full-time
  engineer working on automation in the Coq proof assistant (which is
  written in Ocaml). We're very interested in candidates with strong
  Ocaml background especially in topics related to automated theorem
  proving, e.g. SAT/SMT solvers, datalog, superposition, resolution,
  etc. While Coq experience is great, you do not need to be a Coq expert
  to apply to this position, we're happy to marry your Ocaml expertise
  with our Coq expertise.

  Formal methods are at the core of BedRock's business and we are deeply
  committed to solving problems of system verification at industrial
  scale. We get FM techniques and insights into the code early on and
  use them to build, maintain, and evolve code. This includes developing
  more agile techniques to keep evolving verified systems once they're
  built.

  We have eight folks on the formal methods team today, hailing from
  MPI-SWS, MIT CSAIL, Princeton, and other leading research groups. If
  you're interested, send me an email or you can inquire more broadly at
  jobs@bedrocksystems.com.

  *Company overview:*

  BedRock is building a *trustworthy compute base for mission-critical
  applications* . The foundation of the platform is an open source,
  multi-core, capability-based micro-hypervisor that we are developing
  and verifying. On top of these deep specifications we are writing and
  verifying applications to provide an extensible and configurable core.

  Our contention is that the *time is ripe for verifiably trustworthy
  systems*, for everything from secure phones and industrial IoT to
  autonomous systems and financial infrastructure. With significant seed
  funding, great investors, and commercial projects underway, we are
  growing our team in Boston, the Bay Area, DC, and Germany.


ocaml-aws 1.2
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocaml-aws-1-2/7526/1>


Tim Mc Gilchrist announced
──────────────────────────

  I'm pleased to announce the release of [ocaml-aws] 1.2.

  ocaml-aws aims to provide generated bindings to many AWS services
  using the botocore specifications. In this version we've bumped
  version bounds on a bunch of depedencies and also added new bindings
  for:
  • RDS
  • Route53
  • SDB
  • SQS

  Please check it out and report any issues.


[ocaml-aws] <https://opam.ocaml.org/packages/aws/>


Release of `fmlib.0.2.0'
════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-fmlib-0-2-0/7527/1>


Hbr announced
─────────────

  I am pleased to announce the second release (0.2.0) of fmlib, a
  functional library with managed effects.

  The library has up to now 4 components:

  • [Some standard datatypes]
  • [Pretty printing functions]
  • [Parsing combinator library]
  • [Primitives to compile to javascript]

  The last component is the new one in version 0.2.0. Internally it uses
  `js_of_ocaml' to compile to javascript. It is an easy to use library
  of primitive functions to access mainly browser functionality from
  ocaml and some rudimentary functions to access nodejs functionality.

  It can be installed via opam by

  ┌────
  │ opam update
  │ opam install fmlib
  │ opam install fmlib_js
  └────

  It is located at [github]


[Some standard datatypes]
<https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_std/index.html>

[Pretty printing functions]
<https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_pretty/Print/index.html>

[Parsing combinator library]
<https://hbr.github.io/fmlib/odoc/fmlib/Fmlib_parse/index.html>

[Primitives to compile to javascript]
<https://hbr.github.io/fmlib/odoc/fmlib_js/index.html>

[github] <https://github.com/hbr/fmlib>


Hbr added
─────────

  Hint: `fmlib' is still a bundle of three libraries i.e. three toplevel
  modules `Fmlib_std', `Fmlib_pretty' and `Fmlib_parse'. Therefore they
  have to be used in a `dune' file with

  ┌────
  │ (libraries fmlib.fmlib_std fmlib.fmlib_pretty fmlib.fmlib_parse ...)
  └────

  while the new library can be used with

  ┌────
  │ (libraries fmlib_js ...)
  └────

  This inconvenience will be corrected in the next release.


soupault: a static website generator based on HTML rewriting
════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-soupault-a-static-website-generator-based-on-html-rewriting/4126/14>


Daniil Baturin announced
────────────────────────

  [soupault 2.5.0] offers some features that are unique among SSGs.

  There are two new built-in widgets for rewriting internal links, which
  is useful if you don't host your website at the server root. For
  example, if you host it at `example.com/~user', you cannot just write
  `<img src="/header.png">': it will point to `example.com/header.png'
  while you want `example.com/~user/header.png' instead.

  The `relative_links' widget will convert all internal links to
  relative links according to their depth in the directory tree. For
  example, suppose you have `<img src="/header.png">' in your page
  template. Then in `about/index.html' that link will become `<img
  src="../header.png">'; in `books/magnetic-fields/index.html' it will
  be `<img src="../../header.png">' and so on. This way you can move the
  website to a subdirectory and it will still work.

  The `absolute_links' widget prepends a prefix to every internal
  link. Conceptually similar to the site URL option in other SSGs and
  CMSes, but works for all links, not only links generated by the SSG
  itself.


[soupault 2.5.0] <https://soupault.app/blog/soupault-2.5.0-release/>


Timere-parse 0.0.2, natural language parsing of date, time and duration
═══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-timere-parse-0-0-2-natural-language-parsing-of-date-time-and-duration/7532/1>


Darren announced
────────────────

  I'm happy to announce the release of Timere-parse 0.0.2, the natural
  language parsing component of Timere, a date time handling and
  reasoning library. Both packages are under the [Timere repo].

  Timere-parse allows interpretation of common descriptions of date,
  time and duration.


[Timere repo] <https://github.com/daypack-dev/timere>

Date time examples
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Input strings are in `""', indented lines are pretty printed output.

  ┌────
  │ "2020 jun 6 10am"
  │   Ok 2020-06-06T10:00:00Z
  │ "2020 jun 6th 10:15"
  │   Ok 2020-06-06T10:15:00Z
  │ "Australia/Sydney 2020 jun 6 10am"
  │   Ok 2020-06-06T10:00:00+10:00
  │ "01-06-2020 10:10"
  │   Ok 2020-06-01T10:10:00Z
  │ "2020/06/01 10am"
  │   Ok 2020-06-01T10:00:00Z
  │ "jul 6 2021 9:15am"
  │   Ok 2021-07-06T09:15:00Z
  │ "2020/06/01"
  │   Ok 2020-06-01T00:00:00Z
  └────


Duration examples
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ "24h"
  │   Ok 1 days 0 hours 0 mins 0 secs
  │ "16.5 hours"
  │   Ok 16 hours 30 mins 0 secs
  │ "1h20min"
  │   Ok 1 hours 20 mins 0 secs
  │ "1 hour 2.5 minutes"
  │   Ok 1 hours 2 mins 30 secs
  │ "100 seconds"
  │   Ok 1 mins 40 secs
  │ "2.25 minutes 1 seconds"
  │   Ok 2 mins 16 secs
  │ "5 days 6.5 hours"
  │   Ok 5 days 6 hours 30 mins 0 secs
  └────


Timere object examples
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ "2020 jun"
  │   Ok (pattern (years 2020) (months Jun))
  │ "jan"
  │   Ok (pattern (months Jan))
  │ jan 6 12pm to 2pm"
  │   Ok (bounded_intervals whole (duration 366 0 0 0) (points (pick mdhms Jan 6 12 0 0)) (points (pick hms 14 0 0)))
  │ "12th, 13 to 15, 20"
  │   Ok (pattern (month_days 12 13 14 15 20))
  │ "16th 7:30am"
  │   Ok (pattern (month_days 16) (hours 7) (minutes 30) (seconds 0))
  │ "16th 8am to 10am, 11am to 12pm"
  │   Ok (inter (pattern (month_days 16)) (union (bounded_intervals whole (duration 1 0 0 0) (points (pick hms 8 0 0))
  │ (points (pick hms 10 0 0))) (bounded_intervals whole (duration 1 0 0 0) (points (pick hms 11 0 0)) (points (pick hms
  │ 12 0 0)))))
  │ "2020 jun 16th 10am to jul 1 12pm"
  │   Ok (bounded_intervals whole (duration 366 0 0 0) (points (pick ymdhms 2020 Jun 16 10 0 0)) (points (pick mdhms Jul
  │ 1 12 0 0)))
  └────


Corpus
╌╌╌╌╌╌

  For the full corpus/examples, see [corpus/] for code and
  [corpus-outputs/] for generated outputs.


[corpus/] <https://github.com/daypack-dev/timere/tree/main/corpus>

[corpus-outputs/]
<https://github.com/daypack-dev/timere/blob/main/corpus-outputs>


ocamlnet-4.1.9
══════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00028.html>


Gerd Stolpmann announced
────────────────────────

  there is now ocamlnet-4.1.9 available:

  • compatibility with upcoming OCaml-4.12
  • some fixes regarding TLS (https)
  • a few build-related details

  See the project page for download, documentation, a detailed
  changelog, and the mailing list:
  <http://projects.camlcity.org/projects/ocamlnet.html>

  The repository is at

  <https://gitlab.com/gerdstolpmann/lib-ocamlnet3/>

  opam follows soon.


Release of cohttp 4.0.0
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-cohttp-4-0-0/7537/1>


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

  We are glad to announce the [upcoming release] of [`cohttp 4.0.0'], a
  low-level OCaml library for HTTP clients and servers.

  This release comes with a big update of the documentation and the
  examples, both in the [README] and in the codebase, and improvements
  and bug fixes from many contributors 🙇 which you will find listed
  below.

  A huge thank you to all the people that helped to get this release
  ready by raising issues, participating in discussions, sending PRs,
  and otherwise using our library.


[upcoming release] <https://github.com/ocaml/opam-repository/pull/18385>

[`cohttp 4.0.0'] <https://github.com/mirage/ocaml-cohttp>

[README] <https://github.com/mirage/ocaml-cohttp>

The future of cohttp
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  To quote @avsm from [another post]

        The development process […] is driven by a simple
        principle that is inspired by OCaml itself: don't
        needlessly break backwards compatibility without good
        reason, and when it is necessary, justify it. Our tools
        are embedded in projects that have lifespans measured in
        the decades, and we take compatibility seriously. That’s
        why we take pains to provide migration paths […] that are
        as invisible as possible.

  Since in this release we have decided to include a number of fixes and
  improvements which modified Cohttp module signatures, we decided to
  signal the potential breackage by bumping the major version of the
  library. In most cases, however, you don't need to do anything and
  your code will keep working with the latest cohttp.

  Moving forward, we have agreed to start working on the API and the
  internals of cohttp to modernize it and get it ready for multicore
  support and also for eventual unification with the h2 stack that
  offers HTTP2/3 support.

  To be able to move forward and avoid stalling improvements for months,
  we will be less shy of major releases.  However, to remain true to the
  principle above, we will be careful to introduce one breakage at a
  time, carefully justify its need and provide a clear upgrade path in
  the changelog.

  The version history is:
  • cohttp 2.5.5: security backports (changelog below)
  • cohttp 3.0.0: skipped (explained below)
  • cohttp 4.0.0: the next release (changelog below)
  • cohttp 5.0.0: will include a long-awaited change in [how headers are
    treated]: which fixes a multitude of past issues and simplifies the
    internals of the module.

  For the people that need stability, *we have decided to keep
  backporting important security fixes to the `2.5.x' branch of the
  project*. In fact, `cohttp 2.5.5', released just a few days ago was
  the first release with the backport of a security issue.


[another post]
<https://discuss.ocaml.org/t/defining-standard-ocaml-development-lifecycle-processes/7486/5>

[how headers are treated]
<https://github.com/mirage/ocaml-cohttp/pull/747>


What happened to 3.0.0?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The release of `cohttp 3.0.0' has been long awaited, and we are
  extremely grateful to @dinosaure for the enormous work that went into
  designing and implementing `conduit 3.0.0' and `cohttp 3.0.0' (part of
  which remained in `4.0.0' as bug fixes and API improvements).

  However, a discussion started soon after the release pointing out that
  there could be further room of improvement also with the new design,
  particularly with respect to backwards compatibility. Since the design
  discussion did not reach consensus, these changes were reverted to
  preserve better compatibility with existing cohttp users and `cohttp
  3.0.0' was [marked as unavailable] on the opam repository.  As
  maintainers, our "lesson learnt" is to not do releases incrementally
  when they span multiple libraries: we were caught in an awkward spot
  when conduit 3 was released, but without cohttp 3.

  The work on the new conduit is steadily progressing and will be
  integrated in a new major release of cohttp in the future, once we
  will be confident that the API is settled. If you want to try using it
  immediately, then it is available as the [mimic] library in ocaml-git.


[marked as unavailable]
<https://github.com/mirage/ocaml-cohttp/issues/736>

[mimic] <https://github.com/mirage/ocaml-git/tree/master/src/mimic>


Change Log
╌╌╌╌╌╌╌╌╌╌

v4.0.0
┄┄┄┄┄┄

  • cohttp.response: fix malformed status header for custom status codes
    (@mseri @aalekseyev #752)
  • remove dependency to base (@samoht #745)
  • add GitHub Actions workflow (@smorimoto #739)
  • `cohttp-lwt-jsoo': Forward exceptions to caller when response is
    null (@mefyl #738)
  • Use implicit executable dependency for generate.exe (@TheLortex
    #735)
  • cohttp: update HTTP codes (@emillon #711)
  • cohttp: fix chunked encoding of empty body (@mefyl #715)
  • cohttp-async: fix body not being uploaded with unchunked Async.Pipe
    (@mefyl #706)
  • cohttp-{async, lwt}: fix suprising behaviours of Body.is_empty
    (@anuragsoni #714 #712 #713)
  • refactoring of tests (@mseri #709, @dinosaure #692)
  • update documentation (@dinosaure #716, @mseri #720)
  • fix deadlock in logging (@dinosaure #722)
  • improve media type parsing (@seliopou #542, @dinosaure #725)
  • [reverted] breaking changes to client and server API to use conduit
    3.0.0 (@dinosaure #692). However, as the design discussion did not
    reach consensus, these changes were reverted to preserve better
    compatibility with existing cohttp users. (#741, @samoht)

  *Potentially breaking changes*

  • remove `wrapped false' from the codebase (@rgrinberg #734)
  • cohttp: add Uti.t to uri scheme (@brendanlong #707)
  • cohttp-lwt-jsoo: rename Cohttp_lwt_xhr to Cohttp_lwt_jsoo for
    consistency (@mseri #717)
  • cohttp: fix transfer-encoding ordering in headers (@mseri #721)
  • lower-level support for long-running cohttp-async connections
    (@brendanlong #704)
  • add of_form and to_form functions to body (@seliopou #440, @mseri
    #723)
  • cohttp-lwt: partly inline read_response, fix body stream leak
    (@madroach @dinosaure #696).  Note: there is a new warning that may
    show up in your logs when bodies are leaked, see also [#730].
  • add comparison functions for Request.t and Response.t via
    ppx_compare (@msaffer-js @dinosaure #686)


[#730] <https://github.com/mirage/ocaml-cohttp/issues/730>


v2.5.5
┄┄┄┄┄┄

  • `Cohttp_async.resolve_local_file', `Cohttp_lwt.resolve_local_file'
    and `Cohttp_lwt_unix.resolve_file' are now the same code under the
    hood (`Cohttp.Path.resolve_local_file'). The old names have been
    preserved for compatibility, but will be marked as deprecated in the
    next release. This changes the behavior of
    `Cohttp_lwt_unix.resolve_file': it now percent-decodes the paths and
    blocks escaping from the docroot correctly. This also fixes and
    tests the corner cases in these methods when the docroot is
    empty. (@ewanmellor #755)

    *Double check your code base for uses of
     `Cohttp_lwt_unix.resolve_file': it is unsafe with respect to path
     handling*. If you cannot upgrade to `cohttp 2.5.5', you should
     modify your code to call `Cohttp_lwt.resolve_local_file' instead.


New Try-Alt-Ergo website
════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-new-try-alt-ergo-website/7555/1>


OCamlPro announced
──────────────────

  We are pleased to announce the new version of the [Try Alt-Ergo
  website]!

  As a reminder, Try Alt-Ergo allows you to write and run your problems
  in your browser without any server computation.  It was designed to be
  a powerful and simple tool to use.

  Updates concern these parts of the site:
  • A new back end in JavaScript
  • Front end with news features (Ace editor, top panel, right panel,
    etc.)

  Take a look at [our blogpost] to read how we have updated the Try
  Alt-Ergo website and what's new! You can also visit the [Try Alt-Ergo
  website] directly. As usual, do not hesitate to report bugs, to ask
  questions, or to give your feedback.


[Try Alt-Ergo website] <https://try-alt-ergo.ocamlpro.com/>

[our blogpost] <https://www.ocamlpro.com/2021/03/29/new-try-alt-ergo/>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [New Try-Alt-Ergo]
  • [TZComet's New Token Viewer]


[OCaml Planet] <http://ocaml.org/community/planet/>

[New Try-Alt-Ergo]
<https://www.ocamlpro.com/2021/03/29/new-try-alt-ergo/>

[TZComet's New Token Viewer]
<https://seb.mondet.org/b/0012-tzcomet-token-viewer.html>


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: 35049 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-23  9:05 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-03-23  9:05 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of March 16 to 23,
2021.

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

findlib-1.9.1
Conformist 0.2.1
Compiler Explorer now supports OCaml 4.12.0
Annoucement of OFLAT, a web-based platform to support courses on Formal Languages and Automata Theory
Old CWN


findlib-1.9.1
═════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00014.html>


Gerd Stolpmann announced
────────────────────────

  a couple of installation problems slipped into findlib-1.9, mostly
  missing files in the release tarball, but also a FreeBSD
  incompatibility. For that reason, there is now findlib-1.9.1 fixing
  the problems (so far known, and I hope we caught them all).

  Same link as before:

  <http://projects.camlcity.org/projects/findlib.html>


Conformist 0.2.1
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-conformist-0-2-1/7482/1>


jerben announced
────────────────

  I am happy to announce the release of conformist 0.2.1.

  [Conformist] deals with schema definition and validation. It supports
  decoding to bridge the gap between runtime types and static types
  without ppx.

  ┌────
  │ type occupation =
  │   | Mathematician
  │   | Engineer
  │ 
  │ type user =
  │   { occupation : occupation
  │   ; email : string
  │   ; birthday : int * int * int
  │   ; nr_of_siblings : int
  │   ; comment : string option
  │   ; wants_premium : bool
  │   }
  │ 
  │ let user occupation email birthday nr_of_siblings comment wants_premium =
  │   { occupation; email; birthday; nr_of_siblings; comment; wants_premium }
  │ ;;
  │ 
  │ let occupation_decoder = function
  │   | "mathematician" -> Ok Mathematician
  │   | "engineer" -> Ok Engineer
  │   | _ -> Error "Unknown occupation provided"
  │ ;;
  │ 
  │ let occupation_encoder = function
  │   | Mathematician -> "mathematician"
  │   | Engineer -> "engineer"
  │ ;;
  │ 
  │ let user_schema =
  │   Conformist.(
  │     make
  │       Field.
  │ 	[ custom
  │ 	    occupation_decoder
  │ 	    occupation_encoder
  │ 	    "occupation"
  │ 	    ~meta:()
  │ 	; string "email"
  │ 	; date "birthday"
  │ 	; int ~default:0 "nr_of_siblings"
  │ 	; optional (string "comment")
  │ 	; bool "wants_premium"
  │ 	]
  │       user)
  │ ;;
  │ 
  │   let input =
  │     [ "occupation", [ "engineer" ]
  │     ; "email", [ "test@example.com" ]
  │     ; "birthday", [ "2020-12-01" ]
  │     ; "nr_of_siblings", [ "3" ]
  │     ; "comment", [ "hello" ]
  │     ; "wants_premium", [ "true" ]
  │     ]
  │ 
  │ let user =
  │   Conformist.decode Schema.user_schema input
  │ 
  │ let validation_errors =
  │   Conformist.validate Schema.user_schema input
  └────

  The `user_schema' and the `user' create function are guaranteed to be
  in sync at compile time.


[Conformist] <https://github.com/oxidizing/conformist>


Compiler Explorer now supports OCaml 4.12.0
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-compiler-explorer-now-supports-ocaml-4-12-0/7479/3>


Continuing this thread, Sora Morimoto announced
───────────────────────────────────────────────

  Today we deployed 4.12.0 flambda. It must already be available!


Annoucement of OFLAT, a web-based platform to support courses on Formal Languages and Automata Theory
═════════════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00026.html>


Antonio Ravara announced
────────────────────────

  <http://ctp.di.fct.unl.pt/FACTOR/OFLAT/>

  To support students’ autonomous work on topics related with Formal
  Languages and Automata Theory (FLAT), interactive tools that allow
  them to experiment with examples and solve exercises are very
  important - several studies demonstrate this.

  There are applications with this aim. While some are impressively
  complete, but are mainly Desktop applications (like JFLAP), others
  that can be used via a web browser are under-developed. Moreover,
  these applications are often not fully interactive - illustrations or
  even step-by-step execution is key to understand the algorithms - and,
  due to the programming languages used, implement the concepts in a way
  quite distant from the textbook Mathematical definitions. Code that
  implements closely the definitions is also a relevant pedagogical
  tool.

  With three concerns in mind - availability in mobile devices,
  interactive run of the algorithms (or at least presenting clear
  explanations), and code following closely the definitions - we
  developed OFLAT, a web-based tool to represent and illustrate
  graphically classical mechanisms and algorithms of Formal Languages
  and Automata Theory. It includes not only exercises evaluated
  automatically and providing feedback, but also allows students to
  create their own exercises. An integration with a grading platform
  like Learn-OCaml is underway.

  The tool is implemented in OCaml and is organised in two parts: a
  library - OCamlFLAT - which concentrates the logic of FLAT concepts,
  and the interactive applicational part - OFLAT. To run on browsers,
  the application uses the OCaml to Javascript translator
  Js_of_OCaml. To implement the interactive graphics, it uses Cytoscape,
  a Javascript library for graphs. All code is available in the Git of
  the project: <https://gitlab.com/releaselab/leaf/OCamlFlat>,
  <https://gitlab.com/releaselab/leaf/OFLAT>.

  The development of new functionalities is ongoing (we're now working
  more animations and on Context-Free Grammar and Pushdown Automata).
  Comments most welcome.


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: 21239 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-16 10:31 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-03-16 10:31 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of March 09 to 16,
2021.

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

Links from the OCaml Discourse
findlib-1.9
Compiler Explorer now supports OCaml 4.12.0
Old CWN


Links from the OCaml Discourse
══════════════════════════════

The editor says
───────────────

  Due to a [global Discourse change] that disabled the mailing list
  mode, I was no able to collect the bodies of the news from the OCaml
  Discourse for several days. This has now been fixed and next week’s
  OCaml Weekly News should be as usual. In the meantime, here are links
  to the main announcements. Do not hesitate to [contact me] if you want
  to give feedback about this newsletter.

  • [Release 1.0.0 of bag]
  • [Plan for Dune 3.0]
  • [lascar 0.7.0 - a library for manipulating Labeled Transition
    Systems in OCaml]
  • [dirsift 0.0.3 - Search for directories by type]
  • [FSML 0.3.0 - an OCaml library for describing and describing
    synchronous finite state machines]
  • [Multicore OCaml: February 2021]
  • [VSCode OCaml Platform v1.7.0 - v1.8.0]
  • [ca-certs and ca-certs-nss]
  • [Js_of_Ocaml position at TrustInSoft]
  • [Senior Developer vacancy at Cryptosense, France (or remote)]
  • [hxd.0.3.1 - A simple hexdump tool in OCaml]
  • [Release of Gopcaml-mode (0.0.2) - Unicode & Compatibility Update]


[global Discourse change]
<https://meta.discourse.org/t/mailing-list-mode-mysteriously-deactivated/182650>

[contact me] <mailto:alan.schmitt@polytechnique.org>

[Release 1.0.0 of bag]
<https://discuss.ocaml.org/t/ann-release-1-0-0-of-bag/7464>

[Plan for Dune 3.0] <https://discuss.ocaml.org/t/plan-for-dune-3-0/7414>

[lascar 0.7.0 - a library for manipulating Labeled Transition Systems in
OCaml]
<https://discuss.ocaml.org/t/ann-lascar-0-7-0-a-library-for-manipulating-labeled-transition-systems-in-ocaml/7443>

[dirsift 0.0.3 - Search for directories by type]
<https://discuss.ocaml.org/t/ann-dirsift-0-0-3-search-for-directories-by-type/7435>

[FSML 0.3.0 - an OCaml library for describing and describing synchronous
finite state machines]
<https://discuss.ocaml.org/t/ann-fsml-0-3-0-an-ocaml-library-for-describing-and-describing-synchronous-finite-state-machines/7445>

[Multicore OCaml: February 2021]
<https://discuss.ocaml.org/t/multicore-ocaml-february-2021/7449>

[VSCode OCaml Platform v1.7.0 - v1.8.0]
<https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-7-0-v1-8-0/7424>

[ca-certs and ca-certs-nss]
<https://discuss.ocaml.org/t/ann-ca-certs-and-ca-certs-nss/6804/7>

[Js_of_Ocaml position at TrustInSoft]
<https://discuss.ocaml.org/t/js-of-ocaml-position-at-trustinsoft/7429>

[Senior Developer vacancy at Cryptosense, France (or remote)]
<https://discuss.ocaml.org/t/senior-developer-vacancy-at-cryptosense-france-or-remote/7431>

[hxd.0.3.1 - A simple hexdump tool in OCaml]
<https://discuss.ocaml.org/t/ann-hxd-0-3-1-a-simple-hexdump-tool-in-ocaml/7417>

[Release of Gopcaml-mode (0.0.2) - Unicode & Compatibility Update]
<https://discuss.ocaml.org/t/ann-release-of-gopcaml-mode-0-0-2-unicode-compatibility-update/7425>


findlib-1.9
═══════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-03/msg00012.html>


Gerd Stolpmann announced
────────────────────────

  findlib-1.9 is out. Changes:

  • Overhaul how separately installed packages (e.g. num) are handled
    (by David Allsopp).
  • Switch to opam-2.0 file format (by David Allsopp).
  • Fix an incomaptibility with ocaml-4.13 (by David Allsopp).
  • Expose the native toplevel (by Louis Gesbert).
  • Fix an incompatibility with "Jane Street Style" (by Mark Laws).
  • Switch from m4 to sed (by kit-ty-kate).

  For manual, download, manuals, etc. see here:

  <http://projects.camlcity.org/projects/findlib.html>

  An updated OPAM package will follow soon.


Compiler Explorer now supports OCaml 4.12.0
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-compiler-explorer-now-supports-ocaml-4-12-0/7479/1>


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

  Sorry to the OCaml hacker using Compiler Explorer for the late update
  (it took some time to deploy the infrastructure, etc.), but it now
  supports OCaml 4.12.0, but also 4.10.2 and 4.11.2!

  <https://godbolt.org>


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: 16008 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-03-09 10:58 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-03-09 10:58 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of March 02 to 09,
2021.

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

Working on an app to learn and execute OCaml on iPhone/iPad/Mac for beginners
ERic (Entity-Relation interactive calculator) version 0.3
OCaml Café: Tue, March 9 @ 7-9pm (CST)
Functional Programming User Study (Specifically in OCaml)
OCaml 4.12.0 released (with 4.11.2 too)
Other OCaml News
Old CWN


Working on an app to learn and execute OCaml on iPhone/iPad/Mac for beginners
═════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/working-on-an-app-to-learn-and-execute-ocaml-on-iphone-ipad-mac-for-beginners/7392/1>


Nathan Fallet announced
───────────────────────

  I started to work on a new project recently: My goal is to provide an
  iOS app for beginners to learn OCaml and practice on their device.  I
  think it is a good idea to get started easily.

  Here are some screenshots of what I’ve done so far:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/ef66cf62d1ab605542033f09040cc964787cbb65_2_462x1000.jpeg>

  I’m open to feedback and opinion about this project idea


Nathan Fallet then added
────────────────────────

  I made it available for pre order on the App Store - I will keep
  improving it with time, and I think it can be a great tool for
  beginners

  [https://apps.apple.com/app/ocaml-learn-code/id1547506826]


[https://apps.apple.com/app/ocaml-learn-code/id1547506826]
<https://apps.apple.com/app/ocaml-learn-code/id1547506826>


Yawar Amin replied
──────────────────

  This is really cool. I just want to point out that your app is the
  sole search result for 'OCaml' in the App Store.  So that's a first
  :-)

  Incidentally, there is an 'OCaml Toplevel' app on the Android Play
  Store:
  <https://play.google.com/store/apps/details?id=fr.vernoux.ocaml>

  Your app looks more sophisticated though. Hopefully one day we have
  something like [Swift Playgrounds] and people can start learning OCaml
  interactively on their devices directly.


[Swift Playgrounds] <https://www.apple.com/ca/swift/playgrounds/>


ERic (Entity-Relation interactive calculator) version 0.3
═════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-eric-entity-relation-interactive-calculator-version-0-3/7408/1>


Damien Guichard announced
─────────────────────────

  The [programming languages zoo] is a great resource for wanna-be
  interpreter/compiler writers. The [ICFP 2000 programming contest] is
  another great resource for wanna-be ray tracers. However until now
  there has been no OCaml resource for wanna-be Knowledge Representation
  tool-ers. This makes sound like KR tool is a more difficult area than
  other projects. ERic v0.3 demonstrates the opposite as it's about 1200
  lines size (lexer & hand-written parser included) and reads/writes a
  [Conceptual Graph] Interchange Format (CGIF) notation.

  • ERic v0.3 [Zip archive]
  • ERic v0.3 [SVN repository]


[programming languages zoo] <http://plzoo.andrej.com/>

[ICFP 2000 programming contest]
<https://www.cs.cornell.edu/icfp/contest_results.htm>

[Conceptual Graph] <https://en.wikipedia.org/wiki/Conceptual_graph>

[Zip archive]
<http://damien-guichard.developpez.com/downloads/ERic-0.3.zip>

[SVN repository] <http://subversion.developpez.com/projets/ERic/trunk/>


OCaml Café: Tue, March 9 @ 7-9pm (CST)
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-cafe-tue-march-9-7-9pm-cst/7409/1>


Claude Jager-Rubinson announced
───────────────────────────────

  Please join us next Tuesday at 7pm Central time for the second meeting
  of OCaml Café.  Zoom connection info is available at [Houston
  Functional Programmers].

  OCaml Café offers 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.

  Whether you’re still trying to make sense of currying or can spot
  non-tail-recursive code from across the room, we hope that you’ll join
  us with your questions about OCaml, or just to hang out with the OCaml
  community.


[Houston Functional Programmers] <https://hfpug.org>


Functional Programming User Study (Specifically in OCaml)
═════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/functional-programming-user-study-specifically-in-ocaml/7410/1>


Ahan Malhotra announced
───────────────────────

  We are doing user studies to help us understand how to help people
  understand and navigate complex information about programming
  documentation, *specifically in OCaml*. You will complete a series
  tasks that help us understand working memory and how you navigate a
  new interface. After examining a layout of the data (interface) for a
  short, predetermined amount of time, you will be asked a set of
  comprehension and/or qualitative questions to measure whether the
  methods of presenting this information has any impact on your
  performance.

  *The study will take around 55 minutes, and you will be entered into a
  lottery for a $150 Amazon gift card as compensation for your time.*

  *A bit more about this study*

  The user study will be done virtually on Zoom. You will be asked to
  various tasks with the interface. The interface is deployed as a
  public web application so you don’t have to install anything. This
  research is governed by Harvard University's Committee on the Use of
  Human Subjects.

  *Eligibility*

  You also don’t have to be an expert in anything to participate. You
  just need to be fluent in English and over 18 years of age.

  If you are interested, please fill out this survey to confirm your
  eligibility, and we will follow up to schedule the study session:
  <https://forms.gle/q6vkyEE2tSjjZoiSA>

  If you have any questions, please email
  ahanmalhotra@college.harvard.edu.


OCaml 4.12.0 released (with 4.11.2 too)
═══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-12-0-released-with-4-11-2-too/7358/13>


Continuing this thread from last week, Hannes Mehnert said
──────────────────────────────────────────────────────────

  Congratulations to the new release. For the curious who intend to
  install a flambda version of 4.12 and are surprised that
  `ocaml-variants.4.12.0+flambda' does not exist, from [this thread] the
  opam layout has changed, and now the following works:

  ┌────
  │ $ opam sw create <my-switch-name> --packages=ocaml-variants.4.12.0+options,ocaml-options-only-flambda
  └────

  There are more configuration options available, take a look at the
  output of `opam search ocaml-option' for all options. (I've not been
  involved with this development. I don't quite understand why there is
  for each `Y' a `ocaml-option-Y' and a `ocaml-options-only-Y'.) I also
  have not figured out whether there's a way to pass `-O3' in the just
  created switch.

  Maybe it is worth to embed such information in the very nicely styled
  OCaml manual (considering that opam got quite some traction over the
  years and is recommended for OCaml developers)?


[this thread]
<https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Release of Frama-Clang 0.0.10]
  • [Qubes-lite with KVM and Wayland]
  • [Florence and beyond: the future of Tezos storage]
  • [The ReScript Association]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Release of Frama-Clang 0.0.10]
<https://frama-c.com/fc-plugins/frama-clang.html>

[Qubes-lite with KVM and Wayland]
<https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland/>

[Florence and beyond: the future of Tezos storage]
<https://tarides.com/blog/2021-03-04-florence-and-beyond-the-future-of-tezos-storage>

[The ReScript Association]
<https://rescript-lang.org/blog/rescript-association-rebranding>


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: 21846 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-23  9:51 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-02-23  9:51 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of February 16 to 23,
2021.

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

OCamlFormat 0.17.0
Set up OCaml 1.1.8
Set up OCaml 1.1.9
OCaml 4.12.0, first release candidate
Ppxlib.0.22: an update on the state of ppx
OCaml-based trading firm is hiring remote devs
ocamlearlybird 1.0.0 beta1
OCaml for ARM MacOS
Old CWN


OCamlFormat 0.17.0
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocamlformat-0-17-0/7287/1>


Guillaume Petiot announced
──────────────────────────

  On behalf of the OCamlFormat development team I am pleased to announce
  the release of [ocamlformat.0.17.0] :tada:.

  OCamlformat is an auto-formatter for OCaml code, writing the parse
  tree and comments in a consistent style, so that you do not have to
  worry about formatting it by hand, and to speed up code review by
  focusing on the important parts.

  OCamlFormat is beta software. We expect the program to change
  considerably before we reach version 1.0.0. In particular, upgrading
  the `ocamlformat' package will cause your program to get
  reformatted. Sometimes it is relatively pain-free, but sometimes it
  will make a diff in almost every file. We are working towards having a
  tool that pleases most usecases in the OCaml community, please bear
  with us!

  To make sure your project uses the last version of ocamlformat, please
  set
  ┌────
  │ version=0.17.0
  └────
  in your `.ocamlformat' file.

  Main changes in `ocamlformat.0.17.0' are:

  • the `let-open' option, deprecated since 0.16.0, has been removed
  • support for OCaml 4.06 and 4.07 has been removed, minimal version
    requirement bumped to OCaml 4.08
  • the `extension-sugar' option, deprecated since 0.14.0, has been
    removed
  • the syntax of infix set/get operators is now preserved (`String.get'
    and similar calls used to be automatically rewritten to their
    corresponding infix form `.()', that was incorrect when using the
    `-unsafe' compilation flag. Now the concrete syntax of these calls
    is preserved)
  • all sugared extension points are now preserved
  • injectivity type annotations (OCaml 4.12 feature) are now supported
  • various fixes about comments positions

  We encourage you to try ocamlformat, that can be installed from opam
  directly ( `opam install ocamlformat' ), but please remember that it
  is still beta software. We have a [FAQ for new users ] that should
  help you decide if ocamlformat is the right choice for you.


[ocamlformat.0.17.0] <https://github.com/ocaml-ppx/ocamlformat>

[FAQ for new users ]
<https://github.com/ocaml-ppx/ocamlformat#faq-for-new-users>


Set up OCaml 1.1.8
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-8/7288/1>


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

Changed
╌╌╌╌╌╌╌

  • The Windows opam wrapper is fractionally less-archaically named
    opam.cmd, with no loss in arcaneness.
  • Export `CYGWIN_ROOT' on the Windows runners, allowing bash to be
    invoked as `%CYGWIN_ROOT%\bin\bash~/~$env:CYGWIN_ROOT\bin\bash' (and
    similarly for Cygwin `setup-x86_64.exe').
  • The Windows runner no longer prepends `%CYGWIN_ROOT%\bin' to `PATH'.


Fixed
╌╌╌╌╌

  • Switches in Unix are now properly initialized before running depext.

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.8>


Set up OCaml 1.1.9
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-9/7293/1>


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

Fixed
╌╌╌╌╌

  • Further fix to switch initialisation.

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.9>


OCaml 4.12.0, first release candidate
═════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-12-0-first-release-candidate/7294/1>


octachron announced
───────────────────

  The release of OCaml 4.12.0 is expected next week. We have created a
  release candidate that you can test. Most opam packages should work
  with this release candidate (without the need for an alpha
  repository).

  Compared to the last beta, this new release only contains one fix for
  Solaris and illumos.

  If you find any bugs, please report them here:
   <https://github.com/ocaml/ocaml/issues>

  Happy hacking,

  – Florian Angeletti for the OCaml team.


Installation instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.12.0~rc1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  If you want to tweak the configuration of the compiler, you can pick
  configuration options with
  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~rc1+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where `<option_list>' is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and afl enabled switch:
  ┌────
  │ opam switch create 4.12.0~rc1+flambda+afl --packages=ocaml-variants.4.12.0~rc1+options,ocaml-option-flambda,ocaml-option-afl
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with `opam search ocaml-option'.

  The source code is available at these addresses:

  • <https://github.com/ocaml/ocaml/archive/4.12.0-rc1.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~rc1.tar.gz>


Ppxlib.0.22: an update on the state of ppx
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ppxlib-0-22-an-update-on-the-state-of-ppx/7296/1>


Nathan Rebours announced
────────────────────────

  We're happy to announce the release of ppxlib.0.22.0, the fist release
  of ppxlib fully compatible with OCaml 4.12.  The main and only feature
  of this release is the bump of the internal OCaml AST used by ppxlib
  from 4.11 to 4.12, allowing you to use 4.12 language features with
  ppxlib and any ppxlib-based ppx.  Note that ppxlib was compatible with
  the 4.12 compiler since 0.19.0 but that you couldn't use 4.12 language
  features until now.

  This is the third such AST bump release since we announced our plan to
  improve the state of the PPX ecosystem [here] and we though it'd be a
  good time to report back to you and tell you how things are going on
  this front.

  For those of you who aren't familiar with this plan, the goal is to
  upstream a minimal, stable, ocaml-migrate-parsetree-like API on top of
  the compiler-libs called `Astlib'. It will allow us to keep ppxlib and
  any ppx based on ppxlib compatible with OCaml trunk at all time.  To
  allow better performances and a clear compisition semantic, all the
  ppxlib-based ppx-es need to use the same AST (as opposed to
  ocaml-migrate-parsetree based ppx-es) so from a certain perspective,
  this plan simply moves the breaking API up one step, from
  compiler-libs to ppxlib.  In order to greatly ease the maintainenance
  of ppx-es and to prevent opam-universe splits we decided that
  everytime we cut a breaking ppxlib release, we will send patches to
  keep the existing ppx-es compatible with the latest version and
  therefore with the latest OCaml compilers and language features.

  While this seems like a tremendous task and a huge amount of work,
  dune and other tools that raised in its wake such as [opam-monorepo]
  incredibly simplified this kind of work.

  Ahead of OCaml releases, we prepare a branch of ppxlib with the
  upgraded AST. We then fetch opam-repository to gather a list of
  sensible reverse dependencies (i.e. packages whose latest version
  depends on ppxlib and is compatible with ppxlib's latest version) and
  assemble a dune workspace with a clone of each of those reverse
  dependencies, our ppxlib branch and all of their dependencies thanks
  to opam-monorepo.  We then use dune to build all the packages we're
  interested in and simply follow the compilation errors until
  everything builds successfully with the new ppxlib.  What remains is
  to create PRs on the relevant repositories to upstream those changes,
  after which maintainers have everything they need to cut a new
  compatible release.

  Most of this process is automated using scripts but it still requires
  a bit of handiwork. We aim at extracting tools to further improve this
  workflow and reduce the time and effort required but it has been
  surprisingly smooth. Our experience with the 4.10, 4.11 and 4.12
  upgrades so far is that most reverse dependencies don't need an
  upgrade and that it's far less demanding for one person to upgrade all
  the packages that need it than it would be for each individual
  maintainers to understand the changes in the AST and do the upgrade
  themselves.

  It's worth noting that for this to work well, the ppx-es and all their
  dependencies have to build with dune. We do maitain a separate
  opam-repository with dune ports of commonly used packages so in
  practice most projects fall into this category but a few exceptions
  remain and they are therefore not taken into account for this upgrade
  process.

  We're also trying to improve the tracking of the upgrade's progress
  and for the 4.12 compatible release we created a [github project] to
  have a list of all the packages we considered and see where they
  are. We also keep track of the packages we had to exclude and why.
  During this upgrade, we considered 80 opam packages, out of which only
  4 needed to be patched and 6 had to be excluded from the process as we
  couldn't reasonably get them to build in our workspace.

  Once we have a better idea of what makes a package easy to upgrade we
  plan on releasing a set of reasonable rules to follow to benefit from
  those upgrades, we'll keep you updated on this!

  All in all we're pretty happy with this new process and although it
  needs to be refined, we're confident it can grow into something
  sustainable by creating tools and CI to support it. Hopefully these
  will also benefit the wider community and help grow a healthier Opam
  universe.


[here] <https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231>

[opam-monorepo] <https://github.com/ocamllabs/opam-monorepo>

[github project] <https://github.com/ocaml-ppx/ppxlib/projects/2>


Jason Nielsen asked
───────────────────

  Curious about the current status of `Astlib'.  I was closely following
  [ppx] at one point but it hasn't seen much activity recently.  Thanks
  for all your hard work.


[ppx] <https://github.com/ocaml-ppx/ppx>


Jérémie Dimino
──────────────

  It's in progress. Not much happened in the past couple of months while
  we were finishing the port of a few projects to ppxlib and doing the
  4.12 upgrade. But @pitag re-started working `Astlib' as of a week
  ago. You can follow our progression via [the public meeting notes].

  Note however that the [ppx] project was for our original goal or
  providing a "forever stable" API for ppx rewriters. It has been in
  pause since August 2020 while were trying the "upgrade the world"
  method, which as @NathanReb pointed out is working pretty well
  practice. At this point, it's looking more and more likely that we
  won't resurect the ppx project.


[the public meeting notes] <https://github.com/ocaml-ppx/ppxlib/wiki>

[ppx] <https://github.com/ocaml-ppx/ppx>


OCaml-based trading firm is hiring remote devs
══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-based-trading-firm-is-hiring-remote-devs/7298/1>


Michael Bacarella announced
───────────────────────────

  BTG is a trading firm founded by ex-Jane Street devs looking to hire
  some more devs.

  The role is primarily remote, working with the rest of our mostly
  remote team, though we hope to resume regular on-sites in Puerto Rico.

  We operate 24/7 and will consider employees anywhere in the world.

  Prior experience with OCaml is a plus, though any solid programming
  experience with an interest in functional programming and strong
  static types is also fine.

  Comfort navigating Linux is essential.

  Shoot me a message with a copy of your résumé or C.V. to discuss the
  opportunity further: [michael.bacarella@gmail.com]

  Feel free to re-post this elsewhere.


[michael.bacarella@gmail.com] <mailto:michael.bacarella@gmail.com>


ocamlearlybird 1.0.0 beta1
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180/21>


文宇祥 announced
────────────────

  Hi, all. All the issues of beta1 have been fixed. Beta2 will be
  released soon.

  <https://github.com/ocaml/opam-repository/pull/18191>


OCaml for ARM MacOS
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-for-arm-macos/6019/24>


Aaron L. Zeng announced
───────────────────────

  I noticed that opam 2.08 is now available for ARM Macs using
  [Homebrew], and I was able to confirm on my machine.

  `brew install opam' away :)


[Homebrew] <https://github.com/Homebrew/homebrew-core/pull/71605>


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: 29081 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-16 13:53 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-02-16 13:53 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of February 09 to 16,
2021.

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

opam 2.0.8 release
opam 2.1.0~beta4
Set up OCaml 1.1.6
Set up OCaml 1.1.7
Old CWN


opam 2.0.8 release
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-0-8-release/7242/1>


R. Boujbel announced
────────────────────

  We are pleased to announce the minor release of [opam 2.0.8].

  This new version contains some fixes, mainly for sandbox and fish
  scripts. You can find more information in this [blog post], and more
  detailed in the [release note].

  /opam is a source-based package manager for OCaml. It supports
  multiple simultaneous compiler installations, flexible package
  constraints, and a Git-friendly development workflow./


[opam 2.0.8] <https://github.com/ocaml/opam/releases/tag/2.0.8>

[blog post] <https://opam.ocaml.org/blog/opam-2-0-8>

[release note] <https://github.com/ocaml/opam/releases/tag/2.0.8>


opam 2.1.0~beta4
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-2-1-0-beta4/7252/1>


David Allsopp announced
───────────────────────

  On behalf of the opam team, it gives me great pleasure to announce the
  third beta release of opam 2.1. Don’t worry, you didn’t miss beta3 -
  we had an issue with a configure script that caused beta2 to report as
  beta3 in some instances, so we skipped to beta4 to avoid any further
  confusion!

  We encourage you to try out this new beta release: there are
  instructions for doing so in [our wiki]. The instructions include
  taking a backup of your `~/.opam' root as part of the process, which
  can be restored in order to wind back. _Please note that local
  switches which are written to by opam 2.1 are upgraded and will need
  to be rebuilt if you go back to opam 2.0_. This can either be done by
  removing `_opam' and repeating whatever you use in your build process
  to create the switch, or you can use `opam switch export
  switch.export' to backup the switch to a file before installing new
  packages. Note that opam 2.1 _shouldn’t_ upgrade a local switch unless
  you upgrade the base packages (i.e. the compiler).


[our wiki]
<https://github.com/ocaml/opam/wiki/How-to-test-an-opam-feature>

What’s new in opam 2.1?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Switch invariants
  • Improved options configuration (see the new `option' and expanded
    `var' sub-commands)
  • Integration of system dependencies (formerly the opam-depext
    plugin), increasing their reliability as it integrates the solving
    step
  • Creation of lock files for reproducible installations (formerly the
    opam-lock plugin)
  • CLI versioning, allowing cleaner deprecations for opam now and also
    improvements to semantics in future without breaking
    backwards-compatibility
  • Performance improvements to opam-update, conflict messages, and many
    other areas
  • New plugins: opam-compiler and opam-monorepo


Switch invariants
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  In opam 2.0, when a switch is created the packages selected are put
  into the “base” of the switch. These packages are not normally
  considered for upgrade, in order to ease pressure on opam’s
  solver. This was a much bigger concern early on in opam 2.0’s
  development, but is less of a problem with the default mccs solver.

  However, it’s a problem for system compilers. opam would detect that
  your system compiler version had changed, but be unable to upgrade the
  ocaml-system package unless you went through a slightly convoluted
  process with `--unlock-base'.

  In opam 2.1, base packages have been replaced by switch
  invariants. The switch invariant is a package formula which must be
  satisfied on every upgrade and install. All existing switches’ base
  packages could just be expressed as `package1 & package2 & package3'
  etc. but opam 2.1 recognises many existing patterns and simplifies
  them, so in most cases the invariant will be `"ocaml-base-compiler" {=
  4.11.1}', etc. This means that `opam switch create my_switch
  ocaml-system' now creates a _switch invariant_ of `"ocaml-system"'
  rather than a specific version of the `ocaml-system' package. If your
  system OCaml package is updated, `opam upgrade' will seamlessly switch
  to the new package.

  This also allows you to have switches which automatically install new
  point releases of OCaml. For example:

  ┌────
  │ opam switch create ocaml-4.11 --formula='"ocaml-base-compiler" {>= "4.11.0" & < "4.12.0~"}'
  │ --repos=old=git+https://github.com/ocaml/opam-repository#a11299d81591
  │ opam install utop
  └────

  Creates a switch with OCaml 4.11.0 (the `--repos=' was just to select
  a version of opam-repository from before 4.11.1 was released). Now
  issue:

  ┌────
  │ opam repo set-url old git+https://github.com/ocaml/opam-repository
  │ opam upgrade
  └────

  and opam 2.1 will automatically offer to upgrade OCaml 4.11.1 along
  with a rebuild of the switch. There’s not yet a clean CLI for
  specifying the formula, but we intend to iterate further on this with
  future opam releases so that there is an easier way of saying “install
  OCaml 4.11.x”.


opam depext integration
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  opam has long included the ability to install system dependencies
  automatically via the [depext plugin]. This plugin has been promoted
  to a native feature of opam 2.1.0 onwards, giving the following
  benefits:

  • You no longer have to remember to run `opam depext', opam always
    checks depexts (there are options to disable this or automate it for
    CI use). Installation of an opam package in a CI system is now as
    easy as `opam install .', without having to do the dance of `opam
    pin add -n/depext/install'. Just one command now for the common
    case!
  • The solver is only called once, which both saves time and also
    stabilises the behaviour of opam in cases where the solver result is
    not stable. It was possible to get one package solution for the
    `opam depext' stage and a different solution for the `opam install'
    stage, resulting in some depexts missing.
  • opam now has full knowledge of depexts, which means that packages
    can be automatically selected based on whether a system package is
    already installed. For example, if you have *neither* MariaDB nor
    MySQL dev libraries installed, `opam install mysql' will offer to
    install `conf-mysql' and `mysql', but if you have the MariaDB dev
    libraries installed, opam will offer to install `conf-mariadb' and
    `mysql'.


[depext plugin] <https://github.com/ocaml-opam/opam-depext>


opam lock files and reproducibility
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  When opam was first released, it had the mission of gathering together
  scattered OCaml source code to build a [community repository]. As time
  marches on, the size of the opam repository has grown tremendously, to
  over 3000 unique packages with over 18000 unique versions. opam looks
  at all these packages and is designed to solve for the best
  constraints for a given package, so that your project can keep up with
  releases of your dependencies.

  While this works well for libraries, we need a different strategy for
  projects that need to test and ship using a fixed set of
  dependencies. To satisfy this use-case, opam 2.0.0 shipped with
  support for _using_ `project.opam.locked' files. These are normal opam
  files but with exact versions of dependencies. The lock file can be
  used as simply as `opam install . --locked' to have a reproducible
  package installation.

  With opam 2.1.0, the creation of lock files is also now integrated
  into the client:
  • `opam lock' will create a `.locked' file for your current switch and
    project, that you can check into the repository.
  • `opam switch create . --locked' can be used by users to reproduce
    your dependencies in a fresh switch.

  This lets a project simultaneously keep up with the latest
  dependencies (without lock files) while providing a stricter set for
  projects that need it (with lock files).


[community repository] <https://github.com/ocaml/opam-repository>


CLI Versioning
┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  A new `--cli' switch was added to the first beta release, but it’s
  only now that it’s being widely used. opam is a complex enough system
  that sometimes bug fixes need to change the semantics of some
  commands. For example:

  • `opam show --file' needed to change behaviour
  • The addition of new controls for setting global variables means that
    the `opam config' was becoming cluttered and some things want to
    move to `opam var'
  • `opam switch create 4.11.1' still works in opam 2.0, but it’s really
    an OPAM 1.2.2 syntax.

  Changing the CLI is exceptionally painful since it can break scripts
  and tools which themselves need to drive `opam'.  CLI versioning is
  our attempt to solve this. The feature is inspired by the `(lang dune
  ...)' stanza in `dune-project' files which has allowed the Dune
  project to rename variables and alter semantics without requiring
  every single package using Dune to upgrade their `dune' files on each
  release.

  Now you can specify which version of opam you expected the command to
  be run against. In day-to-day use of opam at the terminal, you
  wouldn’t specify it, and you’ll get the latest version of the CLI. For
  example: `opam var --global' is the same as `opam var --cli=2.1
  --global'. However, if you issue `opam var --cli=2.0 --global', you
  will told that `--global' was added in 2.1 and so is not available to
  you. You can see similar things with the renaming of `opam upgrade
  --unlock-base' to `opam upgrade --update-invariant'.

  The intention is that `--cli' should be used in scripts, user guides
  (e.g. blog posts), and in software which calls opam. The only decision
  you have to take is the _oldest_ version of opam which you need to
  support. If your script is using a new opam 2.1 feature (for example
  `opam switch create --formula=') then you simply don’t support opam
  2.0. If you need to support opam 2.0, then you can’t use `--formula'
  and should use `--packages' instead. opam 2.0 does not have the
  `--cli' option, so for opam 2.0 instead of `--cli=2.0' you should set
  the environment variable `OPAMCLI' to `2.0'. As with _all_ opam
  command line switches, `OPAMCLI' is simply the equivalent of `--cli'
  which opam 2.1 will pick-up but opam 2.0 will quietly ignore (and, as
  with other options, the command line takes precedence over the
  environment).

  Note that opam 2.1 sets `OPAMCLI=2.0' when building packages, so on
  the rare instances where you need to use the `opam' command in a
  _package_ `build:' command (or in your build system), you _must_
  specify `--cli=2.1' if you’re using new features.

  There’s even more detail on this feature [in our wiki]. We’re still
  finalising some details on exactly how `opam' behaves when `--cli' is
  not given, but we’re hoping that this feature will make it much easier
  in future releases for opam to make required changes and improvements
  to the CLI without breaking existing set-ups and tools.


[in our wiki]
<https://github.com/ocaml/opam/wiki/Spec-for-opam-CLI-versioning>


What’s new since the last beta?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • opam now uses CLI versioning ([#4385])
  • opam now exits with code 31 if all failures were during fetch
    operations ([#4214])
  • `opam install' now has a `--download-only' flag ([#4036]), allowing
    opam’s caches to be primed
  • `opam init' now advises the correct shell-specific command for `eval
    $(opam env)' ([#4427])
  • `post-install' hooks are now allowed to modify or remove installed
    files ([#4388])
  • New package variable `opamfile-loc' with the location of the
    installed package opam file ([#4402])
  • `opam update' now has `--depexts' flag ([#4355]), allowing the
    system package manager to update too
  • depext support NetBSD and DragonFlyBSD added ([#4396])
  • The format-preserving opam file printer has been overhauled
    ([#3993], [#4298] and [#4302])
  • pins are now fetched in parallel ([#4315])
  • `os-family=ubuntu' is now treated as `os-family=debian' ([#4441])
  • `opam lint' now checks that strings in filtered package formulae are
    booleans or variables ([#4439])

  and many other bug fixes as listed [on the release page].


[#4385] <https://github.com/ocaml/opam/pull/4385>

[#4214] <https://github.com/ocaml/opam/issues/4214>

[#4036] <https://github.com/ocaml/opam/issues/4036>

[#4427] <https://github.com/ocaml/opam/pull/4427>

[#4388] <https://github.com/ocaml/opam/pull/4388>

[#4402] <https://github.com/ocaml/opam/pull/4402>

[#4355] <https://github.com/ocaml/opam/issues/4355>

[#4396] <https://github.com/ocaml/opam/pull/4396>

[#3993] <https://github.com/ocaml/opam/issues/3993>

[#4298] <https://github.com/ocaml/opam/pull/4298>

[#4302] <https://github.com/ocaml/opam/pull/4302>

[#4315] <https://github.com/ocaml/opam/issues/4315>

[#4441] <https://github.com/ocaml/opam/pull/4441>

[#4439] <https://github.com/ocaml/opam/issues/4439>

[on the release page]
<https://github.com/ocaml/opam/releases/tag/2.1.0-beta4>


New Plugins
╌╌╌╌╌╌╌╌╌╌╌

  Several features that were formerly plugins have been integrated into
  opam 2.1.0. We have also developed some _new_ plugins that satisfy
  emerging workflows from the community and the core OCaml team. They
  are available for use with the opam 2.1 beta as well, and feedback on
  them should be directed to the respective GitHub trackers for those
  plugins.


opam compiler
┄┄┄┄┄┄┄┄┄┄┄┄┄

  The [`opam compiler'] plugin can be used to create switches from
  various sources such as the main opam repository, the ocaml-multicore
  fork, or a local development directory. It can use Git tag names,
  branch names, or PR numbers to specify what to install.

  Once installed, these are normal opam switches, and one can install
  packages in them. To iterate on a compiler feature and try opam
  packages at the same time, it supports two ways to reinstall the
  compiler: either a safe and slow technique that will reinstall all
  packages, or a quick way that will just overwrite the compiler in
  place.


[`opam compiler'] <https://github.com/ocaml-opam/opam-compiler>


opam monorepo
┄┄┄┄┄┄┄┄┄┄┄┄┄

  The [`opam monorepo'] plugin lets you assemble standalone dune
  workspaces with your projects and all of their opam dependencies,
  letting you build it all from scratch using only Dune and OCaml. This
  satisfies the “monorepo” workflow which is commonly requested by large
  projects that need all of their dependencies in one place. It is also
  being used by projects that need global cross-compilation for all
  aspects of a codebase (including C stubs in packages), such as the
  MirageOS unikernel framework.


[`opam monorepo'] <https://github.com/ocamllabs/opam-monorepo>


Next Steps
╌╌╌╌╌╌╌╌╌╌

  This is anticipated to be the final beta in the 2.1 series, and we
  will be moving to release candidate status after this. We could really
  use your help with testing this release in your infrastructure and
  projects and let us know if you run into any blockers. If you have
  feature requests, please also report them on [our issue tracker] – we
  will be planning the next release cycle once we ship opam 2.1.0
  shortly.


[our issue tracker] <https://github.com/ocaml/opam/issues>


Set up OCaml 1.1.6
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-6/7276/1>


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

  This release includes a change to make the OCaml CI workflow on
  Windows faster!

        I tested this on one of my repos where the build itself is
        mere seconds. Before this change, setup-ocaml needed an
        average of 5:39 to install OCaml+opam and 1:53 to build
        the dependencies of the library. After this change, it
        needs an average of 3:15 for the installation and 1:27 for
        the deps.


Changed
╌╌╌╌╌╌╌

  • Windows installs Cygwin to `D:\cygwin', using faster Azure temporary
    storage.

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.6>


Set up OCaml 1.1.7
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-7/7279/1>


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

Changed
╌╌╌╌╌╌╌

  • Ubuntu and macOS runners no longer display "No switch is currently
    installed." before building the compiler.
  • Ubuntu no longer installs the system ocaml packages.
  • macOS no longer builds two compilers on every run.
  • Upgrade opam to 2.0.8 for Linux VMs.

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.7>


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: 32262 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-02-02 13:56 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-02-02 13:56 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of January 26 to
February 02, 2021.

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

release 0.2.2 of ppx_deriving_encoding
OCaml 4.12.0, second beta release
OCaml Office Hours?
Timere 0.1.3 - Dealing with time and time zones have never been easier
Interesting OCaml Articles
json-data-encoding 0.9
ocamlearlybird 1.0.0 beta1
Cmdliner cheatsheet
containers 3.2
OCaml Café: Thu, Feb 11 @ 7pm (U.S. Central)
Dependency graph of some OCaml source files
Other OCaml News
Old CWN


release 0.2.2 of ppx_deriving_encoding
══════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-0-2-2-of-ppx-deriving-encoding/7169/1>


levillain.maxime announced
──────────────────────────

  Following the release of [json-data-encoding.0.9], I am happy to
  announce the release of ppx_deriving_encoding.0.2.2.

  The code source and some documentation is available on [gitlab], and
  the package can be installed with opam (`opam install
  ppx_deriving_encoding').

  This ppx allows to derive encoding of json-data-encoding library from
  most of ocaml types.

  Have fun!


[json-data-encoding.0.9]
<https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157>

[gitlab] <https://gitlab.com/o-labs/ppx_deriving_encoding>


OCaml 4.12.0, second beta release
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-12-0-second-beta-release/7171/1>


octachron announced
───────────────────

  The release of OCaml 4.12.0 is on the horizon. We have created a new
  beta version to help you adapt your software to the new features ahead
  of the release.

  Compared to the first beta release, this new release contains one fix
  for the Thread library (for a race condition on Windows), and
  experimentally re-enables building the compiler on illumos and Oracle
  Solaris.

  We are expecting this beta to be the last one before the release.

  If you find any bugs, please report them here:
   <https://github.com/ocaml/ocaml/issues>

  Happy hacking,

  – Florian Angeletti for the OCaml team.


Installation instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.12.0~beta2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  If you want to tweak the configuration of the compiler, you can pick
  configuration options with
  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~beta2+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where <option_list> is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and afl enabled switch:
  ┌────
  │ opam switch create 4.12.0~beta2+flambda+afl
  │ --packages=ocaml-variants.4.12.0~beta2+options,ocaml-option-flambda,ocaml-option-afl
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with "opam search ocaml-option".

  The source code is available at these addresses:

  • <https://github.com/ocaml/ocaml/archive/4.12.0-beta2.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~beta2.tar.gz>

  If you want to test this version, you may want to install the alpha
  opam repository

  <https://github.com/kit-ty-kate/opam-alpha-repository>

  with
  ┌────
  │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
  └────
  This alpha repository contains various packages patched with fixes in
  the process of being upstreamed. Once the repository installed, these
  patched packages will take precedence over the non-patched version.


Changes from the first beta
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Thread library
┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • *additional fixes* [9757], [9846], +[10161]: check proper ownership
     when operating over mutexes. Now, unlocking a mutex held by another
     thread or not locked at all reliably raises a Sys_error exception.
     Before, it was undefined behavior, but the documentation did not
     say so. Likewise, locking a mutex already locked by the current
     thread reliably raises a Sys_error exception.  Before, it could
     deadlock or succeed (and do recursive locking), depending on the
     OS. (Xavier Leroy, report by Guillaume Munch-Maccagnoni, review by
     Guillaume Munch-Maccagnoni, David Allsopp, and Stephen Dolan)


[9757] <https://github.com/ocaml/ocaml/issues/9757>

[9846] <https://github.com/ocaml/ocaml/issues/9846>

[10161] <https://github.com/ocaml/ocaml/issues/10161>


Build system
┄┄┄┄┄┄┄┄┄┄┄┄

  • [10063]: (Re-)enable building on illumos (SmartOS, OmniOS, …) and
    Oracle Solaris; x86_64/GCC and 64-bit SPARC/Sun PRO C
    compilers. (partially revert [2024]). (Tõivo Leedjärv and Konstantin
    Romanov, review by Gabriel Scherer, Sébastien Hinderer and Xavier
    Leroy)


[10063] <https://github.com/ocaml/ocaml/issues/10063>

[2024] <https://github.com/ocaml/ocaml/issues/2024>


Documentation
┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [9755]: Manual: post-processing the html generated by ocamldoc and
    hevea. Improvements on design and navigation, including a mobile
    version, and a quick-search functionality for the API. (San Vũ Ngọc,
    review by David Allsopp and Florian Angeletti)

  • [10142], [10154]: improved rendering and latex code for toplevel
    code examples. (Florian Angeletti, report by John Whitington, review
    by Gabriel Scherer)


[9755] <https://github.com/ocaml/ocaml/issues/9755>

[10142] <https://github.com/ocaml/ocaml/issues/10142>

[10154] <https://github.com/ocaml/ocaml/issues/10154>


OCaml Office Hours?
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-office-hours/7132/9>


Deep in this thread, Orbifx said
────────────────────────────────

  And there is XMPP: <xmpp:ocaml@conference.orbitalfox.eu?join>


Timere 0.1.3 - Dealing with time and time zones have never been easier
══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-timere-0-1-3-dealing-with-time-and-time-zones-have-never-been-easier/7173/1>


Darren announced
────────────────

  I am happy to announce first release of [Timere], a time handling and
  reasoning library, which @Drup and I have been working on recently.


[Timere] <https://github.com/daypack-dev/timere>

Examples
╌╌╌╌╌╌╌╌

  Christmases which fall on Wednesday from now
  ┌────
  │ let () =
  │   let open Timere in
  │   match
  │     resolve (
  │       after (Date_time.now ())
  │       & months [`Dec]
  │       & days [25]
  │       & weekdays [`Wed]
  │     )
  │   with
  │   | Error msg -> failwith msg
  │   | Ok s ->
  │     Fmt.pr "%a@." (pp_intervals ~sep:(Fmt.any "@.") ()) s
  └────
  gives
  ┌────
  │ [2024 Dec 25 00:00:00 +00:00:00, 2024 Dec 26 00:00:00 +00:00:00)
  │ [2030 Dec 25 00:00:00 +00:00:00, 2030 Dec 26 00:00:00 +00:00:00)
  │ [2041 Dec 25 00:00:00 +00:00:00, 2041 Dec 26 00:00:00 +00:00:00)
  │ [2047 Dec 25 00:00:00 +00:00:00, 2047 Dec 26 00:00:00 +00:00:00)
  │ [2052 Dec 25 00:00:00 +00:00:00, 2052 Dec 26 00:00:00 +00:00:00)
  │ [2058 Dec 25 00:00:00 +00:00:00, 2058 Dec 26 00:00:00 +00:00:00)
  │ ...
  └────

  See [here] for more examples


[here] <https://github.com/daypack-dev/timere/tree/main/examples>


Features
╌╌╌╌╌╌╌╌

  • Timestamp and date time handling with platform independent time zone
    support
    • Subset of the IANA time zone database is built into this library
  • Reasoning over time intervals via timere objects/expressions,
    examples:
    • Pattern matching time and intervals. These work across DST
      boundaries.
    • Intersection and union
    • Chunking at year or month boundary, or in fixed sizes
    • Evaluate (sub)expressions with a different time zone
      (e.g. intersection of 9am to 5pm of Sydney and 9am to 5pm of New
      York)


Links
╌╌╌╌╌

  • Repo: <https://github.com/daypack-dev/timere>
  • API doc:
    <https://daypack-dev.github.io/timere/timere/Timere/index.html>


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/92>


Yawar Amin announced
────────────────────

  Not primarily a programming article but I thought this is an
  interesting exception because it may be the first time OCaml has been
  mentioned in the Financial Times:
  <https://www.ft.com/content/81811f27-4a8f-4941-99b3-2762cae76542>


json-data-encoding 0.9
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157/2>


Raphaël Proust announced
────────────────────────

  On behalf of Nomadic Labs, it is my pleasure to release
  json-data-encoding.0.9.1. The code of this packaging-fix release is
  identical to the recent json-data-encoding.0.9 but the license
  information has been corrected.

  The previous release had _LGPL with linking exception_ headers in the
  source files, LICENSE file in the repository, and license field in the
  opam file. However, the code was actually under MIT as per agreement
  of the copyright holders. Release 0.9.1 has the correct license
  headers, LICENSE file and license field in the opam files.

  The code of 0.9/0.9.1 is in dual license. Future releases will be
  under MIT license only.


ocamlearlybird 1.0.0 beta1
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocamlearlybird-1-0-0-beta1/7180/1>


文宇祥 announced
────────────────

  I'm pleased to annonce that [ocamlearlybird] 1.0.0~beta1 just
  released.  Will soon be available on opam.

  This is a big step that we toward 1.0.0. We solved lots of issues and
  tested with realy ocaml projects such as utop, ocamlformat, and so
  on. And certainly, it can debug ocamlearlybird itself.

  Try yourself!


[ocamlearlybird] <https://github.com/hackwaly/ocamlearlybird>

NOTES.
╌╌╌╌╌╌

  • New version only support OCaml 4.11. If you need other versions
    support, please let me know.
  • Dune-release do not support `1.0.0~beta1' version string. So we
    released 1.0.0 as 1.0.0~beta1 on opam.


KNOWN ISSUES:
╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Continue run command may hit on last removed breakpoint once when
    debug utop.


文宇祥
──────

  Since the post has edited over 3 times. I can't edit it anyway. I
  uploaded demo video here:

  [Debug utop]


[Debug utop]
<https://media.githubusercontent.com/media/hackwaly/ocamlearlybird/master/_assets/utop.webp>


Cmdliner cheatsheet
═══════════════════

  Archive: <https://discuss.ocaml.org/t/cmdliner-cheatsheet/7185/1>


Martin Jambon announced
───────────────────────

  As a follow-up to [an earlier conversation], I made a [cheatsheet and
  a template] for using cmdliner by @dbuenzli. It was done quickly and I
  don't know everything about cmdliner, so please let me know if you see
  mistakes.


[an earlier conversation]
<https://discuss.ocaml.org/t/what-are-some-libraries-you-almost-always-use/7165/17?u=mjambon>

[cheatsheet and a template]
<https://github.com/mjambon/cmdliner-cheatsheet>


Christian Lindig then said
──────────────────────────

  Good to see this. I believe a common use case is to add are sub
  commands as popularised by `git'. It looks like this in my code:

  ┌────
  │ module C = Cmdliner
  │ 
  │ let report =
  │   let doc = "generate HTML or JSON report for an outing" in
  │   let man = ..   in
  │   C.Term.
  │     (ret (const make $ common_options $ json $ path), info "report" ~doc ~man)
  │ 
  │ let default =
  │   let help = `Help (`Pager, None) in
  │   let doc = "GPS analysis for rowers" in
  │  C.Term.(ret @@ const help, info "eightplus" ~doc ~man)
  │ 
  │ let cmds = [ export; report; topspeed; debug; summary; help ]
  │ let main () = C.Term.(eval_choice default cmds |> exit)
  │ let () = if !Sys.interactive then () else main ()
  └────


Martin Jambon later said
────────────────────────

  I just added a demo/template for subcommand handling. There are now
  [two demo programs]. One is focused on the different kinds of
  arguments and the other one on subcommands.


[two demo programs]
<https://github.com/mjambon/cmdliner-cheatsheet/tree/main/src>


Shon also replied
─────────────────

  In this same vein, I've been compiling "executable notes" whenever I
  find myself needing a certain Cmdlner recipe. I took took these recent
  discussion as an occasion to document the module a bit:
  <https://github.com/shonfeder/kwdcmd>

  The aim is to provide "self-documenting" constructors that encode the
  composition of common CLI terms into module namespaces, labeled args,
  and type aliases. The hope being that I can have the type signature of
  a combinator give me all the hints I need to avoid having to look up
  the documentation every time :laughing:

  It's just a very rough (and quite imperfect) collection of idioms I've
  found useful, but it could be worth a look!  When i get a chance, I
  hope to look through your cheat sheet to make sure I have a
  representative constructor for each idiom you've documented.


containers 3.2
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-containers-3-2/7196/1>


Simon Cruanes announced
───────────────────────

  I'm happy to announce that containers 3.2 has just been [released]. It
  should arrive on opam soon. It notably contains an `Either'
  compatibility wrapper, more formatting functions, list functions, and
  a bunch of fixes. Many thanks to @darrenldl for contributing some
  initial fuzzing support.


[released]
<https://github.com/c-cube/ocaml-containers/releases/tag/v3.2>


OCaml Café: Thu, Feb 11 @ 7pm (U.S. Central)
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-cafe-thu-feb-11-7pm-u-s-central/7197/1>


Claude Jager-Rubinson announced
───────────────────────────────

  Join us with your questions about the OCaml language, or just to hang
  out with the OCaml community. Especially geared toward new and
  intermediate users, experienced OCaml developers will be available to
  answer your questions about the language and ecosystem.

  Whether you’re still trying to make sense of currying or can spot
  non-tail-recursive code from across the room, we hope that you’ll join
  us on Thursday, February 11 at 7pm (U.S. Central time). Meeting info
  and additional details can be found at [https://hfpug.org].


[https://hfpug.org] <https://hfpug.org>


Dependency graph of some OCaml source files
═══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dependency-graph-of-some-ocaml-source-files/7198/6>


Deep in this thread, Jun FURUSE said
────────────────────────────────────

  You may be interested in [cmgraph] which scrapes the compiled modules
  (`*.cmi/*.cmo/*.cmx') instead of the source code.  It needs no
  compilation switch options since it does not scrape source code.


[cmgraph] <https://gitlab.com/camlspotter/cmgraph>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Recent and upcoming changes to Merlin]
  • [The road ahead for MirageOS in 2021]
  • [Release of Alt-Ergo 2.4.0]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Recent and upcoming changes to Merlin]
<https://tarides.com/blog/2021-01-26-recent-and-upcoming-changes-to-merlin>

[The road ahead for MirageOS in 2021] <https://hannes.nqsb.io/Posts/NGI>

[Release of Alt-Ergo 2.4.0]
<https://www.ocamlpro.com/2021/01/22/release-of-alt-ergo-2-4-0/>


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: 37092 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-26 13:25 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-01-26 13:25 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of January 19 to 26,
2021.

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

How to get pleasant documentation for a library using Dune?
Alt-Ergo 2.4.0 release
First release of Art - Adaptive Radix Tree in OCaml
perf demangling of OCaml symbols (and a short introduction to perf)
Decimal 0.2.1 - arbitrary-precision decimal floating point
Basic GitLab CI configuration
OCaml Office Hours?
json-data-encoding 0.9
VSCode OCaml Platform v1.6.0
release 0.3.0 of drom, the OCaml project creator
Old CWN


How to get pleasant documentation for a library using Dune?
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/how-to-get-pleasant-documentation-for-a-library-using-dune/7121/1>


gasche announced
────────────────

  I'm working to publish a small library using Dune. The documentation
  automatically generated by `dune build @doc' looks fairly unpleasant
  to me, as I don't see an easy way to explain what the library is
  about. I'm creating this topic in case I am missing something simple,
  and to get other people to share their library-documentation practices
  or examples.


Problem description
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  For the sake of the example let's imagine that the library is called
  `Foo' and contains three modules `A', `B' and `C'. I'm using the
  standard dune approach of wrapped modules, so I get three compilation
  units `Foo.A', `Foo.B', `Foo.C'. Each module has a `.mli' file with
  documentation comments.

  When I run `dune build @doc', dune generates an `index.html' file with
  basically no content, pointing to a `foo/index.html' file with
  basically no content, pointing to a `foo/Foo/index.html' looking like
  this:

        Up – foo » Foo

        *Module `Foo'*

        `module A : sig ... end'

        `module B : sig ... end'

        `module C : sig ... end'

  It's easy to skip the first two pages, and use the third page as a
  landing page for the documentation of my library.  However, this
  landing page is not very pleasant:
  1. It should explain what the library is about.
  2. It should briefly describe what each module does, so that users
     know which module they want to look at first.

  (Point 2 is especially important with "wrapped libraries", where it's
  not necessarily obvious which of the several modules is the main entry
  point with the important functions to look at first. In comparison, in
  a design where the "entry point" is in the `Foo' module, with `Foo.A'
  and `Foo.B' as more advanced submodules (or `Foo_A' and `Foo_B' in the
  old days) the user is guided to look at `Foo' first.)

  My problem is: what should I change in my Dune setup to be able to do
  this?

  I have read the [dune documentation on documentation], but I could not
  find an answer to this question.


[dune documentation on documentation]
<https://dune.readthedocs.io/en/stable/documentation.html>


Rough ideas
╌╌╌╌╌╌╌╌╌╌╌

  Roughly I see two ways to get what I want, that I have not tried yet:
  1. I could write my own landing page for the library as a separate
     `doc.mld' file, use the `(documentation)' stanza to get it included
     in the built documentation, and use this as the entry point into my
     library.
  2. In could write my own `foo.ml' module instead of using Dune's
     default wrapped-module scaffolding, inserting my own `module A =
     Foo__A' aliases, with documentation comments in the standard
     style. Then I suppose that `foo/Foo/index.html' would get this
     content in the way I expect.

  They feel a bit complex to me, and (2) involves the tedious work of
  redoing the wrapping logic myself. I guess that (1) is not so bad, and
  I would be inclined to do this if it was documented somewhere as the
  recommended approach.

  (Maybe there is some odoc option that would help solve this problem?)


Examples from other people?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Do you have a library built using dune with nice documentation? If so,
  can you show the documentation and the corresponding sources (in
  particular dune setup)?


Thibaut Mattio replied
──────────────────────

  I think the documentation of [Streaming] is a great example of the
  option 1 you describe.

  The corresponding Dune setup can be found [here]

  That's also the approach we took for [Opium's documentation], although
  the index page is certainly not as impressive as Streaming's.


[Streaming] <https://odis-labs.github.io/streaming/streaming/index.html>

[here]
<https://github.com/odis-labs/streaming/blob/master/streaming/dune>

[Opium's documentation]
<https://rgrinberg.github.io/opium/opium/index.html>


gasche then said
────────────────

  Thanks! It looks like these systems rely on an undocumented feature of
  the `(documentation)' stanza (or odoc), which is that a user-provided
  `index.mld' file will implicitly replace the automatically-generated
  `index.mld' file, giving a reasonably natural result.

  The opium documentation also [uses] the `{!modules: modulename ...}'
  markup directive, which is a way to include the module index within
  this manually-written landing page without having to duplicate the
  markup. Streaming¹ uses [inline html] instead to get a nicer-looking
  result, but it is too much effort. Maybe there is a better way, or the
  tools could be improved to make this easier.

  ¹: I'm ashamed to admit that I wasn't aware of this very nice library
  [Streaming], am I consuming the wrong sources of information on the
  OCaml ecosystem?

  Finally, the Opium documentation manifestly has a short synopsis for
  each module in its listing, which corresponds to my "It should briefly
  describe what each module does" requirement. I believe that this comes
  from the first line of the first documentation comment of the
  module. There are module-global documentation comments in the library
  I'm working on, but they do not include such first-line headers.

  Once I have the impression of understanding what is a good way to do
  this, I may try to contribute better documentation in `dune'.


[uses]
<https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74>

[inline html]
<https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68>

[Streaming] <https://odis-labs.github.io/streaming/streaming/index.html>


Gabriel Radanne replied
───────────────────────

        It looks like these systems rely on an undocumented
        feature of the `(documentation)' stanza (or odoc), which
        is that a user-provided `index.mld' file will implicitly
        replace the automatically-generated `index.mld' file,
        giving a reasonably natural result.

  I confirm this feature is here to stay, is the right one to customize
  your index page, and in the future will benefit from good support from
  odoc directly.

        The opium documentation also [uses] the `{!modules:
        modulename ...}' markup directive, which is a way to
        include the module index within this manually-written
        landing page without having to duplicate the
        markup. Streaming¹ uses [inline html] instead to get a
        nicer-looking result, but it is too much effort. Maybe
        there is a better way, or the tools could be improved to
        make this easier.

  I would strongly advise to use the `modules' markup directive, and to
  suggests output improvements on odoc's bug instead of hacking HTML
  together. We could absolutely add the synopsis of the module here, for
  instance.


[uses]
<https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74>

[inline html]
<https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68>


Daniel Bünzli then said
───────────────────────

        which is that a user-provided `index.mld' file will
        implicitly replace the automatically-generated `index.mld'
        file, giving a reasonably natural result.

  This is also the correct way to customize the landing page of your
  package for `odig' generated doc sets, see [here] for more
  information.

        I confirm this feature is here to stay, is the right one
        to customize your index page, and in the future will
        benefit from good support from odoc directly.

  There's an open issue about that [here].


[here]
<https://erratique.ch/software/odig/doc/packaging.html#odoc_api_and_manual>

[here] <https://github.com/ocaml/odoc/issues/297>


Alt-Ergo 2.4.0 release
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-alt-ergo-2-4-0-release/7134/1>


OCamlPro announced
──────────────────

  We are pleased to announce a new release of Alt-Ergo!

  Alt-Ergo 2.4.0 is now available from [Alt-Ergo’s website]. An
  associated opam package will be published in the next few days.

  This release contains some major novelties:

  • Alt-Ergo supports incremental commands (push/pop) from the[ smt-lib]
    standard.
  • We switched command line parsing to use[ cmdliner]. You will need to
    use –<option name> instead of -<option name>. Some options have also
    been renamed, see the manpage or the documentation.
  • We improved the online documentation of your solver, available[
    here].

  This release also contains some minor novelties:

  • .mlw and .why extension are depreciated, the use of .ae extension is
    advised.
  • Add –input (resp –output) option to manually set the input (resp
    output) file format
  • Add –pretty-output option to add better debug formatting and to add
    colors
  • Add exponentiation operation, ** in native Alt-Ergo syntax. The
    operator is fully interpreted when applied to constants
  • Fix –steps-count and improve the way steps are counted (AdaCore
    contribution)
  • Add –instantiation-heuristic option that can enable lighter or
    heavier instantiation
  • Reduce the instantiation context (considered foralls / exists) in
    CDCL-Tableaux to better mimic the Tableaux-like SAT solver
  • Multiple bugfixes

  The full list of changes is available [here]. As usual, do not
  hesitate to report bugs, to ask questions, or to give your feedback!


[Alt-Ergo’s website] <https://alt-ergo.ocamlpro.com/>

[ smt-lib] <https://smtlib.cs.uiowa.edu/>

[ cmdliner] <https://erratique.ch/software/cmdliner>

[ here] <https://ocamlpro.github.io/alt-ergo/>

[here] <https://ocamlpro.github.io/alt-ergo/About/changes.html>


First release of Art - Adaptive Radix Tree in OCaml
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-art-adaptive-radix-tree-in-ocaml/7142/1>


Calascibetta Romain announced
─────────────────────────────

  I'm glad to announce the first release of [`art'], an implementation
  of [the Adaptive Radix Tree] in OCaml. The goal of this library is to
  provide a data-structure such as `Map.S' (and keep the order) with
  performances of `Hashtbl.t'.


[`art'] <https://github.com/dinosaure/art>

[the Adaptive Radix Tree] <https://db.in.tum.de/~leis/papers/ART.pdf>

Performances
╌╌╌╌╌╌╌╌╌╌╌╌

  `art' uses [Bechamel] as a tool for micro-benchmarking and it compares
  performances about [insertion] and [lookup]. As you can see, about
  insertion, `art' is definitely more fast than `Hashtbl.t'.

  For the _lookup_ operation, we are slightly more fast than the
  `Hashtbl.t'. The main advantage comparing to `Hashtbl.t' is the
  ability to use `maximum~/~minimum' or to `iter' over the whole
  data-structure with a certain order.

  On details, benchmarks use a normal distribution of `strings' about
  their lengths. As a practical example where `art' will be better than
  `Hashtbl.t' is when you want to _index_ several words (such as email
  addresses).


[Bechamel] <https://github.com/mirage/bechamel>

[insertion] <https://dinosaure.github.io/art/bench/insert.html>

[lookup] <https://dinosaure.github.io/art/bench/find.html>


Tests
╌╌╌╌╌

  Of course, the library provide [a fuzzer] and tests have a coverage
  of: 91.93 %


[a fuzzer] <https://github.com/dinosaure/art/blob/master/fuzz/fuzz.ml>


Read Optimized Write Exclusion - ROWEX
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Even if it's not a part of the package, the distribution comes with
  _lock-free_ implementation of `art': `rowex'.  This implementation
  comes from [a research paper] about data-structure and atomic
  operations.

  ROWEX provides a _persistent_ implementation which manipulates a file
  to store the whole data-structure. The goal is to provide an _indexer_
  free to be manipulated by several processes in parallel.

  Currently, the implementation of ROWEX in OCaml is not well-tested and
  it is no distributed. It does not take the advantage of
  [ocaml-multicore] (but it should) but outcomes are good and the
  development will be more focus on this part.

  So feel free to play with it a bit :+1:.


[a research paper] <https://db.in.tum.de/~leis/papers/artsync.pdf>

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


perf demangling of OCaml symbols (and a short introduction to perf)
═══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-perf-demangling-of-ocaml-symbols-a-short-introduction-to-perf/7143/1>


Fabian announced
────────────────

  As a project sponsored by the [OCaml software foundation], I've worked
  on demangling OCaml symbols in [perf]. Some screenshots are below. The
  work is currently being upstreamed. In the meantime, it can be used as
  follows:

  ┌────
  │ git clone --depth=1 https://github.com/copy/linux.git
  │ # or:
  │ # wget https://github.com/copy/linux/archive/master.tar.gz && tar xfv master.tar.gz
  │ cd linux/tools/perf
  │ make
  │ alias perf=$PWD/perf
  │ # or copy perf to somewhere in your PATH
  └────

  Your distribution's version of perf will also work for the examples
  below, but will have less readable symbols :-)


[OCaml software foundation] <https://ocaml-sf.org/>

[perf] <https://perf.wiki.kernel.org/index.php/Main_Page>

Short intruction to perf
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Perf is a Linux-only sampling profiler (and more), which can be used
  to analyse the performance profile of OCaml and other
  executables. When compiling with ocamlopt, add `-g' to include debug
  information in the executable. dune does this automatically, even in
  the release profile. To start a program and record its profile:
  ┌────
  │ perf record --call-graph dwarf program.exe
  └────
  Or record a running program:
  ┌────
  │ perf record --call-graph dwarf -p `pidof program.exe`
  └────

  Then, view a profile using:
  ┌────
  │ perf report # top-down
  │ perf report --no-children # bottom-up
  └────

  Within the report view, the following keybindings are useful:

  • `+': open/close one callchain level
  • `e': open/close entire callchain
  • `t': Toggle beween current thread and all threads (e.g., only
    `dune', `ocamlopt', etc.)

  Or generate a flamegraph:

  ┌────
  │ git clone https://github.com/brendangregg/FlameGraph
  │ cd FlameGraph
  │ perf script -i path/to/perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > perf-flamegraph.svg
  └────

  You may need to run the following command to allow recording by
  non-root users ([more infos]):
  ┌────
  │ echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid
  └────


[more infos]
<https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html#unprivileged-users>


Sources
╌╌╌╌╌╌╌

  • [Profiling OCaml code]
  • <https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record>
  • <http://www.brendangregg.com/perf.html#FlameGraphs>

  Before:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/95433869e4d55c6c822a096a901483304d44338d_2_1380x602.png>

  After:

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

  Bottom-up:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/0/01042663ccf66e8b955723fae3cd1c6ff9e0b029_2_1380x602.png>

  Flamegraph (cropped):

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/c/c8e3e0f5b9e1d879198892395529ebb3c339c791_2_1380x602.png>


[Profiling OCaml code]
<https://github.com/ocaml-bench/notes/blob/master/profiling_notes.md>


Decimal 0.2.1 - arbitrary-precision decimal floating point
══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/decimal-0-2-1-arbitrary-precision-decimal-floating-point/7144/1>


Yawar Amin announced
────────────────────

  Happy to announce that `decimal' 0.2.1 has been [pubished on opam].

  `decimal' is a port of [Python's `decimal' module] to OCaml and
  implements the [General Decimal Arithmetic Specification]. However
  note that it is a port in progress–basic arithmetic and rounding
  functions have been ported, but I am still working on powers and
  logs. The ported functions pass the same unit test suite that the
  Python version does (with some minor modifications).

  Another caveat: currently the library is only supported on 64-bit
  architectures due to (exponent) overflow issues on 32-bit. If anyone
  is willing to test and fix overflows on 32-bit, I am more than happy
  to accept PRs.

  Here's an example of using the module:

  ┌────
  │ (* Rosetta Code Currency Example *)
  │ 
  │ (* Demo purposes, normally you'd prefix module name or local open *)
  │ open Decimal
  │ 
  │ let hamburger_qty = of_string "4_000_000_000_000_000"
  │ let hamburger_amt = of_string "5.50"
  │ let milkshake_qty = of_int 2
  │ let milkshake_amt = of_string "2.86"
  │ 
  │ (* Shortcut to divide 7.65 by 100 *)
  │ let tax_rate = of_string "7.65e-2"
  │ 
  │ let subtotal = hamburger_qty * hamburger_amt + milkshake_qty * milkshake_amt
  │ let tax = round ~n:2 (subtotal * tax_rate)
  │ let total = subtotal + tax
  │ 
  │ let () = Format.printf "Subtotal: %a
  │      Tax:  %a
  │    Total: %a\n" pp subtotal pp tax pp total
  └────

  You can get the package with: `opam install decimal'. Minimum OCaml
  version 4.08.


[pubished on opam] <http://opam.ocaml.org/packages/decimal/>

[Python's `decimal' module]
<https://docs.python.org/3/library/decimal.html>

[General Decimal Arithmetic Specification]
<http://speleotrove.com/decimal/decarith.html>


Basic GitLab CI configuration
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/basic-gitlab-ci-configuration/3327/25>


gasche announced
────────────────

  After a long ci-golfing adventure (83 tests), I got a `.gitlab-ci.yml'
  file that I think is reusable and useful for small projects /
  libraries:
  • project: <https://gitlab.com/gasche/gitlab-ocaml-ci-example>
  • configuration file:
    <https://gitlab.com/gasche/gitlab-ocaml-ci-example/-/blob/main/.gitlab-ci.yml>

  Features:
  • It is project-agnostic, so it should work unchanged for your own
    (simple) projects.
  • It caches the opam dependencies.
  • It builds the project, runs the tests and builds the documentation.
  • Several compiler versions can be tested in parallel.
  • It provides an easy way to upload the documentation as "Gitlab
    project Pages".

  CI times are satisfying: on very small libraries I observe a 11mn job
  time on the first run (or when cleaning the opam cache), and 2mn job
  time on following runs.

  The expected usage-mode of this CI configuration is that you copy it
  in your own project. If you find that you need/want additional
  features, ideally you would try to write them in a project-agonistic
  way and contribute them back to the example repository.

  This configuration does not use @smondet's trick of generating a
  docker image on the fly. I think this would be an excellent idea to
  get more reliable caching, but it is too complex for me and I don't
  see how to do it in a maintainable and project-agnostic way.


Current status
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I wrote this CI configuration over the week-end, and have not used it
  much. I expect it to keep evolving somewhat before it
  stabilizes. Feedback from other people trying to use the configuration
  would be warmly welcome.


Aside on `_build' caching
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I also implemented caching of dune's `_build' data, inspired by the
  [data-encoding] example of @raphael-proust. I don't need it for my
  small projects (dune build is 3s, compared to 1m setting up the Docker
  image), but I thought it would make the CI configuration scale better
  to larger projects.

  When I tested this CI configuration, I discovered that caching the
  dune `_build' data does not work as well as I had expected. (Tracking
  issue: [dune#4150]).

  I can tell because I am asking dune to tell me about what it is
  rebuilding (`dune build --display short'). I suspect that projects
  that cache the `_build' data *without* logging what dune (re)builds
  are also not caching as much as they think they are.

  (But then maybe the use of a fixed-compiler OPAM image, as
  data-encoding is using, solves the issue.)


[data-encoding]
<https://gitlab.com/nomadic-labs/data-encoding/-/blob/master/.gitlab-ci.yml>

[dune#4150] <https://github.com/ocaml/dune/issues/4150>


official CI template?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I considered submitting this CI configuration as an "OCaml Gitlab CI
  template" to go with the official list of "blessed" CI templates in
  [the documentation]. But reading the [Development guide for Gitlab
  CI/CD templates] convinced me that my CI configuration is nowhere
  ready to serve this role.

  Gitlab developers apparently expect that users will be able to
  "include" those CI templates by pointing to their URL, and then tune
  it for their own use-case (without modifying it) by performing some
  (unreasonable?) inheritance tricks using whatever those configurations
  offers as abstraction/inheritance/extension/overriding
  mechanism. Let's just say that this is next-level CI configuration
  writing, and that my script is not ready for this.


[the documentation]
<https://docs.gitlab.com/ee/ci/examples/README.html#cicd-templates>

[Development guide for Gitlab CI/CD templates]
<https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/cicd/templates.md>


OCaml Office Hours?
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-office-hours/7132/4>


Deep in this thread, UnixJunkie said
────────────────────────────────────

  In addition to mailing lists and discuss, there is also an IRC channel
  where people can interact with some ocaml experts in a more
  "interactive" manner (<irc://irc.freenode.net/#ocaml>)


json-data-encoding 0.9
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157/1>


Raphaël Proust announced
────────────────────────

  On behalf of [Nomadic Labs], I'm happy to announce the release of
  json-data-encoding version 0.9.

  The code is hosted on Gitlab:
  <https://gitlab.com/nomadic-labs/json-data-encoding> It is distributed
  under GNU LGPL with linking exception.  The documentation is available
  online: <https://nomadic-labs.gitlab.io/json-data-encoding/> The
  package is available under opam: `opam install json-data-encoding'

  json-data-encoding is a library to define encoder/decoder values to
  translate OCaml values to JSON and back. It also generates JSON
  schemas so you can document the value representation. It can use
  either Ezjsonm or Yojson as backends.

  The version 0.9 has the following new features:
  • more tests
  • memoisation of fixpoint encoding to avoid repeated computations
  • support for `format' field for string schemas (see
    <https://json-schema.org/understanding-json-schema/reference/string.html#format>)
    (contributed by @levillain.maxime)
  • fixed integer bound printing in schemas (bug report by @pw374)
  • support for json-lexeme streaming (see details below)
  • support for inclusion/exclusion of default-value fields during
    serialisation (contributed by @levillain.maxime)
  • improved union-of-object schemas (contributed by @levillain.maxime)

  One major difference with the previous release is the inclusion of a
  lexeme-streaming JSON constructor. Specifically, the function

  ┌────
  │ val construct_seq : 't encoding -> 't -> jsonm_lexeme Stdlib.Seq.t
  └────

  generates a sequence of `Jsonm.lexeme' (the . This sequence is lazy
  (in the sense of `Stdlib.Seq' not of `Stdlib.Lazy') and it paves the
  way to a similar feature in `data-encoding'. An interesting feature of
  sequences is that they can be used in Vanilla OCaml settings as well
  as Lwt/Async settings where they allow user-driven yielding in between
  elements.


[Nomadic Labs] <https://nomadic-labs.com/>


VSCode OCaml Platform v1.6.0
════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-6-0/7164/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the vscode-ocaml-platform team, I'm pleased to announce
  1.6.0. This release contains a new activity tab for managing opam
  switches developed by @tmattio. We hope you find it useful.

  Change log:

  ┌────
  │ - Highlight token aliases in Menhir associativity declarations (#473)
  │ 
  │ - Activate the extension when workspace contains OCaml, Reason sources or
  │   project marker files. (#482)
  │ 
  │ - Add `ocaml.useOcamlEnv` setting to determine whether to use `ocaml-env` for
  │   opam commands from OCaml for Windows (#481)
  │ 
  │ - Fix terminal creation when using default shell and arguments (#484)
  │ 
  │ - Add an OCaml activity tab.
  │ 
  │   The activity tab provides three views: the available switches, the build
  │   commands and an Help and Feedback section with links to community channels.
  │ 
  │ - Support `eliom` and `eliomi` file extensions (#487)
  │ 
  │ - Fix ocaml/ocaml-lsp#358: automatic insertion of an inferred interface was
  │   inserting code incorrectly on the second switch to the newly created (unsaved)
  │   `mli` file. If the new `mli` file isn't empty, we don't insert inferred
  │   interface (#498)
  └────


release 0.3.0 of drom, the OCaml project creator
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-0-3-0-of-drom-the-ocaml-project-creator/7166/1>


Fabrice Le Fessant announced
────────────────────────────

  We are pleased to release version 0.3.0 of `drom', the OCaml project
  creator.

  `drom' is born from a simple observation: every time you create a new
  OCaml project, you spend time searching and copy-pasting files from
  other projects, adapting them to the new one. `drom' does that for
  you: it comes with a set of predefined skeleton projects, that you can
  easily configure and adapt to your goal.

  It's as easy as:
  ┌────
  │ $ drom new
  │   # check the list of skeletons
  │ $ drom new PROJECT_NAME --skeleton SKELETON_NAME
  │ $ cd PROJECT_NAME
  │ $ emacs drom.toml
  │    # ... edit basic description, dependencies, etc. ...
  │ $ drom project
  │ $ drom build
  └────
  Thanks to contributors (Maxime Levillain and David Declerck), the list
  of project skeletons for drom 0.3.0 has grown:
  • OCaml projects: library menhir mini_lib mini_prg ppx_deriver
    ppx_rewriter program
  • C Bindings: c_binding ctypes_foreign ctypes_stubs
  • Javascript projects: js_lib js_prg vue wasm_binding

  and you can easily contribute your own: for example,
  `gh:USER/SKELETON' will trigger the download of the `USER/SKELETON'
  project from Github as a template for your new project.

  `drom' is available from `opam': `opam update && opam install
  drom.0.3.0'

  <https://github.com/ocamlpro/drom>

  Enjoy !


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-19 14:28 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-01-19 14:28 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of January 12 to 19,
2021.

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

Irmin 2.3.0
Dune 2.8.0
lwt-canceler.0.3
Interesting OCaml Articles
OCaml 4.12.0, first beta release
OCaml for ARM MacOS
Talk on OCaml Batteries at Houston Functional Programmers
Other OCaml News
Old CWN


Irmin 2.3.0
═══════════

  Archive: <https://discuss.ocaml.org/t/ann-irmin-2-3-0/7084/1>


Craig Ferguson announced
────────────────────────

  I'm very happy to announce the release of the Irmin 2.3.0 family of
  packages, including:

  • [`irmin-pack.2.3.0'], a storage backend for Irmin designed for and
    used by Tezos. This release contains a host of performance
    improvements as well as offline CLI features such as integrity
    checking. It also contains a number of high-level design changes,
    which were discussed in a recent [Tarides blog post].

    Finally, `irmin-pack.2.3.0' also contains a prototype of the
    [_layered_] `irmin-pack' store, which provides an [OverlayFS]-esque
    mode of operation for `irmin-pack' in which the causal history of
    the store can be chunked into independently-accessable
    substores. This feature will eventually be deployed in a [future
    version of Tezos].

  • [`irmin-containers'], a collection of pre-defined mergeable data
    structures built using Irmin and compatible with any backend. These
    were originally provided by @kayceesrk as part of [`ezirmin'], and
    has since been modernised and upstreamed by Anirudh S.

  • `irmin-bench', a suite of benchmarks for Irmin for use with
    [`current-bench'], an experimental continuous benchmarking
    infrastructure for OCaml projects. Lots of work has been going on
    behind the scenes to make this a general benchmarking infrastructure
    for the Mirage ecosystem, including a recent [fancy UI overhaul] by
    new contributor @rizo.

  • [`repr'], an extraction of the `Irmin.Type' type representation
    library for use in other packages. This package contains a set of
    combinators for building run-time representations of types, along
    with various generic operations defined over those representations,
    including: equality, comparison, pretty-printing, JSON / binary
    codecs, etc. The API of this library is currently a
    work-in-progress, but we hope to use it more widely in the Mirage
    ecosystem soon.

  • [`semaphore-compat'], an extraction of the `Semaphore' library in
    OCaml 4.12, for libraries that want to maintain compatibility with
    earlier versions of OCaml.

  The full list of changes to Irmin can be found [here].

  Many thanks to our open-source contributors and collaborators. Happy
  hacking!


[`irmin-pack.2.3.0'] <https://www.youtube.com/watch?v=v1lfMUM332w>

[Tarides blog post]
<https://tarides.com/blog/2020-09-08-irmin-september-2020-update>

[_layered_]
<https://gist.github.com/icristescu/1afb7f9f862f8e989b8b6c195908e7d0>

[OverlayFS] <https://en.wikipedia.org/wiki/OverlayFS>

[future version of Tezos]
<https://gitlab.com/tezos/tezos/-/merge_requests/2127>

[`irmin-containers']
<https://mirage.github.io/irmin/irmin-containers/Irmin_containers/index.html>

[`ezirmin'] <https://github.com/kayceesrk/ezirmin>

[`current-bench'] <https://github.com/ocurrent/current-bench/>

[fancy UI overhaul] <https://github.com/ocurrent/current-bench/pull/20>

[`repr'] <https://github.com/mirage/repr>

[`semaphore-compat'] <https://github.com/mirage/semaphore-compat>

[here]
<https://github.com/mirage/irmin/blob/master/CHANGES.md#230-2020-01-12>


Dune 2.8.0
══════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-2-8-0/7090/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the dune, I'm pleased to announce the release of dune
  2.8.0. This release contains many bug fixes, performance improvements,
  and interesting new features. I'll point out two new features that I'm
  most excited about.

  First is the experimental `dune_site' extension that makes it possible
  to register and load plugins at runtime. This feature is quite
  involved, but we've documented it extensively [in the manual].

  Another cool feature is that we've eliminated the need for .merlin
  files and all the caveats that came with them.  Now, merlin talks to
  dune directly to get precise configuration for every module. Say
  goodbye to all those "approximate .merlin file" warnings!

  I encourage everyone to upgrade as soon as possible, as earlier
  versions are not compatible with OCaml 4.12. Happy Hacking.

  Full change log:


[in the manual] <https://dune.readthedocs.io/en/stable/sites.html>

2.8.0 (13/01/2021)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • `dune rules' accepts aliases and other non-path rules (#4063,
    @mrmr1993)

  • Action `(diff reference test_result)' now accept `reference' to be
    absent and in that case consider that the reference is empty. Then
    running `dune promote' will create the reference file. (#3795,
    @bobot)

  • Ignore special files (BLK, CHR, FIFO, SOCKET), (#3570, fixes #3124,
    #3546, @ejgallego)

  • Experimental: Simplify loading of additional files (data or code) at
    runtime in programs by introducing specific installation sites. In
    particular it allow to define plugins to be installed in these
    sites. (#3104, #3794, fixes #1185, @bobot)

  • Move all temporary files created by dune to run actions to a single
    directory and make sure that actions executed by dune also use this
    directory by setting `TMPDIR' (or `TEMP' on Windows). (#3691, fixes
    #3422, @rgrinberg)

  • Fix bootstrap script with custom configuration. (#3757, fixes #3774,
    @marsam)

  • Add the `executable' field to `inline_tests' to customize the
    compilation flags of the test runner executable (#3747, fixes #3679,
    @lubegasimon)

  • Add `(enabled_if ...)' to `(copy_files ...)' (#3756, @nojb)

  • Make sure Dune cleans up the status line before exiting (#3767,
    fixes #3737, @alan-j-hu)

  • Add `{gitlab,bitbucket}' as options for defining project sources
    with `source' stanza `(source (<host> user/repo))' in the
    `dune-project' file.  (#3813, @rgrinberg)

  • Fix generation of `META' and `dune-package' files when some targets
    (byte, native, dynlink) are disabled. Previously, dune would
    generate all archives for regardless of settings. (#3829, #4041,
    @rgrinberg)

  • Do not run ocamldep to for single module executables &
    libraries. The dependency graph for such artifacts is trivial
    (#3847, @rgrinberg)

  • Fix cram tests inside vendored directories not being interpreted
    correctly.  (#3860, fixes #3843, @rgrinberg)

  • Add `package' field to private libraries. This allows such libraries
    to be installed and to be usable by other public libraries in the
    same project (#3655, fixes #1017, @rgrinberg)

  • Fix the `%{make}' variable on Windows by only checking for a `gmake'
    binary on UNIX-like systems as a unrelated `gmake' binary might
    exist on Windows.  (#3853, @kit-ty-kate)

  • Fix `$ dune install' modifying the build directory. This made the
    build directory unusable when `$ sudo dune install' modified
    permissions. (fix #3857, @rgrinberg)

  • Fix handling of aliases given on the command line (using the `@' and
    `@@' syntax) so as to correctly handle relative paths. (#3874, fixes
    #3850, @nojb)

  • Allow link time code generation to be used in preprocessing
    executable. This makes it possible to use the build info module
    inside the preprocessor.  (#3848, fix #3848, @rgrinberg)

  • Correctly call `git ls-tree' so unicode files are not quoted, this
    fixes problems with `dune subst' in the presence of unicode
    files. Fixes #3219 (#3879, @ejgallego)

  • `dune subst' now accepts common command-line arguments such as
    `--debug-backtraces' (#3878, @ejgallego)

  • `dune describe' now also includes information about executables in
    addition to that of libraries. (#3892, #3895, @nojb)

  • instrumentation backends can now receive arguments via
      `(instrumentation (backend <name> <args>))'. (#3906, #3932, @nojb)

  • Tweak auto-formatting of `dune' files to improve
    readability. (#3928, @nojb)

  • Add a switch argument to opam when context is not default. (#3951,
    @tmattio)

  • Avoid pager when running `$ git diff' (#3912, @AltGr)

  • Add `(root_module ..)' field to libraries & executables. This makes
    it possible to use library dependencies shadowed by local modules
    (#3825, @rgrinberg)

  • Allow `(formatting ...)' field in `(env ...)' stanza to set
    per-directory formatting specification. (#3942, @nojb)

  • [coq] In `coq.theory', `:standard' for the `flags' field now uses
    the flags set in `env' profile flags (#3931 , @ejgallego @rgrinberg)

  • [coq] Add `-q' flag to `:standard' `coqc' flags , fixes #3924,
    (#3931 , @ejgallego)

  • Add support for Coq's native compute compilation mode (@ejgallego,
    #3210)

  • Add a `SUFFIX' directive in `.merlin' files for each dialect with no
    preprocessing, to let merlin know of additional file extensions
    (#3977, @vouillon)

  • Stop promoting `.merlin' files. Write per-stanza Merlin
    configurations in binary form. Add a new subcommand `dune
    ocaml-merlin' that Merlin can use to query the configuration
    files. The `allow_approximate_merlin' option is now useless and
    deprecated. Dune now conflicts with `merlin < 3.4.0' and
    `ocaml-lsp-server < 1.3.0' (#3554, @voodoos)

  • Configurator: fix a bug introduced in 2.6.0 where the configurator
    V1 API doesn't work at all when used outside of dune. (#4046,
    @aalekseyev)

  • Fix `libexec' and `libexec-private' variables. In cross-compilation
    settings, they now point to the file in the host context. (#4058,
    fixes #4057, @TheLortex)

  • When running `$ dune subst', use project metadata as a fallback when
    package metadata is missing. We also generate a warning when `(name
    ..)' is missing in `dune-project' files to avoid failures in
    production builds.

  • Remove support for passing `-nodynlink' for executables. It was
    bypassed in most cases and not correct in other cases in particular
    on arm32.  (#4085, fixes #4069, fixes #2527, @emillon)

  • Generate archive rules compatible with 4.12. Dune longer attempt to
    generate an archive file if it's unnecessary (#3973, fixes #3766,
    @rgrinberg)

  • Fix generated Merlin configurations when multiple preprocessors are
    defined for different modules in the same folder. (#4092, fixes
    #2596, #1212 and #3409, @voodoos)

  • Add the option `use_standard_c_and_cxx_flags' to `dune-project' that
    1.  disables the unconditional use of the `ocamlc_cflags' and
    `ocamlc_cppflags' from `ocamlc -config' in C compiler calls, these
    flags will be present in the `:standard' set instead; and 2. enables
    the detection of the C compiler family and populates the `:standard'
    set of flags with common default values when building CXX
    stubs. (#3875, #3802, fix #3718 and #3528, @voodoos)


lwt-canceler.0.3
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-lwt-canceler-0-3/7092/1>


Raphaël Proust announced
────────────────────────

  On behalf of [Nomadic Labs], I'm happy to announce the release of
  Lwt-canceler version 0.3. Lwt-canceler is a small library to help
  programs written using Lwt to synchronise promises around resource
  clean-up. This library was developed as part of the [Tezos codebase]
  before being released.

  With this version, the code has matured significantly (including
  tests, documentation and some refactoring); the next release will
  probably be a version 1.0 at which point a more robust versioning
  scheme will be used.

  The documentation is available online:
  <https://nomadic-labs.gitlab.io/lwt-canceler/lwt-canceler/Lwt_canceler/index.html>
  The code is released under MIT License and hosted on Gitlab:
  <https://gitlab.com/nomadic-labs/lwt-canceler> The new version is
  available on opam: `opam install lwt-canceler'

  Happy hacking!


[Nomadic Labs] <https://nomadic-labs.com/>

[Tezos codebase] <https://gitlab.com/tezos/tezos>


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/90>


Weng Shiwei announced
─────────────────────

  Let me share my new blog post on understanding `format6' with
  examples.  <https://blog.tail.moe/2021/01/13/format6.html>

  It's almost my reading note for the paper Format Unraveled (on module
  Format) and experiments on utop. I tried not to be too verbose though.


Weng Shiwei later said
──────────────────────

  Well, I made a sequel of `format6' post, *Understanding `format6' in
  OCaml by diagrams*
  <https://blog.tail.moe/2021/01/15/format6-diagram.html>

  This time I just use four examples with four diagrams e.g. it's the
  one for `Scanf.sscanf'

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/f/f18093391072f739d70c68c2ccf4be92441078c2_2_1034x432.png>

  p.s. It's a pity that I missed Gabriel's post [The 6 parameters of
  (’a, ’b, ’c, ’d, ’e, ’f) format6] after writing that one.


[The 6 parameters of (’a, ’b, ’c, ’d, ’e, ’f) format6]
<http://gallium.inria.fr/blog/format6/>


OCaml 4.12.0, first beta release
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-12-0-first-beta-release/7099/1>


octachron announced
───────────────────

  The release of OCaml 4.12.0 is close.

  The set of new features has been stabilized, and core opam packages
  already work with this release. After three alpha releases, we have
  created a first beta version to help you adapt your software to the
  new features ahead of the release. Compared to the last alpha, this
  beta contains only three new bug fixes and one change to the standard
  library.

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.12.0~beta1 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────

  If you want to tweak the configuration of the compiler, you can pick
  configuration options with
  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~beta1+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where <option_list> is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and afl enabled switch:
  ┌────
  │ opam switch create 4.12.0~beta1+flambda+afl
  │ --packages=ocaml-variants.4.12.0~beta1+options,ocaml-option-flambda,ocaml-option-afl
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with "opam search ocaml-option".

  The source code is available at these addresses:

  • <https://github.com/ocaml/ocaml/archive/4.12.0-beta1.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~beta1.tar.gz>

  If you want to test this version, you may want to install the alpha
  opam repository

  <https://github.com/kit-ty-kate/opam-alpha-repository>

  with

  opam repo add alpha
  git://github.com/kit-ty-kate/opam-alpha-repository.git

  This alpha repository contains various packages patched with fixes in
  the process of being upstreamed. Once the repository installed, these
  patched packages will take precedence over the non-patched version.

  If you find any bugs, please report them here:
   <https://github.com/ocaml/ocaml/issues>


Changes from the third alpha release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Postponed features
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [9533], [10105], [10127] : Added String.starts_with and
    String.ends_with. (Bernhard Schommer, review by Daniel Bünzli,
    Gabriel Scherer and Alain Frisch)


[9533] <https://github.com/ocaml/ocaml/issues/9533>

[10105] <https://github.com/ocaml/ocaml/issues/10105>

[10127] <https://github.com/ocaml/ocaml/issues/10127>


Additional bug fixes
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [9096], [10096]: fix a 4.11.0 performance regression in
    classes/objects declared within a function (Gabriel Scherer, review
    by Leo White, report by Sacha Ayoun)

  • [10106], [10112]: some expected-type explanations where forgotten
    after some let-bindings (Gabriel Scherer, review by Thomas Refis and
    Florian Angeletti, report by Daniil Baturin)

  • [9326], [10125]: Gc.set incorrectly handles the three `custom_*'
    fields, causing a performance regression (report by Emilio Jesús
    Gallego Arias, analysis and fix by Stephen Dolan, code by Xavier
    Leroy, review by Hugo Heuzard and Gabriel Scherer)


[9096] <https://github.com/ocaml/ocaml/issues/9096>

[10096] <https://github.com/ocaml/ocaml/issues/10096>

[10106] <https://github.com/ocaml/ocaml/issues/10106>

[10112] <https://github.com/ocaml/ocaml/issues/10112>

[9326] <https://github.com/ocaml/ocaml/issues/9326>

[10125] <https://github.com/ocaml/ocaml/issues/10125>


OCaml for ARM MacOS
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-for-arm-macos/6019/23>


Deep in this thread, Xavier Leroy said
──────────────────────────────────────

  It's quite easy to get up to speed using the precompiled OPAM binary
  for macOS/ARM64.

  • Download [opam-2.0.7-arm64-macos].

  • Move it to some directory in your PATH, rename it to `opam', and
    make it executable.  From a Terminal window:
  ┌────
  │ mv ~/Downloads/opam-2.0.7-arm64-macos /usr/local/bin/opam
  │ chmod +x /usr/local/bin/opam
  └────

  • Try to execute it: `opam init'.  You will be blocked by the macOS
    security checks, as the binary is not signed.

  • Open Preferences / Security and Privacy.  There should be a notice
    "opam was blocked because…" and an "Allow Anyway" button.  Click on
    that button.

  • Try again to execute `opam init'.  You will be blocked again, but
    now there is an "Open" button.  Click on that button. `opam init'
    should run and install the OCaml 4.10.2 compiler.

  • From now on, you can run `opam' without being blocked.  Use this
    freedom to `opam install' the packages you need.

  • Some packages that depend on external C libraries may fail to
    install because these C libraries are not available. Normally we
    would rely on Homebrew or MacPorts to provide these C libraries, but
    these package collections are still being ported to macOS/ARM64.

  As a reward for these minor inconveniences, you'll get excellent
  performance running OCaml software such as Coq.  Single-core
  performance on a MacBook Air M1 is 20% better than the best x86
  workstation I have access to.


[opam-2.0.7-arm64-macos]
<https://github.com/ocaml/opam/releases/download/2.0.7/opam-2.0.7-arm64-macos>


Talk on OCaml Batteries at Houston Functional Programmers
═════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/talk-on-ocaml-batteries-at-houston-functional-programmers/7103/1>


Claude Jager-Rubinson announced
───────────────────────────────

  @UnixJunkie will be speaking (virtually, of course) on *OCaml
  Batteries Included* at Houston Functional Programmers, this coming
  Wednesday, Jan 20 at 7pm (U.S. Central time).  His talk will cover
  Batteries' history, place within the OCaml ecosystem, and comparisons
  with OCaml's other alternative standard libraries.  All are welcome to
  join us, even if you're not from Houston.  Complete details and Zoom
  info are at [hfpug.org].


[hfpug.org] <https://hfpug.org>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Coq 8.13.0 is out]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Coq 8.13.0 is out] <https://coq.inria.fr/news/coq-8-13-0-is-out.html>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-12  9:47 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-01-12  9:47 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of January 05 to 12,
2021.

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

Marshal determinism and stability
Sedlex + Menhir parser for both tty and file parsing
First release of awa-ssh
Introducing Feather: A lightweight shell-scripting library for OCaml
postdoc researcher and research engineer positions for CHERI and Arm verification
First ocb (OCaml Badgen) release
Release of OCaml-Git v3.0 and co
Other OCaml News
Old CWN


Marshal determinism and stability
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/marshal-determinism-and-stability/7041/28>


Continuing this thread, David Allsopp said
──────────────────────────────────────────

  A couple of notes on `Marshal', which I don't think have been covered
  • Although the guarantee is only between identical versions of OCaml,
    the implementation actually goes to considerable lengths to maintain
    backwards compatibility (so a value _written_ by older OCaml remains
    _readable_ in newer OCaml). Our own testsuite, for example,
    indirectly [includes a test which unmarshals a 3.12.1 value]. I
    don't know exactly how far back the support goes.
  • As it happens, the change which affected Unison in 4.08 was the
    first breaking change to Marshal since either 4.00 or 4.01. The fact
    that it doesn't break often (and that the two code paths - at least
    at present - are small) meant I have suggested a few months back
    that we could in future add an additional flag in the style of
    `Compat_32' to allow values to be written in a way which should be
    readable on older versions of OCaml. Indeed, it's small enough that
    flags could be added for the changes in 4.08 ([PR#1683]) and in 4.11
    ([PR#8791]).
  • Neither point undermines using alternative formats either for
    network serialisation or persistent storage, for the many reasons
    discussed above!


[includes a test which unmarshals a 3.12.1 value]
<https://github.com/ocaml/ocaml/blob/trunk/testsuite/tests/lib-hashtbl/compatibility.ml>

[PR#1683] <https://github.com/ocaml/ocaml/pull/1683>

[PR#8791] <https://github.com/ocaml/ocaml/pull/8791>


Sedlex + Menhir parser for both tty and file parsing
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/sedlex-menhir-parser-for-both-tty-and-file-parsing/7055/1>


Bernard Sufrin announced
────────────────────────

  I am a great fan of Menhir, and have used it in several private
  language projects, using the ulexing scanner generator to provide
  Unicode-capable scanners.

  Alarmed by the obsolescence of ulexing, and needing a utf8-capable
  scanner in a hurry I decided to (teach myself to) use Sedlex. On the
  whole the experience was very satisfactory, and I found it
  straightforward to produce a variant of the sedlexing library which
  supports buffers with variable chunk sizes, thereby enabling efficient
  lexing on channels connected to files as well as immediately
  responsive lexing on channels connected to terminals.

  I also wanted to teach myself how to use the error-reporting,
  incremental, interfaces to Menhir-generated parsers. In the hope that
  it might be useful to others facing the same learning task, or the
  problem of adapting Sedlex for efficient interactive use, I have
  placed the example mock-S-Expression parser that resulted from this
  excursion in:

  [Git Repository: github.com/sufrin/InteractiveSedlexMenhirExample]


[Git Repository: github.com/sufrin/InteractiveSedlexMenhirExample]
<https://github.com/sufrin/InteractiveSedlexMenhirExample>


First release of awa-ssh
════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh/7057/1>


Hannes Mehnert announced
────────────────────────

  I'm happy to announce that `awa-ssh'
  (<https://github.com/mirage/awa-ssh>) has just been merged into
  opam-repository. It is a pure OCaml implementation of the ssh (secure
  shell, <https://en.wikipedia.org/wiki/SSH_(Secure_Shell)>) protocol.

  This is the initial release, please report issues you encounter.

  It was initially developed by Christiano Haesbaert in 2016, and
  revived mid-2019 by myself and in 2020 it was migrated to the MirageOS
  organization on GitHub for further development and maintenance.

  Both client and server code are present in the library (pure code in
  the main awa package), though the awa-lwt package implements only a
  server, and the awa-mirage package implements only a client. Tests and
  examples are in the test subdirectory.

  The MirageOS client has been successfully used to clone git
  repositories (on private servers, on GitHub, etc.). It supports apart
  from RSA keys also ED25519 keys (and key exchanges).


Introducing Feather: A lightweight shell-scripting library for OCaml
════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/introducing-feather-a-lightweight-shell-scripting-library-for-ocaml/7059/1>


Charles announced
─────────────────

  I wrote a shell scripting library called [Feather]. I like idea of
  writing bash-like code quickly, later being able to intersperse OCaml
  to add more typeful components as needed. It's kind of like [Shexp]
  but without the monadic interface and with Async
  support. ([Feather_async])

  There's a tutorial and some examples in the link above but here's a
  quick taste:

  ┌────
  │ open Feather
  │ 
  │ let lines = find "." ~name:"*.ml"
  │   |. tr "/" "\n"
  │   |. map_lines ~f:String.capitalize
  │   |. sort
  │   |. process "uniq" [ "-c" ]
  │   |. process "sort" [ "-n" ]
  │   |. tail 4
  │   |> collect_lines
  │ in
  │ String.concat ~sep:", " lines |> print_endline
  └────
  Let me know if you have any feedback! And feel free to file bug
  reports [here]. Hope it ends up being useful, entertaining, or both!


[Feather] <https://hg.sr.ht/~etc/feather>

[Shexp] <https://github.com/janestreet/shexp/>

[Feather_async] <https://hg.sr.ht/~etc/feather_async>

[here] <https://todo.sr.ht/~etc/feather>


postdoc researcher and research engineer positions for CHERI and Arm verification
═════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2021-01/msg00023.html>


Peter Sewell announced
──────────────────────

  We are looking for postdoctoral researchers and postdoctoral or
  postgraduate research engineers to help develop semantics and
  verification to improve the foundations and security of mainstream
  computer systems, for CHERI and Arm system software verification, at
  the University of Cambridge.  OCaml expertise to help develop
  verification tools will be especially welcome. Closing date 13 January
  2021 - see the advert <http://www.jobs.cam.ac.uk/job/28012/>.


First ocb (OCaml Badgen) release
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-ocb-ocaml-badgen-release/7073/1>


zapashcanon announced
─────────────────────

  A few days ago, I released [ocb]. It's a library and a command-line
  tool to generate SVG badges.

  To get started quickly:

  ┌────
  │ ocb --label Hello --color green --style flat --labelcolor white --status Goodbye
  └────

  Will gives this result: [SVG example].

  My first use case was [To.ml] where I'm using [bisect_ppx] to generate
  and deploy a [coverage report]. I wanted to display the coverage
  percentage in the README and tried existing tools but wasn't fully
  satisfied as they didn't work or were failing randomly. Now, [I'm
  generating the badge directly in a GitHub action].

  The project was inspired by [badgen]. I still have to add support for
  icons and to improve the documentation but it's usable.


[ocb] <https://github.com/ocamlpro/ocb>

[SVG example]
<https://raw.githubusercontent.com/OCamlPro/ocb/master/example/cli.svg>

[To.ml] <https://github.com/ocaml-toml/To.ml>

[bisect_ppx] <https://github.com/aantron/bisect_ppx>

[coverage report] <https://ocaml-toml.github.io/To.ml/coverage/>

[I'm generating the badge directly in a GitHub action]
<https://github.com/ocaml-toml/To.ml/blob/6ac580848ad1d34ec3032da8672bbd9aca203cc4/.github/workflows/deploy.yml#L34>

[badgen] <https://github.com/badgen/badgen>


Release of OCaml-Git v3.0 and co
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-of-ocaml-git-v3-0-and-co/7076/1>


Ulugbek Abdullaev announced
───────────────────────────

  We, the [`ocaml-git'] team, are happy to announce a new major release
  of `ocaml-git v3.0' and related libraries.


[`ocaml-git'] <https://github.com/mirage/ocaml-git>

Release Notes
╌╌╌╌╌╌╌╌╌╌╌╌╌

OCaml-Git v3.0
┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  [*OCaml-Git*] is a library that implements `git' format and protocol
  implementation in pure OCaml. The library is used by libraries such as
  [`irmin'], a git-like distributed database, or [`pasteur'], a MirageOS
  unikernel-based snippet storage service.


[*OCaml-Git*] <https://github.com/mirage/ocaml-git>

[`irmin'] <https://github.com/mirage/irmin>

[`pasteur'] <https://github.com/dinosaure/pasteur>

Changes
┈┈┈┈┈┈┈

  The main goal behind this major release was to get better
  compatibility with various platforms, including
  [~MirageOS~](mirage.io), 32-bit platforms, and `js_of_ocaml'. In order
  to achieve that, we broke down `ocaml-git' into several components,
  which are represented as sub-libraries. We will describe some of those
  components later in this post.

  Along with better support for various platforms, `ocaml-git 3.0' also
  comes with SSH support for `fetch/push' and various bug fixes.

  The rest of the changes are mostly internal and pave a way for
  interesting features such as a full-blown `git' [garbage collector]
  and wire protocol v2 ([announcment] and [spec]).

  *References:*

  • Full [changes list]
  • [PR] that introduced the major rewrite of `ocaml-git'

  —

  In the new version of `ocaml-git', we try to have better separation of
  concerns by breaking some of the `ocaml-git' components into
  sub-libraries, which do not contain `git'-specific logic and can be
  reused for other purposes.


[garbage collector] <https://git-scm.com/docs/git-gc>

[announcment]
<https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html>

[spec]
<https://github.com/git/git/blob/master/Documentation/technical/protocol-v2.txt>

[changes list]
<https://github.com/mirage/ocaml-git/blob/master/CHANGES.md>

[PR] <https://github.com/mirage/ocaml-git/pull/395>


Carton
┄┄┄┄┄┄

  Git uses [PACK files] to store old git objects such as commits and
  transfer objects over wire using git's wire protocols (`git-nss'
  library mentioned below implements [v1] of the protocol; [v2]
  implementation is in progress).

  [*Carton*] is a library to work with PACK files. The library does not
  contain git-specific code, so one can easily reuse the library and
  PACK format for non-git objects. One can see how `ocaml-git' uses
  `carton' for its purposes [here].

  *References:*

  • [PR] that introduces `carton'


[PACK files]
<https://github.com/git/git/blob/master/Documentation/technical/pack-format.txt>

[v1]
<https://github.com/git/git/blob/master/Documentation/technical/pack-protocol.txt>

[v2]
<https://github.com/git/git/blob/master/Documentation/technical/protocol-v2.txt>

[*Carton*] <https://github.com/mirage/ocaml-git/tree/master/src/carton>

[here] <https://github.com/mirage/ocaml-git/tree/master/src/carton-git>

[PR] <https://github.com/mirage/ocaml-git/issues/375>


Git-NSS (Not So Smart)
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  When one wants to synchronize with a remote repository using git, they
  need to use `git fetch/push'.  Communication and
  synchronization/negotiation is defined by git *wire protocol*, which
  has two versions: older version 1 and newer leaner version 2. The
  protocols are defined for four wire transports: HTTP(S), SSH, and
  `git://' (TCP).

  [`Not-So-Smart'] library is a library that allows for such
  synchronization based on the git wire protocols but without
  git-specific code, meaning that files being fetched do not need to be
  git objects or that there is no assumptions on the "repository" that
  one is synchronizing with. So, as well as `carton', the library aims
  to be reusable for other purposes.

  This release features support for SSH using [awa-ssh] by @hannesm (see
  [the release]), support for [partial-clone] (of various `depth'), and
  memory consumption fixes for unikernels.

  *Note 1:* The library's name "Not so smart" is a play on the git's
  "smart" protocol, a part of wire protocol v1 over HTTP(S) transport.

  *Note 2:* only client side logic is implemented for wire
  protocols. The server-side is planned but not yet implemented. One can
  use `git' as the server for now.


[`Not-So-Smart']
<https://github.com/mirage/ocaml-git/tree/master/src/not-so-smart>

[awa-ssh] <https://github.com/mirage/awa-ssh>

[the release]
<https://discuss.ocaml.org/t/ann-first-release-of-awa-ssh/7057>

[partial-clone] <https://git-scm.com/docs/partial-clone>


Mimic
┄┄┄┄┄

  [*Mimic*] is a small reimplementation of [`conduit'], a library that
  helps to abstract over a transport protocol such as HTTP(S) or SSH. In
  other words, the code using `mimic' can deal not with different types
  that represent an HTTP or SSH connection, but just deal, e.g., read
  from or write to, with a `flow' value, which hides protocol-specific
  details under its hood.

  —

  There are several independent libraries that were upgraded along with
  `ocaml-git 3.0'.


[*Mimic*] <https://github.com/mirage/ocaml-git/tree/master/src/mimic>

[`conduit'] <https://github.com/mirage/ocaml-conduit>


Duff v0.3
┄┄┄┄┄┄┄┄┄

  [*Duff*] is a library that implements git's [`libXdiff'] (`xdiff'
  algorithm) in OCaml. PACK files use a binary diff algorithm, `xdiff',
  to compress binary data. More on the project [page] and release
  [notes] for `ocaml-git 2.0'.


[*Duff*] <https://github.com/mirage/duff>

[`libXdiff'] <http://www.xmailserver.org/xdiff-lib.html>

[page] <https://github.com/mirage/duff>

[notes] <https://discuss.ocaml.org/t/ann-ocaml-git-2-0/2740>

Changes
┈┈┈┈┈┈┈

  This release fixes the support for 32-bit architecture platforms.


Encore v0.7
┄┄┄┄┄┄┄┄┄┄┄

  [*Encore*] is a library that can create an encoder/decoder based on
  the format given. It also ensures isomorphism by construction.


[*Encore*] <https://github.com/mirage/encore>

Changes
┈┈┈┈┈┈┈

  Extensive changes to the API. See the project page.


Decompress v1.2.0
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  [*Decompress*] is an OCaml implementation of certain decompression
  algorithms such as `Zlib', `Gzip', etc.


[*Decompress*] <https://github.com/mirage/decompress>

Changes
┈┈┈┈┈┈┈

  `ocaml-git 3.0' uses new version of `decompress' with extensive
  performance improvements documented in *Tarides's* blog [API changes]
  and [performance improvements].

  We'd be happy to get your feedback or questions! :-)


[API changes]
<https://tarides.com/blog/2019-08-26-decompress-the-new-decompress-api>

[performance improvements]
<https://tarides.com/blog/2019-09-13-decompress-experiences-with-ocaml-optimization>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [How We Lost at The Delphi Oracle Challenge]
  • [Tarides sponsors the Oxbridge Women in Computer Science Conference
    2020]
  • [Coq 8.12.2 is out]
  • [First release of MetAcsl plugin]
  • [Announcing MirageOS 3.10]
  • [ ReScript 8.4]
  • [Coq 8.13+beta1 is out]


[OCaml Planet] <http://ocaml.org/community/planet/>

[How We Lost at The Delphi Oracle Challenge]
<https://seb.mondet.org/b/0010-delphi-challenge-post-vivum.html>

[Tarides sponsors the Oxbridge Women in Computer Science Conference
2020]
<https://tarides.com/blog/2020-12-14-tarides-sponsors-the-oxbridge-women-in-computer-science-conference-2020>

[Coq 8.12.2 is out] <https://coq.inria.fr/news/coq-8-12-2-is-out.html>

[First release of MetAcsl plugin]
<https://frama-c.com/fc-plugins/metacsl.html>

[Announcing MirageOS 3.10]
<https://mirage.io/blog/announcing-mirage-310-release>

[ ReScript 8.4]
<https://rescript-lang.org/blog/bucklescript-release-8-4>

[Coq 8.13+beta1 is out]
<https://coq.inria.fr/news/coq-8-13beta1-is-out.html>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2021-01-05 11:22 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2021-01-05 11:22 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of December 29, 2020
to January 05, 2021.

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

First release of Feat
OCluster and OBuilder
Plotting 3D vectors
Marshal determinism and stability
It there a tutorial for `js_of_ocaml' with simple graphics?
Interesting OCaml exercises from François Pottier available online
Old CWN


First release of Feat
═════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-feat/7033/1>


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

  A brief note to announce the first release of Feat:

  ┌────
  │ opam update
  │ opam install feat
  └────

  Feat is a library that offers support for counting, enumerating, and
  sampling objects of a certain kind, such as (say) the inhabitants of
  an algebraic data type.

  Feat was inspired by the paper "Feat: Functional Enumeration of
  Algebraic Types" by Jonas Duregård, Patrik Jansson and Meng Wang
  (2012).

  More details can be found here:

  <https://gitlab.inria.fr/fpottier/feat/>


OCluster and OBuilder
═════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocluster-and-obuilder/7035/1>


Thomas Leonard announced
────────────────────────

  I'm pleased to announce the first release of [OCluster]. A user can
  submit a build job (either a Dockerfile or an OBuilder spec) to the
  scheduler, which then runs the build on a worker machine, streaming
  the logs back to the client.

  This is the build scheduler / cluster manager that we use for e.g.
  [opam-repo-ci] (which you may have seen in action if you submitted a
  package to opam-repository recently).

  See [ocurrent/overview] for a quick overview of the various other CI
  services using it too.

  To install and run the scheduler use e.g.

  ┌────
  │ opam depext -i ocluster
  │ mkdir capnp-secrets
  │ ocluster-scheduler \
  │   --capnp-secret-key-file=./capnp-secrets/key.pem \
  │   --capnp-listen-address=tcp:0.0.0.0:9000 \
  │   --capnp-public-address=tcp:127.0.0.1:9000 \
  │   --state-dir=/var/lib/ocluster-scheduler \
  │   --pools=linux-arm32,linux-x86_64
  └────

  It will generate `key.pem' on the first run, as well as various
  capability files granting access for workers and clients. You then
  copy each generated pool capability (e.g. `pool-linux-x86_64.cap') to
  each machine you want in that pool, and run `ocluster-worker
  pool-linux-x86_64.cap' to start the worker agent. See the [README] for
  full details.

  [OBuilder] is an alternative to `docker build'. The main differences
  are that it takes a spec in S-expression format, which is easier to
  generate than a Dockerfile, handles concurrent builds reliably, and
  keeps copies of the logs so that you still see the output even if
  someone else performed the same build step earlier and the result is
  therefore taken from the cache.

  It currently supports ZFS and Btrfs for storage (it needs cheap
  snapshots) and `runc' for sandboxing builds. [macos support] is under
  development, but not yet upstreamed. It should be fairly easy to add
  support for any platform that has some form of secure chroot.

  OCluster supports monitoring with Prometheus, so you can see what the
  cluster is doing:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/d/d5ff5aaa0259d7b59445b156e6b642a421040b64_2_920x750.png>


[OCluster] <https://github.com/ocurrent/ocluster>

[opam-repo-ci] <https://github.com/ocurrent/opam-repo-ci>

[ocurrent/overview] <https://github.com/ocurrent/overview>

[README] <https://github.com/ocurrent/ocluster/blob/master/README.md>

[OBuilder] <https://github.com/ocurrent/obuilder>

[macos support] <https://github.com/ocurrent/obuilder/issues/57>


Plotting 3D vectors
═══════════════════

  Archive: <https://discuss.ocaml.org/t/plotting-3d-vectors/7038/1>


Andreas Poisel asked
────────────────────

  I'm doing linear algebra with Owl.  Owl-plplot works great for
  visualizing 2D vectors, but it doesn't seem to capable of plotting 3D
  vectors.

  I took a (fast) look at vanilla [Plplot], [Oplot], and the [GNUplot
  bindings], but I didn't find a simple way to plot 3D vectors.

  I don't need high quality plots, 3D surfaces, a lot of control or
  fancy features, just a coordinate system and some function to draw
  geometric primitives (points, lines, circles, etc.).

  Did I miss anything or do I have to build this myself with the good
  old Graphics module?


[Plplot] <http://plplot.org/>

[Oplot] <https://github.com/sanette/oplot>

[GNUplot bindings] <https://github.com/c-cube/ocaml-gnuplot>


Marshall Abrams replied
───────────────────────

  What kind of vector representation do you want?  Just lines/arrows in
  3D?  That's just a curve in 3D, so it should be possible with Owl and
  plplot, at least.  Looks like it should be easy with oplot, too (but I
  haven't used oplot).  There are some 3D Owl plplot examples, with
  source code, on these pages:

  <https://ocaml.xyz/book/visualisation.html>

  <https://github.com/owlbarn/owl/wiki/Tutorial:-How-to-Plot-in-Owl%3F>

  <https://github.com/owlbarn/owl/wiki/Plot-Gallery>

  I don't know whether it will be easy to adapt them to your needs.  I
  wrote the last example on the last page above.  It's a plot of a
  series 2D curves in 3D.  Maybe some of the techniques can be adapted
  to your needs.  (The code is a few years old.  I'm not sure whether it
  works with the current version of Owl.)

  (If you end up having to use low-level bindings to plplot, oplot,
  etc. from Owl, you might consider contributing a wrapper module that
  makes it easy to do the kind of plot you want.)


Andreas Poisel then said
────────────────────────

  Thank you for your answer.

  I'd just like to draw 3D vectors in a cartesian coordinate system.  A
  plot should look similar to this:

  <https://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/3D_Vector.svg/800px-3D_Vector.svg.png>

  I wouldn't even need arrows, simple lines would be ok.

  Maybe there is a way to use one of the 3D functions (`Plot.surf',
  `Plot.mesh', `Plot.contour'), but I can't figure it out.


Hezekiah Carty replied
──────────────────────

  It's been a while since I worked with plplot but what you showed
  should be possible. The [plline3] function allows you to plot line
  segments in 3d space. The function is setup to take multiple segments
  in a single call. For a single segment each array would hold a single
  value. Colors can be set between draw calls.


[plline3]
<http://plplot.org/docbook-manual/plplot-html-5.15.0/plline3.html>


sanette also replied
────────────────────

  in oplot, there is the Curve3d object that should do it,
  <https://sanette.github.io/oplot/oplot/Oplot/Plt/index.html#type-plot_object.Curve3d>
  although it is quite rudimentary


Marshal determinism and stability
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/marshal-determinism-and-stability/7041/25>


Deep in this thread, Bikal Lem mentioned and Raphaël Proust described
─────────────────────────────────────────────────────────────────────

        [Binary module of data-encoding]

  Quick notes about this approach:

  • It is used extensively in the Tezos codebase. For data exchange (in
    the p2p layer), for data at rest (configuration files), and for a
    mix of the two (serialisation of economic protocol data which is
    both exchanged by peers and stored on disk).
  • It is flexible in that you have great control over the
    representation of data and the serialisation/deserialisation
    procedure. There is a medium-term plan to allow even more
    control. For now you can decide, say, if 8 booleans are represented
    as one byte, 8 bytes, or 8 words (or something else altogether) (see
    code below).
  • Some of the responsibility for correctness rests upon your shoulders
    as a user. E.g., when you encode a tuple, the left element must have
    either a fixed length (e.g., be an int8, int32, etc., be a
    fixed-length string, or be a tuple of fixed-length values) or be
    prefixed by a length marker (which the library provides a combinator
    for). Most of the errors for this are raised when you declare the
    encoding and a few are raised when you use the encoding. I recommend
    writing some tests to check that your encodings accept the range of
    values that you are going to throw at them.
  • The library is well tested: there are tests using crowbar to check
    that encoding and decoding are actual inverse of each others.

  Let me know if you have more questions. And in the meantime, here's
  two different encodings for a tuple of 8 booleans:

  ┌────
  │ (* easy-encoding, produces 8 bytes *)
  │ let boolsas8bytes =
  │    tup8 bool bool bool bool bool bool bool bool
  │ 
  │ (* very-compact encoding, produces 1 byte *)
  │ let boolsas1byte =
  │    conv
  │       (fun (b1, b2, b3, b4, b5, b6, b7, b8) ->
  │ 	 let acc = 0 in
  │ 	 let acc = if b1 then acc lor 0b10000000 else acc in
  │ 	 let acc = if b2 then acc lor 0b01000000 else acc in
  │ 	 let acc = if b3 then acc lor 0b00100000 else acc in
  │ 	 …
  │ 	 acc)
  │       (fun i ->
  │ 	 let b1 = i land 0b10000000 <> 0 in
  │ 	 let b1 = i land 0b01000000 <> 0 in
  │ 	 let b1 = i land 0b00100000 <> 0 in
  │ 	 …
  │ 	 (b1, b2, b3, b4, b5, b6, b7, b8))
  │       uint8
  └────

  In general, data-encoding is probably slower than marshal, but its
  strong points are:
  • it offers some type guarantees,
  • it gives you some control over the representation of the data,
  • it allows you to define representations that are easy to parse in
    other languages or in other versions of the same language,
  • it generates documentation about the data-representation.


[Binary module of data-encoding]
<https://gitlab.com/nomadic-labs/data-encoding>


It there a tutorial for `js_of_ocaml' with simple graphics?
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/it-there-a-tutorial-for-js-of-ocaml-with-simple-graphics/4636/7>


Deep in this thread, Phat Ky said
─────────────────────────────────

  This is a really, really late reply but this youtube video was very
  helpful to me …  <https://www.youtube.com/watch?v=h_e5pPKI0K4>


Interesting OCaml exercises from François Pottier available online
══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-exercises-from-francois-pottier-available-online/7050/1>


gasche announced
────────────────

  The recent URL
  <https://ocaml-sf.org/learn-ocaml-public/#activity%3Dexercises>
  contains auto-graded OCaml exercises, in particular a bunch of
  advanced and fairly interesting exercices written by François Pottier,
  which I would recommend for anyone knowledgeable in OCaml and curious
  about algorithms and functional programming. (You have to scroll down
  to see those, the exercises at the top come from the OCaml MOOC.)

  See for example François' exercises on:
  • [Alpha-Beta Search],
  • [Parser combinators],
  • [Huffman Compression],
  • [Implementing backtracking with continuations], or
  • my personal favorite, [reimplementing the core of a pretty-printer].

  Context: the exercise platform is [LearnOCaml], initially written by
  OCamlPro for the OCaml MOOC and maintaing by Yann Régis-Gianas
  (@yurug) on behalf of the [OCaml Software Foundation]. We (at the
  Foundation) are trying to assemble a corpus of nice OCaml exercises
  for teachers and people self-studying, and the nice exercises by
  François Pottier (@fpottier) were written as part of this initiative.


[Alpha-Beta Search]
<https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/alpha_beta%26tab%3Dtext%26prelude%3Dshown>

[Parser combinators]
<https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/parser_combinators%26tab%3Dtext>

[Huffman Compression]
<https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/huffman%26tab%3Dtext%26prelude%3Dshown>

[Implementing backtracking with continuations]
<https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/nondet_monad_cont%26tab%3Dtext%26prelude%3Dshown>

[reimplementing the core of a pretty-printer]
<https://ocaml-sf.org/learn-ocaml-public/exercise.html#id%3Dfpottier/pprint%26tab%3Dtext%26prelude%3Dshown>

[LearnOCaml] <https://github.com/ocaml-sf/learn-ocaml>

[OCaml Software Foundation] <http://ocaml-sf.org/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-29  9:59 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-12-29  9:59 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of December 22 to 29,
2020.

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

ppx_deriving_yaml 0.1.0
A Heroku buildpack for OCaml
opam-dune-lint - keep opam and dune dependencies in sync
Scirep, a utility for literate programming
Camel Calendar for 2021
Old CWN


ppx_deriving_yaml 0.1.0
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ppx-deriving-yaml-0-1-0/7007/1>


Patrick Ferris announced
────────────────────────

  I'm proud to announce the first release (and my first release) of
  [ppx_deriving_yaml]. If you are familiar with the excellent
  [ppx_deriving_yojson] then this library should come as no surprise. In
  fact it helped me a lot in writing this ppx, so thank you to its
  creators/maintainers.


[ppx_deriving_yaml] <https://github.com/patricoferris/ppx_deriving_yaml>

[ppx_deriving_yojson] <https://github.com/ocaml-ppx/ppx_deriving_yojson>

Installation
╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ $ opam update
  │ $ opam install ppx_deriving_yaml
  └────


Usage
╌╌╌╌╌

  Ppx_deriving_yaml converts your OCaml types to the "basic" [OCaml Yaml
  value type] (the one that is currently compatible with ezjsonm). So
  for example you can have:

  ┌────
  │ type t = { title: string; authors: string list } [@@deriving yaml]
  │ 
  │ let () =
  │   let v = { title = "Yaml PPX!"; authors = [ "Patrick Ferris" ] } in
  │   let yaml = to_yaml v in
  │   Yaml.pp Format.std_formatter yaml;
  │   match of_yaml yaml with
  │     | Ok t -> Format.print_string t.title
  │     | Error (`Msg m) -> failwith m
  └────

  The ppx generates two functions:

  ┌────
  │ val of_yaml : Yaml.value -> t Yaml.res
  │ val to_yaml : t -> Yaml.value
  └────

  And when built with this dune file:

  ┌────
  │ (executable
  │  (name main)
  │  (libraries yaml)
  │  (preprocess
  │   (pps ppx_deriving_yaml)))
  └────

  The following output is generated:

  ┌────
  │ title: Yaml PPX!
  │ authors:
  │ - Patrick Ferris
  │ Yaml PPX!
  └────

  The [README] contains some more information and the library is still a
  little rough around the edges, especially with error reporting, but
  I'm currently using it in a few places such as an "ocaml-ified"
  [github actions] library (ppx_deriving_yaml's [test workflow] was
  automatically generated with it :sparkles:). This is a nice example of
  how it can be used in a fairly straightforward way to generate OCaml
  versions of the many projects that use Yaml for configuration files.

  Happy yaml-ing :)


[OCaml Yaml value type]
<https://github.com/avsm/ocaml-yaml/blob/6de8fa6926d391334b945754619a64857d352e5d/lib/types.ml#L44>

[README]
<https://github.com/patricoferris/ppx_deriving_yaml#implementation-details>

[github actions] <https://github.com/patricoferris/opam-github-workflow>

[test workflow]
<https://github.com/patricoferris/ppx_deriving_yaml/blob/main/.github/workflows/test.yml>


A Heroku buildpack for OCaml
════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-a-heroku-buildpack-for-ocaml/7012/1>


roddy announced
───────────────

  I wrote [a Heroku buildpack] for OCaml web apps that use opam/dune.


[a Heroku buildpack]
<https://github.com/roddyyaga/heroku-buildpack-ocaml>


opam-dune-lint - keep opam and dune dependencies in sync
════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-opam-dune-lint-keep-opam-and-dune-dependencies-in-sync/7014/1>


Thomas Leonard announced
────────────────────────

  We're pleased to announce the first release of [opam-dune-lint]. This
  little tool checks that every ocamlfind dependency listed in your
  `dune' files has the corresponding opam package listed as a dependency
  in your `*.opam' file(s).

  e.g.

  ┌────
  │ $ cd charrua
  │ $ opam dune-lint
  │ charrua-client.opam: changes needed:
  │   "tcpip" {with-test & >= 6.0.0}           [from test/client, test/client/lwt]
  │ charrua-server.opam: changes needed:
  │   "ppx_cstruct" {with-test & >= 6.0.0}     [from (ppx), test]
  │   "tcpip" {with-test & >= 6.0.0}           [from test]
  │ charrua-unix.opam: changes needed:
  │   "cstruct-lwt" {>= 6.0.0}                 [from unix]
  │   "ipaddr" {>= 5.0.1}                      [from unix]
  │   "tcpip" {>= 6.0.0}                       [from unix]
  │ charrua.opam: OK
  │ Note: version numbers are just suggestions based on the currently installed version.
  │ Write changes? [y] y
  │ Wrote "./charrua-client.opam"
  │ Wrote "./charrua-server.opam"
  │ Wrote "./charrua-unix.opam"
  └────

  If your project generates the opam files from `dune-project', then it
  will update your `dune-project' instead.

  It can also be useful to run this in CI. It will exit with a non-zero
  exit status if anything needs to be changed. [ocaml-ci] runs this
  automatically as part of the "lint-opam" check.


[opam-dune-lint] <https://github.com/ocurrent/opam-dune-lint>

[ocaml-ci] <https://ci.ocamllabs.io/>


Scirep, a utility for literate programming
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/scirep-a-utility-for-literate-programming/7016/1>


Philippe announced
──────────────────

  I wrote a utility called [scirep] to render a markdown file with OCaml
  code blocks as an HTML document, which provides some support for
  graphics. Here are some examples of generated documents: [one based on
  vg], and [another using owl-plplot].

  It can also be used downstream of [mdx] as a markdown-to-html
  converter that detects pictures in the toplevel's standard output and
  renders them in the final document.

  It is really a hack, and it is poorly documented, but I'm advertising
  it in case it might be useful to others.


[scirep] <https://github.com/pveber/scirep>

[one based on vg] <http://pveber.github.io/scirep/fold.html>

[another using owl-plplot] <http://pveber.github.io/scirep/damped.html>

[mdx] <https://github.com/realworldocaml/mdx>


Camel Calendar for 2021
═══════════════════════

  Archive: <https://discuss.ocaml.org/t/camel-calendar-for-2021/7020/1>


Florent Monnier announced
─────────────────────────

  I would like to share with you a [camel calendar for 2021 in pdf] with
  the nice theme from ocaml dot org.

  It was generated from an ocaml script that you can find in this repo:
  [svg calendar generator].

  Several scripts are available, you can find some results on this [web
  page].

  At the beginning of 2020 I was searching for a free software to
  generate calendars in SVG that I could customise for my own use, but I
  was unable to install the Perl script that exists (it has a lot of
  dependencies and the error message when I try to install it didn't
  help us to find what's wrong with it).

  This explains the design of these scripts, that are made to work
  without any dependencies and without any compilation. There's code
  duplication, but every script only need the ocaml interpreter to be
  run, so most people comfortable with the command line should be able
  to use it.

  (I also tried to sell some [on Etsy] but didn't sold a single one.)

  By default 12 languages are included in every script, but you can
  generate the calendars for more than 200 languages if you use [these
  dates locales] that come from the CLDR repository.

  You can also switch monday first or sunday first.

  These generators are provided under Zlib license.

  I hope some will enjoy!


[camel calendar for 2021 in pdf]
<http://decapode314.free.fr/cal/cal-camel/cal-camel-2021-en.pdf>

[svg calendar generator] <https://github.com/fccm/ocaml-cal-svg>

[web page] <http://decapode314.free.fr/cal/>

[on Etsy] <https://www.etsy.com/fr/shop/Decapode>

[these dates locales] <https://github.com/fccm/DateLocale-ocaml>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-22  8:48 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-12-22  8:48 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of December 15 to 22,
2020.

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

ocaml-lsp-server 1.4.0
OCaml 4.12.0, third alpha release
Lwt 5.4.0, Lwt_ppx 2.0.2, Lwt_react 1.1.4 releases
Senior software engineer at Docent, France - Remote OK
Old CWN


ocaml-lsp-server 1.4.0
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-4-0/6996/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the ocaml-lsp team, it is my pleasure to announce version
  1.4.0. This release introduces support for [automatic signature help].
  Signature help is not yet present in all possible contexts. We intend
  to improve to support as many relevant language constructs as possible
  in the future. Many thanks to @mnxn for implementing this feature.

  The full change log is replicated at the end of this post for your
  convenience.

  Happy Holidays!

  • Support cancellation notifications when possible. (#323)

  • Implement signature help request for functions (#324)

  • Server LSP requests & notifications concurrently. Requests that
    require merlin are still serialized. (#330)


[automatic signature help]
<https://code.visualstudio.com/api/language-extensions/programmatic-language-features#help-with-function-and-method-signatures>


OCaml 4.12.0, third alpha release
═════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-12-0-third-alpha-release/6997/1>


octachron announced
───────────────────

  The release of OCaml 4.12.0 is approaching. We have released a third
  alpha version to help fellow hackers join us early in our bug hunting
  and opam ecosystem fixing fun.

  Beyond the usual bug fixes, this new alpha version contains two small
  API fixes for statmemprof and the Unix module. (Keen-eyed readers
  might notice a breaking change in the change log below but this
  concerns a corner case of a corner case of the type system that should
  not affect anyone.)

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.12.0~alpha3
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  If you want to tweak the configuration of the compiler, you can pick
  configuration options with
  ┌────
  │ opam update
  │ opam switch create <switch_name> --packages=ocaml-variants.4.12.0~alpha3+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where <option_list> is a comma separated list of ocaml-option-*
  packages. For instance, for a flambda and afl enabled switch:
  ┌────
  │ opam switch create 4.12.0~alpha3+flambda+afl
  │ --packages=ocaml-variants.4.12.0~alpha3+options,ocaml-option-flambda,ocaml-option-afl
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  All available options can be listed with "opam search ocaml-option".

  The source code for the alpha is also available at these addresses:

  • <https://github.com/ocaml/ocaml/archive/4.12.0-alpha3.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.12/ocaml-4.12.0~alpha3.tar.gz>

  If you want to test this version, it is advised to install the alpha
  opam repository

  <https://github.com/kit-ty-kate/opam-alpha-repository>

  with
  ┌────
  │ opam repo add alpha git://github.com/kit-ty-kate/opam-alpha-repository.git
  └────
  This alpha repository contains various packages patched with fixes in
  the process of being upstreamed. Once the repository installed, these
  patched packages will take precedence over the non-patched version.

  If you find any bugs, please report them here:
   <https://github.com/ocaml/ocaml/issues>


Changes from the second alpha:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • *additional fixes* [1128], [7503], [9036], [9722], +[10069]:
     EINTR-based signal handling. When a signal arrives, avoid running
     its OCaml handler in the middle of a blocking section. Instead,
     allow control to return quickly to a polling point where the signal
     handler can safely run, ensuring that

  • [9907]: Fix native toplevel on native Windows. (David Allsopp,
    review by Florian Angeletti)

  • [10056]: Memprof: ensure young_trigger is within the bounds of the
    minor heap in caml_memprof_renew_minor_sample (regression from
    [8684]) (David Allsopp, review by Guillaume Munch-Maccagnoni and
    Jacques-Henri Jourdan)

  • [10062]: set ARCH_INT64_PRINTF_FORMAT correctly for both modes of
    mingw-w64 (David Allsopp, review by Xavier Leroy)

  • [10025]: Track custom blocks (e.g. Bigarray) with Statmemprof
    (Stephen Dolan, review by Leo White, Gabriel Scherer and
    Jacques-Henri Jourdan)

  • [10070]: Fix Float.Array.blit when source and destination arrays
    coincide. (Nicolás Ojeda Bär, review by Alain Frisch and Xavier
    Leroy)

  • *additional fixes* [9869], +[10073]: Add Unix.SO_REUSEPORT (Yishuai
     Li, review by Xavier Leroy, amended by David Allsopp)

  • [9877]: manual, warn that multi-index indexing operators should be
    defined in conjunction of single-index ones. (Florian Angeletti,
    review by Hezekiah M. Carty, Gabriel Scherer, and Marcello Seri)

  • [10046]: Link all DLLs with -static-libgcc on mingw32 to prevent
    dependency on libgcc_s_sjlj-1.dll with mingw-w64 runtime 8.0.0
    (previously this was only needed for dllunix.dll). (David Allsopp,
    report by Andreas Hauptmann, review by Xavier Leroy)

  • [9896]: Share the strings representing scopes, fixing some
    regression on .cmo/.cma sizes (Alain Frisch and Xavier Clerc, review
    by Gabriel Scherer)

  • [10044]: Always report the detected ARCH, MODEL and SYSTEM, even for
    bytecode- only builds (fixes a "configuration regression" from 4.08
    for the Windows builds) (David Allsopp, review by Xavier Leroy)

  • [10071]: Fix bug in tests/misc/weaklifetime.ml that was reported in
    [10055] (Damien Doligez and Gabriel Scherer, report by David
    Allsopp)

  • *breaking change* [8907], [9878]: `Typemod.normalize_signature' uses
     wrong environment Does not treat submodules differently when
     normalizing conjunctive types in polymorphic variants. This may
     break code that expose conjunctive types in inferred
     interface. (Jacques Garrigue, report and review by Leo White)

  • [9739], [9747]: Avoid calling type variables, types that are not
    variables in recursive occurence error messages (for instance, "Type
    variable int occurs inside int list") (Florian Angeletti, report by
    Stephen Dolan, review by Armaël Guéneau)

  • [10048]: Fix bug with generalized local opens. (Leo White, review by
    Thomas Refis)


[1128] <https://github.com/ocaml/ocaml/issues/1128>

[7503] <https://github.com/ocaml/ocaml/issues/7503>

[9036] <https://github.com/ocaml/ocaml/issues/9036>

[9722] <https://github.com/ocaml/ocaml/issues/9722>

[10069] <https://github.com/ocaml/ocaml/issues/10069>

[9907] <https://github.com/ocaml/ocaml/issues/9907>

[10056] <https://github.com/ocaml/ocaml/issues/10056>

[8684] <https://github.com/ocaml/ocaml/issues/8684>

[10062] <https://github.com/ocaml/ocaml/issues/10062>

[10025] <https://github.com/ocaml/ocaml/issues/10025>

[10070] <https://github.com/ocaml/ocaml/issues/10070>

[9869] <https://github.com/ocaml/ocaml/issues/9869>

[10073] <https://github.com/ocaml/ocaml/issues/10073>

[9877] <https://github.com/ocaml/ocaml/issues/9877>

[10046] <https://github.com/ocaml/ocaml/issues/10046>

[9896] <https://github.com/ocaml/ocaml/issues/9896>

[10044] <https://github.com/ocaml/ocaml/issues/10044>

[10071] <https://github.com/ocaml/ocaml/issues/10071>

[10055] <https://github.com/ocaml/ocaml/issues/10055>

[8907] <https://github.com/ocaml/ocaml/issues/8907>

[9878] <https://github.com/ocaml/ocaml/issues/9878>

[9739] <https://github.com/ocaml/ocaml/issues/9739>

[9747] <https://github.com/ocaml/ocaml/issues/9747>

[10048] <https://github.com/ocaml/ocaml/issues/10048>


Lwt 5.4.0, Lwt_ppx 2.0.2, Lwt_react 1.1.4 releases
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-lwt-5-4-0-lwt-ppx-2-0-2-lwt-react-1-1-4-releases/7001/1>


Raphaël Proust announced
────────────────────────

  We are glad to announce the release of version 5.4.0 of Lwt, version
  2.0.2 of Lwt_ppx, and version 1.1.4 of Lwt_react.

  <https://github.com/ocsigen/lwt/releases/tag/5.4.0>

  It can be installed from opam as usual:

  ┌────
  │ opam update
  │ opam upgrade lwt lwt_ppx lwt_react
  └────


OCaml 4.12 compatibility
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  With this release, Lwt is now compatible with OCaml 4.12. Thanks
  @kit-ty-kate for the contribution towards this support.

  Thanks as well to all the other contributors for all the other
  improvements that made it into this release. Check-out the release's
  changelog (link above) for a full list of bugfixes and additions.


Maintainers' notes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  As per [a previous announce] I am a co-maintainer of Lwt. With this
  release I'm taking on a more and more central role in the maintenance
  effort. Whilst I've received a lot of help getting this release
  together, I'm most likely the one responsible for any issues in the
  process.

  I'd like to thank @antron who is as stellar with maintenance of the
  project as he is with guiding me through the learning process. I'd
  also like to thank the opam-repository team who stepped up very
  quickly to fix some CI-related build-issues. And I'd like to thank my
  employer, [Nomadic Labs], who agreed to make Lwt maintenance part of
  my day job.

  I'm looking forward to all your bug reports, pull requests, comments,
  ideas, questions, remarks, as well as any sort of feedback. Don't
  hesitate to get in touch!


[a previous announce]
<https://discuss.ocaml.org/t/announcing-a-new-maintainer-for-lwt/6192>

[Nomadic Labs] <https://nomadic-labs.com/>


Senior software engineer at Docent, France - Remote OK
══════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/senior-software-engineer-at-docent-france-remote-ok/7002/1>


Thibaut Mattio announced
────────────────────────

  Docent, a company I'm working with, is recruiting an OCaml
  developer. You can see the job post [here]

  The team and project are really nice, I would definitely recommend it!

  I've built the current version of the backend, so don't hesitate to
  reach out (thibaut.mattio@gmail.com) if you have any questions on the
  tech (or other).


[here]
<https://www.notion.so/docentart/OCaml-Developer-bc047ff6c80b448e814943f7116fa14b>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-15  9:51 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-12-15  9:51 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of December 08 to 15,
2020.

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

MirageOS 3.10 released
Exception vs Result
Release: scikit-learn, Numpy, Scipy for OCaml, 0.3.1
OCaml 4.10.2
BAP 2.2.0 Release
Liquidshop 1.0, Jan. 17th and 18th, 2021
Opium 0.20.0
Set up OCaml 1.1.5
Other OCaml News
Old CWN


MirageOS 3.10 released
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mirageos-3-10-released/6941/1>


Hannes Mehnert announced
────────────────────────

  we're pleased to announce MirageOS 3.10:

  IPv6 and dual (IPv4 and IPv6) stack support
  <https://github.com/mirage/mirage/pull/1187>
  <https://github.com/mirage/mirage/issues/1190>

  Since a long time, IPv6 code was around in our TCP/IP stack (thanks to
  @nojb who developed it in 2014).  Some months ago, @hannesm and
  @MagnusS got excited to use it. After we managed to fix some bugs and
  add some test cases, and writing more code to setup IPv6-only and dual
  stacks, we are eager to share this support for MirageOS in a released
  version. We expect there to be bugs lingering around, but duplicate
  address detection (neighbour solicitation and advertisements) has been
  implemented, and (unless "–accept-router-advertisement=false") router
  advertisements are decoded and used to configure the IPv6 part of the
  stack. Configuring a static IPv6 address is also possible (with
  "–ipv6=2001::42/64").

  While at it, we unified the boot arguments between the different
  targets: namely, on Unix (when using the socket stack), you can now
  pass "–ipv4=127.0.0.1/24" to the same effect as the direct stack: only
  listen on 127.0.0.1 (the subnet mask is ignored for the Unix socket
  stack).

  A dual stack unikernel has "–ipv4-only=BOOL" and "–ipv6-only=BOOL"
  parameters, so a unikernel binary could support both Internet Protocol
  versions, while the operator can decide which protocol version to
  use. I.e. now there are both development-time (stackv4 vs stackv6 vs
  stackv4v6) choices, as well as the run-time choice (via boot
  parameter).

  I'm keen to remove the stackv4 & stackv6 in future versions, and
  always develop with dual stack (leaving it to configuration & startup
  time to decide whether to enable ipv4 and ipv6).

  Please also note that the default IPv4 network configuration no longer
  uses 10.0.0.1 as default gateway (since there was no way to unset the
  default gateway <https://github.com/mirage/mirage/issues/1147>).

  For unikernel developers, there are some API changes in the Mirage
  module
  • New "v4v6" types for IP protocols and stacks
  • The ipv6_config record was adjusted in the same fashion as the
    ipv4_config type: it is now a record of a network (V6.Prefix.t) and
    gateway (V6.t option)

  Some parts of the Mirage_key module were unified as well:
  • Arp.ip_address is available (for a dual Ipaddr.t)
  • Arg.ipv6_address replaces Arg.ipv6 (for an Ipaddr.V6.t)
  • Arg.ipv6 replaces Arg.ipv6_prefix (for a Ipaddr.V6.Prefix.t)
  • V6.network and V6.gateway are available, mirroring the V4 submodule

  If you're ready to experiment with the dual stack: below is a diff for
  our basic network example (from mirage-skeleton/device-usage/network)
  replacing IPv4 with a dual stack, and the tlstunnel unikernel commit
  <https://github.com/roburio/tlstunnel/commit/2cb3e5aa11fca4b48bb524f3c0dbb754a6c8739b>
  changed tlstunnel from IPv4 stack to dual stack.

  ┌────
  │ diff --git a/device-usage/network/config.ml b/device-usage/network/config.ml
  │ index c425edb..eabc9d6 100644
  │ --- a/device-usage/network/config.ml
  │ +++ b/device-usage/network/config.ml
  │ @@ -4,9 +4,9 @@ let port =
  │    let doc = Key.Arg.info ~doc:"The TCP port on which to listen for
  │ incoming connections." ["port"] in
  │    Key.(create "port" Arg.(opt int 8080 doc))
  │ 
  │ -let main = foreign ~keys:[Key.abstract port] "Unikernel.Main" (stackv4
  │ @-> job)
  │ +let main = foreign ~keys:[Key.abstract port] "Unikernel.Main"
  │ (stackv4v6 @-> job)
  │ 
  │ -let stack = generic_stackv4 default_network
  │ +let stack = generic_stackv4v6 default_network
  │ 
  │  let () =
  │    register "network" [
  │ diff --git a/device-usage/network/unikernel.ml
  │ b/device-usage/network/unikernel.ml
  │ index 5d29111..1bf1228 100644
  │ --- a/device-usage/network/unikernel.ml
  │ +++ b/device-usage/network/unikernel.ml
  │ @@ -1,19 +1,19 @@
  │  open Lwt.Infix
  │ 
  │ -module Main (S: Mirage_stack.V4) = struct
  │ +module Main (S: Mirage_stack.V4V6) = struct
  │ 
  │    let start s =
  │      let port = Key_gen.port () in
  │ -    S.listen_tcpv4 s ~port (fun flow ->
  │ -        let dst, dst_port = S.TCPV4.dst flow in
  │ +    S.listen_tcp s ~port (fun flow ->
  │ +        let dst, dst_port = S.TCP.dst flow in
  │ 	 Logs.info (fun f -> f "new tcp connection from IP %s on port %d"
  │ -                  (Ipaddr.V4.to_string dst) dst_port);
  │ -        S.TCPV4.read flow >>= function
  │ +                  (Ipaddr.to_string dst) dst_port);
  │ +        S.TCP.read flow >>= function
  │ 	 | Ok `Eof -> Logs.info (fun f -> f "Closing connection!");
  │ Lwt.return_unit
  │ -        | Error e -> Logs.warn (fun f -> f "Error reading data from
  │ established connection: %a" S.TCPV4.pp_error e); Lwt.return_unit
  │ +        | Error e -> Logs.warn (fun f -> f "Error reading data from
  │ established connection: %a" S.TCP.pp_error e); Lwt.return_unit
  │ 	 | Ok (`Data b) ->
  │ 	   Logs.debug (fun f -> f "read: %d bytes:\n%s" (Cstruct.len b)
  │ (Cstruct.to_string b));
  │ -          S.TCPV4.close flow
  │ +          S.TCP.close flow
  │        );
  │ 
  │      S.listen s
  └────

  Other bug fixes include <https://github.com/mirage/mirage/issues/1188>
  (in <https://github.com/mirage/mirage/pull/1201>) and adapt to charrua
  1.3.0 and arp 2.3.0 changes
  (<https://github.com/mirage/mirage/pull/1199>).


Exception vs Result
═══════════════════

  Archive: <https://discuss.ocaml.org/t/exception-vs-result/6931/18>


Continuing this thread, Vladimir Keleshev announced
───────────────────────────────────────────────────

  A bit late to the party, but here's an overview of error handling
  methods that I did a while ago:

  [Composable Error Handling in OCaml (keleshev.com)]

  It compares the following approaches:
  • Exceptions
  • Result type with strings for errors
  • Result type with custom variants for errors
  • Result type with polymorphic variants for errors


[Composable Error Handling in OCaml (keleshev.com)]
<https://keleshev.com/composable-error-handling-in-ocaml>


Release: scikit-learn, Numpy, Scipy for OCaml, 0.3.1
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-release-scikit-learn-numpy-scipy-for-ocaml-0-3-1/6942/1>


Ronan Le Hy announced
─────────────────────

  I've just released an update of OCaml wrappers for scikit-learn:
  • documentation: <https://lehy.github.io/ocaml-sklearn/>
  • code: <https://github.com/lehy/ocaml-sklearn>
  • `opam install sklearn'

  These bindings also come with bindings for Numpy (`opam install np')
  and Scipy (`opam install scipy').

  Scikit-learn is all of these things:
  • Simple and efficient tools for predictive data analysis
  • Accessible to everybody, and reusable in various contexts
  • Built on NumPy, SciPy, and matplotlib
  • Open source, commercially usable - BSD license

  Scikit-learn is robust, well-engineered and covers most basic machine
  learning use cases. As a professional data scientist I use it
  extensively from Python. I built these wrappers because I felt
  challenged by my friend @UnixJunkie's funny R wrappers.

  I don't depend personally on these packages and maintain/improve them
  without any guarantees. They have many unpolished corners. However,
  they have tests and I don't expect them to add too many bugs to
  scikit-learn. Contributions and bug reports are welcome (but be aware
  that the bindings are generated from a big hairy Python script).

  Many thanks to everybody involved in opam!


OCaml 4.10.2
════════════

  Archive: <https://discuss.ocaml.org/t/ann-ocaml-4-10-2/6945/1>


octachron announced
───────────────────

  The OCaml team has the pleasure of celebrating the birthday of Grace
  Hopper by announcing the release of OCaml version 4.10.2.

  This exceptional release makes OCaml 4.10 available on the new
  macOS/arm64 platform, and fixes some compatibility issues for the
  mingw64 and FreeBSD/amd64 platform.

  If OCaml 4.10.1 already works on your platform of choice, this release
  should be completely transparent to you (and can be safely ignored).

  Note that those fixes were backported from OCaml 4.12: further
  improvement to the support of the macOS/arm64 platform will happen on
  the 4.12 branch.

  The release is available as a set of OPAM switches, and as a source
  download here:

  <https://github.com/ocaml/ocaml/archive/4.10.2.tar.gz>
  <https://caml.inria.fr/pub/distrib/ocaml-4.10/>


OCaml 4.10.2
╌╌╌╌╌╌╌╌╌╌╌╌

  • [9938], [9939]: Define __USE_MINGW_ANSI_STDIO=0 for the mingw-w64
    ports to prevent their C99-compliant snprintf conflicting with
    ours. (David Allsopp, report by Michael Soegtrop, review by Xavier
    Leroy)


[9938] <https://github.com/ocaml/ocaml/issues/9938>

[9939] <https://github.com/ocaml/ocaml/issues/9939>

◊ Supported platforms:

  • [9699], [10026]: add support for iOS and macOS on ARM 64 bits
    Backported from OCaml 4.12.0 (GitHub user @EduardoRFS, review by
    Xavier Leroy, Nicolás Ojeda Bär and Anil Madhavapeddy, additional
    testing by Michael Schmidt)


  [9699] <https://github.com/ocaml/ocaml/issues/9699>

  [10026] <https://github.com/ocaml/ocaml/issues/10026>


◊ Code generation and optimization

  • [9752], [10026]: Revised handling of calling conventions for
    external C functions. Provide a more precise description of the
    types of unboxed arguments, so that the ARM64 iOS/macOS calling
    conventions can be honored. Backported from OCaml 4.12.0 (Xavier
    Leroy, review by Mark Shinwell and Github user @EduardoRFS)

  • [9969], [9981]: Added mergeable flag tqo ELF sections containing
    mergeable constants.  Fixes compatibility with the integrated
    assembler in clang 11.0.0. Backported from OCaml 4.12.0 (Jacob
    Young, review by Nicolás Ojeda Bär)


  [9752] <https://github.com/ocaml/ocaml/issues/9752>

  [10026] <https://github.com/ocaml/ocaml/issues/10026>

  [9969] <https://github.com/ocaml/ocaml/issues/9969>

  [9981] <https://github.com/ocaml/ocaml/issues/9981>


Anil Madhavapeddy
─────────────────

  There is also a [macos/arm64 binary of opam] available from the
  releases page for your convenience, and opam repository has been
  updated to understand the new tier-1 constraints imposed by macos/arm
  (i.e. the only working compilers there are 4.10.2 and 4.12.0~dev, and
  `opam init' will now do the right thing).

  There will be a number of packages that are broken due to the shift to
  `/opt/homebrew' from `/usr/local' for Homebrew/ARM (due to the need to
  keep them simultaneously installed on the same Mac), so please feel
  free to submit PRs to opam-repository to fix this stuff.

  We'll shortly have Mac (both Intel and ARM) testing up and running on
  opam-repository, so CI will catch up with reality once more, thanks to
  furious hacking by @patricoferris to extend our ocurrent-based CI
  infrastructure to support the unique vagaries of the Mac environment
  (notably, a total lack of native containers).  We have it working
  locally, and are just upstreaming it now.


[macos/arm64 binary of opam]
<https://github.com/ocaml/opam/releases/tag/2.0.7>


BAP 2.2.0 Release
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-bap-2-2-0-release/6950/1>


Ivan Gotovchits announced
─────────────────────────

  We are proud to announce the 2.2.0 release of the Carnegie Mellon
  University [Binary Analysis Platform]. BAP is the framework and
  toolkit for analyzing programs in their machine code
  representation. This update has a lot of [new features] despite that
  originally it was more as a maintenance version. Special thanks to
  @XVilka and [@Phosphorus15] for contributing Thumb/ThumbV2 lifter and
  radare2 integration. We would also like to thank [ForAllSecure] for
  open-sourcing and contributing to us their x86 floating-point
  lifter. The new version of BAP is also much more efficient and we now
  have a much better symbolization facility (so we're no longer really
  dependent on the presence of external tools). Another nice addition is
  a new REPL powered by [ocaml-linenoise], see the demo below.

  <https://asciinema.org/a/358996>


[Binary Analysis Platform]
<https://github.com/BinaryAnalysisPlatform/bap>

[new features]
<https://github.com/BinaryAnalysisPlatform/bap/releases/tag/v2.2.0>

[@Phosphorus15] <https://github.com/Phosphorus15>

[ForAllSecure] <https://forallsecure.com/>

[ocaml-linenoise] <https://github.com/ocaml-community/ocaml-linenoise>


Liquidshop 1.0, Jan. 17th and 18th, 2021
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-liquidshop-1-0-jan-17th-18th-2021/6951/1>


Romain Beauxis announced
────────────────────────

  We are happy to announce that we'll be holding Liquidshop 1.0 these
  coming Jan. 17th & 18th, our first ever (online) conference and
  workshops on liquidsoap and other related technologies and projects!

  Liquidsoap is a statically typed scripting language with specialized
  primitives and operators for creating media streams used for media
  processing, online streaming and a lot more. It is written in OCaml
  and has been maintained for over a decade now.

  We will have 3 different tracks for the event, namely:
  • Showcases: short presentations about a website / radio / art
    installation that you built using Liquidsoap or other related tools
  • Tech talks: in-depth presentation of a technology related to
    Liquidsoap and streaming in general
  • Workshops: user-centered freeform discussions about your project or
    issues around Liquidsoap and streaming

  If you're interested to participate, wether as an attendee or a
  presenter, make sure to register via our website at:
  <http://www.liquidsoap.info/liquidshop/> or directly via the form
  available at: <https://forms.gle/HdGNLz5qM3HVU1ub7>

  We are super excited for this event. We have already secured a couple
  of interesting speakers and we would love to get to know the community
  better, see what y'all are doing with liquidsoap and other releated
  projects, community radios, live video, weird installations, etc. and
  meet with everyone.

  Also, if you have any suggestion about the best technical solutions to
  organize such an event, we'd be happy to hear about them.

  Finally, if any of y'all have some specific topics to discuss and
  would like to learn more about liquidsoap, this will be a great place
  to connect!


Opium 0.20.0
════════════

  Archive: <https://discuss.ocaml.org/t/ann-opium-0-20-0/6955/1>


Thibaut Mattio announced
────────────────────────

  I'm pleased to announce a new version of [Opium] web framework
  (0.20.0) is available on Opam.

  Here's the changelog:


[Opium] <https://github.com/rgrinberg/opium>

Added
╌╌╌╌╌

  • New `Auth' module to work with `Authorization' header ([#238])

  • New `basic_auth' middleware to protect handlers with a `Basic'
    authentication method ([#238])

  • New `Response.of_file' API for conveniently creating a response of a
    file ([#244])

  • Add a package `opium-graphql' to easily create GraphQL server with
    Opium ([#235])

  • Add a function `App.run_multicore' that uses pre-forking and spawns
    multiple processes that will handle incoming requests ([#239])


[#238] <https://github.com/rgrinberg/opium/pull/238>

[#244] <https://github.com/rgrinberg/opium/pull/244>

[#235] <https://github.com/rgrinberg/opium/pull/235>

[#239] <https://github.com/rgrinberg/opium/pull/239>


Fixed
╌╌╌╌╌

  • Fix reading cookie values when multiple cookies are present in
    `Cookie' header ([#246])

  Happy hacking :slight_smile:


[#246] <https://github.com/rgrinberg/opium/pull/246>


Set up OCaml 1.1.5
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-5/6971/1>


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

  This release reduces build time by up to 2 minutes by exporting
  modified `OPAMJOBS' environment variable.

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.5>


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Memthol: exploring program profiling]
  • [Growing the Hardcaml toolset]
  • [ Editor Plugin for VSCode and Vim Officially Released!]
  • [Announcing Our Market Prediction Kaggle Competition]
  • [Every proof assistant: introducing homotopy.io – a proof assistant
    for geometrical higher category theory]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Memthol: exploring program profiling]
<https://www.ocamlpro.com/2020/12/01/memthol-exploring-program-profiling/>

[Growing the Hardcaml toolset]
<https://blog.janestreet.com/growing-the-hardcaml-toolset-index/>

[ Editor Plugin for VSCode and Vim Officially Released!]
<https://rescript-lang.org/blog/editor-support-release-1-0>

[Announcing Our Market Prediction Kaggle Competition]
<https://blog.janestreet.com/announcing-our-market-prediction-kaggle-competition-index/>

[Every proof assistant: introducing homotopy.io – a proof assistant for
geometrical higher category theory]
<http://math.andrej.com/2020/11/24/homotopy-io/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-12-01  8:54 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-12-01  8:54 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of November 24 to
December 01, 2020.

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

drom.0.2.0: OCaml Project Manager, beta release
OCaml on the BEAM webinar
ocaml-lsp-server 1.3.0
OCaml User Survey 2020
http-cookie 2.0.0
reparse 2.0.0
VSCode OCaml Platform v1.5.0
Database modelling
Opium 0.19.0
Operator lookup tool for OCaml
Other OCaml News
Old CWN


drom.0.2.0: OCaml Project Manager, beta release
═══════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-drom-0-2-0-ocaml-project-manager-beta-release/6841/1>


Fabrice Le Fessant announced
────────────────────────────

  I am happy to announce the first release of `drom', version 0.2.0, a
  tool to create and manage OCaml projects. `drom' is a simple layer on
  top of `opam' and `dune', with project and package descriptions
  written in TOML syntax. It is an attempt at providing a `cargo'-like
  experience for developers, with builtin support for standard OCaml
  tools (`opam', `dune', `odoc', etc.) and source managers (Github for
  now, with Github Actions and Github Pages).

  There are mainly 2 use-cases of `drom':

  • Scafolding tool: `drom' makes it easy to create OCaml projects by
    generating all the files needed for a standard OCaml project. It
    creates files for `opam' and `dune', formatters (`ocp-index' and
    `ocamlformat'), documentation (`sphinx' and `odoc'), testing
    directories and Github CI. Once these files have been created,
    `drom' is not needed anymore and you can keep using your preferred
    tools.

  • Management tool: `drom' can also be used to keep managing the
    project afterwards. It has commands like `drom build' to build the
    project, automatically installing a local switch with all needed
    dependencies, `drom doc' to generate the documentation and `drom
    test' to execute tests. `drom' works as a simple interface over
    `opam' and `dune' so you almost never need to use them directly.

  <https://ocamlpro.github.io/drom>

  (this site and the documentation was mostly generated by `drom'
  itself)

  `drom' is available in the official opam repository.

  Examples:

  ┌────
  │ $ drom new mylib --skeleton library // generate library project
  │                                     //           or
  │ $ drom new hello                    // generate program project
  │ 
  │ $ cd hello
  │ $ emacs drom.toml // edit the project description
  │ $ drom project    // update files
  │ $ drom build                  // create local switch and build
  │                               //      or
  │ $ drom build --switch 4.10.0  // use global switch and build
  │ $ ./hello         // run the executable
  │ $ drom test       // run tests
  │ $ drom install    // install in opam switch
  └────

  This is an early release to get feedback from users. `drom' has been
  tested on several of our internal projects, like `opam-bin' and
  `ez_file'.

  Since `drom' creates local `opam' switches for every project by
  default (though it is possible to use global switches too), it is
  advised to use it with `opam-bin' to speed up switch creation and
  upgrades.

  `drom' works by creating projects using "skeletons", i.e. project and
  package templates. `drom' comes with a few predefined skeletons
  (`program' or `library'), and allows users to add their own
  skeletons. We will of course extend the substitution language to help
  users develop such new skeletons.

  `drom' is a collaborative work between OCamlPro and Origin Labs.


François Bobot asked and Fabrice Le Fessant replied
───────────────────────────────────────────────────

        I'm very happy to see work in the OCaml world in that
        direction. I was currently looking for duniverse for that
        kind of need. Do they fullfil different needs or how do
        they compare?

  My understanding is that `duniverse' tackles the problem of the
  "mono-repo", i.e. when you want to manage many different projects as
  just one project, using `dune' capacity to build them all at once. I
  would say that `drom' tackles an orthogonal problem, which is to
  simplify the creation of simple OCaml projects (generating all the
  standard files you need, like Makefile, dune-project, dune,
  .ocamlformat, .github CI, documentation, license, etc.) and day-to-day
  management (changing dependencies, having a copy of headers that you
  can insert in new files, etc.). It also provides a single interface
  over basic opam/dune commands.

  It would probably be possible to use `duninverse' on a set of projects
  containing projects generated by `dune', but I don't know enough about
  `duniverse' to be sure.

  Of course, `drom' can manage projects composed of multiple libraries
  and executables (called `packages' because `drom' generates one `opam'
  file for every one of them), but I wouldn't call that a mono-repo,
  it's just frequent to have more than one package in a small project.


OCaml on the BEAM webinar
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-on-the-beam-webinar/6851/1>


Yawar Amin announced
────────────────────

  Erlang Solutions is going to do a webinar on Leandro Ostera's new BEAM
  backend for OCaml:
  <https://www2.erlang-solutions.com/webinar-registration-2>

  Should be exciting!


ocaml-lsp-server 1.3.0
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-3-0/6856/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the ocaml-lsp team, I’d like to announce version 1.3.0.

  This release an improvement in keyword completion and a new code
  action. Keywords are now filtered by the context the user requested
  the completion, and there's a new code action to quickly populate .mli
  files with the the inferred types from the .ml file.


OCaml User Survey 2020
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/28>


Xavier Leroy announced
──────────────────────

  Here is a summary and analysis of the survey results I wrote on behalf
  of the OCaml Software Foundation:
  <https://www.dropbox.com/s/omba1d8vhljnrcn/OCaml-user-survey-2020.pdf?dl=0>
  Enjoy!


http-cookie 2.0.0
═════════════════

  Archive: <https://discuss.ocaml.org/t/ann-http-cookie-2-0-0/6866/1>


Bikal Lem announced
───────────────────

  A new version of `cookies' package - now named `http-cookie'- has been
  released to opam. This version has been rewritten to remove all its
  external and ppx dependencies and now only depends on stock ocaml and
  its stdlib.

  `http-cookie' is a [RFC 6265] compliant HTTP cookie library.  RFC 6265
  is a HTTP cookie standard specifying cookie data validity
  requirements.

  Additionally, I have also removed the use of `Result.t' from the
  previous version and have used plain old exceptions to denote any
  cookie data validation errors.

  • [Github - http-cookie]
  • [Docs - http-cookie]


[RFC 6265] <https://tools.ietf.org/html/rfc6265>

[Github - http-cookie] <https://github.com/lemaetech/http-cookie>

[Docs - http-cookie] <https://lemaetech.co.uk/http-cookie/>


reparse 2.0.0
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-reparse-2-0-0/6868/1>


Bikal Lem announced
───────────────────

  A new version of `reparse' 2.0.0 has been released to opam.

  Reparse is a monadic, recursive descent based, comprehensive, parser
  construction library for ocaml.


CHANGES for version 2.0.0:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Rewrite the whole package to use exceptions rather than `result'
    type
  • Adds many more parsing combinators
  • Adds comprehensive unit tests
  • Adds comprehensive documentation, host documentation and add links
    in repo home page
  • Adds abstraction for input source
  • Provides unix file source and string input source
  • Adds separate package `reparse-unix' for unix file input
  • Adds calc.ml and json.ml in examples.

  Additionally, the API is now comprehensively documented with at least
  an example for each API call.

  • [Github Reparse]
  • [API Docs]


[Github Reparse] <https://github.com/lemaetech/reparse>

[API Docs] <https://lemaetech.co.uk/reparse/>


VSCode OCaml Platform v1.5.0
════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-5-0/6871/1>


Max Lantas announced
────────────────────

  We are happy to announce the v1.5.0 release of [VSCode OCaml
  Platform], a Visual Studio Code extension for OCaml. It is available
  on the [VSCode Marketplace] and [Open VSX Registry].

  This release has the following changes:
  • Highlight `rec' keyword in OCaml mli files for recursive modules
    ([#434])
  • Highlight `cram' stanza in dune-project files ([#441])
  • Fix reason highlighting of let extensions ([#447])
  • Improve highlighting of Menhir new syntax ([#450])
  • Improve Menhir syntax highlighting ([#455])
  • Add `Alt + P' keyboard shortcut for infer interface code action
    ([#448])
  • Infer interface when switching to a non-existing interface file
    ([#437])

  This is the first release to be automatically published to Open VSX,
  which will benefit users of [VSCodium] and other editors.

  Please feel free to share feedback.


[VSCode OCaml Platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>

[VSCode Marketplace]
<https://marketplace.visualstudio.com/items?itemName=ocamllabs.ocaml-platform>

[Open VSX Registry]
<https://open-vsx.org/extension/ocamllabs/ocaml-platform>

[#434] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/434>

[#441] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/441>

[#447] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/447>

[#450] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/450>

[#455] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/455>

[#448] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/448>

[#437] <https://github.com/ocamllabs/vscode-ocaml-platform/pull/437>

[VSCodium] <https://github.com/VSCodium/vscodium>


Database modelling
══════════════════

  Archive: <https://discuss.ocaml.org/t/database-modelling/1150/2>


Reviving this very old thread, paul announced
─────────────────────────────────────────────

  And a version for postgresql:
  <https://github.com/pat227/ocaml-pgsql-model.git>


Opium 0.19.0
════════════

  Archive: <https://discuss.ocaml.org/t/ann-opium-0-19-0/6876/1>


Thibaut Mattio announced
────────────────────────

  On behalf of the Opium team, I am pleased to announce a new version of
  Opium (`0.19.0') is available on Opam.

  This release comes with a complete rewrite of Opium's internals to
  switch from Cohttp to Httpaf (work done by @anuragsoni).

  As demonstrated in several benchmarks, Httpaf's latency is much lower
  than Cohttp's in stress tests, so it is expected that Opium will
  perform better in these high-pressure situations.

  The underlying HTTP server implementation is now contained in a `rock'
  package, that provides a Service and Filter implementation, inspired
  by Finagle's. The architecture is similar to Ruby's Rack library
  (hence the name), so one can compose complex web applications by
  combining Rock applications.

  The `rock' package offers a very slim API, with very few dependencies,
  so it should be an attractive option for other Web frameworks to build
  on, which would allow the re-usability of middlewares and handlers,
  independently of the framework used (e.g. one could use Sihl
  middlewares with Opium, and vice versa).

  Apart from the architectural changes, this release comes with a lot of
  additional utilities and middlewares which should make Opium a better
  candidate for complex web applications, without having to re-write a
  lot of common Web server functionalities.

  The Request and Response modules now provide:
  • JSON encoders/decoders with `Yojson'
  • HTML encoders/decoders with `Tyxml'
  • XML encoders/decoders with `Tyxml'
  • SVG encoders/decoders with `Tyxml'
  • multipart/form encoders/decoders with `multipart_form_data'
  • urlencoded encoders/decoders with `Uri'

  And the following middlewares are now built-in:
  • `debugger' to display an HTML page with the errors in case of
    failures
  • `logger' to log requests and responses, with a timer
  • `allow_cors' to add CORS headers
  • `static' to serve static content given a custom read function
    (e.g. read from S3)
  • `static_unix' to serve static content from the local filesystem
  • `content_length' to add the `Content-Length' header to responses
  • `method_override' to replace the HTTP method with the one found in
    the `_method' field of `application/x-www-form-urlencoded' encoded
    `POST' requests.
  • `etag' to add `ETag' header to the responses and send an HTTP code
    `304' when the computed ETag matches the one specified in the
    request.
  • `method_required' to filter the requests by the HTTP method and
    respond with an HTTP code `405' if the method is not allowed.
  • `head' to add supports for `HEAD' request for handlers that receive
    `GET' requests.

  Lastly, this release also adds a package `opium-testing' that can be
  used to test Opium applications with Alcotest. It provides `Testable'
  modules for every Opium types, and implements helper functions to
  easily get an `Opium.Response' from an `Opium.Request'.

  As this release changes the API drastically, we will keep maintaining
  the `0.18.0' branch for bug fixes, for users who don't want to (or
  can't) migrate to `0.19.0'.


What's next?
╌╌╌╌╌╌╌╌╌╌╌╌

  Recent discussions have shown that building optimized applications was
  not trivial. This is partly due to the lack of documentation, and
  probably because some configurations that should come by default, are
  left to the user to optimize. Therefore, we will keep performance in
  mind for the next release and investigate the current bottlenecks in
  Opium.

  We will also continue adding higher-level functionalities to Opium to
  make users productive with real-world applications. This includes:
  • Sessions support (with signed cookies)
  • Handlers for authentication
  • Adding more middlewares (compression, flash messages, caching, etc.)

  Your feedback is welcome, don't hesitate to open Issues on Github!


Andreas Poisel asked and Anurag Soni replied
────────────────────────────────────────────

        Does Opium + Httpaf support TLS?

  It doesn't at the moment.


Calascibetta Romain then said
─────────────────────────────

  According the interface of `opium', it's possible to have the support
  of TLS (with `ocaml-tls') with the [new version of Conduit] and
  [`paf'] (which is a MirageOS compatible layer of HTTP/AF -
  unreleased):

  ┌────
  │ let stack ip =
  │   Tcpip_stack_socket.UDPV4.connect (Some ip) >>= fun udpv4 ->
  │   Tcpip_stack_socket.TCPV4.connect (Some ip) >>= fun tcpv4 ->
  │   Tcpip_stack_socket.connect [ ip ] udpv4 tcpv4
  │ 
  │ let http_with_conduit (ip, port) error_handler request_handler =
  │   Paf.https httpaf_config ~error_handler ~request_handler:(fun _ -> request_handler)
  │     ({ Paf.TCP.stack= stack ip
  │      ; keepalive= None
  │      ; nodelay= false
  │      ; port= port}, Tls.Config.server ~certificates ())
  │ 
  │ let () = match Lwt_main.run (Opium.run (https_with_conduit (Ipaddr.V4.localhost, 4343)) opium_app) with
  │   | Ok () -> ()
  │   | Error err -> Fmt.epr "%a.\n%!" Conduit_mirage.pp_error err
  └────

  I used it for a long time on my personal unikernels and did some tests
  to ensure that [it does fails when it handles many requests]. Note
  that you are able to use OpenSSL too if you want.


[new version of Conduit]
<https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611>

[`paf'] <https://github.com/dinosaure/paf-le-chien/>

[it does fails when it handles many requests]
<https://github.com/dinosaure/paf-le-chien/pull/12>


Robin Björklin also replied
───────────────────────────

  If you want to use this new version of Opium there are ways around
  this problem. You could have Haproxy (or similar) terminate your TLS
  connections externally and if your environment requires TLS for your
  internal network something like [Consul Connect] can cover that
  use-case for you.


[Consul Connect]
<https://learn.hashicorp.com/tutorials/consul/get-started-service-networking?in=consul/getting-started>


Operator lookup tool for OCaml
══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-operator-lookup-tool-for-ocaml/6882/1>


Craig Ferguson announced
────────────────────────

  I'm pleased to announce the initial release of
  craigfe.io/operator-lookup/, a search tool for OCaml operators and
  syntax elements:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/e/ee41569b4426c9b77fd6d367e50ff5ac759f4e46_2_1034x558.png>

  For each operator, the tool provides a short explanation of its
  behaviour, examples of usage and warnings of common misuses and
  misunderstandings:

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/8/879ae652a8895fa0258bc288c8d0c819cb9ef314_2_920x1000.png>

  The intent of writing this tool was to give OCaml beginners a quick
  way to find the standard / conventional operators in the language and
  to disambiguate "operator-like" syntax that can be hard to search for
  otherwise. It currently supports:

  • all standard library operators,
  • conventional infix operators (`>>=', `>>|', `>|='),
  • binding operators (`let+', `let*', `and+', etc.),
  • syntax that is often confused for an operator (`#', `;;').

  Please let me know if you have any suggestions for improvements. I
  hope you find it useful!


Acknowledgements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This tool is heavily based on the [JavaScript operator lookup] utility
  by [Josh Comeau]. Thanks to him for the initial idea and for allowing
  me to re-use his design elements.


[JavaScript operator lookup]
<https://www.joshwcomeau.com/operator-lookup/>

[Josh Comeau] <https://twitter.com/JoshWComeau>


Kakadu asked and Craig Ferguson replied
───────────────────────────────────────

        It's not obvious for me are these operators hardcoded or
        do you scan opam packages from time to time?

  They're hardcoded. The operators fall into three classes:

  • The vast majority of them are from the `Stdlib' module, so I don't
    expect those to change very regularly.

  • A small number of "conventional" operators used in the community
    (`>>=', `let*', etc.). Even for that small set there is some
    divergence in Opam – c.f. `>>|' vs `>|=' for a _map_ operator – so I
    suspect there are not many other candidates for this group.

  • There are a few regexes behind the scenes for catching valid
    operator names that don't fall into the first two
    categories. e.g. many search terms are classified as "_a
    left-associative operator_" with a correspondingly vague
    description.


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [“Universal” Dune Tip: Rebuild Stuff, Sometimes]


[OCaml Planet] <http://ocaml.org/community/planet/>

[“Universal” Dune Tip: Rebuild Stuff, Sometimes]
<https://seb.mondet.org/b/0009-dune-universe-hack.html>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-11-03 15:15 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-11-03 15:15 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of October 27 to
November 03, 2020.

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

Brr 0.0.1, a toolkit for programming browsers
New release of Monolith (20201026)
MirageOS 3.9.0 released
An AST typing problem
erlang 0.0.14, a toolkit to manipulate Erlang sources
opam-bin.1.0.0: binary packages for opam
Interesting OCaml Articles
Old CWN


Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/9>


Continuing this thread, Daniel Bünzli said
──────────────────────────────────────────

  One thing I forgot, is that there is a [todomvc] example in the repo,
  see `todomvc.{html,ml}' in [this directory].

  It doesn't use the UI toolkit you mentioned, just the basic reactive
  DOM support provided by [`Brr_note'] and [`Brr_note_kit']. But you can
  see how quickly you get reusable and composable components like
  [`bool_editor'] and [`string_editor'].

  The program structure in that example is quite similar to the one I
  had in the drawing app. You define a purely functional, non reactive
  [data model], [actions] over the data model, create small UI fragments
  that renders parts of your data model and generate actions events for
  it, gradually glue them together using note combinators and finally
  define a [fixed point signal] that holds the data model as massaged by
  the actions events of your UI (as mentioned I'd like to replace fix
  points by direct `let rec' and a lazy infinitesimal delay combinator).

  There are a few pitfalls like you should avoid retaining parts of your
  data model in the UI otherwise you could get outdated data come back
  in your model (makes for very fun and spooky bugs though).  Identity
  in the data model is also a bit tricky, it seems in todomvc I [used]
  `=='. That didn't work in the drawing app where my surfaces had
  properties that could be updated but they could also be linked
  toghether (that window belongs to that wall etc.) so I needed stable
  identifiers for which I introduced a little abstraction to identify
  values and define relations between them.

  One thing I remember fondly when doing the drawing app is that I would
  still get the odd interaction glitches you get when coding direct
  mouse manipulation interactions (surface
  definition/selection/move/transform) however thanks to the ability to
  denotationally reason and act (left leaning [`E.select']) on the
  simultaneity of events, they were easy to understand and fix in an
  explicit way (that is via a defining *expression*).

  Also if you get into [`Note'] the denotational semantics notation is
  not yet explained there, refer to the [one of react] it's the same.


[todomvc] <http://todomvc.com/>

[this directory] <https://github.com/dbuenzli/brr/tree/master/test>

[`Brr_note'] <https://erratique.ch/software/brr/doc/Brr_note/index.html>

[`Brr_note_kit']
<https://erratique.ch/software/brr/doc/Brr_note_kit/index.html>

[`bool_editor']
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L229>

[`string_editor']
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L213-L214>

[data model]
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L36>

[actions]
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L101>

[fixed point signal]
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L314-L324>

[used]
<https://github.com/dbuenzli/brr/blob/41580885f40bfd184c3d8e5be2ddd56b0712b411/test/todomvc.ml#L84>

[`E.select']
<https://erratique.ch/software/note/doc/Note/E/index.html#val-select>

[`Note'] <https://erratique.ch/software/note/doc/Note/>

[one of react]
<https://erratique.ch/software/react/doc/React/index.html#sem>


Yoann Padioleau asked and Daniel Bünzli replied
───────────────────────────────────────────────

        How hard would it be to build on top of Brr_note something
        like an Elm Architecture-style toolkit? I know there's a
        TEA-Bucklescript library, but I'd rather use something
        relying on dune/jsoo.

        I've read somewhere else that you were a bit skeptical
        about the advantage of MVU (movel-view-update) over MVC,
        but I personnaly find the counter UI example in ELM at
        <https://guide.elm-lang.org/architecture/buttons.html> far
        simpler than the corresponding one in Brr at
        <https://github.com/barko/brr-eg/blob/master/counter/counter.ml>

  I don't know. I didn't look into MVU too much, but to me it's largely
  a remix of MVC – despite what its proponents try to tell you. Since we
  now live in an age of software adverstising it's a bit hard to get
  frank assessments.

  As far as I'm concerned the compositionality story of MVU doesn't look
  great. Basically it enforces state machines on you, and composing
  state machines is a bit meh. In FRP state machines become signals (via
  `S.accum') which are highly composable entities with *fine
  granularity* (and bonus point, a well defined denotational semantics
  for equational reasoning).

  If you are looking for MVU I think you can simply jump on [LexiFI's
  vdom]. But when I see how you get to [compose two models] in that
  paradigm, I'm not convinced.

        There’s no need for those E.select. The UI is IMHO more
        declarative in ELM.

  That example could be rewritten (I didn't write the examples in this
  repo) to be more like the ELM one in it's declarations.

  But I think the ELM example is also more rigid. You may not like that
  `E.select' on this toy example, but you may get to enjoy it you when
  you start composing larger systems from smaller components.


[LexiFI's vdom] <https://github.com/LexiFi/ocaml-vdom>

[compose two models]
<https://github.com/LexiFi/ocaml-vdom/blob/9c5e42888ba72e69d5a018e38a4633e400913bfb/examples/demo/demo.ml#L196-L223>


Yaron Minsky then said
──────────────────────

  You might be interested in Bonsai! At some level, you can think of it
  as a library for building composable state machines. It uses
  [Incremental] as its engine for incrementalizing the computation of
  views, with a virtual-dom implementation underneath.

  <https://github.com/janestreet/bonsai>

  It's the primary tool we use for building UIs inside of Jane Street.

  In some ways, Bonsai is like Elm, but it has its own interesting
  ideas. Some of the concepts are borrowed from this paper:

  <https://www.cl.cam.ac.uk/~jdy22/papers/the-arrow-calculus.pdf>

  though I won't pretend to understand this paper myself!

  Bonsai doesn't yet have enough public-facing documentation, and really
  the bleeding edge version on github is considerably better and more
  usable than the one released into opam. But there's at least one
  public-facing UI that's built with it, if you want a real-world
  example.

  <https://blog.janestreet.com/finding-memory-leaks-with-memtrace/>


[Incremental] <https://github.com/janestreet/incremental>


Yoann Padioleau replied
───────────────────────

  Thx for the links!

  The memtrace viewer example is pretty cool, but Bonsai looks far more
  complicated than ELM.  If you look at the counter example (the hello
  world of UI), here:
  <https://github.com/janestreet/bonsai/blob/master/examples/counters/lib/bonsai_web_counters_example.ml>

  and you compare it to the one in ocaml-vdom (thx @dbuenzli for the
  link) at
  <https://github.com/LexiFi/ocaml-vdom/blob/master/examples/counters/counters.ml>

  there's a huge difference in simplicity.


Ty Overby then said
───────────────────

  Hi Aryx, I wrote the Bonsai example that you linked, and it certainly
  isn't the most concise, but that's because it was built for a tutorial
  on building small components (one counter is a single component), how
  to use more advanced combinators (Bonsai.assoc), and how to move data
  from one component to another (the add_counter_component into the
  associated counters component.)  I think it's a great example of the
  power of structuring an UI as a DAG rather than a tree, but it
  definitely doesn't make for the most concise code!

  In the example, the comments that look like "CODE_EXCERPT_BEGIN" are
  actually preprocessor definitions that are used in the (honestly,
  kinda out of date) [tutorial here].  A bonsai app that wasn't written
  for such a tutorial would look more like [this].


[tutorial here]
<https://github.com/janestreet/bonsai/blob/master/docs/getting_started/open_source/counters.mdx>

[this]
<https://gist.github.com/TyOverby/e0f7e944d002cdf7144aaf0102d16ed5>


New release of Monolith (20201026)
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-new-release-of-monolith-20201026/6667/1>


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

  It is my pleasure to announce a major new release of Monolith.

  ┌────
  │ opam update && opam install monolith
  └────

  Monolith offers facilities for testing an OCaml library (for instance,
  a data structure implementation) by comparing it against a reference
  implementation. It can be used to perform either random testing or
  fuzz testing. Fuzz testing relies on the external tool afl-fuzz.

  More information on Monolith is available [here] and in the draft
  paper [Strong Automated Testing of OCaml Libraries].


[here] <https://gitlab.inria.fr/fpottier/monolith>

[Strong Automated Testing of OCaml Libraries]
<http://cambium.inria.fr/~fpottier/publis/pottier-monolith-2021.pdf>


MirageOS 3.9.0 released
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-mirageos-3-9-0-released/6668/1>


Martin Lucina announced
───────────────────────

  We are pleased to announce the release of MirageOS 3.9.0.

  Our last release announcement was for [MirageOS 3.6.0], so we will
  also cover changes since 3.7.x and 3.8.x in this announcement.

  New features:

  • The Xen backend has been [re-written from scratch] to be based on
    Solo5, and now supports PVHv2 on Xen 4.10 or higher, and QubesOS
    4.0.
  • As part of this re-write, the existing Mini-OS based implementation
    has been retired, and all non-UNIX backends now use a unified OCaml
    runtime based on `ocaml-freestanding'.
  • OCaml runtime settings settable via the `OCAMLRUNPARAM' environment
    variable are now exposed as unikernel boot parameters. For details,
    refer to [#1180].

  Security posture improvements:

  • With the move to a unified Solo5 and ocaml-freestanding base
    MirageOS unikernels on Xen gain several notable improvements to
    their overall security posture such as SSP for all C code, W^X, and
    malloc heap canaries. For details, refer to the mirage-xen 6.0.0
    release [announcement].

  API breaking changes:

  • Several Xen-specific APIs have been removed or replaced, unikernels
    using these may need to be updated. For details, refer to the
    mirage-xen 6.0.0 release [announcement].

  Other notable changes:

  • `Mirage_runtime' provides event loop enter and exit hook
    registration ([#1010]).
  • All MirageOS backends now behave similarly on a successful exit of
    the unikernel: they call `exit' with the return value 0, thus
    `at_exit' handlers are now executed ([#1011]).
  • The unix backend used a toplevel exception handler, which has been
    removed. All backends now behave equally with respect to exceptions.
  • Please note that the `Mirage_net.listen' function still installs an
    exception handler, which will be removed in a future release. The
    out of memory exception is no longer caught by `Mirage_net.listen'
    ([#1036]).
  • To reduce the number of OPAM packages, the `mirage-*-lwt' packages
    are now deprecated. `Mirage_net' (and others) now use `Lwt.t'
    directly, and their `buffer' type is `Cstruct.t' ([#1004]).
  • OPAM files generated by `mirage configure' now include opam build
    and installation instructions, and also an URL to the Git `origin'
    ([#1022]).

  Known issues:

  • `mirage configure' fails if the unikernel is under version control
    and no `origin' remote is present ([#1188]).
  • The Xen backend has issues with event delivery if built with an
    Alpine Linux GCC toolchain. As a work-around, please use a Fedora or
    Debian based toolchain.

  Acknowledgements:

  • Thanks to Roger Pau Monné, Andrew Cooper and other core Xen
    developers for help with understanding the specifics of how Xen
    PVHv2 works, and how to write an implementation from scratch.
  • Thanks to Marek Marczykowski-Górecki for help with the QubesOS
    specifics, and for forward-porting some missing parts of PVHv2 to
    QubesOS version of Xen.
  • Thanks to @palainp on Github for help with testing on QubesOS.


[MirageOS 3.6.0] <https://mirage.io/blog/announcing-mirage-36-release>

[re-written from scratch] <https://github.com/mirage/mirage/issues/1159>

[#1180] <https://github.com/mirage/mirage/pull/1180>

[announcement]
<https://github.com/mirage/mirage-xen/releases/tag/v6.0.0>

[#1010] <https://github.com/mirage/mirage/pull/1010>

[#1011] <https://github.com/mirage/mirage/pull/1011>

[#1036] <https://github.com/mirage/mirage/issues/1036>

[#1004] <https://github.com/mirage/mirage/issues/1004>

[#1022] <https://github.com/mirage/mirage/pull/1022>

[#1188] <https://github.com/mirage/mirage/issues/1188>


An AST typing problem
═════════════════════

  Archive: <https://discuss.ocaml.org/t/an-ast-typing-problem/3677/8>


Chet Murthy announced
─────────────────────

  This note discusses the beginnings of an OCaml attribute-grammar
  evaluator generator.  You can find this code on github at
  `camlp5/pa_ppx_ag'.

  All of this code is implemented using `camlp5' and the `pa_ppx' suite
  of PPX rewriters.

  Caveat: this code is less than a week old, so it's changing fast.  In
  the unlkely event that anybody out there is actually interested in
  using this code, I'm happy to help in any way I can.  But just be
  aware that it's changing -really- fast.


Attribute Grammars for the multipass AST analysis problem
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  A year-and-a-half ago, the OP "An AST Typing Problem"
  (<https://discuss.ocaml.org/t/an-ast-typing-problem/3677>) raised the
  problem of how to deal with ASTs, in the presence of multiple passes
  of program-analysis, each of which will want to hang various bits of
  data off nodes.  The author of the OP pointed also at a couple of
  posts on Lambda-the-Ultimate (LtU), discussing related problems.

  The author notes:

        There’s a lot of passes, many of which depend on the
        previous ones, each one making some slight change to the
        AST which might or might not result in having to walk
        through the whole AST to catch all occurrences of that
        particular node. Clearly you’ll want to encode semantic
        errors in the types, so each pass ends up having its own
        unique AST, each depending on the previous one. To change
        a single node deep in the AST I have to write about a
        hundred lines of types and mapping functions’ worth of
        boilerplate. Any change in the lower levels of the AST
        bubbles up to the higher ones, and refactoring becomes a
        nightmare.

  I've been thinking about this problem ever since, and at the time, had
  suggested that while it seemed like attribute-grammars might be a
  workable solution, they were a pretty heavy hammer.  It doesn't help
  (of course) that there exist no attribute-grammar evaluator
  generators, for OCaml.  Also, at least in the LtU threads, there was
  discussion of modifying the AST, and having the analyses automatically
  be updated for the modified AST.  Obviously this would require an
  incremental re-attribution algorithm: more complexity and again,
  something that isn't implemented for OCaml.

  But imagine that there existed an attribute-grammar evaluator
  generator for OCaml.  So for a simple language of expressions, with an
  assignment-operator, we could write an evaluator as an
  attribute-grammar.  Imagine that you could write an ast like this
  (test1_ast.ml):
  ┌────
  │ type expr =
  │     INT of int
  │   | BINOP of binop * expr * expr
  │   | UNOP of unop * expr
  │   | REF of string
  │   | ASSIGN of string * expr
  │   | SEQ of expr * expr
  │ and unop = UPLUS | UMINUS
  │ and binop = PLUS | MINUS | STAR | SLASH | PERCENT
  │ and prog = expr
  └────
  and then (having elsewhere written parser/pretty-printer) declare
  attributes on those types (test1_variants.ml):
  ┌────
  │ module Attributed = struct
  │   [%%import: Test1_ast.expr]
  │   [@@deriving attributed {
  │     attributed_module_name = AT
  │   ; normal_module_name = OK
  │   ; attributes = {
  │       expr = {
  │ 	inh_env = [%typ: (string * int) list]
  │       ; syn_env = [%typ: (string * int) list]
  │       ; value_ = [%typ: int]
  │       }
  │     ; prog = {
  │ 	value_ = [%typ: int]
  │       }
  │     ; binop = {
  │ 	oper = [%typ: int -> int -> int]
  │       }
  │     ; unop = {
  │ 	oper = [%typ: int -> int]
  │       }
  │     }
  │   }]
  │ end
  └────
  and then declare attribute equations (test1_ag.ml):
  ┌────
  │ module REC = struct
  │ [%%import: Test1_variants.Attributed.AT.expr]
  │   [@@deriving ag {
  │     module_name = AG
  │   ; storage_mode = Records
  │   ; axiom = prog
  │   ; attributes = {
  │       expr = {
  │ 	inh_env = [%typ: (string * int) list]
  │       ; syn_env = [%typ: (string * int) list]
  │       ; value_ = [%typ: int]
  │       }
  │     ; prog = {
  │ 	value_ = [%typ: int]
  │       }
  │     ; binop = {
  │ 	oper = [%typ: int -> int -> int]
  │       }
  │     ; unop = {
  │ 	oper = [%typ: int -> int]
  │       }
  │     }
  │   ; attribution = {
  │       expr__INT = (
  │ 	[%nterm 0].syn_env := [%nterm 0].inh_env ;
  │ 	[%nterm 0].value_ := [%prim 1].intval
  │       )
  │     ; expr__BINOP = (
  │ 	[%nterm expr.(1)].inh_env := [%nterm expr].inh_env ;
  │ 	[%nterm expr.(2)].inh_env := [%nterm expr.(1)].syn_env ;
  │ 	[%nterm expr].syn_env := [%nterm expr.(2)].syn_env ;
  │ 	[%nterm expr].value_ := [%nterm binop.(1)].oper [%nterm expr.(1)].value_ [%nterm
  │ expr.(2)].value_
  │       )
  │     ; expr__UNOP = (
  │ 	[%nterm expr.(1)].inh_env := [%nterm expr].inh_env ;
  │ 	[%nterm expr].syn_env := [%nterm expr.(1)].syn_env ;
  │ 	[%nterm expr].value_ := [%nterm unop.(1)].oper [%nterm expr.(1)].value_
  │       )
  │     ; expr__REF = (
  │ 	[%nterm 0].syn_env := [%nterm 0].inh_env ;
  │ 	[%nterm 0].value_ := List.assoc [%prim 1].stringval [%nterm 0].inh_env
  │       )
  │     ; expr__ASSIGN = (
  │ 	[%nterm 0].syn_env := ([%prim 1].stringval, [%nterm expr.(1)].value_) :: [%nterm
  │ expr.(1)].syn_env ;
  │ 	[%nterm expr.(1)].inh_env := [%nterm 0].inh_env ;
  │ 	[%nterm 0].value_ := [%nterm expr.(1)].value_
  │       )
  │     ; expr__SEQ = (
  │ 	[%nterm 1].inh_env := [%nterm 0].inh_env ;
  │ 	[%nterm 2].inh_env := [%nterm 1].syn_env ;
  │ 	[%nterm 0].syn_env := [%nterm 2].syn_env ;
  │ 	[%nterm 0].value_ := [%nterm 2].value_
  │       )
  │     ; prog = (
  │ 	[%nterm 1].inh_env := [] ;
  │ 	[%nterm 0].value_ := [%nterm 1].value_ ;
  │ 	assert True
  │       )
  │     ; unop__UPLUS = (
  │ 	[%nterm unop].oper := fun x -> x
  │       )
  │     ; unop__UMINUS = (
  │ 	[%nterm unop].oper := fun x -> (- x)
  │       )
  │     ; binop__PLUS = (
  │ 	[%nterm binop].oper := (+)
  │       )
  │     ; binop__MINUS = (
  │ 	[%nterm binop].oper := (-)
  │       )
  │     ; binop__STAR = (
  │ 	[%nterm binop].oper := fun a b -> a*b
  │       )
  │     ; binop__SLASH = (
  │ 	[%nterm binop].oper := (/)
  │       )
  │     ; binop__PERCENT = (
  │ 	[%nterm binop].oper := (mod)
  │       )
  │     }
  │   }]
  │ end
  └────
  and then, turning a crank, you would get an evaluator:
  ┌────
  │ let test_records ctxt =
  │   assert_equal 3 ({| x := 1 ; x ; y := 2 ; x + y |} |> pa_prog_attributed |> REC.AG.evaluate)
  │ ; assert_equal 0 ({| x := 1 ; y := 2 ; x / y |} |> pa_prog_attributed |> REC.AG.evaluate)
  └────
  where `pa_prog_attributed' is a parser that parses the surface syntax
  into an AST, which has empty slots for all attributes, and
  `REC.AG.evaluate' evaluates attributes in its argument AST, and then
  returns a tuple of all the synthesized attributes of the root node.


Retaining familiar surface syntax for pattern-matching and constructing ASTs
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Now, we don't want to give up easy pattern-matching and construction
  of the AST, just because the AST has attributes strewn throughout it.
  But we don't have to: with Camlp5's "quotations", once we define a
  surface syntax parser for the basic AST (unadorned with attributes –
  viz. `test1_ast.ml'), we can use that to bootstrap ourselves to a
  surface syntax parser for expressions and patterns over that AST, and
  then in a similar manner we can get them for the AST adorned with
  attributes.

  This has already been done for hashconsed ASTs, and ASTs with built-in
  unique-IDs, and and doing it for "attributed ASTs" isn't any harder.
  Those examples can be found in the github project
  `camlp5/pa_ppx_q_ast'.


Limitations
╌╌╌╌╌╌╌╌╌╌╌

  There are still limitations.

  1. The current code only implements topological-order evaluation.
     That is, it builds the entire dependency-graph, topologically-sorts
     it, and then evaluates attributes.  This is …. suboptimal, when we
     well know that almost all interesting AGs are already in the class
     of ordered attribute-grammars (OAGs).  I plan to implement the OAG
     evaluation strategy next.

  2. Traditionally AGs are defined over "productions" which are
     sequences of nonterminals and terminals.  This doesn't correspond
     to the way we define OCaml constructor data-types.  So instead of a
     constructor like

     ┌────
     │ type expr =
     │   ... | Call of name * arg_list
     │ and arg_list = NoArgs | SomeArgs of expr * arg_list
     └────
     we might want to use ~ 'a list~
     ┌────
     │ type expr =
     │   ... | Call of name * expr list
     └────

     Problem is: defining attribute-equations for (effectively) an array
     of nodes, is not part of the standard lingo of AGs.  But I believe
     we can invent new syntax and make this succinct.

  3. Storage optimization.  A naive implementation of AGs can store all
     attributes ever computed, at all the nodes in the AST.  This can
     use a lot of memory.  But there are well-known techniques to
     discard attributes once they'll never more be needed in the rest of
     the attribute-evaluation, and I plan to implement these techniques.

  There's an entire literature on things like remote-references in
  attribute grammars, aggregates, and other things, all of which can
  probably be usefully employed.


Conclusion
╌╌╌╌╌╌╌╌╌╌

  I think that attribute-grammars could be a useful way to structure
  complex multipass program-analysis, just as they used to do back in
  the good ol' days.

  Maybe worth a look-see!


erlang 0.0.14, a toolkit to manipulate Erlang sources
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-erlang-0-0-14-a-toolkit-to-manipulate-erlang-sources/6694/1>


ostera announced
────────────────

  Hej, hope you're staying safe :raised_hands:

  I'm excited to share with you the first release of `erlang'.

  *tl;dr*: _parser/lexer/ast/printer for Erlang_


Description
╌╌╌╌╌╌╌╌╌╌╌

  `erlang' is a toolkit for manipulating Standard Erlang and Core Erlang
  sources and their abstract syntax trees according to the Erlang
  specifications.

  Version 0.0.14 provides:
  • A lexer/parser written in Menhir for Standard Erlang
  • ASTs for Core Erlang and Standard Erlang
  • An AST helper module for constructing Standard Erlang programs
  • A printer for the Standard Erlang AST (of highly volatile
    prettiness)
  • Support to turn ASTs to S-expressions
  • `erldump', a binary tool for reading Erlang sources and printing
    their concrete syntax trees as S-expressions.

  It is distributed under Apache-2.0 license, depends on Menhir and
  Cmdliner, and it is being developed as part of the Caramel project.

  • *PR*: <https://github.com/ocaml/opam-repository/pull/17553> – should
     be on opam.ocaml.org sometime tomorrow :)
  • *Homepage*: <https://github.com/AbstractMachinesLab/caramel>
  • *Install*: `opam install erlang'
  • *API Docs & manuals*: maybe on next release, but _follow the types_,
     and the `Erlang.Ast_helper' module is modeled after the
     `Parsing.Ast_helper' so it should feel familiar.

  I started writing `erlang' to let Caramel do an entirely symbolic
  compilation from the OCaml typedtree that would still allow for other
  passes/checks to be made cleanly. It's come with a decent number of
  tests, and it can parse some OTP modules with small modifications.

  There's [a few outstanding issues] regarding the parsing for the next
  release, but it should be a starting point for anyone wanting to read
  sources and _do something_ with them. I plan on cover these issues in
  the rest of the year, but as with all open source, it may take longer.

  I'd like to add a few other things, like an AST invariants module to
  check that ASTs are actually valid Erlang programs, and
  transformations more suitable for static analyses of the sources.

  My thanks go to @antron, @c-cube, @Drup, @rgrinberg, and @mseri for
  helping me get around the OCaml compiler, Menhir, and eventually to
  get this version split from Caramel and released independently.  Also
  a shoutout to the Js_of_ocaml project that served as a starting point
  for the parser/lexer work here.

  If you can give me some feedback on the design and implementation, I'd
  very much like to hear your thoughts :slight_smile:

  For those of you hoping to start using it, _do not_ let it crash.


[a few outstanding issues]
<https://github.com/AbstractMachinesLab/caramel/issues?q=is%3Aissue+is%3Aopen+label%3Alib%3Aerlang>


opam-bin.1.0.0: binary packages for opam
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-opam-bin-1-0-0-binary-packages-for-opam/6696/1>


Fabrice Le Fessant announced
────────────────────────────

  I am happy to announce the first stable release of `opam-bin', version
  1.0.0, a framework to CREATE, USE and SHARE binary relocatable
  packages with opam, to speed-up installation of packages. It is easily
  installable from opam-repository, and available on Github:

  <https://ocamlpro.github.io/opam-bin>

  With opam-bin, you can :

  • build binary packages while installing their source counterpart with
    opam
  • automatically reuse previously created binary packages instead of
    compiling them again
  • export and share your binary packages as part of opam repositories
    for other users/computers to use

  `opam-bin' is a framework in 3 parts :
  • a tool `opam-bin' to create binary packages:
    <https://ocamlpro.github.io/opam-bin>
  • a set of patches to make some packages relocatable (`opam-bin' will
    apply them automatically when building packages), including patches
    to make the OCaml distribution relocatable from version 4.02.0 to
    4.11.1: <https://github.com/ocamlpro/relocation-patches>
  • a set of contributed repositories of binary packages. For now, there
    is only one contribution, during the summer, by Origin Labs :
    <https://www.origin-labs.com/opam-bin/debian10.4-amd64/> containing
    5 repos, among which the "4.10.0" repo contains more than 1800
    packages. These repos can be used DIRECTLY WITH opam, WITHOUT USING
    opam-bin.

  This is the first stable release:
  • Specific support has been added in the current `master' branch of
    `opam' to make working with this version more convenient, by
    printing pre- and post- installation messages. Yet, it will still
    work with previous version of opam, but with no output on the
    terminal when calling opam.
  • The `sharing' option can be enabled to share files with hard-links
    between switches, making the creation of new local switches almost
    costless in time and disk space.

  `opam-bin' is a collaborative work between OCamlPro and Origin Labs.

  `opam-bin' is particularly useful if you create many local switches,
  as they become unexpensive. Tools like Drom (an OCaml project
  scaffolder, <https://ocamlpro.github.io/drom>) can take advantage of
  that to provide a cargo-like experience.


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/63>


Ryan Slade announced
────────────────────

  Anyone who's been following this blog probably saw this coming:

  <https://blog.darklang.com/leaving-ocaml/>

  It's an interesting read and hopefully can be used as constructive
  criticism in order to improve the state of the OCaml ecosystem.


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-27  8:43 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-10-27  8:43 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of October 20 to 27,
2020.

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

Bisect_ppx, the coverage tool, now has excellent integration with Dune
Js_of_ocaml in the VSCode OCaml Platform
Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
Set up OCaml 1.1.2
Set up OCaml 1.1.3
First release of FSML
Qrc 0.1.0, a QR code encoder
cumulus 0.0.1
Brr 0.0.1, a toolkit for programming browsers
Old CWN


Bisect_ppx, the coverage tool, now has excellent integration with Dune
══════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/bisect-ppx-the-coverage-tool-now-has-excellent-integration-with-dune/6634/1>


Anton Bachin announced
──────────────────────

  [*Bisect_ppx*], the coverage tool, has just had its [2.5.0] release,
  in which the main addition is a very neat integration with Dune:

  ┌────
  │ dune runtest --instrument-with bisect_ppx --force
  └────

  This uses the new [instrumentation support] added in Dune 2.7.0, and
  is a considerable improvement over the dubious methods Bisect and its
  users were previously forced to rely on :)

  It is no longer necessary to edit `dune' files for a release, as
  Bisect only becomes a dependency of your project when
  `--instrument-with bisect_ppx' is supplied on the Dune command line,
  which is only during development and in CI. This makes projects ready
  for release from any commit. Dune also now knows to rebuild affected
  files when instrumentation is turned on or off, so you don't have to
  manually run `dune clean' in between. Everything just works the way it
  should.

  See the updated [instructions] for all the details on how to use this
  integration.

  I've also adapted [Lambda Soup] as a simple full-project example. See
  its [`opam'], [`dune-project'], [`dune'], and [`Makefile'].

  Bisect_ppx still supports all the older integrations, so if you have
  an existing setup, you don't have to edit it. Support may eventually
  be removed in the future, however, so I encourage users to gradually
  update.

  See the full [changelog] for information on bugs fixed by the release.

  Thanks to the Dune team for adding `--instrument-with', to @undu for
  supporting it on the Bisect side, and to all the Bisect_ppx users and
  contributors!

  Happy testing!

  <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/original/2X/1/1911adc6af898b6f4efd7dc69d2c1f90699031ba.gif>

  <https://github.com/aantron/bisect_ppx>


[*Bisect_ppx*] <https://github.com/aantron/bisect_ppx>

[2.5.0] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>

[instrumentation support]
<https://dune.readthedocs.io/en/stable/instrumentation.html?highlight=instrument-with>

[instructions] <https://github.com/aantron/bisect_ppx#Dune>

[Lambda Soup] <https://github.com/aantron/lambdasoup>

[`opam']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/lambdasoup.opam#L17-L22>

[`dune-project']
<https://github.com/aantron/lambdasoup/blob/master/dune-project#L1>

[`dune']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/src/dune#L7>

[`Makefile']
<https://github.com/aantron/lambdasoup/blob/a0cbf54bf9affda00455c54369e473b905458114/Makefile#L15>

[changelog] <https://github.com/aantron/bisect_ppx/releases/tag/2.5.0>


Js_of_ocaml in the VSCode OCaml Platform
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/js-of-ocaml-in-the-vscode-ocaml-platform/6635/1>


Max LANTAS announced
────────────────────

  I just finished a write-up about [vscode-ocaml-platform]'s recent
  transition to Js_of_ocaml:
  <https://mnxn.github.io/blog/ocaml/vscode-jsoo/>

  I can answer any questions here.

  This is also my first technical blog post, so any constructive
  criticism or comments about my writing would be very helpful.


[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform/>


Training Sessions for "Fast Track to OCaml" and "Expert OCaml" in Paris (23-26 November 2020)
═════════════════════════════════════════════════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2020-10/msg00018.html>


Laurène Gibaud announced
────────────────────────

  At OCamlPro, we will be organizing 2 cross-company training sessions
  in French. Both sessions interleave theory and practice. You'll have
  time to ask your specific questions and get personalized feedback on
  your programs.

  • Our Beginner session will allow developers to build upon their
    experience of other programming languages (such as C, C++, Python,
    C# or Java) to program confidently in OCaml. Feel free to share the
    info with your coworkers or your network!
  • Our “Expert OCaml” training will allow you to master OCaml’s
    advanced features such as its type-system, OCaml’s open source tools
    and libraries, and how to write compact and efficient code.

  More info on the program and prerequisites on
  <http://www.ocamlpro.com/training-ocamlpro/> or ask away (answer this
  email or write at contact@ocamlpro.com).

  When? The Beginner session is scheduled for November 23-24, 2020. The
  Expert session will be on November 25-26, 2020.

  Where? Paris 14, in OCamlPro's office.

  How? Register on:
  <https://www.ocamlpro.com/pre-inscription-a-une-session-de-formation-inter-entreprises/>

  We can also organize custom and on-site sessions upon request.


Set up OCaml 1.1.2
══════════════════

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


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

  This release contains these changes:

  • Add the Cygwin setup to a known location for later steps
  • Check if the switch exists before creating the switch

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.2>


Set up OCaml 1.1.3
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-set-up-ocaml-1-1-3/6644/1>


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

  This release contains these changes:

  • Update the `@actions/core' package to address [CVE-2020-15228]

  <https://github.com/avsm/setup-ocaml/releases/tag/v1.1.3>


[CVE-2020-15228] <https://github.com/advisories/GHSA-mfwh-5m23-j46w>


First release of FSML
═════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-fsml/6645/1>


jserot announced
────────────────

  This is to announce the first public release of FSML, an OCaml library
  for describing and describing synchronous finite state machines.

  FSML is a simplified version of the library provided in the [Rfsm]
  package for which

  • the system is composed of a single FSM

  • this FSM has a single, implicit, triggering event (typically called
    the *clock* , hence the term *synchronous* used in the description)

  The FSML library provides

  • a type `Fsm.t' for describing FSMs
    • possibly having *local variables*
    • for which *transitions* , implicitely triggered by a clock, are
      defined by a set of *boolean guards* and a set of *actions*

  • a set of PPX extensions for building values of type `Fsm.t'

  • functions for producing and viewing graphical representations of
    FSMs in the `.dot' format

  • functions for saving and reading FSM representations in files using
    the JSON format

  • functions for performing single or multi-step simulations of FSMs
    and generating trace files in the `.vcd' format to be viewed by VCD
    viewers such as [gtkwave]

  • functions for generating C or VHDL code from a FSM representation
    (for integration into existing
  code and/or simulation)

  FSML is available from [Github] or as an [OPAM package].


[Rfsm] <http://github.com/jserot/rfsm>

[gtkwave] <http://gtkwave.sourceforge.net/>

[Github] <https://github.com/jserot/fsml>

[OPAM package] <https://opam.ocaml.org/packages/fsml>


Qrc 0.1.0, a QR code encoder
════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-qrc-0-1-0-a-qr-code-encoder/6647/1>


Daniel Bünzli announced
───────────────────────

  QR codes are unsightly – a mirror of their specification. But they
  enable all sorts of neat tricks now that scanners for them are in many
  pockets.

  Qrc generate them:

        Qrc encodes your data into QR codes. It has built-in QR
        matrix renderers for SVG, ANSI terminal and text.

        Qrc is distributed under the ISC license. It has no
        dependencies.

  Homepage: <https://erratique.ch/software/qrc>
  API docs: <https://erratique.ch/software/qrc/doc/> or `odig doc qrc'
  Install: `opam install qrc'


cumulus 0.0.1
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-cumulus-0-0-1/6655/1>


Petter A. Urkedal announced
───────────────────────────

  I would like to announce a new FRP library built on the React library.
  The purpose of [cumulus] is to help organize code which work on
  differential updates.  The main type is the *cumulus signal*, which is
  analogous to a react signal, except that information about the
  difference from the previous value is provided to consumers along with
  the new value, when the cumulus signal changes.

  So, why does a cumulus signal provide both the state and the
  difference to downstream signals?  That is, what is the difference
  between the following:?
  ┌────
  │ type t1 = state * change React.E     (* initial value and even of changes *)
  │ type t2 = (state, change) Cumulus.t  (* the cumulus signal *)
  └────
  The former type presumes that after the consumer has received the
  initial state, it will only need to know what changes on successive
  updates.  This seems quite natural.  It works well if, for instance,
  we want to reconstruct a signal holding a set of strings, given an
  initial set and a series of additions and removals:
  ┌────
  │ module String_set = Set.Make (String)
  │ 
  │ type 'a set_patch = [`Add of string | `Remove of string]
  │ type 'a update = 'a -> 'a
  │ 
  │ let patch_string_set : string set_patch -> String_set.t update = function
  │  | `Add x -> String_set.add x
  │  | `Remove x -> String_set.remove x
  │ 
  │ let integrate_strings (init, changes) =
  │   React.E.fold (fun l p -> patch_string_set p l) init changes
  └────
  But what if we want to maintain a signal holding the intersection of
  two sets of strings?  If we try to lift the intersection operation to
  work on patches, we discover that learning about the addition of an
  element to left-hand set is not sufficient to determine whether the
  element shall the added to the resulting set; we also need to know
  whether the element is a member of the right-hand set.  So, in this
  case we would instead use cumulus signals:
  ┌────
  │ let cu : (String_set.t, string set_patch) Cumulus.t = ...
  │ let cv : (String_set.t, string set_patch) Cumulus.t = ...
  │ let cuv =
  │   let init u v = String_set.inter u v in
  │   let patch (u, du) (v, dv) r' =
  │     (match du, dv with
  │      | None, Some x when String_set.mem x u ->
  │ 	Cumulus.Patch (String_set.add x r', `Add1 x)
  │      ...)
  │   in
  │   Cumulus.l2 ~init ~patch cu cv
  └────
  For the complete example, using integers instead of strings, see
  [`test_isecn.ml'] from the testsuite.

  (Footnote: If consumers know how to integrate the states they depend
  on, they could in principle keep their own record of the full states
  of the arguments.  But this would be inefficient if there are many
  consumers, and there is also a simplification of code and possibly
  improved abstraction in letting the producer maintain its own state.)

  Formally, we can understand the difference between `t1' and `t2' in
  terms of calculus.  For instance, the differential of a product
  `d(x·y) = dx·y + x·dy' contains a mix of both the differentials and
  values of the two variables.  But if the expression is linear, only
  differentials will will occur: `d(a·x + b·y + c) = a·dx + b·dy'.  So,
  when `t1' is sufficient, we are dealing with the analogue of a linear
  function.  The above example could be turned into a linear one by
  making `Labels.t' a multiset type and considering the multiset union
  operation.

  Thus far we only considered purely functional code, but a cumulus
  signal may chose to modify and return the same physical state during
  an update.  Also note when designing the differential component of the
  cumulus signal, that we may exploit the fact the consumers also may
  inspect the corresponding new state.  Combining these two points, a
  cumulus signal holding an array might have the type `('a array, [`Set
  of int | `Resize of int])'. Here the state may be reused for ``Set'
  and replaced for ``Resize'.

  On a related not, there is also the [reactiveData] library which deals
  with (linear) patching of containers.

  I must also mention that there there is an [OCaml project with the
  same name] (except casing). Sorry for not checking thoroughly in
  advance. I hope it is not an issue in practise, otherwise there is
  still time to rename while the library is fresh.


[cumulus] <https://github.com/paurkedal/ocaml-cumulus/>

[`test_isecn.ml']
<https://github.com/paurkedal/ocaml-cumulus/blob/master/tests/test_isecn.ml>

[reactiveData] <https://github.com/ocsigen/reactiveData>

[OCaml project with the same name] <https://github.com/Cumulus/Cumulus>


Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/5>


Continuing this thread, Yoann Padioleau asked Daniel Bünzli replied
───────────────────────────────────────────────────────────────────

        What are the differences with the default bindings
        provided in js_of_ocaml to the browser APIs (e.g., js.mli,
        dom.mli, etc.)?

  I'm not sure exactly what you are asking but:

  1. If you are asking about the way API are exposed: `brr' does not
     type JavaScript's objects as phantom types. It simply relies on
     OCaml's abstract data types and plain functions. More about this
     can be found in brr's [FFI manual] and [FFI cookbook].
  2. If you are asking about binding coverage, you should be able to get
     a sense of what is bound in `brr' [here].

  Regarding 2. `brr''s coverage of more recent browser APIs is broader
  and more consistent than in `js_of_ocaml' – Promise support, Fetch,
  Service workers, Media capture APIs, WebGL2, Webcrypto, WebAudio,
  etc. Conversly older APIs supported in `js_of_ocaml' may not supported
  in `brr' (e.g.  XMLHTTPRequest). Besides `brr''s coverage of some of
  the DOM *element-specific* interfaces may be shallower than in
  `js_of_ocaml'. There is however good coverage for the
  [`HTMLMediaElement'], [`HTMLCanvasElement'], [`HTMLFormElement'] and
  [`HTMLInputElement'] interfaces. For the rest the [attribute and
  property API] and the occasional trivial FFI method binding should be
  able to get you a long way.


[FFI manual] <https://erratique.ch/software/brr/doc/ffi_manual.html>

[FFI cookbook] <https://erratique.ch/software/brr/doc/ffi_cookbook.html>

[here] <https://erratique.ch/software/brr/doc/index.html#supported_apis>

[`HTMLMediaElement']
<https://erratique.ch/software/brr/doc/Brr_io/Media/index.html#el>

[`HTMLCanvasElement']
<https://erratique.ch/software/brr/doc/Brr_canvas/Canvas/index.html>

[`HTMLFormElement']
<https://erratique.ch/software/brr/doc/Brr_io/Form/index.html>

[`HTMLInputElement']
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ifaces>

[attribute and property API]
<https://erratique.ch/software/brr/doc/Brr/El/index.html#ats_and_props>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-20  8:15 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-10-20  8:15 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of October 13 to 20,
2020.

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

Dialo is hiring frontend and backend OCaml developers (Remote)
Progress 0.1.0
Brr 0.0.1, a toolkit for programming browsers
New release of Conduit
Easy cross compilation using esy
OCaml User Survey 2020
Old CWN


Dialo is hiring frontend and backend OCaml developers (Remote)
══════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dialo-is-hiring-frontend-and-backend-ocaml-developers-remote/6604/1>


Wojtek Czekalski announced
──────────────────────────

  [Dialo] is an early stage company with an experienced founding
  team. Assembling a team that consists of the best and brightest is our
  top priority. In the immediate term we are building a visual
  programming language for conversational AI. Our long term vision is
  that personalized contact we are enabling will cause deeper
  relationships between users and businesses and turn all interactions
  into a unified long term customer journey.

  The work is quite demanding when it comes to both ideation and
  implementation. We are aiming to provide a room for growth both
  technically and/or as a leader. For current open source maintainers we
  are willing to sponsor your work on OSS for 20% of time.

  We use OCaml for frontend and backend (along with Python for machine
  learning, natural language processing). We are hiring people for
  different positions. Both people with extensive experience and
  newcomers are encouraged to apply. We try to find the sharpest people
  rather than checking boxes with particular skills.

  The official job posting:
  <https://dialo.recruitee.com/o/software-developer-ocamlreason> We are
  also hiring for two other (related) positions:
  • <https://dialo.recruitee.com/o/software-developer-frontend>
  • <https://dialo.recruitee.com/o/software-developer-backend>


[Dialo] <https://dialo.ai>


Progress 0.1.0
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-progress-0-1-0/6607/1>


Craig Ferguson announced
────────────────────────

  I'm pleased to announce the first release of [`Progress'], now
  available on Opam.

  <https://raw.githubusercontent.com/CraigFe/progress/main/.meta/example.svg>

  `Progress' is a small library for quickly defining and using progress
  bars in OCaml programs. It aims to provide the following:

  • support for rendering multiple progress bars simultaneously;
  • responds dynamically to changes in terminal size;
  • allows user-defined progress bar layouts.


[`Progress'] <https://github.com/CraigFe/progress/>

Defining your own progress bars
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The example animation above uses a pre-provided progress bar layout
  that should meet many needs ([`Progress_unix.counter']), but it's
  fairly easy to re-define it ourselves using the low-level
  [`Progress.Segment'] API:

  ┌────
  │ let counter filename =
  │   let proportion i = Int64.to_float i /. 1_000_000. in
  │   let open Progress in
  │   Segment.(
  │     list
  │       [
  │ 	const filename;
  │ 	Units.bytes of_pp;
  │ 	Progress_unix.stopwatch ();
  │ 	bar ~mode:`ASCII proportion;
  │ 	using proportion (Units.percentage of_pp);
  │       ]
  │     |> box_winsize ~fallback:80  (* Dynamically scale to window size *)
  │     |> periodic 100              (* Re-render once every 100 updates *)
  │     |> accumulator Int64.add 0L  (* Accumulate progress updates *))
  │   |> make ~init:0L
  └────

  The `Segment' combinators are similar to those of general-purpose
  pretty-printing libraries (e.g.  [`pp'] and [`fmt']), but are equipped
  with extra logic for "stateful" segments and segments that can have
  dynamic width. Together, these make for a convenient way to express
  common patterns when pretty-printing progress bars. For instance, the
  stateful segment `periodic' seen above can be used to ensure that very
  frequent updates from a hot-loop do not result in too much time spent
  re-rendering the output.

  The library is not yet feature-complete, but should still be
  reasonably useful :slightly_smiling_face: Happy hacking!


[`Progress_unix.counter']
<https://craigfe.github.io/progress/progress/Progress_unix/index.html#val-counter>

[`Progress.Segment']
<https://craigfe.github.io/progress/progress/Progress/Segment/index.html>

[`pp'] <https://github.com/ocaml-dune/pp>

[`fmt'] <https://erratique.ch/software/fmt>


Brr 0.0.1, a toolkit for programming browsers
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-brr-0-0-1-a-toolkit-for-programming-browsers/6608/1>


Daniel Bünzli announced
───────────────────────

  I'd like to announce the first release of Brr.

  The TL; DR is:
        If you are looking for a productive way to program
        browsers with js_of_ocaml but without ppx and ghost OCaml
        objects, give Brr a try.

  The details:

        Brr is a toolkit for programming browsers in OCaml with
        the [`js_of_ocaml'] compiler. It provides:
        • Interfaces to a [selection] of browser APIs.
        • Note based reactive support (optional and experimental).
        • An [OCaml console] developer tool for live interaction
          with programs running in web pages.
        • A JavaScript FFI for idiomatic OCaml programming.

        Brr is distributed under the ISC license. It depends on
        [Note] and on the `js_of_ocaml' compiler and runtime – but
        not on its libraries or syntax extension.

  • Homepage: <https://erratique.ch/software/brr>
  • API Docs & manuals: <https://erratique.ch/software/brr/doc/> or
    `odig doc brr'
  • Install: `opam install brr'

  Brr is essentially what I need to be productive for browser
  programming with js_of_ocaml: an obvious FFI with JavaScript objects
  as abstract data types without OCaml object phantom types and binding
  documentation precisely linking into MDN.

  The OCaml console is the hack on the cake. In the past I often found
  it frustrating to have OCaml programs running in my webpages and be
  greeted with a JavaScript prompt in the browser dev tools.  Quite a
  bit of polishing could be done on that though. Some of which should
  likely directly be done upstream in the toplevel machinery
  (e.g. identifier completion, a better toploop API and support for easy
  pretty printer installation). It would also be nice if we could cut
  down on `js_of_ocaml''s toplevel compilation times ;–)

  Parts of Brr have been seriously dogfooded in the past but that new
  incarnation is largely untested for now and certain APIs might need
  adjustements. Early adopters should study actual binding coverage,
  expect glitches and little breakages in the future.

  The Note reactive functionality was also seriously used in the past
  but Note itself needs a new design round and I don't have the
  ressources to do it right now, expect breakage, don't pay too much
  attention to it for now.

  My thanks to the `js_of_ocaml' developers for the nice ocaml to
  javascript compiler and a special shootout to Hugo Heuzard for not
  getting mad at me when pinging him directly for questions.

  Happy browser compatibility bug hunting,


[`js_of_ocaml'] <https://ocsigen.org/js_of_ocaml>

[selection]
<https://erratique.ch/software/brr/doc/index.html#supported_apis>

[OCaml console]
<https://erratique.ch/software/brr/doc/ocaml_console.html>

[Note] <https://erratique.ch/software/note>


gasche asked
────────────

  It's not really released, but I'm curious about [Note] now: this is a
  new FRP library from you, the author of [React] (the FRP library for
  OCaml, not the Javascript framework of the same name).

  Would you say a few words on why you went for a different library? My
  guess would be that React depends on runtime mechanisms (weak
  pointers) that are not well-supported in Javascript-lang; but even if
  the guess is right, I'm not sure what would be the impact on the API
  or properties of the library.


[Note] <https://erratique.ch/software/note>

[React] <https://erratique.ch/software/react>


Daniel Bünzli replied
─────────────────────

        Would you say a few words on why you went for a different
        library?

  `Note' is the result from seeing people (and myself) struggling to use
  ~React~/FRP "correctly" over the years.

  Some of this, I largely attribute to ergonomic problems with the
  API. It's my hope for `Note' to address most of these points (one
  thing that still needs to be done is replace fix points by a simple
  lazy infinitesimal delay combinator).

  I don't think I could have made all these changes in `React' itself so
  I found it better to start a new library. Also I lost the trademark on
  the name :–)

  `Note' also tries to provide a much simpler implementation. `React''s
  implementation was based on the [FrTime Phd thesis]. It's quite subtle
  and involved and, as you suggested, uses weak pointer. `Note' tries to
  avoid them since those are not available in the browser (but you have
  things like [MutationObservers] which I use as gc in Brr's Note-based
  [reactive dom support]).

  However not using weak pointers has a semantic uncleanness cost whose
  impact I'm unsure yet – without discipline from the programmer it may
  lead to subtle and hard to track bugs when the reactive graph changes
  dynamically, which I'm a bit wary of.

  When my brain dumped `Note' I wrote a few more technical points in the
  readme you can read them [here].


[FrTime Phd thesis] <http://cs.brown.edu/people/ghcooper/thesis.pdf>

[MutationObservers]
<https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver>

[reactive dom support]
<https://erratique.ch/software/brr/doc/Brr_note/Elr/index.html>

[here] <https://github.com/dbuenzli/note#history>


New release of Conduit
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-new-release-of-conduit/6611/1>


Calascibetta Romain announced
─────────────────────────────

  *Conduit 3.0.0*

  Hello everyone,

  We're glad to announce the new release of [`conduit'], a framework
  that allows to _abstract_ over transfer protocols. One of its main
  advantages is allowing the implemententation of _free-dependencies_
  protocols.


[`conduit'] <https://github.com/mirage/ocaml-conduit>

Introduction
╌╌╌╌╌╌╌╌╌╌╌╌

  There are several ways to abstract over an implementation in
  OCaml. However, those solutions are often lost deep in the stack of
  protocols and allowing the user to choose the implementations of the
  sub-procotols implies growing complexity as we move up through the
  stack. (For example, allowing to abstract over the implementation of
  the TLS protocol from the implementation of the HTTP protocol)

  One of those solutions, the _functors_, can rapidly become a hellish
  nightmare for the end-user. This is especially true in the case of
  MirageOS, which literally wants to abstract over everything!

  This is why Conduit was implemented: it aims to provide to the user a
  cleaner abstraction mechanism which would allow the protocol
  developers to get rid of most of the responsibilities concerning the
  choice of sub-protocols (Like which TLS implementation use between
  OpenSSL or our great [ocaml-tls] library), while giving the end-users
  an easy way to compose the protocols of their choice and inject them
  in the stack via conduit.


[ocaml-tls] <https://github.com/mirleft/ocaml-tls>


Usage of Conduit
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Such a framework allows us to separate the logic of a protocol from
  underlying implementation needed to communicate with a peer. The
  distribution of Conduit comes with [a simple tutorial] which explains
  step by step how to implement a _ping-pong_ client & server and, most
  importantly, how to upgrade them with TLS.

  With Conduit, we ensure the compatibility with MirageOS (and specially
  [mirage-tcpip]) while being useful for others. Of course, Conduit is
  not mandatory to ensure this compatibility, but it helps us for
  _higher_ libraries such as [ocaml-git]/[Irmin] or [Cohttp].


[a simple tutorial]
<https://mirage.github.io/ocaml-conduit/conduit/howto.html>

[mirage-tcpip] <https://github.com/mirage/mirage-tcpip>

[ocaml-git] <https://github.com/mirage/ocaml-git>

[Irmin] <https://github.com/mirage/irmin>

[Cohttp] <https://github.com/mirage/ocaml-cohttp>


Specific improvements
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Abstract and destruct it!

  The most requested feature on the new version of Conduit is the
  ability to _destruct_ the [Conduit.flow][conduit-flow]. The ability to
  abstract the protocol comes with the _abstract_ type
  `Conduit.flow'. The new version permits to _destruct_ it to a
  well-known value (such as an UNIX socket):

  ┌────
  │ let handler flow = match flow with
  │   | Conduit_lwt.TCP.T (Value file_descr) ->
  │     let peer = Lwt_unix.getpeername file_descr in
  │     ...
  │   | flow -> ... (* other kind of protocol *)
  │ 
  │ let run =
  │   Cohttp_lwt_unix.serve ~handler
  │     { sockaddr= Unix.inet_addr_loopback }
  └────


◊ The dispatch of the protocol

  The second most interesting feature of Conduit is the full control
  over the dispatch between protocols by the end-user. From a concrete
  information such as an `Uri.t', the end-user is able to describe how
  Conduit should choose the protocol (and with which value it should try
  to initiate the connection):

  ┌────
  │ let my_tls_config = Tls.Config.client ...
  │ 
  │ let connect uri =
  │   let edn = Conduit.Endpoint.of_string
  │     (Uri.host_with_default ~default:"localhost" uri) in
  │   let resolvers = match Uri.scheme uri with
  │     | Some "https" ->
  │       let port = Option.value ~default:443 (Uri.port uri) in
  │       Conduit_lwt.add
  │ 	Conduit_lwt_tls.TCP.protocol
  │ 	(Conduit_lwt_tls.TCP.resolve ~port ~config:my_tls_config)
  │ 	Conduit.empty
  │     | Some "http" | None ->
  │       let port = Option.value ~default:80 (Uri.port uri) in
  │       Conduit_lwt.add
  │ 	Conduit_lwt.TCP.protocol
  │ 	(Conduit_lwt.TCP.resolve ~port)
  │ 	Conduit.empty in
  │   Conduit_lwt.resolve ~resolvers edn >>= fun flow ->
  │   ...
  └────


◊ An explicit way to launch a server

  Conduit comes with a new API for the server-side, where everything
  becomes explicit: no dispatch, no hidden choice. It proposes now a
  simple function to start the usual server loop:

  ┌────
  │ let run handler =
  │   Conduit_lwt.serve ~handler
  │     Conduit_lwt.TCP.service
  │     { Conduit_lwt.TCP.sockaddr= Unix.(ADDR_INET (inet_addr_loopback, 8080)
  │     ; capacity= 40 }
  └────


Reverse-dependencies
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Conduit is used by many libraries (~150 packages) and we spend 2
  months to track this breaking-change.  Currently, it's mostly about
  [Cohttp] and [Irmin] and both have a PR according the new version of
  Conduit. These packages will be released as soon as we can with the
  new version of Conduit.


[Cohttp] <https://github.com/mirage/ocaml-cohttp>

[Irmin] <https://github.com/mirage/irmin>


Conclusion
╌╌╌╌╌╌╌╌╌╌

  Conduit is a piece required by many libraries but nobody really uses
  it. This new version wants to replace and redefine more concretely
  what Conduit is. The update is [huge] for us but small for people
  where we tried to keep the same global idea of the abstraction.

  I would like to thank many people (MirageOS core team, Cohttp peoples,
  some not so famous guys of the Reason/OCaml eco-system) who followed
  us on this deep development (and tried and iterated on our
  version). It does not change too much our world, but it paves the way
  for a better MirageOS/OCaml eco-system.

  As a french guy, I just would like to say: Conduit est mort, Vive
  Conduit!


[huge] <https://github.com/mirage/ocaml-conduit/pull/311>


Easy cross compilation using esy
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-easy-cross-compilation-using-esy/6612/1>


EduardoRFS announced
────────────────────

  I've been working on this for a couple of months now, and now it is
  ready for an initial announcement of my tools to cross compiling OCaml
  and ReasonML Native.

  <https://github.com/EduardoRFS/reason-mobile>


What it can do
╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Out of box it can cross compile most dune and topkg, packages
  available on opam for a couple of platforms, there is also patches for
  popular packages.

  You can also compile opam packages by making an wrapper, like

  <https://github.com/mirage/mirage-crypto/pull/84/files>


Limitations
╌╌╌╌╌╌╌╌╌╌╌

  Your package should build with OCaml 4.10, and all the packages that
  are built for the `host' will also be build for the `target', so
  sometimes you need to fix a package that you will not use directly.

  Some packages you will need to pin to a `dune-universe' fork version


How to use it
╌╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ ## compile your project
  │ esy
  │ 
  │ ## generate the wrapper
  │ esy add -D generate@EduardoRFS/reason-mobile:generate.json
  │ esy generate android.arm64
  │ 
  │ ## build for android.arm64
  │ esy @android.arm64
  └────


Platforms
╌╌╌╌╌╌╌╌╌

  All of the following are tested from Linux and macOS, but I would
  suppose that FreeBSD should be also working as a build system.

  ━━━━━━━━━━━━━━━━━━━━━━
   Targets              
  ──────────────────────
   android.arm64        
   android.x86_64       
   ios.arm64            
   ios.simulator.x86_64 
   linux.musl.arm64     
   linux.musl.x86_64    
  ━━━━━━━━━━━━━━━━━━━━━━


What I tested
╌╌╌╌╌╌╌╌╌╌╌╌╌

  In the past I was able to build `Revery' the UI framework for
  `Android' and `iOS'

  But recently I did compile `esy' the package manager itself for all of
  the following platforms above from an `Arch Linux x86_64' and `macOS
  Catalina x86_64'. Including `iOS', with the right version of OCaml it
  will run inside of the new `macOS ARM64' and inside of a jailbroken
  iPhone.


OCaml User Survey 2020
══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-user-survey-2020/6624/1>


gasche announced
────────────────

  We are happy to announce the [OCaml User Survey 2020]. We are trying
  to get a better picture of the OCaml community and its needs. It would
  be very useful if you could fill the survey (10-15 minutes), and share
  it widely with other OCaml programmers!

  The survey is run by the [OCaml Software Foundation]. Thanks in
  particular to our sponsors OCamlPro (@MuSSF) for preparing many of the
  questions, Jane Street (@Yaron_Minsky) for excellent feedback, and to
  Kim @K_N Nguyễn for his technical help.

  This is our first year running the survey, we hope to continue in
  following years. There are many things to improve; please feel free to
  give us feedback! (There is a feedback question at the end of the
  survey, or you can post here, or send me a message/email.)

  The survey was inspired by programming-language surveys ran by other
  communities. See for example past survey results for [Go], [Haskell],
  [Rust], and [Scala].


[OCaml User Survey 2020] <https://forms.gle/MAT7ZE7RtxTWuNgK7>

[OCaml Software Foundation] <https://ocaml-sf.org/>

[Go] <https://blog.golang.org/survey2019-results>

[Haskell] <https://taylor.fausak.me/2019/11/16/haskell-survey-results/>

[Rust] <https://blog.rust-lang.org/2020/04/17/Rust-survey-2019.html>

[Scala] <https://scalacenter.github.io/scala-developer-survey-2019/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-10-06  7:22 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-10-06  7:22 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of September 29 to
October 06, 2020.

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

vue-jsoo 0.2
Rehabilitating packs using functors and recursivity, part 2
Clap 0.1.0 (Command-Line Argument Parsing)
Old CWN


vue-jsoo 0.2
════════════

  Archive: <https://discuss.ocaml.org/t/ann-vue-jsoo-0-2/6522/1>


levillain.maxime announced
──────────────────────────

  I'd like to announce the second release of vue-jsoo (vue-jsoo.0.2). A
  js_of_ocaml binding and helpers to use the vue-js framework with
  js_of_ocaml.


Xavier Van de Woestyne added
────────────────────────────

  Here is the link: <https://gitlab.com/o-labs/vue-jsoo>

  (Congratulation!)


Rehabilitating packs using functors and recursivity, part 2
═══════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity-part-2/6525/1>


OCamlPro announced
──────────────────

  Following the publication of [the first part] of our blogpost about
  the redemption of packs in the OCaml ecosystem, we are pleased to
  share "[Rehabilitating packs using functors and recursivity, part 2.]"

        This blog post and the previous one about functor packs
        covers two RFCs currently developed by OCamlPro and Jane
        Street. We previously introduced functor packs, a new
        feature adding the possiblity to compile packs as
        functors, allowing the user to implement functors as
        multiple source files or even parameterized libraries.

        In this blog post, we will cover the other aspect of the
        packs rehabilitation: allowing anyone to implement
        recursive compilation units using packs (as described
        formally in the RFC#20). Our previous post introduced
        briefly how packs were compiled and why we needed some
        bits of closure conversion to effectively implement big
        functors. Once again, to implement recursive packs we will
        need to encode modules through this technique, as such we
        advise the reader to check at least the introduction and
        the compilation part of functor packs.


[the first part]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>

[Rehabilitating packs using functors and recursivity, part 2.]
<https://www.ocamlpro.com/2020/09/30/rehabilitating-packs-using-functors-and-recursivity-part-2/>


Clap 0.1.0 (Command-Line Argument Parsing)
══════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-clap-0-1-0-command-line-argument-parsing/6544/1>


rbardou announced
─────────────────

  I am happy to announce the first release of Clap.

  Clap is a library for command-line argument parsing. Clap works by
  directly consuming arguments in an imperative way. Traditionally,
  argument parsing in OCaml is done by first defining a specification
  (an OCaml value defining the types of arguments), and then parsing
  from this specification. The "impure" approach of Clap skips the need
  to define a specification and results in code which is quite simple in
  practice, with limited boilerplate.

  Clap is available as an opam package (`opam install clap').

  Source code, API documentation and a full commented example are
  available at: <https://github.com/rbardou/clap/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-29  7:02 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-09-29  7:02 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of September 22 to
29, 2020.

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

Opam-repository: security and data integrity posture
jsonoo 0.1.0
Interesting OCaml Articles
Rehabilitating Packs using Functors and Recursivity
the OCaml Software Foundation
dual 0.1.0
Old CWN


Opam-repository: security and data integrity posture
════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/opam-repository-security-and-data-integrity-posture/6478/1>


Chas Emerick said, spawning a huge thread
─────────────────────────────────────────

  In connection with [another thread] discussing the fact that
  Bitbucket's closure of mercurial support had affected the availability
  of around 60+ projects' published versions, I learned of a number of
  facts about how the opam repository is arranged, and how it is managed
  that are concerning.

  In summary, it seems that opam / opam-repository:

  1. Never retains "published" artifacts, only links to them as provided
     by library authors.
  2. Allows very weak hashes (even md5).
  3. Allows authors to _update_ artifact URLs and hashes of previously
     "published" versions.
  4. Offers scant support for individually signing artifacts or
     metadata.

  All of these are quite dangerous. As a point of reference, the
  ecosystems I am most familiar with using prior to OCaml (JVM and
  Javascript) each had very serious documented failures and exploits
  (and many many more quiet ones) until their respective package
  managers (Maven Central et al., and npm) plugged the above
  vulnerabilities that opam-repository suffers from.

  To make things concrete, without plugging the above (and especially
  items 1-3):

  • the availability and integrity of published libraries can be
    impacted by third-party hosting services changing or going offline
    (as in the case of the Bitbucket closure)
  • the integrity of libraries can be impacted by authors
    non-maliciously publishing updates to already-released versions,
    affecting functionality, platform compatibility, build
    reproducibility, or all of the above (anecdotes of which were shared
    with me when talking about this issue earlier today)
  • the integrity of libraries can be impacted by malicious authors
    publishing updates to already-released versions
  • the integrity of libraries can be impacted by malicious non-authors
    changing the contents at tarball URLs to include changed code that
    could e.g. exfiltrate sensitive data from within the organizations
    that use those libraries. This is definitely the nuclear nightmare
    scenario, and unfortunately opam is wide open to it thanks to
    artifacts not being retained authoritatively and [essential
    community libraries] continuing to use md5 in 2020.

  Seeing that this has been well-established policy for years was
  honestly quite shocking (again, in comparison to other languages'
  package managers that have had these problems licked for a very very
  long time). I understand that opam and its repository probably have
  human-decades of work put into them, and that these topics have been
  discussed here and there (in somewhat piecemeal fashion AFAICT), so
  I'm certain I have not found (nevermind read) all of the prior art,
  but I thought it reasonable to open a thread to gauge what the
  projects' posture is in general.


[another thread]
<https://discuss.ocaml.org/t/bitbucket-stopped-supporting-mercurial-repositories/6324/3?u=cemerick>

[essential community libraries]
<https://github.com/ocaml/opam-repository/blob/master/packages/core/core.v0.14.0/opam>


Hannes Mehnert replied
──────────────────────

  first of all thanks for your post raising this issue, which is
  important for me as well.

  I've been evaluating and working on improving the security of the
  opam-repository over the years, including to not use `curl –insecure`
  (i.e. properly validate TLS certificates) - the WIP result is [conex],
  which aims at cryptographically signed community repositories without
  single points of failures (threshold signatures for delegations,
  built-in key rollover, …) - feel free to read the blog posts or OCaml
  meeting presentations. Unfortunately it still has not enough traction
  to be deployed and mandatory for the main opam repository. Without
  cryptopgraphic signatures (and an established public key
  infrastructure), the hashes used in opam-repository and opam are more
  checksums (i.e. integrity protection) than for security. Threat models
  - I recommend to read section [1.5.2 "goals to protect against
  specific attacks"] - that's what conex above is based on and attempts
  to mitigate. I'll most likely spend some time on improving conex over
  the next year, and finally deploying it on non-toy repositories.

  In the meantime, what you're mentioning:
  1. "Never retains 'published' artifacts" <- this is not true, the
     opam.ocaml.org host serves as an artifact cache, and is used by
     opam when you use the default repository. This also means that the
     checksums and the tarballs are usually taken from the same host ->
     the one who has access there may change anything arbitrarily for
     all opam users.
  2. "Weak hashes" <- this is true, I'd appreciate if (a) opam would
     warn (configurable to error out) if a package which uses weak
     checksum algorithms, and (b) Camelus or some other CI step would
     warn when md5/sha1 are used
  3. "Authors can modify URLs and hashes" <- sometimes (when a
     repository is renamed or moved on GitHub) the GitHub auto-generated
     tarball has a different checksum. I'd appreciate to, instead of
     updating that meta-data in the opam-repository to add new
     patch-versions (1.2.3-1 etc.) with the new URL & hash - there could
     as well be a CI job / Camelus check what is allowed to be modified
     in an edit of a package (I think with the current state of the
     opam-repository, "adding upper bounds" on dependencies needs to be
     allowed, but not really anything else).
  4. I'm not sure I understand what you mean - is it about cryptographic
     signatures and setting up a public key infrastructure?


[conex] <https://github.com/hannesm/conex>

[1.5.2 "goals to protect against specific attacks"]
<https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#the-update-framework-specification>


Anton Kochkov said
──────────────────

  Closely related issue is
  <https://discuss.ocaml.org/t/how-to-setup-local-opam-mirror/4423>,
  since the integrity checks and verification will become even more
  important if there will be multiple mirrors in the future.


jsonoo 0.1.0
════════════

  Archive: <https://discuss.ocaml.org/t/ann-jsonoo-0-1-0/6480/1>


Max LANTAS announced
────────────────────

  Hello! I am announcing the first release of `jsonoo', a JSON library
  for Js_of_ocaml.

  <https://github.com/mnxn/jsonoo>
  <https://opam.ocaml.org/packages/jsonoo>

  This library provides a very similar API to the excellent BuckleScript
  library, [bs-json] by [glennsl]. Unlike bs-json, this port of the
  library tries to follow OCaml naming conventions and be easier to
  interface with other OCaml types like `Hashtbl.t' . This library
  passes a nearly equivalent test suite.

  This project is part of ongoing work to port [vscode-ocaml-platform]
  to Js_of_ocaml.

  Generated documentation can be found [here].


[bs-json] <https://github.com/glennsl/bs-json>

[glennsl] <https://github.com/glennsl>

[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>

[here] <https://mnxn.github.io/jsonoo/jsonoo/Jsonoo/index.html>


Interesting OCaml Articles
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/62>


Ryan Slade announced
────────────────────

  <https://blog.darklang.com/fizzboom-benchmark/>


Rehabilitating Packs using Functors and Recursivity
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/rehabilitating-packs-using-functors-and-recursivity/6497/1>


OCamlPro announced
──────────────────

  Our new blogpost is about the redemption of packs in the OCaml
  ecosystem. This first part shows our work to generate functor units
  and functor packs : [Rehabilitating Packs using Functors and
  Recursivity, part 1.]

        Packs in the OCaml ecosystem are kind of an outdated
        concept (options `-pack' and `-for-pack' the OCaml manual,
        and their main utility has been overtaken by the
        introduction of module aliases in OCaml 4.02. What if we
        tried to redeem them and give them a new youth and utility
        by adding the possibility to generate functors or
        recursive packs?

        This blog post covers the functor units and functor packs,
        while the next one will be centered around recursive
        packs. Both RFCs are currently developed by JaneStreet and
        OCamlPro. This idea was initially introduced by functor
        packs (Fabrice Le Fessant) and later generalized by
        functorized namespaces (Pierrick Couderc /et al/.).


[Rehabilitating Packs using Functors and Recursivity, part 1.]
<https://www.ocamlpro.com/2020/09/24/rehabilitating-packs-using-functors-and-recursivity-part-1/>


the OCaml Software Foundation
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-the-ocaml-software-foundation/4476/19>


gasche announced
────────────────

  We were all very busy during the last semester, and have been mostly
  quiet on the foundation activities, but of course our actions were
  running in the background. Some highlights:

  • Kate @kit-ty-kate Deplaix has worked on opam-repository QA for the
    OCaml 4.11 release, and the work and results are just as superb as
    for 4.10. We will fund Kate to work again on the upcoming 4.12
    release.

  • We are funding ongoing maintenance work on [ocaml-rs] (a port of the
    OCaml FFI library from C to Rust) by its author and maintainer, Zach
    @zshipko Shipko. Zach did a big round of cleanup changes this
    summer, improving the overall design of the library and completing
    its feature set.

  • We are funding @JohnWhitington (the author of [OCaml from the Very
    Beginning]) to do some technical writing work for OCaml
    documentation. His contributions so far have been very diverse, from
    a script to harmonize the documentation of List and ListLabels (and
    Array and ArrayLabels, etc.) in the standard library, to small
    cleanups and improvement to ocaml.org web pages. One focus of his
    work is the upcoming documentation page "Up and running with OCaml",
    taking complete newcomers through the basic setup, using the
    toplevel and building and running a Hello World. ([ocaml.org#1165],
    [rendered current state])

  • Two [Outreachy] internships were supervised this summer, focusing on
    the compiler codebase. Florian @Octachron Angeletti (INRIA)
    supervised an intern on adding a JSON format for some compiler
    messages (we expect PRs to be submitted soon). Vincent @vlaviron
    Laviron and Guillaume @zozozo Bury (OCamlPro) supervised an intern
    on reducing mutable state in the internal implementation.

  • Inspired by [this Discuss thread], we are funding experimental work
    by @sanette on the HTML rendering of the OCaml manual. This work is
    in the process of being reviewed for upstreaming in the OCaml
    compiler distribution. ([#9755].) This is a better end-result than I
    had initially expected.

  (We also had a couple non-highlights. For example, we funded a sprint
  (physical development meeting) for the [Owl] contributors, with
  Marcello @mseri Seri doing all the organization work; it was planned
  for the end of March, and had to be postponed due to the pandemic.)


[ocaml-rs] <https://github.com/zshipko/ocaml-rs/>

[OCaml from the Very Beginning] <http://ocaml-book.com/>

[ocaml.org#1165] <https://github.com/ocaml/ocaml.org/pull/1165>

[rendered current state]
<https://github.com/johnwhitington/ocaml.org/blob/up-and-running/site/learn/tutorials/up_and_running.md>

[Outreachy] <https://outreachy.org>

[this Discuss thread]
<https://discuss.ocaml.org/t/suggestions-for-ocaml-documentation/4504>

[#9755] <https://github.com/ocaml/ocaml/pull/9755>

[Owl] <https://github.com/owlbarn>


dual 0.1.0
══════════

  Archive: <https://discuss.ocaml.org/t/ann-dual-0-1-0/6512/1>


Jason Nielsen announced
───────────────────────

  I’ve released [dual] which is now up on opam.  It is a dual numbers
  library which includes a one dimensional root finder (via Newton's
  method).


[dual] <https://github.com/drjdn/ocaml_dual>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-22  7:27 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-09-22  7:27 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of September 15 to
22, 2020.

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

Liquidsoap 1.4.3
Simple63 v1: compression of integer sequences
bentov v1: streaming estimation of 1D histograms
opam-compiler 0.1.0
lua_parser 1.0.0
Merlin 3.4.0 : introducing external configuration readers
gRPC server and client in OCaml
Bitstring (and ppx_bitstring) 4.0.0
Old CWN


Liquidsoap 1.4.3
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-liquidsoap-1-4-3/6429/1>


Romain Beauxis announced
────────────────────────

  I'm happy to announce that liquidsoap `1.4.3' is out at:
  <https://github.com/savonet/liquidsoap/releases/tag/v1.4.3>

  This is the 3rd bugfix release for the `1.4.x' branch. It contains
  important fixes and a couple of new minor features. Update is
  recommended and should be fairly safe.

  Along we this release, we have now added builds for `arm64' debian
  packages and docker-ready production images for `amd64' and `arm64'
  architectures available at:
  <https://hub.docker.com/repository/docker/savonet/liquidsoap>

  Again, we would like to warmly thank all users, contributors and
  reporters for helping us bring liquidsoap to the next step!

  Also, please note that a couple of issues had to be left out to make
  sure that the release comes out on time. These are listed [here] and
  will be tackled as soon as possible.

  Next for liquidsoap, we will focus on getting the current `2.x' branch
  finalized and polished. We already have support for encoded content
  and ffmpeg raw frames. We need to write a couple of inline encoders
  and decoders and we'll have 90% of the features ready. This will be a
  major update for us!


[here] <https://github.com/savonet/liquidsoap/milestone/7>


Simple63 v1: compression of integer sequences
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-simple63-v1-compression-of-integer-sequences/6431/1>


Mika Illouz announced
─────────────────────

  This is to announce Simple63, an opam package for compression of
  integer sequences; similar to Anh and Moffat's Simple-8b. More details
  found in:

  • github: [https://github.com/barko/simple63]
  • documentation: [https://barko.github.io/simple63/]

  Feedback and bug reports welcome.


[https://github.com/barko/simple63] <https://github.com/barko/simple63>

[https://barko.github.io/simple63/] <https://barko.github.io/simple63/>


bentov v1: streaming estimation of 1D histograms
════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-bentov-v1-streaming-estimation-of-1d-histograms/6434/1>


Mika Illouz announced
─────────────────────

  This is to announce bentov, a opam package that implements a 1D
  histogram-sketching algorithm. For more details:

  • github: [https://github.com/barko/bentov]
  • documentation: [https://barko.github.io/bentov]

  Feedback and bug reports welcome.


[https://github.com/barko/bentov] <https://github.com/barko/bentov>

[https://barko.github.io/bentov] <https://barko.github.io/bentov>


opam-compiler 0.1.0
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-opam-compiler-0-1-0/6442/1>


Etienne Millon announced
────────────────────────

  On behalf of the opam maintainers, I'd like to announce the first
  release of opam-compiler, a plugin to work with compiler variants,
  branches and forks.

  This can cover a pretty wide range of use cases, so the first version
  is starting small with a single command to create a switch from a
  branch or github PR:

  ┌────
  │ % opam compiler create '#9921'
  │ Opam plugin "compiler" is not installed. Install it on the current switch? [Y/n] y
  │ 
  │ ...
  │ 
  │ <><> Carrying on to "opam compiler create #9921" ><><><><><><><><><><><><><><><>
  │ 
  │ [ocaml-variants.4.12.0+trunk+no-flat-float-array] synchronised from
  │ git+https://github.com/gasche/ocaml#Atomic.create
  │ ocaml-variants is now pinned to git+https://github.com/gasche/ocaml#Atomic.create (version
  │ 4.12.0+trunk)
  │ % opam switch
  │ ...
  │ →  ocaml-ocaml-9921
  │           [opam-compiler] ocaml/ocaml#9921 - stdlib: rename Atomic.make into Atomic.create
  └────

  You can also override the arguments passed to `--configure'.

  As you can see in the above snippet, it's an opam plugin so it will
  auto-install if needed (assuming you ran `opam update' recently) and
  will be available across all switches. Its sources and issue tracker
  are available [here].

  For the next releases, our plan is to add a user-friendly way to setup
  a switch based on a local git clone, so that it's easy to test your
  compiler fork with opam packages. You can find the other features we'd
  like to add in the future in [the relevant part of the opam roadmap].

  Thanks and have fun compiling compilers!


[here] <https://github.com/ocaml-opam/opam-compiler>

[the relevant part of the opam roadmap]
<https://github.com/ocaml/opam/wiki/Spec-for-working-with-the-OCaml-compiler>


lua_parser 1.0.0
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-lua-parser-1-0-0/6445/1>


Jason Nielsen announced
───────────────────────

  I've release [lua_parser] which is now up on opam.  It is a parser and
  pretty-printer for lua 5.2.  Actually it was developed with luajit in
  mind which is lua 5.1 plus goto/labels (which syntactically for the
  purposes of parsing and pretty-printing is lua 5.2).


[lua_parser] <https://github.com/drjdn/ocaml_lua_parser>


Merlin 3.4.0 : introducing external configuration readers
═════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-merlin-3-4-0-introducing-external-configuration-readers/6446/1>


vds announced
─────────────

  I am glad to announce, on behalf of the Merlin team, the release of
  Merlin `3.4.0' which brings some major changes in the way
  configuration is handled.

  As you might know, Merlin reads its configuration from the closest
  `.merlin' file to the source file being edited. These files tell
  merlin where to find other source files and build artifacts, but also
  which flags should be passed to the compiler, which syntax extensions
  are enabled and which packages are used by the project.

  In this setting the configuration is the same for all the source files
  of a folder, regardless of their specificities. In other words, the
  configuration loaded for a single source file contains the union of
  the dependencies of this file and of all its siblings which is not an
  optimal behavior.

  Starting with version `3.4.0' merlin will ship with two packages:
  `merlin' and `dot-merlin-reader' which, as the name suggests, reads
  configuration from `.merlin' files. Both are necessary for proper
  function.

  When a `.merlin' file is present in the source folder the Merlin
  server will start a `dot-merlin-reader' process and communicate with
  it via standard input and output following a simple protocol. These
  processes are halted with the server.

  *This change should not have any visible impact on users' workflows as
  long as the `dot-merlin-reader' binary is correctly installed and in
  the path*. (which should be the case in opam-based setups)

  This change in itself will not solve the granularity problem mentioned
  earlier, but it paves the way for such improvements: in a near-future
  Dune will stop generating `.merlin' files and Merlin will obtain
  file-based configuration directly from the build system using the same
  protocol as the one used by `dot-merlin-reader'.


Changelog
╌╌╌╌╌╌╌╌╌

  ⁃ merlin binary
    • fix completion of pattern matchings with exception patterns
      (#1169)
    • delegate configuration reading to external programs via a simple
      protocol and create a new package `dot-merlin-reader' with a
      binary that reads `.merlin' files. (#1123, #1152)


gRPC server and client in OCaml
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/grpc-server-and-client-in-ocaml/6465/1>


blandinw announced
──────────────────

  TL;DR <https://github.com/blandinw/ocaml-grpc-envoy/>

  Hey, I'm new to OCaml after writing some Clojure, C++ and Haskell in
  various contexts, including working at FB (relevant below).

  After browsing this forum and Reddit for a bit, the assumption seems
  to be that OCaml is not a good fit for gRPC, since there's no pure
  implementation today. Now, this is something I have experience with,
  so I thought I'd try and challenge this assumption.

  As you may know, services inside FB use Thrift (both the format and
  protocol) to communicate. The Thrift team worked primarily in C++ (for
  good reasons), causing support for other languages to lag behind
  despite their best efforts. Now, the interchange format (equivalent to
  Protobuf) does not change very often so it's fine to have a
  per-language implementation, but the client and server (equivalent to
  HTTP2 + gRPC) frequently receive new features, optimizations and
  fixes. After a valiant and continued effort to support most languages
  used internally, the Thrift team came up with an idea. Instead of
  maintaining multiple implementations and dealing with obscure FFI
  bugs, ~FingerprintTrustManagerFactory~s and whatnot, they would focus
  solely on the C++ implementation and provide a daemon to be ran
  alongside whatever code you were trying to run. You could then use
  simple IPC to exchange Thrift (the format) messages with that daemon,
  and it would handle all the nitty-gritty of running a service at scale
  (load balancing, connection pooling, service discovery, security,
  retries, timeouts, network stats, hot restarts, etc.). Needless to
  say, it worked remarkably well even at very high scale and everybody
  was much happier.

  I wanted to replicate this idea with OCaml and gRPC. We already have
  support for protobuf thanks to the excellent `ocaml-protoc'. All we
  need is a way to exchange protobuf messages reliably on the wire.
  Instead of having an OCaml implementation that will have to stay
  up-to-date and have its own set of bugs (the official `grpc/grpc-java'
  repo has 4450 commits and 2400 issues at the moment), can we reuse
  existing infra with already massive support and production time?

  Fortunately, the people at Lyft built just that, open-sourced it and
  contributed it to the Cloud Native Computing Foundation in late
  2017. It is called Envoy and it is bliss.

  I demonstrate how to fit these pieces together at
  [blandinw/ocaml-grpc-envoy] to build a simple KV store, including a
  gRPC client and server in 200 lines of OCaml code. The idea is to
  spawn an Envoy process that will handle all gRPC communication for our
  OCaml code. We use HTTP/1.1 to exchange Protobuf messages with it,
  using for example `httpaf' and `Lwt'. This solution has the added
  benefit that it is highly scalable from the start, allowing you for
  instance to spawn one OCaml process per core and load balance between
  them. You can also use Envoy (with proper config!) as your web reverse
  proxy instead of say, nginx.

  At the very least, this solution allows us to start writing gRPC code
  today, and gracefully evolve towards HTTP/2, Multicore and maybe a
  native OCaml implementation later.

  I'm curious to hear your perspective on the future of building
  services with OCaml, or your past experience like what went well, what
  was missing, etc.


[blandinw/ocaml-grpc-envoy]
<https://github.com/blandinw/ocaml-grpc-envoy/>


Yawar Amin asked and blandinw replied
─────────────────────────────────────

        Fantastic idea. So if I understand correctly, the only
        thing that Envoy (server-side) is doing is translating the
        Protobuf from gRPC HTTP2 transport to HTTP1, and
        forwarding these Protobuf objects over HTTP1 to the OCaml
        server? Envoy doesn't know to know about the actual gRPC
        schema, because it doesn't touch the Protobuf objects
        themselves, right?

  That's correct. Envoy is only concerned with transporting bytes (along
  with load balancing, routing, etc, etc). Only OCaml knows about the
  Protobuf schemas.

  In the OCaml server case, Envoy listens for HTTP/2 gRPC requests,
  accesses the bytes payload with no knowledge of the actual
  schema/layout and repackages these same bytes in a HTTP/1.1 request
  that OCaml can process. OCaml then responds with bytes (an encoded
  Protobuf response message) that Envoy sends back on the original HTTP2
  connection.


Bitstring (and ppx_bitstring) 4.0.0
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-bitstring-and-ppx-bitstring-4-0-0/6471/1>


xrguerin announced
──────────────────

Features
╌╌╌╌╌╌╌╌

  • Add support for let bindings introduced in 4.08
  • Switch to PPXLIB


Deprecations
╌╌╌╌╌╌╌╌╌╌╌╌

  As PPXLIB requires `ocaml >= 4.04' support for earlier versions has
  been dropped.


Breaking changes
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This release splits the library from the PPX to reduce runtime
  dependencies. Projects using the PPX from bitstring will need to also
  depends on ppx_bitstring from now on.


Rudi Grinberg added
───────────────────

  The project is hosted [here] for those who are interested.There's also
  some excellent [docs]


[here] <https://github.com/xguerin/bitstring>

[docs] <https://bitstring.software/documentation/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-08 13:11 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-09-08 13:11 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of September 01 to
08, 2020.

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

OCaml 4.11.1: early bugfix release
textmate-language 0.1.0
Batteries v3.1.0
Job offer in Paris - Be Sport
Some SIMD in your OCaml
A PPX Rewriter approach to ocaml-migrate-parsetree
telltime - when is when exactly?
Ocamlunit emacs minor-mode
Sihl 0.1.0
promise_jsoo 0.1.0
Other OCaml News
Old CWN


OCaml 4.11.1: early bugfix release
══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-4-11-1-early-bugfix-release/6337/1>


octachron announced
───────────────────

  A serious bug has been discovered last week in OCaml 4.11.0: explicit
  polymorphic annotations are checked too permissively.  Some incorrect
  programs (possibly segfaulting) are accepted by the compiler in
  4.11.0.

  Programs accepted by OCaml 4.10 are unchanged.

  We are thus releasing OCaml 4.11.1 as an early bugfix version.  You
  are advised to upgrade to this new version if you were using OCaml
  4.11.0.

  It is (or soon will be) available as a set of OPAM switches with
  ┌────
  │ opam switch create 4.11.1
  └────

  and as a source download here:
    <https://caml.inria.fr/pub/distrib/ocaml-4.11/>

  This bug was introduced when making polymorphic recursion easier to
  use. We are working on making the typechecker more robust and more
  exhaustively tested to avoid such issues in the future.


Bug fixes:
╌╌╌╌╌╌╌╌╌╌

  • [#9856], [#9857]: Prevent polymorphic type annotations from
    generalizing weak polymorphic variables. (Leo White, report by
    Thierry Martinez, review by Jacques Garrigue)

  • [#9859], [#9862]: Remove an erroneous assertion when inferred
    function types appear in the right hand side of an explicit :>
    coercion (Florian Angeletti, report by Jerry James, review by Thomas
    Refis)


[#9856] <https://github.com/ocaml/ocaml/issues/9856>

[#9857] <https://github.com/ocaml/ocaml/issues/9857>

[#9859] <https://github.com/ocaml/ocaml/issues/9859>

[#9862] <https://github.com/ocaml/ocaml/issues/9862>


Rwmjones then said
──────────────────

  We've now got 4.11.1 in Fedora 33 & Fedora 34.  No apparent problems
  so far.


textmate-language 0.1.0
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-textmate-language-0-1-0/6339/1>


dosaylazy announced
───────────────────

  I am pleased to announce [textmate-language 0.1.0]. Textmate-language
  is a library for tokenizing code using TextMate grammars. Therefore,
  it may be useful for implementing syntax highlighters. Please report
  any bugs or API inconveniences you find.


[textmate-language 0.1.0]
<https://opam.ocaml.org/packages/textmate-language/textmate-language.0.1.0/>


Batteries v3.1.0
════════════════

  Archive: <https://discuss.ocaml.org/t/batteries-v3-1-0/6347/1>


UnixJunkie announced
────────────────────

  OCaml Batteries Included is a community-maintained extended standard
  library for OCaml.

  The latest API can be found here:
  <https://ocaml-batteries-team.github.io/batteries-included/hdoc2/>

  This minor release adds support for OCaml 4.11.  It has been available
  in opam for some days.

  Special thanks to all the contributors!

  The changelog follows:

  • Compatibility fixes for OCaml-4.11 [#962] (Jerome Vouillon)
  • BatEnum: added combination [#518] (Chimrod, review by hcarty)
  • fix benchmarks [#956] (Cedric Cellier)
  • BatFile: added count_lines [#953] (Francois Berenger, review by
    Cedric Cellier)
  • BatArray: use unsafe_get and unsafe_set more often [#947] (Francois
    Berenger, review by Cedric Cellier)
  • fix some tests for ocaml-4.10.0 [#944] (kit-ty-kate)
  • BatResult: BatPervasives.result is now equal to Stdlib.result
    instead of sharing constructors without being the same type [#939],
    [#957] (Clément Busschaert, Cedric Cellier).


[#962]
<https://github.com/ocaml-batteries-team/batteries-included/pull/962>

[#518]
<https://github.com/ocaml-batteries-team/batteries-included/pull/518>

[#956]
<https://github.com/ocaml-batteries-team/batteries-included/pull/956>

[#953]
<https://github.com/ocaml-batteries-team/batteries-included/pull/953>

[#947]
<https://github.com/ocaml-batteries-team/batteries-included/pull/947>

[#944]
<https://github.com/ocaml-batteries-team/batteries-included/pull/944>

[#939]
<https://github.com/ocaml-batteries-team/batteries-included/pull/939>

[#957]
<https://github.com/ocaml-batteries-team/batteries-included/pull/957>


Job offer in Paris - Be Sport
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/job-offer-in-paris-be-sport/6355/1>


Vincent Balat announced
───────────────────────

  Be Sport is looking to hire an OCaml developer with skills in

  • Mobile/web feature design
  • Team management
  • Use of Social networks

  She/he will take part in the development of our Web and mobile apps,
  entirely written in OCaml with Ocsigen, and participate in reflections
  on features.

  Please contact me for more information or send an email to
  jobs@besport.com.


Some SIMD in your OCaml
═══════════════════════

  Archive: <https://discuss.ocaml.org/t/some-simd-in-your-ocaml/6367/1>


Anmol Sahoo announced
─────────────────────

  Fresh from a weekend of hacking, I would like to share some results of
  an experiment I conducted of creating a library for exposing Intel
  AVX2 intrinsics to OCaml code. AVX2 is an instruction set subset that
  adds data-parallel operations in hardware.

  I chose to fork the amazing [bigstringaf] library and modified it. You
  can find the additions to the code here - [bigstringaf_simd].


[bigstringaf] <https://github.com/inhabitedtype/bigstringaf>

[bigstringaf_simd]
<https://github.com/anmolsahoo25/bigstringaf/blob/8df94c4fb5607317ee9634611784eea65368a270/lib/bigstringaf_simd.mli#L287>

Overview
╌╌╌╌╌╌╌╌

  Given a type `Bigstring.t' (1 dimensional byte arrays) there now exist
  functions such as -
  ┌────
  │ val cmpeq_i8 : (t * int) -> (t * int) -> (t * int) -> unit
  └────
  So `cmpeq_i8 (x,o1) (y,o2) (z,03)' will compare 32 bytes starting at
  `o1' and `o2' from `x' and `y' respectively and store the result in
  `z' at `o3'.


Why?
╌╌╌╌

  This was mainly an exercise in curiosity. I just wanted to learn
  whether something like this is viable.  I also want to see if adding
  some type-directed magic + ppx spells can let us write data parallel
  code much more naturally similar to what `lwt / async' did for async
  code.

  At the same time, you might ask - why not use something like Owl
  (which already has good support for data-parallel operations)? Apart
  from the fact that such libraries are oriented towards numerical code,
  I would also like to explore if we can operate directly on OCaml types
  and cast them into data parallel algorithms. Like how `simdjson'
  pushed the boundaries of JSON parsing, it would be nice to port
  idiomatic code to data-parallel versions in OCaml. Can we, at some
  point, have generic traversals of data-types, which are actually
  carried out in a data-parallel fashion?


Does it work?
╌╌╌╌╌╌╌╌╌╌╌╌╌

  Given the limitation of the current implementation (due to foreign
  function calls into C), I still found some preliminary results to be
  interesting! Implementing the `String.index' function, which returns
  the first occurence of a char, the runtime for finding an element at
  the `n-1' position in an array with `320000000' elements is -
  ┌────
  │ serial: 1.12 seconds
  │ simd: 0.72 seconds (1.5x)
  └────
  I still have to do the analysis what the overhead of the function call
  into C is (even with `[@@noalloc]'!


Future directions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  It would be interesting to see, if we can create a representation
  which encapsulates the various SIMD ISA's such as AVX2, AVX512, NEON,
  SVE etc. Further more, it would be really interesting to see if we can
  use ppx to automatically widen `map` functions to operate on blocks of
  code, or automatically cast data types in a data parallel
  representation.


Disclaimer
╌╌╌╌╌╌╌╌╌╌

  This was mostly a hobby project, so I cannot promise completing any
  milestones or taking feature requests etc. I definitely do not
  recommend using this in production, because of the lack of testing
  etc.


A PPX Rewriter approach to ocaml-migrate-parsetree
══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/a-ppx-rewriter-approach-to-ocaml-migrate-parsetree/6369/1>


Chet Murthy announced
─────────────────────

TL;DR
╌╌╌╌╌

  Based on `camlp5' and the `pa_ppx' PPX rewriters, I've written a new
  one, `pa_deriving_plugins.rewrite', that automates almost all the work
  of writing a migration from one version of OCaml's AST to another.
  1. It took a few days (b/c of laziness) to write the initial PPX
     rewriter
  2. A day to get 4.02->4.03 AST migration working
  3. a couple of hours to get 4.03->4.02 working
  4. and a few more hours to get 4.03<->4.04 and 4.04<->4.05 working

  At this point, I fully expect that the other version-pairs will not be
  difficult.

  You can find this code [warning: very much a work-in-progress] at
  <https://github.com/chetmurthy/pa_ppx/tree/migrate-parsetree-hacking>

  The file `pa_deriving.plugins/pa_deriving_rewrite.ml' contains the
  source for the PPX rewriter.

  The directory `pa_omp' contains the migrations, typically named
  `rewrite_NNN_MMM.ml'.


A slightly longer-winded explanation
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  If you think about it, `ppx_deriving.map' isn't so different from what
  we need for `ocaml-migrate-parsetree'.  `ppx_deriving.map', from a
  type definition for ~ 'a t~, will automatically generate a function
  ┌────
  │ map_t : ('a -> 'b) -> 'a t -> 'b t
  └────
  If you think about it, if we could just substitute our own type for
  the second occurrence of `t' (somehow …. yeah *grin*) then it would be
  almost like what we want for o-m-p, yes?

  With 11 versions of the Ocaml AST so far, maybe it's worth thinking
  about how to automate more of the migration task.  Also, since so much
  of it is type-structure-driven, one would think that it would be an
  excellent opportunity to apply PPX rewriting technology.  *Indeed, one
  might think that a good test of PPX rewriting, is the ability to
  automate precisely such tasks.*

  So what's hard about this migration task?  Here are some issues (maybe
  there are more):
  1. the types are slightly differently-organized in different versions
     of the AST.  Types might move from one module to another.
  2. sometimes new types are introduced and old ones disappear
  3. constructor data-types may get new branches, or lose them
  4. record-types may get new fields, or lose them
  5. sometimes the analogous types in two consecutive versions are just
     really, really different [but this is rare]: we need to supply the
     code directly
  6. when mapping from one version to another, sometimes features are
     simply not mappable, and an error needs to be raised; that error
     ought to contain an indication of where in the source that
     offending feature was found
  7. And finally, when all else fails, we might need to hack on the
     migration code directly

  But morally, the task is really straightforward (with problems listed
  in-line):

  1. use `ppx_import' to copy over types from each of the AST times of
     each Ocaml version
     • `ppx_import' works on `.cmi' files, and those have different
       formats in different versions of Ocaml.  Wouldn't it be nice if
       it worked on `.mli' files, whose syntax (b/c OCaml is
       well-managed) doesn't change much?
  2. build a single OCaml module that has all the AST types in it (from
     all the versions of OCaml)
     • but without the form
       ┌────
       │ type t = M.t = A of .. | B of ....
       └────
       that is, without the "type equation" that allows for a new
       type-definition to precisely repeat a previous one.
  3. Then use `ppx_import' against this single module to construct a
     recursive type-declaration list of all the AST types for a
     particular version of OCaml, and apply a "souped-up" version of
     ppx_deriving.map to it, to map the types to *another* version of
     the AST types.
     • but `ppx_deriving.map' doesn't do this today, and besides, it
       would have to provide a bunch of "escape hatches" for all the
       special-cases I mentioned above.

  But this is in principle doable, and it has the nice feature that all
  the tedious boilerplate is mechanically-generated from
  type-definitions, hence likely to not contain errors (assuming the PPX
  rewriter isn't buggy).

  So I decided to do it, and this little post is a result.


Discussion
╌╌╌╌╌╌╌╌╌╌

  I think this is a quite viable approach to writing
  `ocaml-migrate-parsetree', and I would encourage the PPX community to
  consider it.  One of the nice things about this approach, is that it
  relies *heavily* on PPX rewriting itself, to get the job done.  I
  think one of the important things we've learned in programming
  languages research, is that our tools need to be largely sufficient to
  allow us to comfortably implement those same tools.  It's a good test
  of the PPX infrastructure, to see if you can take tedious tasks and
  automate them away.

  I'm not going to describe anymore of how this works, b/c I'd rather
  get the rest of the migrations working, start figuring out how to
  test, and get this code integrated with camlp5.

  But for anybody who's interested, I'd be happy to interactively
  describe the code and walk them thru how it works.


Louis Roché then asked
──────────────────────

  For a person who hasn't digged into OMP, can you explain how it is
  different from what is done currently? Because the idea I had of OMP
  is basically what you describe, a set of functions transformation an
  AST from vX to vX-1 and vX+1. So I am obviously missing something.


Chet Murthy replied
───────────────────

  Yes, you're right: imagine a series of modules M2…M11.  Each declares
  the same set of types, but with different definitions, yes?  Then
  you'd have migration modules, `migrate_i_j' (j=i+1 or j=i-1) that have
  functions that convert between the analogously-named types.  The
  entire question is: how are these functions implemented?  By hand?
  With significant mechanized support?  They can't be implemented
  fully-mechanically, because there are decisions to be made about how
  to bridge differences in type-definitions.  For instance, look at the
  4.02 type `label' and the 4.03 type `arg_label'.  Sometimes these are
  analogous (and sometimes they're not).  When they're analogous, the
  code that converts between -cannot- be automatically inferred: a human
  has to write it.  But -most- of the code of these migration functions
  can be inferred automatically from the type-definitions themselves.

  And that's really all that my little experiment does: automatically
  infer the migration code (most of the time) with some hints for those
  cases where it's not possible to automatically infer.

  Now, why would one do this?  Well, two reasons:

  1. it should be more maintainable to automatically generate most of
     the code from types, and it should be quicker to bring online a
     migration for a new version of the Ocaml AST.
  2. this should be a good test of PPX rewriting.  That is, if we're
     going to build a macro-preprocessing support system, shouldn't it
     be able to make solving such straightforward, but very tedious,
     problems much, much easier?


Chet Murthy then added
──────────────────────

  I forgot to add a third reason why this PPX-rewriter-based approach is
  better:

  1. If you look at ocaml-migrate-parsetree "migrations", you'll find
     that they're almost all boilerplate code.  But sprinkled
     here-and-there, is actual logic, actual decisions about how to come
     up with values for new fields, about which fields, when non-trivial
     (e.g. not "[]") should lead to migration-failure, etc.  It is this
     code, that is the actual meat of the migration, and it's not at all
     obvious, when sprinkled thru the mass of mechanically-produclble
     boilerplate.

  A mechanized production of that boilerplate would mean that we
  retained explicitly only this nontrivial code, and hence for
  maintenance we could focus on it, and make sure it does the right
  thing.


Josh Berdine asked
──────────────────

  Figuring out ways to make maintaining this stuff more efficient would
  be great! One aspect that isn't clear to me is how this approach
  compares to the process currently used to generate the omp code. I
  haven't done it myself, but at first glance the tools to generate the
  omp code (e.g. gencopy) seem to also accurately be describable as
  heavily using ppx infrastructure in order to implement the map code
  from one version to another. Is there an executive summary that
  compares and contrasts that and this proposal?


Chet Murthy replied
───────────────────

  From the README, gencopy is used to generate a prototype file for each
  migration, and then a human goes in and fixes up the code.  A way to
  put my point is: gencopy should be provided the fixups in some compact
  form, and apply them itself.


telltime - when is when exactly?
════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-telltime-when-is-when-exactly/6372/1>


Darren announced
────────────────

  I'm happy to announce release of [telltime] 0.0.1, a small cli tool
  for interacting with Daypack-lib (a schedule, time, time slots
  handling library) components.

  It primarily answers time related queries, with support for union
  (`||'), intersect (`&&') and "ordered select" (`>>', explanation of
  this is at the bottom).

  The query language, time expression, aims to mimic natural language,
  but without ambiguity. The grammar is only documented in the online
  demo [here] at the moment.

  Some examples copied from the README are as follows.


[telltime] <https://github.com/daypack-dev/telltime>

[here] <https://daypack-dev.github.io/time-expr-demo/>

Search for time slots matching Daypack time expression
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  "Hm, I wonder what years have Febuary 29th?"

  ┌────
  │ $ telltime search --time-slots 5 --years 100 "feb 29 00:00"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 03 19:24:15
  │ 
  │ Matching time slots (in above time zone):
  │ [2024 Feb 29 00:00:00, 2024 Feb 29 00:00:01)
  │ [2028 Feb 29 00:00:00, 2028 Feb 29 00:00:01)
  │ [2032 Feb 29 00:00:00, 2032 Feb 29 00:00:01)
  │ [2036 Feb 29 00:00:00, 2036 Feb 29 00:00:01)
  │ [2040 Feb 29 00:00:00, 2040 Feb 29 00:00:01)
  └────

  "Would be handy to know what this cron expression refers to"
  ┌────
  │ $ telltime search --time-slots 5 "0 4 8-14 * *"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 06 17:39:56
  │ 
  │ Matching time slots (in above time zone):
  │ [2020 Sep 08 04:00:00, 2020 Sep 08 04:01:00)
  │ [2020 Sep 09 04:00:00, 2020 Sep 09 04:01:00)
  │ [2020 Sep 10 04:00:00, 2020 Sep 10 04:01:00)
  │ [2020 Sep 11 04:00:00, 2020 Sep 11 04:01:00)
  │ [2020 Sep 12 04:00:00, 2020 Sep 12 04:01:00)
  └────

  "I have a bunch of time ranges, but some of them overlap, and they are
  not in the right order. If only there is a way to combine and sort
  them easily."

  ┌────
  │ $ telltime search --time-slots 1000 "2020 . jan . 1, 10, 20 . 13:00 to 14:00 \
  │   || 2019 dec 25 13:00 \
  │   || 2019 dec 25 10am to 17:00 \
  │   || 2020 jan 5 10am to 1:30pm \
  │   || 2020 . jan . 7 to 12 . 9:15am to 2:45pm"
  │ Searching in time zone offset (seconds)            : 36000
  │ Search by default starts from (in above time zone) : 2020 Sep 06 18:01:12
  │ 
  │ Matching time slots (in above time zone):
  │ [2019 Dec 25 10:00:00, 2019 Dec 25 17:00:00)
  │ [2020 Jan 01 13:00:00, 2020 Jan 01 14:00:00)
  │ [2020 Jan 05 10:00:00, 2020 Jan 05 13:30:00)
  │ [2020 Jan 07 09:15:00, 2020 Jan 07 14:45:00)
  │ [2020 Jan 08 09:15:00, 2020 Jan 08 14:45:00)
  │ [2020 Jan 09 09:15:00, 2020 Jan 09 14:45:00)
  │ [2020 Jan 10 09:15:00, 2020 Jan 10 14:45:00)
  │ [2020 Jan 11 09:15:00, 2020 Jan 11 14:45:00)
  │ [2020 Jan 12 09:15:00, 2020 Jan 12 14:45:00)
  │ [2020 Jan 20 13:00:00, 2020 Jan 20 14:00:00)
  └────


Get exact time after some duration from now
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  ┌────
  │ $ telltime from-now "1 hour"
  │ Now                   : 2020-09-03 15:53:29
  │ Duration (original)   : 1 hour
  │ Duration (normalized) : 1 hours 0 mins 0 secs
  │ Now + duration        : 2020-09-03 16:53:29
  └────

  ┌────
  │ $ telltime from-now "1.5 days 2.7 hours 0.5 minutes"
  │ Now                   : 2020-09-03 15:55:43
  │ Duration (original)   : 1.5 days 2.7 hours 0.5 minutes
  │ Duration (normalized) : 1 days 14 hours 42 mins 30 secs
  │ Now + duration        : 2020-09-05 06:38:13
  └────


Difference between ordered select and union
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  `s1 >> s2' is similar to `s1 || s2', but `>>' picks between s1 and s2
  in a round robin fashion, instead of just picking the smallest between
  two.

  One specific differing case would be when the search starts at 4pm
  today, `3pm || 5pm' would return 5pm today and 3pm tomorrow, and so
  on, while `3pm >> 5pm' would return 3pm tomorrow and 5pm tomorrow (a
  5pm is only picked after a 3pm has been picked already).


Ocamlunit emacs minor-mode
══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocamlunit-emacs-minor-mode/6373/1>


Manfred Bergmann announced
──────────────────────────

  Here is a first version of this plugin that allows running `dune test'
  with an Emacs key stroke.  It shows the test result in a separate
  buffer and a simple colorized status 'message'.

  <https://github.com/mdbergmann/emacs-ocamlunit>

  While it is possible to run `dune' in 'watch' mode I'd like to
  manually run tests.

  I didn't find a way to specify individual test modules in `dune'. Is
  that possible?


Sihl 0.1.0
══════════

  Archive: <https://discuss.ocaml.org/t/ann-sihl-0-1-0/6374/1>


jerben announced
────────────────

  I am happy to announce this milestone release of Sihl, a web framework
  for OCaml.

  Github: <https://github.com/oxidizing/sihl>
  opam: <http://opam.ocaml.org/packages/sihl/>

  Sihl is really just a collection of services that can be plugged into
  each other and a tiny core that knows how to start them. The goal is
  to take care of infrastructure concerns so you can focus on the
  domain.

  After many iterations, the API is in a shape where we dare to show it
  to you :slight_smile: It is still under heavy development so expect
  breakage without a major version bump. However, we just finished
  migrating a project from Reason on NodeJS to OCaml on Sihl, so we use
  it in production.

  We provide service implementations that were useful to us so far. In
  the future we want to provide many more to cover all kinds of
  needs. (PRs are always welcome!)

  Any feedback is greatly appreciated, thanks! :)


jerben then added
─────────────────

  Here is an example of a tiny Sihl app:

  ┌────
  │ module Service = struct
  │   module Random = Sihl.Utils.Random.Service
  │   module Log = Sihl.Log.Service
  │   module Config = Sihl.Config.Service
  │   module Db = Sihl.Data.Db.Service
  │   module MigrationRepo = Sihl.Data.Migration.Service.Repo.MariaDb
  │   module Cmd = Sihl.Cmd.Service
  │   module Migration = Sihl.Data.Migration.Service.Make (Cmd) (Db) (MigrationRepo)
  │   module WebServer = Sihl.Web.Server.Service.Make (Cmd)
  │   module Schedule = Sihl.Schedule.Service.Make (Log)
  │ end
  │ 
  │ let services : (module Sihl.Core.Container.SERVICE) list =
  │   [ (module Service.WebServer) ]
  │ 
  │ let hello_page =
  │   Sihl.Web.Route.get "/hello/" (fun _ ->
  │       Sihl.Web.Res.(html |> set_body "Hello!") |> Lwt.return)
  │ 
  │ let routes = [ ("/page", [ hello_page ], []) ]
  │ 
  │ module App = Sihl.App.Make (Service)
  │ 
  │ let _ = App.(empty |> with_services services |> with_routes routes |> run)
  └────


promise_jsoo 0.1.0
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-promise-jsoo-0-1-0/6377/1>


Max LANTAS announced
────────────────────

  Hello! I am announcing the first release of `promise_jsoo', a library
  for JS promises in Js_of_ocaml.

  <https://github.com/mnxn/promise_jsoo>
  <https://opam.ocaml.org/packages/promise_jsoo/>

  The library has bindings to the core `Promise' methods as well as
  helper functions that make it easier to deal with a `Promise' of an
  `option' or `result'. It is also possible to use this library with
  [gen_js_api] to make for an easier JavaScript binding experience

  Inspired by [aantron/promise], this library also uses indirection
  internally when handling nested promises in order to ensure that the
  bindings are type safe.

  This project is part of ongoing work to port [vscode-ocaml-platform]
  to Js_of_ocaml.

  Generated documentation can be found [here].


[gen_js_api] <https://github.com/LexiFi/gen_js_api>

[aantron/promise]
<https://github.com/aantron/promise#discussion-how-reason-promise-makes-promises-type-safe>

[vscode-ocaml-platform]
<https://github.com/ocamllabs/vscode-ocaml-platform>

[here]
<https://mnxn.github.io/promise_jsoo/promise_jsoo/Promise/index.html>


Other OCaml News
════════════════

>From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Announcing Signals and Threads, a new podcast from Jane Street]


[OCaml Planet] <http://ocaml.org/community/planet/>

[Announcing Signals and Threads, a new podcast from Jane Street]
<https://blog.janestreet.com/announcing-signals-and-threads-index/>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-09-01  7:55 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-09-01  7:55 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of August 25 to
September 01, 2020.

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

Writing bindings for Google Apps Script (GAS)
What the Jane Street interns have wrought
a small library for shell/AWK/Perl-like scripting
letters 0.2.0
raylib-ocaml 0.1.0
OCaml Workshop 2020 Online Conference is live now
Other OCaml News
Old CWN


Writing bindings for Google Apps Script (GAS)
═════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/writing-bindings-for-google-apps-script-gas/6293/1>


Danielo Rodríguez announced
───────────────────────────

  Thanks to the help of this community I successfully completed a crazy
  idea: To write some ocaml functions to use inside [Google Apps Script]
  for a small stupid spreadsheet that I had.

  The way it works now is by having a main index.js file that calls the
  Ocaml functions that are available under a global Lib
  namespace. Everything is bundled using parcel and the Idea was to use
  as few JS code as possible. Because it was easier than I expected I
  decided to go one step further and write some bindings for the GAS
  functions I was using and reduce the glue JS code even more.

  This are the bindings that I wrote so far. They work, but are not
  usable inside Ocaml yet.

  ┌────
  │ type spreadsheet
  │ type sheet
  │ type range
  │ external getActiveSpreadsheet : unit -> spreadsheet = "getActiveSpreadsheet" [@@bs.val][@@bs.scope
  │ "SpreadsheetApp"]
  │ external getSheets : spreadsheet -> sheet array = "getSheets" [@@bs.send]
  │ external getSheetByName : spreadsheet -> string -> sheet = "getSheetByName" [@@bs.send]
  │ external getDataRange : sheet -> range = "getDataRange"  [@@bs.send]
  │ external getValues : range -> 'a array array = "getValues"  [@@bs.send]
  └────

  My doubt are on the edges. When it is just obscure GAS stuff I have no
  doubt, abstract types and functions to interact with them. Is when a
  GAS function returns data where I have doubts. Usually they are just
  arrays of arrays of Numbers or Strings. In the example above, the last
  definition says that you will get an array of arrays of `'a', but that
  is not true because it will be an array of "stuff" (strings, numbers,
  floats).  How should I type it in a way that it's flexible but not
  cumbersome? For example, I don't think using a functor will help
  because you will need to create a functor for every possible return
  type, in my case if you have 3 sheets with 3 different shapes, you
  will need 3 functors.  An alternative that I have used was to provide
  some helper functions to convert from JS to Ocaml types and then
  unwrap the Ocaml types, like the example I'm doing with
  Number_or_string.  This is nothing serious and I will just add the
  bindings that I may need for now, but I want to hear what the
  community (and potential users) thinks.

  If anyone is interested in taking a look on the project, it is here:
  <https://github.com/danielo515/ElectronicProjectsSpreadsheet>


[Google Apps Script] <https://developers.google.com/apps-script>


Matthieu Dubuget said
─────────────────────

  Not answering directly to your question, sorry.

  But here is a binding I have been using for around 4 years:
  <https://dubuget.fr/gitea/matthieu/ocaml-google-app.git>.


Hongbo Zhang also replied
─────────────────────────

  For return type polymorphism, you can use GADT with bs.ignore, the
  rough idea:

  ┌────
  │ type 'a t =  Int : int t | String : string t
  │ external f : ('a t [@bs.ignore]) -> ... -> 'a = "xx"
  └────
  I read discuss.ocaml.org from time to time, but checks
  <https://forum.rescript-lang.org/> daily where you can get a quick
  answer


What the Jane Street interns have wrought
═════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/what-the-jane-street-interns-have-wrought/6294/1>


Yaron Minsky announced
──────────────────────

  I thought folks here might find this interesting:

  <https://blog.janestreet.com/what-the-interns-have-wrought-2020/>

  The post summarizes three of the intern projects that happened this
  summer at Jane Street. It might be interesting if you're looking for
  an internship (or know someone who is), or if you're interested in any
  of the underlying tech. For example, if there's significant interest
  in a library for writing OCaml, we'd be more likely to open-source it.


a small library for shell/AWK/Perl-like scripting
═════════════════════════════════════════════════

  Archive:
  <https://sympa.inria.fr/sympa/arc/caml-list/2020-08/msg00021.html>


Oleg announced
──────────────

  Some time ago Chet Murthy asked about writing shell-like scripts in
  OCaml. Prompted by it, I also want to report on my experience and
  announce a small library that made it pleasant to do
  shell/AWK/Perl-like scripting in OCaml.

  The library is available at
          <http://okmij.org/ftp/ML/myawk/0README.dr>
  and consists of two small ML files, myawk.ml and strings.ml. The
  latter collects general-purpose string operations, more convenient
  than those in Stdlib.String. The rest of that web directory contains
  half a dozen sample scripts with comments.

  Here is the first example: a typical AWK script, but written in OCaml:

  ┌────
  │ #!/bin/env -S ocaml
  │ 
  │ #load "myawk.cma"
  │ open Myawk open Strings
  │ let hash = string_of_int <|> Hashtbl.hash
  │ ;;
  │ (* Sanitize the files originally used by join1.ml and join2.ml
  │    The files are made of space-separated fields; the first field is the
  │    key. It is sensitive; but because it is a key it can't be replaced with
  │    meaningless garbage. We obfuscate it beyond recognition. The third field
  │    is obfuscated as well. The second and fourth can be left as they are,
  │    and the fifth, if present, is replaced with XXX
  │ 
  │    The script is a proper filter: reads from stdin, writes to stdout
  │  *)
  │ 
  │ for_each_line @@ map words @@ function (f1::f2::f3::f4::rest) ->
  │   print [hash f1; f2; hash f3; f4; if rest = [] then "" else "XXX"]
  │ ;;
  └────

  Here <|> is a function composition. I wish it were in Stdlib. The real
  example, used in real life, was performing a database join

  ┌────
  │ SELECT T2.* from Table1 as T1, Table2 as T2 where T1.f1 = T2.f1
  └────

  where Table1 and Table2 are text files with space-separated column
  values. Table1 is supposed to be fed to stdin:

  ┌────
  │ let () =
  │   for_each_line @@ map words @@
  │   map_option (function (x::_) -> Some x | _ -> None) @@
  │   (ignore <|> shell "grep %s table1.txt")
  └────

  It is a typical rough-and-dirty script. Alas, it was too rough: I was
  so excited that it typechecked and worked the first time, that I
  didn't look carefully at the output and overlooked what I was looking
  for (resulting in an unneeded hassle and apology). I should have
  queried exactly for what I wanted:
  ┌────
  │ SELECT T1.f1, T1.f4 FROM Table1 as T1, Table2 as T2
  │ WHERE T1.f1 = T2.f1 AND T1.f3 <> "3"
  └────

  which is actually easy to write in myawk (probably not so in AWK
  though)

  ┌────
  │ let () =
  │   for_each_line ~fname:"table2.txt" @@ map words @@
  │   map_option (function (w::_) -> Some w | _ -> None) @@
  │   fun w ->
  │     for_each_line ~fname:"table1.txt" @@  map words @@
  │     map_option (function
  │      (x::f2::f3::f4::_) when x = w && f4 <> "3" -> Some [x;f4] | _ -> None) @@
  │     print
  └────

  This is the classical nested loop join. Chet Murthy might be pleased
  to see the extensive use of the continuation-passing style. I was
  apprehensive at first, but it turned out not to be a hassle.

  The library has a few other examples, including case-branching and
  rewriting a real AWK script from the OCaml distribution.

  Finally, let's compare with shell scripts. The example below doesn't
  show off the library, but it does show the benefits of OCaml for
  scripting. The original shell script is a sample GIT commit hook,
  quoted in the comments:

  ┌────
  │ (*
  │ From GIT's sample hooks:
  │   ANY-GIT-REPO/.git/hooks/commit-msg.sample
  │ 
  │   # Called by "git commit" with one argument, the name of the file
  │   # that has the commit message.  The hook should exit with non-zero
  │   # status after issuing an appropriate message if it wants to stop the
  │   # commit.  The hook is allowed to edit the commit message file.
  │ 
  │   # This example catches duplicate Signed-off-by lines.
  │ 
  │ test "" = "$(grep '^Signed-off-by: ' "$1" |
  │ 	 sort | uniq -c | sed -e '/^[ 	]*1[ 	]/d')" || {
  │ 	echo >&2 Duplicate Signed-off-by lines.
  │ 	exit 1
  │ }
  │ 
  │ *)
  │ module H = Hashtbl
  │ 
  │ let commit_msg = Sys.argv.(1)
  │ let ht = H.create 5
  │ let () =
  │   for_each_line ~fname:commit_msg @@ fun l ->
  │   if is_prefix "Signed-off-by: " l <> None then begin
  │     if H.find_opt ht l <> None then begin
  │       prerr_endline "Duplicate Signed-off-by lines.";
  │       exit 1
  │     end else
  │       H.add ht l ()
  │   end
  └────

  Although the OCaml script seems to have more characters, one doesn't
  need to type them all. Scripts like that are meant to be entered in an
  editor; even ancient editors have completion facilities.

  Looking at the original shell script brings despair, and drives me
  right towards Unix Haters. Not only the script is algorithmically
  ugly: if a duplicate signed-off line occurs near the beginning, we can
  report it right away and stop. We don't need to read the rest of the
  commit message, filter it, sort it, precisely count all duplicates and
  filter again. Not only the script gratuitously wastes system resources
  (read: the laptop battery) by launching many processes and allocating
  communication buffers. Mainly, the script isn't good at its primary
  purpose: it isn't easy to write and read. Pipeline composition of
  small stream processors is generally a good thing – but not when each
  stream processor is written in its own idiosyncratic
  language. Incidentally, I have doubts about the script: I think that
  quotes around $1 are meant to be embedded; but why they are not
  escaped then? Probably it is some edge case of bash, out of several
  0thousands.

  In contrast, OCaml script does exactly what is required, with no extra
  work. Everything is written in only one language.


letters 0.2.0
═════════════

  Archive: <https://discuss.ocaml.org/t/ann-letters-0-2-0/6307/1>


Miko announced
──────────────

  Getting this release done took a bit longer than expected due to some
  real life factors, but finally here it is.

  This one mainly focuses on the most requested features and
  improvements like simplifying configuration around CA certificates,
  provides some basic documentation and additionally adds support for
  `multipart/alternative' emails with combined HTML and plain text
  content.


jerben then added
─────────────────

  Link to Github: <https://github.com/oxidizing/letters>


raylib-ocaml 0.1.0
══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-raylib-ocaml-0-1-0/6313/1>


Tobias Mock announced
─────────────────────

  I'd like to announce the first version of [raylib-ocaml], a binding to
  the awesome [raylib] game development library. The release can be
  found on opam as ["raylib"].

  The bindings are nearly complete, as far as functions and types go,
  but only a subset was tested so far. I will work on bringing more of
  the numerous examples of the C version to OCaml in the future.

  Currently, raylib-ocaml only works on Linux, but I plan to support
  Windows (and possibly other targets) in the future.

  Feel free to give it a spin and please report any issues you run into.


[raylib-ocaml] <https://github.com/tjammer/raylib-ocaml>

[raylib] <https://www.raylib.com/>

["raylib"] <https://opam.ocaml.org/packages/raylib/>


OCaml Workshop 2020 Online Conference is live now
═════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-workshop-2020-online-conference-is-live-now/6287/30>


Deep in this thread, Didier Wenzek announced
────────────────────────────────────────────

  [OCaml 2020 All Videos]


[OCaml 2020 All Videos]
<https://www.youtube.com/playlist?list=PLKO_ZowsIOu5fHjRj0ua7_QWE_L789K_f>


Other OCaml News
════════════════

>From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [BuckleScript Good and Bad News]
  • [What the interns have wrought, 2020 edition]
  • [Coq 8.12.0 is out]


[OCaml Planet] <http://ocaml.org/community/planet/>

[BuckleScript Good and Bad News]
<http://psellos.com/2020/08/2020.08.east-van-girls.html>

[What the interns have wrought, 2020 edition]
<https://blog.janestreet.com/what-the-interns-have-wrought-2020/>

[Coq 8.12.0 is out] <https://coq.inria.fr/news/coq-8-12-0-is-out.html>


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-08-18  7:25 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-08-18  7:25 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of August 11 to 18,
2020.

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

Ppx: omp 2.0.0 and next steps
Old CWN


Ppx: omp 2.0.0 and next steps
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ppx-omp-2-0-0-and-next-steps/6231/1>


Jérémie Dimino announced
────────────────────────

  quick summary:
  • ocaml-migrate-parsetree 2.0.0 release
  • you should add a upper bound in your dev repos
  • ppxlib compatible version coming soon
  • ppxlib is now the official ppx library supported by the OCaml
    platform

  Hi everyone,

  As [previously announced], we are [releasing the version 2.0.0 of
  ocaml-migrate-parsetree]. At the moment nothing is compatible with the
  new version and we will soon release a version of ppxlib that is
  compatible with it. If your project depends on
  ocaml-migrate-parsetree, you should add a upper bound to your
  development repository.

  If you plan to use ocaml-migrate-parsetree 2.0.0 directly, please note
  however that this is a transitory package. The technology implemented
  by ocaml-migrate-parsetree will live on and hopefully find a new home
  in the compiler repository proper. However, ocaml-migrate-parsetree as
  a standalone project will eventually stop being maintained.

  I am also taking the opportunity to announce that *ppxlib is the first
  ppx library officially supported by the OCaml platform*, and the one
  we recommend all ppx authors to use. It is the library that we plan to
  maintain for the long term.

  Other libraries such as `ppx_tools' or `ppx_tools_versioned' may
  continue to be maintained by open source contributors, however they
  will not be maintained by the OCaml platform and will not receive
  updates from the platform when new compilers are released. Only ppxlib
  will receive updates from the platform.

  If you would like to port your project to use ppxlib and are
  experiencing difficulties or have any question, please get in touch by
  replying to this post or opening a ticket on
  <https://github.com/ocaml-ppx/ppxlib>.

  The overall plan described in this post is the result of various
  discussions and/or collaborative effort between the following people:
  @avsm, @ceastlund, @Drup, @gasche, @jeremiedimino, @kit-ty-kate,
  @let-def, @NathanReb and @pitag.


[previously announced]
<https://discuss.ocaml.org/t/ocaml-migrate-parsetree-2-0-0/5991>

[releasing the version 2.0.0 of ocaml-migrate-parsetree]
<https://github.com/ocaml/opam-repository/pull/16999>

Next steps
╌╌╌╌╌╌╌╌╌╌

  As soon as the new version of ppxlib is released, we will work towards
  our next milestone. As a reminder, our current goal is to setup a ppx
  ecosystem that is continously compatible with the trunk of OCaml. To
  achieve that goal, we plan to add a stable API called "Astlib" on top
  of the compiler libraries. To keep things sustainable on the compiler
  side and increase flexibility, Astlib will be minimal and will be
  targeted at ppxlib only rather than be a general API aimed at ppx
  authors.

  The difficulty of this API is that it must expose a stable interface
  to the OCaml AST, which is composed of a large collection of data
  types. To make it work, we plan to use the technology developed in
  ocaml-migrate-parsetree; i.e. whole AST migration functions.

  While we eventually want Astlib to live in the compiler repository, we
  will initially develop it inside the ppxlib repository. Once it is
  ready, we will submit it for inclusion in the compiler. Although, we
  will keep a copy inside ppxlib for older versions of the compiler.

  We also plan to setup a smooth workflow for compiler developers to
  update Astlib when they change the development AST.

  Once this is all done, we will be in a situation where the ppx
  ecosystem is compatible with the trunk of OCaml at all time. And as a
  result, new releases of the compiler will no longer break ppx packages
  as long as they limit themselves to the ppxlib API.


Future
╌╌╌╌╌╌

  While this work will make the ecosystem compatible with the trunk of
  OCaml at all times, it will essentially move the backward
  compatibility issue from the compiler to ppxlib.[1] This will already
  give us a lot more flexibility as for instance a single version of
  ppxlib can be compatible with a wide range of OCaml versions. However,
  we recognise that it is not usual to ask a community to rely on an
  unstable API.

  We made this choice as a trade-off between sustainability and
  complexity. Indeed, we want to maintain Astlib and Ppxlib over the
  long term and the best way to make things sustainable is to use simple
  and clear designs. While we do have solutions in our sleeves that
  would provide a fully stable ppx API, these are much more complicated
  to maintain and work with.

  To mitigate this, we are setting up a Dune based workflow to upgrade
  all ppx rewriters at once. So once the system is rolling and if your
  ppx rewriters are up to date and using Dune, you should expect to
  receive pull requests as we update ppxlib. This last part will take
  some time to be fully rolling, so please bear with us :)

  In any case, about a year after this new world is fully setup, we will
  review the situation and decide whether it is sustainable or whether
  we need to go all the way and mint a fully stable ppx API.


Timeline
╌╌╌╌╌╌╌╌

  • today: ocaml-migrate-parsetree 2.0.0 is being released

  • next week: a ppxlib compatible version is released

  • December 2020: astlib is ready inside the ppxlib repository

  • next OCaml release after that: astlib lives in the compiler

  • September 2021: we review the situation and decide what to do next

  [1]: At any given time the API of ppxlib refer to a single version of
  the OCaml AST. In order to allow OCaml users to enjoy both ppx
  rewriters and new language features, the version of the AST selected
  by ppxlib needs to be bumped after each release of the compiler, which
  is a breaking change that has the potential to break several ppx
  packages.  As a result, ppx packages will still need to be regularly
  updated in order to stay compatible with the latest version of ppxlib.


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] <http://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <http://alan.petitepomme.net/>


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-28 16:57 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-07-28 16:57 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp


[-- Attachment #1.1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

[-- Attachment #2.1: Type: text/plain, Size: 23258 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of July 21 to 28,
2020.

As I will be away with no internet next week, the next CWN will be on
August 11.

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

Embedded ocaml templates
Proposal: Another way to debug memory leaks
Camlp5 (8.00~alpha01) and pa_ppx (0.01)
OCaml 4.11.0, third (and last?) beta release
Other OCaml News
Old CWN


Embedded ocaml templates
════════════════════════

  Archive: [https://discuss.ocaml.org/t/embedded-ocaml-templates/6124/1]


Emile Trotignon announced
─────────────────────────

  I am very happy to announce the release of ocaml-embedded-templates.

  This is a tool similar to camlmix, but camlmix was not updated for 7
  years, and there is no easy way to handle a lot of templates (my
  command takes a directory as an argument and generate an ocaml module
  by going through the directory recursively) I also choosed to use a
  syntax similar to EJS, and there is a ppx for inline EML.

  You can check it out here :
  [https://github.com/EmileTrotignon/embedded_ocaml_templates]

  Here is a more extensive exemple of what can be done with this :
  [https://github.com/EmileTrotignon/resume_of_ocaml] (This project
  generate my resume/website in both latex and html).

  This is my first opam package : feedback is very much welcome.


Proposal: Another way to debug memory leaks
═══════════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/proposal-another-way-to-debug-memory-leaks/6134/1]


Jim Fehrle said
───────────────

  `memprof' helps you discover where memory was allocated, which is
  certainly useful.  However, that may not be enough information to
  isolate a leak.  Sometimes you'd like to know what variables refer to
  excessive amounts of memory.

  For this, you'd want to examine all the garbage collection roots and
  report how much memory is used by each.  This is useful information if
  you can map a GC root back to a source file and variable.

  I prototyped code to do that to help with Coq bug
  [https://github.com/coq/coq/issues/12487].  It localized several leaks
  enough across over 500 source files so that we could find and fix
  them.  But my prototype code is a bit crude.  I'd like to clean it up
  and submit it as a PR.  Since this could be done in various ways, I
  wanted to get some design/API feedback up front rather than maybe
  doing some of it twice.  Also I'd like to confident that such a PR
  would be accepted and merged in a reasonable amount of time–otherwise
  why bother.

  [caml_do_roots] shows how to access the GC roots.  There are several
  types of roots:
  • global roots, corresponding to top-level variables in source files
  • dynamic global roots
  • stack and local roots
  • global C roots
  • finalized values
  • memprof
  • hook

  *API (in Gc):*

  ┌────
  │ val print_global_reachable : out_channel -> int -> unit
  └────

  Prints a list to `out_channel' of the global roots that reach more
  than the specified number of words.  Each item shows the number of
  reachable words, the associated index of the root in the `*glob' for
  that file and the name of the source file.

  Something like this (but with only filenames rather than pathnames):

  ┌────
  │   102678 field  17 plugins/ltac/pltac.ml
  │   102730 field  18 plugins/ltac/pltac.ml
  │   164824 field  20 plugins/ltac/tacenv.ml
  │  1542857 field  26 plugins/ltac/tacenv.ml
  │ 35253743 field  65 stm/stm.ml
  │ 35201913 field   8 vernac/vernacstate.ml
  │  8991864 field  24 vernac/library.ml
  │   112035 field   8 vernac/egramml.ml
  │  6145454 field  84 vernac/declaremods.ml
  │  6435878 field  89 vernac/declaremods.ml
  └────

  I would use ELF information in the binary file to map from `*glob'
  back to a filename.  For example, the address symbol of the entry
  `camlTest' corresponds to `test.ml'.  This would only work for binary
  executables compiled with the `-g' option.  It wouldn't work for
  byte-compiled code.  It would print an error message if it's not ELF
  or not `-g'.  Also, being a little lazy, how essential is it to
  support 32-bit binaries?  (Q: What happens if you have 2 source files
  with the same name though in different directories?  Would the symbol
  table distinguish them?)

  ┌────
  │ val get_field_index : Obj.t -> int
  └────

  Returns the `*glob' index number for the top-level variable (passed as
  `Obj.repr var').  I expect there's no way to recover variable names
  from the `*glob' index.  In my experiments, it appeared that the
  entries in `*glob' were in the same order as as the variable and
  function declarations.  This would let a developer do a binary search
  in the code to locate the variable which it probably a necessity for
  large, complex files such as Coq's `stm.ml'–3300 lines, 10+ modules
  defined within the file.  (I noticed that variables defined in modules
  defined within the source file were not in `*glob'.  I expect there is
  a root for the module as a whole and that those variables can be
  readily found within that root.)

  This would need an extended explanation in `gc.mli'.

  ┌────
  │ val print_stack_reachable : out_channel -> int -> unit
  └────

  Prints a backtrace to `out_channel' that also shows which roots for
  each frame reach more than the specified number of words.  (I'd keep
  the "item numbers" since there's no way to translate them to variables
  and they might give some clues.)

  ┌────
  │ Called from file "tactics/redexpr.ml" (inlined), line 207, characters 29-40
  │  356758154 item    0 (stack)
  │ Called from file "plugins/ltac/tacinterp.ml", line 752, characters 6-51
  │   17646719 item    0 (stack)
  │     119041 item    1 (stack)
  │ Called from file "engine/logic_monad.ml", line 195, characters 38-43
  │     119130 item    0 (stack)
  │  373378237 item    1 (stack)
  └────

  As it turns out, 90% of the memory in Coq issue mentioned above is
  reachable only from the stack.

  I didn't consider the other types of roots yet, which I don't fully
  understand, such as local roots.  Just covering global and stack roots
  seems like a good contribution.  Dynamic global roots may be easy to
  add if they are otherwise similar to global roots.  For the others I
  could print the reachable words, but I don't know how to direct the
  developer to look at the relevant part of the code, especially if it's
  in C code.  I suppose `print_global_reachable' and
  `print_stack_reachable' could be a single routine as well.  That's
  probably better.

  Let me know your thoughts.


[caml_do_roots]
https://github.com/ocaml/ocaml/blob/80326033cbedfe59c0664e3912f21017e968a1e5/runtime/roots_nat.c#L399


Camlp5 (8.00~alpha01) and pa_ppx (0.01)
═══════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/ann-camlp5-8-00-alpha01-and-pa-ppx-0-01/6144/1]


Chet Murthy announced
─────────────────────

`Camlp5 (8.00~alpha01)' and `pa_ppx (0.01)'
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  I'm pleased to announce the release of two related projects:

  1. [Camlp5]: version 8.00~alpha01 is an alpha release of Camlp5, with
     full support for OCaml syntax up to version 4.10.0, as well as
     minimal compatibility with version 4.11.0. In particular there is
     full support for PPX attributes and extensions.

  2. [pa_ppx]: version 0.01 is a re-implementation of a large number of
     PPX rewriters (e.g. ppx_deriving (std (show, eq, map, etc), yojson,
     sexp, etc), ppx_import, ppx_assert, others) on top of Camlp5, along
     with an infrastructure for developing new ones.

  This allows projects to combine the existing style of Camlp5 syntax
  extension, with PPX rewriting, without having to jump thru hoops to
  invoke camlp5 on some files, and PPX processors on others.

  Camlp5 alone is not compatible with existing PPX rewriters: Camlp5
  syntax-extensions (e.g. "stream parsers") would be rejected by the
  OCaml parser, and PPX extensions/attributes are ignored by Camlp5
  (again, without `pa_ppx').  `pa_ppx' provides Camlp5-compatible
  versions of many existing PPX rewriters, as well as new ones, so that
  one can use Camlp5 syntax extensions as well as PPX rewriters.  In
  addition, some of the re-implemented rewriters are more-powerful than
  their original namesakes, and there are new ones that add interesting
  functionality.


[Camlp5] https://github.com/camlp5/camlp5

[pa_ppx] https://github.com/chetmurthy/pa_ppx


For democratizing macro-extension-authoring in OCaml
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  TL;DR Writing OCaml PPX rewriters is *hard work*.  There is a
  complicated infrastructure that is hard to explain, there are multiple
  such incompatible infrastructures (maybe these are merging?) and it is
  hard enough that most Ocaml programmers do not write macro-extensions
  as a part of their projects.  I believe that using Camlp5 and pa_ppx
  can make it easier to write macro-extensions, via:

  1. providing a simple way of thinking about adding your extension to
     the parsing process.

  2. providing transparent tools (e.g. quotations) for
     pattern-matching/constructing AST fragments

  Explained below in [Macro Extensions with
  Pa_ppx](#macro-extensions-with-pa_ppx).


◊ The original arguments against Camlp4

  The original argument against using Camlp4 as a basis for
  macro-preprocessing in Ocaml, had several points (I can't find the
  original document, but from memory):

  1. *syntax-extension* as the basis of macro-extension leads to brittle
      syntax: multiple syntax extensions often do not combine well.

  2. a different AST type than the Ocaml AST

  3. a different parsing/pretty-printing infrastructure, which must be
     maintained alongside of Ocaml's own parser/pretty-printer.

  4. A new and complicated set of APIs are required to write syntax
     extensions.

  To this, I'll add

  1. Camlp4 was *forked* from Camlp5, things were changed, and hence,
     Camlp4 lost the contribution of its original author.  Hence,
     maintaining Camlp4 was always labor that fell on the Ocaml
     team. [Maybe this doesn't matter, but it counts for something.]


◊ Assessing the arguments, with some hindsight

  1. *syntax-extension* as the basis of macro-extension leads to brittle
      syntax: multiple syntax extensions often do not combine well.

     In retrospect, this is quite valid: even if one prefers and enjoys
     LL(1) grammars and parsing, when multiple authors write
     grammar-extensions which are only combined by third-party projects,
     the conditions are perfect for chaos, and of a sort that
     project-authors simply shouldn't have to sort out.  And this chaos
     is of a different form, than merely having two PPX rewriters use
     the same attribute/extension-names (which is, arguably, easily
     detectable with some straightforward predeclaration).

  2. Camlp4/5 has a different AST type than the Ocaml AST

     Over time, the PPX authors themselves have slowly started to
     conclude that the current reliance on the Ocaml AST is fraught with
     problems.  The "Future of PPX" discussion thread talks about using
     something like s-expressions, and more generally about a
     more-flexible AST type.

  3. a different parsing/pretty-printing infrastructure, which must be
     maintained alongside of Ocaml's own parser/pretty-printer.

     A different AST type necessarily means a different
     parser/pretty-printer.  Of course, one could modify Ocaml's YACC
     parser to produce Camlp5 ASTs, but this is a minor point.

  4. A new and complicated set of APIs are required to write syntax
     extensions.

     With time, it's clear that PPX has produced the same thing.

  5. Maintaining Camlp4 was always labor that fell on the Ocaml team.

     The same argument (that each change to the Ocaml AST requires work
     to update Camlp5) can be made for PPX (specifically, this is the
     raison d'etre of ocaml-migrate-parsetree).  Amusingly, one could
     imagine using ocaml-migrate-parsetree as the basis for making
     Camlp5 OCaml-version-independent, too.  That is, the "backend" of
     Camlp5 could use ocaml-migrate-parsetree to produce ASTs for a
     version of OCaml different from the one on which it was compiled.


Arguments against the current API(s) of PPX rewriting
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The overall argument is that it's too complicated for most OCaml
  programmers to write their own extensions; what we see instead of a
  healthy ecosystem of many authors writing and helping-improve PPX
  rewriters, is a small number of rewriters, mostly written by Jane
  Street and perhaps one or two other shops.  There are a few big
  reasons why this is the case (which correspond to the responses
  above), but one that isn't mentioned is:

  1. When the "extra data" of a PPX extension or attribute is
     easily-expressed with the fixed syntax of PPX payloads, all is
     `~well~' ok, but certainly not in great shape.  Here's an example:

  ┌────
  │ type package_type =
  │ [%import: Parsetree.package_type
  │ 	  [@with core_type    := Parsetree.core_type [@printer Pprintast.core_type];
  │ 		 Asttypes.loc := Asttypes.loc [@polyprinter fun pp fmt x -> pp fmt x.Asttypes.txt];
  │ 		 Longident.t  := Longident.t [@printer pp_longident]]]
  │ [@@deriving show]
  └────

  The expression-syntax of assignment is used to express type-expression
  rewrites.  And this is necesarily limited, because we cannot (for
  example) specify left-hand-sizes that are type-expressions with
  variables.  It's a perversion of the syntax, when what we really want
  to have is something that is precise: "map this type-expression to
  that type-expression".

  Now, with the new Ocaml 4.11.0 syntax, there's a (partial) solution:
  use "raw-string-extensions" like `{%foo|argle|}'.  This is the same as
  `[%foo {|argle|}]'.  This relies on the PPX extension to parse the
  payload.  But there are problems:

  1. Of course, there's no equivalent `{@foo|argle|}' (and "@@", "@@@"
     of course) for attributes.

  2. If the payload in that string doesn't *itself* correspond to some
     parseable Ocaml AST type, then again, we're stuck: we have to
     cobble together a parser instead of being able to merely extend the
     parser of Ocaml to deal with the case.

  Note well that I'm not saying that we should extend the parsing rules
  of the Ocaml language.  Rather, that with an *extensible parser*
  (hence, LL(1)) we can add new nonterminals, add rules that reference
  existing nonterminals, and thereby get an exact syntax (e.g.) for the
  `ppx_import' example above.  That new nonterminal is used *only* in
  parsing the payload – nowhere else – so we haven't introduced examples
  of objection #1 above.

  And it's not even very hard.


Macro Extensions with Pa_ppx
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The basic thesis of `pa_ppx' is "let's not throw the baby out with the
  bathwater".  Camlp5 has a lot of very valuable infrastructure that can
  be used to make writing macro-preprocessors much easier.  `pa_ppx'
  adds a few more.

  1. Quotations for patterns and expressions over all important OCaml
     AST types.

  2. "extensible functions" to make the process of recursing down the
     AST transparent, and the meaning of adding code to that process
     equally transparent.

  3. `pa_ppx' introduces "passes" and allows each extension to register
     which other extensions it must follow, and which may follow it;
     then `pa_ppx' topologically sorts them, so there's no need for
     project-authors to figure out how to order their PPX extension
     invocations.

  As an example of a PPX rewriter based on `pa_ppx', here's
  [pa_ppx.here] from the `pa_ppx' tutorial.  In that example, you'll see
  that Camlp5 infrastructure is used to make things easy:

  1. quotations are used to both build the output AST fragment, and to
     pattern-match on inputs.

  2. the "extensible functions" are used to add our little bit of
     rewriter to the top-down recursion.

  3. and we declare our rewriter to the infrastructure (we don't specify
     what passes it must come before or after, since `pa_ppx.here' is so
     simple).


[pa_ppx.here]
https://pa-ppx.readthedocs.io/en/latest/tutorial.html#an-example-ppx-rewriter-based-on-pa-ppx


Conclusion
╌╌╌╌╌╌╌╌╌╌

  I'm not trying to convince you to switch away from PPX to Camlp5.
  Perhaps, I'm not even merely arguing that you should use `pa_ppx' and
  author new macro-extensions on it.  But I *am* arguing that the
  features of

  1. quotations, with antiquotations in as many places as possible, and
     hence, *in places where Ocaml identifiers are not permitted*.

  2. facilities like "extensible functions", with syntax support for
     them

  3. a new AST type, that is suitable for macro-preprocessing, but isn't
     merely "s-expressions" (after all, there's a reason we all use
     strongly-typed languages)

  4. an extensible parser for the Ocaml language, usable in PPX
     attribute/extension payloads

  are important and valuable, and a PPX rewriter infrastructure that
  makes it possible for the masses to write their own macro-extensions,
  is going to incorporate these things.


OCaml 4.11.0, third (and last?) beta release
════════════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/ocaml-4-11-0-third-and-last-beta-release/6149/1]


octachron announced
───────────────────

  The release of OCaml 4.11.0 is near.  As one step further in this
  direction, we have published a third and potentially last beta
  release.

  This new release fixes an infrequent best-fit allocator bug and an
  issue with floating-point software emulation in the ARM EABI port.  On
  the ecosystem side, merlin is now available for this new version of
  OCaml.  The compatibility of the opam ecosystem with OCaml 4.11.0 is
  currently good, and it should be possible to test this beta without
  too much trouble.

  The source code is available at these addresses:

  [https://github.com/ocaml/ocaml/archive/4.11.0+beta3.tar.gz]
  [https://caml.inria.fr/pub/distrib/ocaml-4.11/ocaml-4.11.0+beta3.tar.gz]

  The compiler can also be installed as an OPAM switch with one of the
  following commands:
  ┌────
  │ opam update
  │ opam switch create ocaml-variants.4.11.0+beta3 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  or
  ┌────
  │ opam update
  │ opam switch create ocaml-variants.4.11.0+beta3+VARIANT --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  where you replace VARIANT with one of these: afl, flambda, fp,
  fp+flambda

  We would love to hear about any bugs. Please report them here:
   [https://github.com/ocaml/ocaml/issues]

  Compared to the previous beta release, the exhaustive list of changes
  is as follows:


Runtime:
╌╌╌╌╌╌╌╌

  • [#9736], [#9749]: Compaction must start in a heap where all free
    blocks are blue, which was not the case with the best-fit
    allocator. (Damien Doligez, report and review by Leo White)

  • + [*new bug fixes*] [#9316], [#9443], [#9463], [#9782]: Use typing
    information from Clambda or mutable Cmm variables. (Stephen Dolan,
    review by Vincent Laviron, Guillaume Bury, Xavier Leroy, and Gabriel
    Scherer; temporary bug report by Richard Jones)


[#9736] https://github.com/ocaml/ocaml/issues/9736

[#9749] https://github.com/ocaml/ocaml/issues/9749

[#9316] https://github.com/ocaml/ocaml/issues/9316

[#9443] https://github.com/ocaml/ocaml/issues/9443

[#9463] https://github.com/ocaml/ocaml/issues/9463

[#9782] https://github.com/ocaml/ocaml/issues/9782


Manual and documentation:
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • [#9541]: Add a documentation page for the instrumented runtime;
    additional changes to option names in the instrumented
    runtime. (Enguerrand Decorne, review by Anil Madhavapeddy, Gabriel
    Scherer, Daniel Bünzli, David Allsopp, Florian Angeletti, and
    Sébastien Hinderer)

  Entries marked with "+" were already present in previous alphas, but
  they have been complemented by new bug fixes.

  If you are interested by the list of new features, and the nearly
  final list of bug fixes the updated change log for OCaml 4.11.0 is
  available at:

  [https://github.com/ocaml/ocaml/blob/4.11/Changes]


[#9541] https://github.com/ocaml/ocaml/issues/9541


Other OCaml News
════════════════

From the ocamlcore planet blog
──────────────────────────────

  Here are links from many OCaml blogs aggregated at [OCaml Planet].

  • [Frama-Clang 0.0.9 is out. Download it here.]


[OCaml Planet] http://ocaml.org/community/planet/

[Frama-Clang 0.0.9 is out. Download it here.]
http://frama-c.com/index.html


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] http://alan.petitepomme.net/cwn/

[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss

[online] http://lists.idyll.org/listinfo/caml-news-weekly/

[Alan Schmitt] http://alan.petitepomme.net/


[-- Attachment #2.2: Type: text/html, Size: 37178 bytes --]

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-21 14:42 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-07-21 14:42 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of July 14 to 21,
2020.

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

Dune-release: version 1.4.0 released
Using AF_XDP sockets for high-performance packet processing in OCaml
Ubase 0.03
clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
Old CWN


Dune-release: version 1.4.0 released
════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/dune-release-version-1-4-0-released/6103/1]


Sonja Heinze announced
──────────────────────

  This post is about [dune-release], a tool that helps users release
  their packages to Opam in a fast and organized manner. You can install
  it via `opam install dune-release'.

  On behalf of the dune-release team at Tarides, I'm happy to announce
  the new dune-release [1.4.0 release]. The release includes two new
  subcommands described below and a variety of bug fixes and user
  experience improvements. In particular, we've put some work into
  improving the error handling and reporting.

  One of the new subcommands is `dune-release config' , which inspects
  and edits dune-release's global configuration, such as git related,
  opam related and github related data. For example, if you insert a
  typo when being asked for your github id during your first release
  with dune-release, you can correct it comfortably with that new
  subcommand.

  The other new subcommand is `dune-release delegate-info', which helps
  users with an alternative release workflow to integrate dune-release
  into it: imagine you want to use dune-release only for a couple of
  things, such as tagging the distribution and creating the distribution
  tarball and the documentation.  In that case, now you can integrate
  the work done by dune-release into your individual release workflow by
  accessing the path to the created tarball etc via `dune-release
  delegate-info'. It forms part of the broader change in progress
  described in the following post:
  [https://discuss.ocaml.org/t/replacing-dune-release-delegates/4767]


[dune-release] https://github.com/ocamllabs/dune-release/#readme

[1.4.0 release]
https://github.com/ocamllabs/dune-release/releases/tag/1.4.0


Using AF_XDP sockets for high-performance packet processing in OCaml
════════════════════════════════════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/using-af-xdp-sockets-for-high-performance-packet-processing-in-ocaml/6106/1]


suttonshire announced
─────────────────────

  I just wanted to share a fun result from a project I've been hacking
  on.  [ocaml-xsk] is a binding to AF_XDP interface of libbpf.

  AF_XDP is an address family in Linux for high-performance packet
  processing. With an AF_XDP socket a packet bypasses most of the kernel
  networking stack and is passed directly to userspace program.
  Depending on the configuration packets can be passed from the NIC
  without any data copies on either Rx or Tx. If you're interested in
  this kind of stuff here are a couple very useful resources:

  • [https://github.com/torvalds/linux/blob/master/Documentation/networking/af_xdp.rst]
  • [https://github.com/xdp-project/xdp-tutorial/tree/master/advanced03-AF_XDP]

  The cool part is that without installing large dependencies like DPDK
  you can get packets into your program basically as fast as your NIC
  can provide them! It turns out this is true even if your program is
  written in OCaml. Using ocaml-xsk I could receive or transmit 64 byte
  UDP packets at 14.8M packets per second. This is the limit for a
  10Gb/s NIC.

  I'm still trying to figure out the best interface for AF_XDP. There
  are several resources to manage, and simple receive and transmit
  operations actually require a few steps. But it's encouraging know
  OCaml doesn't get in the way of packet throughput.


[ocaml-xsk] https://github.com/suttonshire/ocaml-xsk


Ubase 0.03
══════════

  Archive: [https://discuss.ocaml.org/t/ann-ubase-0-03/6115/1]


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

  I'm happy to announce the release of [ubase], a tiny library whose
  only purpose is to remove diacritics (accents, etc.) from utf8-encoded
  strings using the latin alphabet.

  It was created after the discussion:
  [https://discuss.ocaml.org/t/simplify-roman-utf8/4398].

  It's now available from `opam':

  `opam install ubase'

  This also installs an executable that you may use in a shell, for
  instance:

  ┌────
  │ $ ubase "et grønt træ"
  │ et gront trae
  │ 
  │ $ ubase Anh xin lỗi các em bé vì đã đề tặng cuốn sách này cho một ông người lớn.
  │ Anh xin loi cac em be vi da de tang cuon sach nay cho mot ong nguoi lon.
  └────

  More info [here].


[ubase] https://github.com/sanette/ubase

[here] https://sanette.github.io/ubase/


clangml 4.2.0: OCaml bindings for Clang API (for C and C++ parsing)
═══════════════════════════════════════════════════════════════════

  Archive:
  [https://discuss.ocaml.org/t/ann-clangml-4-2-0-ocaml-bindings-for-clang-api-for-c-and-c-parsing/6123/1]


Thierry Martinez announced
──────────────────────────

  We are happy to announce the new clangml 4.2.0 release.  Clangml
  provides bindings for all versions of Clang, from 3.4 to the not yet
  released 10.0.1.

  The library can be installed via opam: `opam install clangml' The
  documentation is online:
  [https://memcad.gitlabpages.inria.fr/clangml/]

  This new release improves C++ support, including C++20 specific
  constructs.

  All Clang C/C++ attributes should now be supported.  You may have a
  look to the interface of the new auto-generated module [`Attributes'].

  There is now a lazy version of the AST (`Clang.Lazy.Ast'): this is
  useful to explore large ASTs efficiently (note that Clang parsing
  itself can still be slow; the lazy part only concerns the conversion
  into the `Clang.Lazy.Ast' datatypes).


[`Attributes']
https://memcad.gitlabpages.inria.fr/clangml/doc/clangml/Clang__/Attributes/


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] http://alan.petitepomme.net/cwn/

[RSS feed of the archives] http://alan.petitepomme.net/cwn/cwn.rss

[online] http://lists.idyll.org/listinfo/caml-news-weekly/

[Alan Schmitt] http://alan.petitepomme.net/


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

^ permalink raw reply	[flat|nested] 78+ messages in thread

* [Caml-list] Attn: Development Editor, Latest OCaml Weekly News
@ 2020-07-14  9:54 Alan Schmitt
  0 siblings, 0 replies; 78+ messages in thread
From: Alan Schmitt @ 2020-07-14  9:54 UTC (permalink / raw)
  To: lwn, cwn, caml-list, comp

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

Hello

Here is the latest OCaml Weekly News, for the week of July 07 to 14,
2020.

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

OCaml 4.11.0, second beta re