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

Alan Schmitt
2021-03-30T14:55:57Z

[-- 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
` ': 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 ` ' 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 ` ' 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 --]