[cwn] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt alan.schmitt at polytechnique.org
Tue Feb 15 01:23:09 PST 2022


Hello

Here is the latest OCaml Weekly News, for the week of February 08 to 15,
2022.

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

OCaml 4.14.0, second alpha release
Multicore OCaml: January 2022 and post-merge activity
Cmdliner 1.1.0
stdcompat.18: forward compatibility for OCaml 4.14 standard library
Eio 0.1 - effects-based direct-style IO for OCaml 5
OCaml job at genomics company
MirageOS 4.0 Beta Release
VSCode OCaml Platform 1.9.0
ocaml-lsp-server 1.10.0
SiFun1.0.0 released
First release of prbnmcn-dagger
First Release of ppx_pyformat 0.1.1
Caqti 1.7.0
Gg 1.0.0 – Basic types for computer graphics
Old CWN


OCaml 4.14.0, second alpha release
══════════════════════════════════

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


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

  The release of OCaml 4.14.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/20501> .

  If you find any bugs, please report them here:

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

  Compared to the last alpha release, we have exceptionally a new
  feature for writing future-compatible early thread exit in 4.14.0 .
  The second notable change is a major fix in the typechecker for
  escaping existential types when using GADTs, that might break existing
  code that relied on the broken types. However, there are currently no
  known instance of package broken by this change in the opam
  repository.  The other fixes are more usual and should be fairly safe.


Changes compared to the first alpha
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The full list of new features and bug fixes, is available at:

  <https://github.com/ocaml/ocaml/blob/4.14/Changes>


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

  • [10951]: Introduce the Thread.Exit exception as an alternative way
    to terminate threads prematurely.  This alternative way will become
    the standard way in 5.00. (Xavier Leroy, review by Florian
    Angeletti)


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


Major new bug fix
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [10907], [10959]: Wrong type inferred from existential types
    (Jacques Garrigue and Gabriel Scherer, report by @dyzsr, review by
    Leo White)


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

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


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

  • *additional fixes* [10596], +[10978]: Add with_open_bin,
     with_open_text and with_open_gen to In_channel and
     Out_channel. Also, add In_channel.input_all. (Nicolás Ojeda Bär,
     review by Daniel Bünzli, Jérémie Dimino, Damien Doligez and Xavier
     Leroy)

  • [10839]: Fix regression of #show when printing class type (Élie
    Brami, review by Florian Angeletti)

  • [10836], [10952]: avoid internal typechecker errors when checking
    signature inclusion in presence of incompatible types. (Florian
    Angeletti, report by Craig Ferguson, review by Gabriel Scherer)


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

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

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

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

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


Deprecation fine tuning
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • *additional fixes* [10675], +[10937]: Emit deprecation warnings when
     old C runtime function names are used.  This will break C stub code
     that uses these old names and treats warnings as errors.  The
     workaround is to use the new names. (Xavier Leroy and David
     Allsopp, review by Sébastien Hinderer and Damien Doligez)


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

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


Tools fine tuning
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • [10846]: add the `-shape' command-line option to ocamlobjinfo. When
    reading a `cmt' file, shape information will only be shown if that
    option is used. (Ulysse Gérard, review by Florian Angeletti)


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


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

  The base compiler can be installed as an opam switch with the
  following commands
  ┌────
  │ opam update
  │ opam switch create 4.14.0~alpha2 --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  With opam 2.1, the previous command line can be simplified to
  ┌────
  │ opam update
  │ opam switch create 4.14.0~alpha2
  └────
  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.14.0~alpha2+options,<option_list>
  │ --repositories=default,beta=git+https://github.com/ocaml/ocaml-beta-repository.git
  └────
  or with opam 2.1:
  ┌────
  │ opam update
  │ opam switch create <switch_name> ocaml-variants.4.14.0~alpha2+options <option_list>
  └────

  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.14.0~alpha2+flambda+nffa ocaml-variants.4.14.0~alpha2+options ocaml-option-flambda
  │ ocaml-option-no-flat-float-array
  └────
  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.14.0-alpha2.tar.gz>
  • <https://caml.inria.fr/pub/distrib/ocaml-4.14/ocaml-4.14.0~alpha2.tar.gz>


Multicore OCaml: January 2022 and post-merge activity
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/multicore-ocaml-january-2022-and-post-merge-activity/9294/1>


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

  Welcome to the January 2022 [Multicore OCaml] monthly update!  This
  update along with the [previous updates] has been compiled by @avsm,
  @ctk21, @kayceesrk and @shakthimaan.

  @xavierleroy clicked "merge" on the [upstream Multicore OCaml
  PR#10831] to upstream OCaml, which simultaneously made for a great
  start to the new year and prepared us for the hard work ahead to get
  to a stable release of OCaml 5.00.0! Since the merge, we have
  continued to work on the release via bug fixes, code improvements, and
  tooling support directly in the main ocaml repository. Notably, a new
  draft PR for [ARM64 backend support] has already been proposed.

  OCaml 5.0 trunk also [removes a number of deprecated modules], and
  renames `EffectHandlers' to `Effect' for consistency with the rest of
  the standard library. In the ecosystem, several of the key support
  libraries like `uring', `multicore-opam', and `domainslib' have had
  updates to work with 5.0.0+trunk. The Eio effects-based direct-style
  parallel IO for OCaml has had significant enhancements, and now also
  builds with OCaml 5.00.0+trunk. The Sandmark benchmarking suite now
  provides a `5.00.0+stable' and `5.00.0+trunk' OCaml variants to build
  the benchmarks for trunk.


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

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

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

[ARM64 backend support] <https://github.com/ocaml/ocaml/pull/10972>

[removes a number of deprecated modules]
<https://github.com/ocaml/ocaml/blob/3e622e41aca318df0d8ccfeb5c65272a0d2acfa3/Changes#L47-L66>

OCaml 5.00 Release Planning
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The core development team is currently pinning down exactly what will
  constitute the OCaml 5.00 release in terms of supported
  features. Anything that will be part of OCaml 5.00 but not currently
  supported must be in this list so that we can plan for its
  implementation.  If you spot something that isn't below but should be,
  please get in touch or post a reply.  This list is, as always, subject
  to change as the core development team plans and implements the
  release.


Runtime
┄┄┄┄┄┄┄

  • Mark stack overflow
    • Currently the mark-stack is allowed to grow to an unbounded
      size. There is a multicore implementation of mark stack overflow
      in [mc#466] . This design is complex and concurrently touches the
      major GC logic for determining when marking is complete. There is
      a feeling that a better design is to handle mark stack overflow
      with a stop-the-world section, but this has not yet been tried.
  • Statmemprof
  • Make the runtime memory model safe
    • Ensure that the implementation of `caml_modify' is correct.
    • Fix warnings reported by Thread Sanitizer on the testsuite.
  • Mark pre-fetching optimisation
  • Minor heap design that reduces virtual memory consumption
    • [#10955] proposes deciding size of the minor area at program
      startup rather than fixed 256GB reservation now. Fixes Valgrind
      and AFL (with default limited virtual memory).
    • Designs exploring alternative organisation of minor heap (DLAB,
      BiBoP) is
      1. Too risky to undertake now due to code change
      2. Benefits unclear. See experiments in [mc#508].
  • Make runtime safe for async callbacks
    ⁃ See the meta issue on asynchronous callback handling in [#10915]
    ⁃ Potentially requires changes to both the stop-the-world mechanism
      and major GC logic
    ⁃ Currently no proposed plan or implementation. Implementation will
      require significant testing and benchmarking
    ⁃ May make sense to complete as part of statmemprof work as both
      will potentially encounter similar implementation issues
  • Eventring runtime tracing eventlog replacement
    ⁃ Monitoring and optimising GC in multicore programs is difficult,
      current multicore eventlog was a temporary fix
    ⁃ PR that adds eventring support to trunk in [#10964]
  • Runtime is capable of running bytecode-only for 32-bit platforms?
    ⁃ sequential or multiple domains?
  • Remove the use of mmap for `Caml_state' (see [mc#796])


[mc#466] <https://github.com/ocaml-multicore/ocaml-multicore/issues/466>

[#10955] <https://github.com/ocaml/ocaml/pull/10955>

[mc#508] <https://github.com/ocaml-multicore/ocaml-multicore/pull/508>

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

[#10964] <https://github.com/ocaml/ocaml/pull/10964>

[mc#796] <https://github.com/ocaml-multicore/ocaml-multicore/issues/796>


Stdlib
┄┄┄┄┄┄

  • Finish the Stdlib audit ([#10960])
  • Domains, Mutex, Semaphore, Condition in 4.14
    ⁃ Support systhread based implementation of Domains and related
      modules. Mutex, Semaphore and Condition work as is.
    ⁃ 4.14 is pretty much frozen already; so an emulation of Domains can
      be provided by a separate compatibility library.
  • API Docs
    ⁃ Write API docs for effect handlers and domains
  • Manual chapters
    ⁃ New manual chapters for effect handlers, domains and memory model
  • OCamldoc thread-safety annotations
    ⁃ Introduce an OCamldoc tag for thread-safety ([#10983]).
    ⁃ Partial order between `domain-safe', `systhread-safe',
      `fiber-safe'. `not-concurrency-safe' as default placeholder for
      those API functions, modules not audited for thread-safety.
  • Atomic arrays
  • Atomic mutable record fields
  • Concurrency-safe lazy
    ⁃ Lazy that is safe for domains, systhreads and fibers


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

[#10983] <https://github.com/ocaml/ocaml/pull/10983>


Backend / middle-end
┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄

  • Flambda support
  • Arm64 support
    ⁃ Currently being worked on in trunk.
    ⁃ Targets are Mac M1 and AWS Graviton
  • 32-bit support
    ⁃ Sequential-only native backend is achievable on x86.  32-bit ARM
      can probably support multiple domains.  Time to drop x86-32 to
      bytecode only?
    ⁃ Wasm is 32-bit only now.
  • RISC-V, Power, …
  • OpenBSD, FreeBSD merged.
    ⁃ [#10875] adds OpenBSD support
  • Framepointer support
    ⁃ Useful for `perf' based performance benchmarking.
    ⁃ x86 and/or arm64?


[#10875] <https://github.com/ocaml/ocaml/pull/10875>


Tooling
┄┄┄┄┄┄┄

  • Revive `ocamldebug`


January 2021 updates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  As always, the Multicore OCaml updates are listed first, which are
  then followed by the ecosystem tooling updates.  Finally, the Sandmark
  benchmarking tasks are listed for your reference.

  /editor’s note: please find the detailed notes at the archive link
  above/


octachron later said
────────────────────

  After a meeting last week, the core compiler team has agreed on a
  short-list of blocking issues for the OCaml 5.0 at
  <https://github.com/ocaml/ocaml/issues/11013> .


Cmdliner 1.1.0
══════════════

  Archive: <https://discuss.ocaml.org/t/ann-cmdliner-1-1-0/9295/1>


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

  It's my pleasure to announce the release 1.1.0 of cmdliner. Cmdliner
  allows the declarative definition of command line interfaces in OCaml.

  The main points of this release are:

  • Support for UTF-8 man pages.
  • Support for deprecating commands, arguments and environment
    variables.
  • Arbitrary sub command nesting, each with its own command line syntax
    and help page.

  To bring in the latter but limit cruft and confusion, the API was
  reorganized around the notion of [command]. But except for the
  vagaries of introducing a new module in your scope, no existing
  program should be broken due to this.

  However /all/ programs will be subject to deprecation warnings to
  migrate to this new API. This being mostly a reorganization rather
  than a redesign, transitioning to it should be smooth ([example] for a
  simple tool), but a few defaults have been changed along the way.

  Therefore make sure to read the [release notes][notes] which have all
  the details and credits the people who gave a hand for this long
  delayed release; many thanks to them.

  Finally a special thanks to @kit-ty-kate for her tremendous help and
  dedicated boring work in having this merged into the opam package
  repository.

  If you have any question about the new API, use this thread.

  • Home page: <https://erratique.ch/software/cmdliner>
  • API docs & manuals: <https://erratique.ch/software/cmdliner/doc/> or
    `odig doc cmdliner'
  • Install: `opam install cmdliner'


[example]
<https://github.com/dbuenzli/uuidm/commit/5898246570f5d74343d08ba279d07fbfcd27fbb1>


stdcompat.18: forward compatibility for OCaml 4.14 standard library
═══════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-stdcompat-18-forward-compatibility-for-ocaml-4-14-standard-library/9297/1>


Thierry Martinez announced
──────────────────────────

  It's my pleasure to announce a new release (#18) of `stdcompat',
  providing an implementation of OCaml 4.14 standard library which is
  compatible with all versions of OCaml from 3.07.

  In particular, the new modules `In_channel' and `Out_channel', and the
  new functions introduced in `Seq' are now available whatever the
  version of OCaml you use.

  Available through `opam': `opam install stdcompat'

  Development repository:
  <https://github.com/thierry-martinez/stdcompat>


Eio 0.1 - effects-based direct-style IO for OCaml 5
═══════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/eio-0-1-effects-based-direct-style-io-for-ocaml-5/9298/1>


Thomas Leonard announced
────────────────────────

  [Eio] provides an effects-based direct-style IO stack for OCaml
  5.0. It aims to be easy to use, secure, well documented, and fast. It
  consists of a generic cross-platform API, plus optimised backends for
  different platforms.

  This 0.1 release is for early adopters to try it out and provide
  feedback. It works with OCaml 5.00.0+trunk at the time of writing, but
  as that is a moving target we suggest using 4.12.0+domains for now:

  ┌────
  │ opam switch create 4.12.0+domains
  │ --repositories=multicore=git+https://github.com/ocaml-multicore/multicore-opam.git,default
  │ opam install eio_main
  └────

  There is a [tutorial] giving a tour of the main features:

  • Concurrent code without a need for monads or special syntax: no more
    `>>=', `let%lwt', `Lwt_list.iter_s', etc. Just use plain OCaml code
    (`|>', `let', `List.iter').
  • Concurrency primitives (promises, streams, semaphores), as usual.
  • Run multiple fibres on a single core, or distribute work across
    multiple CPUs.
  • Replace any OS features (files, networks, clocks, etc) with mocks
    for testing.
  • Structured concurrency, to prevent leaking resources (such as open
    file descriptors or fibres).
  • Automatic handling of cancellation, so that if one part of your
    program fails then other fibres are cancelled automatically until
    the exception is handled or the program exits with a stack trace.
  • Capability-based security. For example, a `Dir.t' only grants access
    within some sub-tree of the filesystem, and prevents escaping it
    using `..' or by following symlinks out of the tree.

  Various libraries are in the process of being ported to Eio. Examples
  include a [Gemini client] (including ports of angstrom, httpaf, notty
  and ocaml-tls), and [Dream] (providing a direct-style API to users
  while using [lwt-eio] internally to integrate with existing
  libraries).

  Performance seems good, especially on recent versions of Linux were
  Eio can take advantage of io_uring. For example, this graph shows how
  various HTTP servers cope with increasing load:

  <https://user-images.githubusercontent.com/554131/151006021-2eb8f55e-40b3-409c-bbce-3cd582ac1231.png>

  `httpaf_eio' is currently at the top (though note that the Rust
  server, rust_hyper, is not using io_uring, so this is not a completely
  fair comparison).

  Useful resources:
  • [Eio] – the main project
  • [Lwt_eio] – integration with or porting from Lwt
  • [awesome-multicore-ocaml] – list of multicore resources

  Feedback, and PRs adding missing features, are welcome!


[Eio] <https://github.com/ocaml-multicore/eio>

[tutorial] <https://github.com/ocaml-multicore/eio/blob/main/README.md>

[Gemini client] <https://gitlab.com/talex5/gemini-eio>

[Dream] <https://github.com/aantron/dream/pull/194>

[lwt-eio] <https://github.com/talex5/lwt_eio>

[Lwt_eio] <https://github.com/talex5/lwt_eio>

[awesome-multicore-ocaml]
<https://github.com/patricoferris/awesome-multicore-ocaml>


The editor says
───────────────

  A huge debate followed this message. Please follow the archive link
  above if you want to read more.


OCaml job at genomics company
═════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ocaml-job-at-genomics-company/9301/1>


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

  At Solvuu, we develop software for the life sciences industry. Our
  projects touch human health in various ways, from pursuing cancer
  therapies to improving agricultural output. We use OCaml across the
  full stack: cloud infrastructure management, job scheduling, data
  management and security, statistical data analysis, clients and
  servers for many APIs, and web based UIs for data exploration.

  We currently have a full-time position open for an OCaml programmer
  with cloud computing experience. The ideal candidate would have at
  least 2 years of professional software development experience in
  OCaml, and 2 years of experience building systems on AWS. Other
  requirements include exceptionally good written and verbal
  communication skills, organizational skills, and attention to
  detail. We insist on clean elegant code and a team-first attitude, and
  will want to be convinced that you do too. Though not required, the
  following would all strengthen your application: a PhD in distributed
  systems or programming languages, experience with IaC technologies
  like Terraform, or experience in the life science industry.

  To apply, please send an email to jobs at solvuu.com expressing your
  interest, and please attach your CV. This is a full-time position and
  requires authorization to work in the US. Ideally, you would work from
  one of our offices in Manhattan or San Francisco (which immerse you in
  an ecosystem of innovative companies alongside Solvuu), but we welcome
  remote work from anywhere in the US. Our compensation package includes
  a competitive salary, equity, and health insurance for you and your
  family.

  If the above sounds exciting, but you are outside the US, available
  only part-time, or feel you don’t quite meet the requirements, please
  do still reach out. We are keen to meet anyone passionate about OCaml
  programming as a career, and we will be happy to explore options for
  working together. You do not need to know any Biology.


MirageOS 4.0 Beta Release
═════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/mirageos-4-0-beta-release/9302/1>


Thomas Gazagnaire announced
───────────────────────────

  *On behalf of the Mirage team, I am delighted to announce the beta
   release of MirageOS 4.0!*

  [MirageOS] is a library operating system that constructs unikernels
  for secure, high-performance network applications across a variety of
  hypervisor and embedded platforms. For example, OCaml code can be
  developed on a standard OS, such as Linux or macOS, and then compiled
  into a fully standalone, specialised unikernel that runs under a Xen
  or KVM hypervisor. The MirageOS project also supplies several protocol
  and storage implementations written in pure OCaml, ranging from TCP/IP
  to TLS to a full Git-like storage stack.

  The beta of the MirageOS 4.00 release contains:
  • `mirage.4.0.0~beta': the CLI tool;
  • `ocaml-freestanding.0.7.0': a libc-free OCaml runtime;
  • and `solo5.0.7.0': a cross-compiler for OCaml.

  They are all available in `opam' by using:
  ┌────
  │ opam install 'mirage>=4.0'
  └────

  /Note/: you need to explicitly add the `4.0>=0' version here,
  otherwise `opam' will select the latest `3.*' stable release. For a
  good experience, check that at least version `4.0.0~beta3' is
  installed.


[MirageOS] <https://mirage.io>

New Features
╌╌╌╌╌╌╌╌╌╌╌╌

  This new release of MirageOS adds systematic support for
  cross-compilation to all supported unikernel targets. This means that
  libraries that use C stubs (like Base, for example) can now seamlessly
  have those stubs cross-compiled to the desired target.  Previous
  releases of MirageOS required specific support to accomplish this by
  adding the stubs to a central package.

  MirageOS implements cross-compilation using /Dune Workspaces/, which
  can take a whole collection of OCaml code (including all transitive
  dependencies) and compile it with a given set of C and OCaml compiler
  flags. This workflow also unlocks support for familiar IDE tools (such
  as `ocaml-lsp-server' and Merlin) while developing unikernels in
  OCaml. It makes day-to-day coding much faster because builds are
  decoupled from configuration and package updates.  This means that
  live-builds, such as Dune's watch mode, now work fine even for exotic
  build targets!

  A complete list of features can be found on the [MirageOS 4 release
  page].


[MirageOS 4 release page] <https://mirage.io/docs/mirage-4>


Cross-Compilation and Dune Overlays
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This release introduces a significant change in the way MirageOS
  projects are compiled based on Dune Workspaces. This required
  implementing a new developer experience for Opam users in order to
  simplify cross-compilation of large OCaml projects.

  That new tool, called [opam-monorepo] (née duniverse), separates
  package management from building the resulting source code. It is an
  Opam plugin that:
  • creates a lock file for the project dependencies
  • downloads and extracts the dependency sources locally
  • sets up a Dune Workspace so that `dune build' builds everything in
    one go.

  <https://asciinema.org/a/rRf6s8cNyHUbBsDDfZkBjkf7X?speed=2>

  `opam-monorepo' is already available in Opam and can be used on many
  projects which use `dune' as a build system.  However, as we don't
  expect the complete set of OCaml dependencies to use `dune', we
  MirageOS maintainers are committed to maintaining patches to build the
  most common dependencies with `dune'. These packages are hosted in a
  separate [dune-universe/mirage-opam-overlays] repository, which can be
  used by `opam-monorepo' and is enabled by default when using the
  Mirage CLI tool.


[opam-monorepo] <https://github.com/ocamllabs/opam-monorepo>

[dune-universe/mirage-opam-overlays]
<https://github.com/mirage/opam-overlays>


Next Steps
╌╌╌╌╌╌╌╌╌╌

  Your feedback on this beta release is very much appreciated. You can
  follow the tutorials on <https://mirage.io/wiki/mirage-4>, our
  self-hosted staging site using MirageOS 4. Issues are very welcome on
  <https://github.com/mirage/mirage/issues>, or come find us on Matrix
  in the MirageOS channel: [#mirageos:matrix.org].

  The *final release* will happen in about a month. This release will
  incorporate your early feedback. It will also ensure the existing
  MirageOS ecosystem is compatible with MirageOS 4 by reducing the
  overlay packages to the bare minimum. We also plan to write more on
  `opam-monorepo' and all the new things MirageOS 4.0 will bring.


[#mirageos:matrix.org] <https://matrix.to/#/#mirageos:matrix.org>


VSCode OCaml Platform 1.9.0
═══════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-1-9-0/9305/1>


Rudi Grinberg announced
───────────────────────

  On behalf of our vscode team, I’m excited to announce the long awaited
  version 1.9.0 of our vscode extension.

  This release is rich in new features, but I’d like to highlight one in
  particular. @arozovyk added a full blown interactive AST explorer for
  PPX development. So long to flipping back and forth between your
  project and `parsetree.mli' during development.

  This release also features work from three new contributors: @tatchi,
  @SaySayo and @arozovyk. I thank them for their work and wish them luck
  in participating in our cozy open source community.

  Happy Hacking.


1.9.0
╌╌╌╌╌

  • Dune syntax highlighting fix (#742)

    The syntax for dune files has been re-written from scratch for a
    more correct implementation. Every dune stanza documented by Dune is
    now supported, and only the correct fields in each stanza are
    recognized.

  • Fix the detection of opam's root directory when no switch is
    detected (#831)

  • Add support for opening compilation artifacts in human-readable form
    in the editor (#798)

    Currently supported artifacts include `.cmi', `.cmt(i)', `.cmo',
    `.cma', `.cmx(a/s)', and `.bc' files.

    To learn more about these files, see:
    <https://ocaml.org/manual/comp.html>

  • Warn if the extension sees not the latest OCaml-LSP version
    compatible with the OCaml distribution installed in the current
    sandbox.

  • Highlighted the UNREACHABLE element in cram .t files (#754)

  • Activate extension on cram files, or when the workspace contains
    dune-workspace or dune files. (#750)

  • Add commands `Jump to Next Typed Hole' (shortcut: `Alt + L') and
    `Jump to Previous Typed Hole' (shortcut: `Alt + Shift + L')

    _What typed holes are_

    Merlin has a concept of "typed holes" that are syntactically
    represented as `_'. Files that incorporate typed holes are not
    considered valid OCaml, but Merlin and OCaml-LSP support them. One
    example when such typed holes can occur is when one "destructs" a
    value, e.g., destructing `(Some 1)' will generate code `match Some 1
    with Some _ -> _ | None -> _'. While the first underscore is a valid
    "match-all"/wildcard pattern, the rest of underscores are typed
    holes that one needs to replace with valid OCaml code. These new
    commands help to navigate easily from one hole to another (#643)

  • Rename the extension's section in VS Code Settings from `OCaml
    configuration' to `OCaml Platform' (#674)

  • Add `ocaml.server.extraEnv' configuration option to pass extra
    environment variables to the language server, i.e., OCaml-LSP (#674)

  • Parsetree exploration and development tools. It is now possible to
    explore the structure of the parsetree in a custom
    editor. Additionally, it is possible to view preprocessed source of
    any OCaml source file (when applicable). Full functionality is
    available only for dune projects. (#666)

  • Add commands `Show OCaml Language Server Output', `Show OCaml
    Platform Extension Output', and `Show OCaml Commands Output'.
    (#745)

  • Fix highlighting of escaped odoc source code braces (#690)

  • `opam exec' is now called with `--set-switch' flag; this is useful
    when we launch a terminal within a certain sandbox set in the
    extension (#744, fixes #655)

  • The currently active OPAM switch in the workspace folder (project
    root) is shown first in the list of sandboxes when selecting a
    sandbox. (#751)

  • Show a different icon for the currently active OPAM switch in the
    "OPAM Switches" tree view (#751)


ocaml-lsp-server 1.10.0
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-lsp-server-1-10-0/9307/1>


Rudi Grinberg announced
───────────────────────

  On behalf of the ocamllsp team, I’m pleased to announce version
  1.10.0.  The only new feature this release offers is better code
  folding, but there are some important bug fixes and performance
  improvements. If you encounter any sluggishness with our server, do
  not hesitate to report it.

  Unless there are serious bugs with this release, this will be the last
  release for OCaml 4.13.

  Happy Hacking.


1.10.0
╌╌╌╌╌╌

Features
┄┄┄┄┄┄┄┄

  • Add better support for code folding: more folds and more precise
    folds


Fixes
┄┄┄┄┄

  • Fix infer interface code action crash when implementation source
    does not exist (#597)

  • Improve error message when the reason plugin for merlin is absent
    (#608)

  • Fix `chdir' races when running ppx (#550)

  • More accurate completion kinds.  New completion kinds for variants
    and fields. Removed inaccurate completion kinds for constructors and
    types. (#510)

  • Fix handling request cancellation (#616)


SiFun1.0.0 released
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ann-sifun1-0-0-released/9308/1>


Krzysztof Druciarek announced
─────────────────────────────

  I wanted to announce the first release of the SiFun project!!!

  SiFun is a Simple Functional language created by me as the part of my
  bachelor's dissertation project. The aim of the project is to create a
  language that supports higher rank polymorphism (unlike OCaml). So far
  I created two type systems: Hindley–Milner (which is just a simply
  typed lambda calculus) and System F (which extends HM system and adds
  features of type abstractions, typed functions and visible type
  application).

  The next part of the project is currently under development - the
  Bidirectional Type checking, which will fully support higher rank
  types, as expected.

  Feel free to play around with this simple interpreter (I've added
  support of interactive REPL command line) and raise any issues you
  find. :blush:

  Link to the GitHub repo: <https://github.com/kkd26/SiFun>


First release of prbnmcn-dagger
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-prbnmcn-dagger/9311/1>


Igarnier announced
──────────────────

  I'm pleased to announce the first release of [prbnmcn-dagger] (dagger
  for short).

  dagger is a library/edsl for [probabilistic programming].  Models are
  written in a monadic language and inference is performed by backends
  implementing that monadic interface.  In this first release, dagger
  only implements variants of [lightweight Metropolis-Hastings].

  You can have a look at the [README] or jump straight at the
  [documentation]

  Some notable sources of inspiration for this project are:
  • [Functional programming for modular Bayesian inference]
  • [Hakaru10]


[prbnmcn-dagger] <https://github.com/igarnier/prbnmcn-dagger>

[probabilistic programming]
<https://en.wikipedia.org/wiki/Probabilistic_programming>

[lightweight Metropolis-Hastings]
<http://proceedings.mlr.press/v15/wingate11a.html>

[README] <https://github.com/igarnier/prbnmcn-dagger#readme>

[documentation]
<https://igarnier.github.io/prbnmcn-dagger/prbnmcn-dagger/index.html>

[Functional programming for modular Bayesian inference]
<https://dl.acm.org/doi/10.1145/3236778>

[Hakaru10] <https://okmij.org/ftp/kakuritu/Hakaru10/>


First Release of ppx_pyformat 0.1.1
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-first-release-of-ppx-pyformat-0-1-1/9321/1>


Boning announced
────────────────

  I am very glad to announce the first release of [`ppx_pyformat']!

  `ppx_pyformat' is a ppxlib based rewriter inspired by Python string
  `format()' . This rewriter allows the user to do complex variable
  substitutions and value formatting. The format string syntax of
  `ppx_pyformat' is closely modeled after [that of Python3.10] (with
  several enhancements). Most Python format strings should be compatible
  with `ppx_pyformat' with minor modifications. And the behavior is also
  very similar. So Python users should be able to quickly pick up this
  rewriter.

  The rewriter takes a required format string following with optional
  input arguments. The rewriter will parse the format string,
  substitute/format the replacement fields and finally return everything
  as a single `string'.

  For more details about this package, please check the [README.md].

  Here is some sample code
  ┌────
  │ let _ =
  │   let hello = "Hello" in
  │   let world = "world" in
  │   print_endline [%pyformat "{hello} {world}!"]
  │ (*Hello world!*)
  │ 
  │ let _ =
  │   print_endline [%pyformat "pi = {Float.pi:.10f}"]
  │ (*pi = 3.141592653*)
  │ 
  │ let _ =
  │   let string_of_tuple (a, b) = "("^a^", "^b^")" in
  │   print_endline [%pyformat "{!string_of_tuple}"; ("foo", "bar")]
  │ (*(foo, bar)*)
  │ 
  │ let _ =
  │   print_endline [%pyformat "the answer to life the universe and everything {0:#020_b}"; 42]
  │ (*the answer to life the universe and everything 0b000_0000_0010_1010*)
  └────

  Hope this plugin can make logging/debugging in OCaml a bit
  easier. Feel free to leave any feedback! Thanks.


[`ppx_pyformat'] <https://opam.ocaml.org/packages/ppx_pyformat/>

[that of Python3.10]
<https://docs.python.org/3.10/library/string.html#format-string-syntax>

[README.md] <https://github.com/bn-d/ppx_pyformat/blob/master/README.md>


Caqti 1.7.0
═══════════

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


Petter A. Urkedal announced
───────────────────────────

  I am pleased to announce the release of [Caqti] 1.7.0.  Caqti is a
  generic RDBMS client interface supporting MariaDB, PostgreSQL, and
  Sqlite3 via the corresponding bindings to the client libraries.  The
  full release notes follows.


[Caqti] <https://github.com/paurkedal/ocaml-caqti>

v1.7.0 - 2022-02-13
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  New features:

  • Added a new query-string parser based on Angstrom.  Its main
    advantage is that it can be used stand-alone e.g. to load SQL
    schemas from files split into individual statements which can be
    sent to the database.

  • Support passing a query environment to the connect and pool
    construction functions.  This avoids using globals to modify the
    environment and facilitates e.g. targeting different database
    schemas with different connetions or connection pools.

  • A new `Caqti_query.E' case was added to support the two above cases.
    This is a breaking change, but hopefully does not break existing
    code.  The exception (not counting `module type of') would be if the
    constructors are aliased along with an alias of the type.  On the
    other hand, pattern matching should be compatible since the new
    constructor is only emitted by newly introduced functions.

  • Added a module `Caqti_request.Infix' providing a new high-level API
    for constructing requests.  It uses two-stage combinators, first to
    apply type arguments then to apply the query string.  Apart from
    allowing nicer looking code, this solves the problem of switching to
    a the query string parser while maintaining backwards compatibility.

  • Added `set_statement_timeout' to connection modules, used to set
    query timeout.  It is only supported for PostgreSQL and
    MariaDB. (#74)

  • Added `with_transaction' function to connection modules.  This is
    just fail-safed wrapper around `start', `commit', and `rollback'.

  Fixes:

  • Fixed delayed recovery of connection pools after loosing connections
    to PostgreSQL.  Due to a missing call to consume inputs, the pool
    validator did not discover that a connection was lost before it was
    attempted reused.

  • Improved resilience against exceptions and monadic errors in
    callbacks and fixed in-use checking.

  • Changed Sqlite3 driver to use non-linear parameters and improve
    error reporting when the wrong number of arguments are received (#77
    & GPR#79 Reynir Björnsson).

  Other changes:

  • The Caqti license now uses the LGPL-3.0 Linking Exception instead of
    a rephrasing of the OCaml LGPL Linking Exception which was written
    for LGPL-2.1.

  • Improved documentation, pretty-printing, logging, and exception
    details.

  • The test suite has been switched to use Alcotest; not without some
    struggle due to the use of test harness and argument-dependent test
    suite, but the result seems like a clear improvement.


Gg 1.0.0 – Basic types for computer graphics
════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-gg-1-0-0-basic-types-for-computer-graphics/9330/1>


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

  It's my pleasure to announce the release 1.0.0 of Gg. Gg provides
  basic types for computer graphics.

  The big change of this release is that the `Gg.Float' module now
  includes the `Stdlib.Float' module introduced in OCaml 4.07. This
  means that the additions made there are also in the `Float' module in
  your scope when you `open Gg'.

  Ideally the [`Gg.Float'] module would have disappeared but some values
  remain in it that are not in `Stdlib.Float' and which are unlikely to
  be ever added there.

  Be *very* careful on upgrading since this entails subtle changes to
  three of the existing functions of `Gg.Float'.  Besides the semantics
  of `Gg.Float.pp' and `Box{1,2,4}.inset' was also changed.

  All of this is carefully documented in the [release notes].

  Sorry for these silent semantic changes.

  • Home page: <https://erratique.ch/software/gg>
  • API docs & manuals: <https://erratique.ch/software/gg/doc/>
  • Install: `opam install gg'


[`Gg.Float'] <https://erratique.ch/software/gg/doc/Gg/Float/index.html>

[release notes]
<https://github.com/dbuenzli/gg/blob/master/CHANGES.md#v100-2022-02-15-la-forclaz-vs>


Old CWN
═══════

  If you happen to miss a CWN, you can [send me a message] and I'll mail
  it to you, or go take a look at [the archive] or the [RSS feed of the
  archives].

  If you also wish to receive it every week by mail, you may subscribe
  [online].

  [Alan Schmitt]


[send me a message] <mailto:alan.schmitt at polytechnique.org>

[the archive] <https://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>

[online] <http://lists.idyll.org/listinfo/caml-news-weekly/>

[Alan Schmitt] <https://alan.petitepomme.net/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20220215/1f6afcbf/attachment-0001.html>


More information about the caml-news-weekly mailing list