OCaml Weekly News

On behalf of the opam dev team, I’m happy to announce you the alpha release of opam 2.2.0. :tada:

The library used for accessing emission information from electricity grids called “carbon” should now be available on opam. This is an initial release and might change a bit (e.g. it depends on an alpha release of cohttp-eio).

opam update && opam install carbon

Here’s a simple example to get the emission numbers for Great Britain.

Eio_main.run @@ fun env ->
Mirage_crypto_rng_eio.run (module Mirage_crypto_rng.Fortuna) env @@ fun _ ->
Carbon.Gb.get_intensity env#net
|> Eio.traceln "%a" Carbon.Gb.Intensity.pp

Thanks to @emillon for providing a backend for French data and to @reynir for suggesting important changes to the CO2-signal backend before the release.

A recent blog article on the subject:

https://ocamlpro.com/blog/2023_03_18_autofonce/

After two alpha releases, the release of OCaml 5.1.0 is drawing near.

We have thus released a first beta version of OCaml 5.1.0 to help you update your softwares and libraries ahead of the release (see below for the installation instructions).

Compared to the last alpha release, this beta contains two subtle internal runtime fixes, and one Windows fix. Overall, the opam ecosystem looks in a good shape for the first beta release.

If you find any bugs, please report them on OCaml’s issue tracker.

Nearly all core development tools supports OCaml 5.1.0, and you can follow the last remaining wrinkles on the opam readiness for 5.1.0 meta-issue.

Currently, the release is planned for the end of July or the beginning of August.

If you are interested in full list of features and bug fixes of the new OCaml version, the updated change log for OCaml 5.1.0 is available on GitHub.

After spending some time trying to map the current package build failures with the current beta release on the opam repository, I have written down a short topography of such build failures at http://gallium.inria.fr/blog/florian-compiler-weekly-2023-07-05 .

Just released 0.1.0 with a couple of small helpers:

• Hx.__ can be used to render the _ attribute, which is used for Hyperscript
• attr "attr-name" can be used to create a new attribute which does not carry a payload (what is usually called a boolean attribute)

I am very happy to announce the second release (v0.2.0) of ppx_subliner ! The new version is available through OPAM.

The extension had been greatly enhanced since the first release.

Now, the user is able to generate a multi-subcommand application from a single variant type with inline records. And the new version does not need to rely on other extensions.

type params = Foo of { my_arg : string } | Bar
[@@deriving subliner]

let handle = function
  | Foo { my_arg } -> print_endline ("Foo " ^ my_arg)
  | Bar -> print_endline "Bar"

[%%subliner.cmds
eval.params <- handle]
(** Some docs *)

The user is also able to generate Cmdliner.Term.t from a record type, and the signature is fully compatible with the generated value of ppx_deriving_cmdliner . The deriver support various attributes, such as [@pos], [@pos_all], [@pos_left], [@non_empty], [@conv], [@term], [@file], to support different kinds of positional arguments and types, and give the user great flexibility.

type foo = { my_arg : string } [@@deriving subliner]

This release should cover majority of Cmdliner. Please see the documentation for the full feature set.

Happy hacking!

Dear OCaml people,

some time ago we encountered issues in the connection establishment of http-lwt-client in a GitHub action (using a pre-commit.com) hook. It was quite some journey from surfacing issue “HTTP connection timeout” to the actual issue, so we wrote it up at https://semgrep.dev/blog/2023/http-request-failed-timeout-issue-in-ocaml – it reminds me of an issue surfacing as “bad record mac” in the TLS stack some years ago (see https://hannes.robur.coop/Posts/BadRecordMac).

This lead to the releases of happy-eyeballs{,-lwt,-mirage} 0.6.0 and dns* 7.0.3. In related news, we just release http-lwt-client 0.2.5 with further fixes (related to HTTP2) and http-mirage-client 0.0.5.

This debugging and fixing work was sponsored by semgrep.com – a great open source utility to statically analyse your codebase :D

All the best, and please report issues and feedback either here, via eMail, or in the issue tracker(s). Enjoy your day!

A short blog post on getting started with ReasonReact and Melange: https://dev.to/psb/getting-started-with-reasonreact-and-melange-13hd

I wrote up a summary of the various efforts at Tarides aimed at making OCaml 5 succeed for developers: https://tarides.com/blog/2023-07-07-making-ocaml-5-succeed-for-developers-and-organisations/.

The post gives an idea of how we’ve been approaching this challenge. It would be great to hear what the community thinks about our approach and whether we are missing something impactful that we should be focussing on.

Also, I hope you give OCaml 5 a try if you haven’t already :-)

llama is a library for building audio synthesizers using a declarative EDSL. It contains a collection of combinators which consume and produce streams of values (usually ~float~s for audio signals and ~bool~s for control signals) which can be composed much in the same way as one would patch a modular synthesizer. The library also contains a player which can play a stream of ~float~s (treated as audio samples) through your sound card.

An additional library llama_interactive can be used to connect synthesizers to input events and to render oscilloscope visualizations:

Some demos (from the examples directory):

• Midi file player
• Interactive synth played with computer keyboard

There are more demo videos linked from the readme.

Get llama with opam install llama or opam install llama_interactive. A third package llama_core contains just the core type definitions and combinators but not the player. Use this if you just want to make more effects, filters, etc without depending on additional packages needed to play audio.

Note that llama (and llama_interactive) depends on conf-rust-2021 as interacting with the sound card is done using the cpal rust library. If you don’t want to install rust system-wide (e.g. because you use rustup) then run opam install conf-rust-2021 --assume-depexts before installing llama.

Thank you to the Dune team for all your fantastic work.

For anyone using macOS there is a know bug with this version https://github.com/ocaml/dune/issues/8083 that you might want to hold off until it is fixed before upgrading.

To expand on that:

In Dune 3.9.0, we added a feature that offloads some computations to background threads. Unfortunately, this has a bad interaction on macOS, where we fork processes to implement the RPC server and watch mode.

We marked Dune 3.9.0 unavailable on macOS, and released 3.9.1 with some mitigations: we don’t offload these computations on macOS, and we only fork when necessary.

The plan for the next release is to stop forking processes on macOS.

The first alpha for Dune 3.10.0 is planned to happen around 2023-07-25.

Here’s the changelog for 3.9.1:

I’m currently reviewing feature requests for the opam repository, and one of the most common ones is for us to support non-OCaml toolchains as dependencies from OCaml packages submitted to our package repository. In recent years, there have been a number of OCaml libraries that depend on Rust, Python or Node, and cannot be easily tested in our automated infrastructure (which currently uses a fixed base image per distribution).

I’ve put together a prototype way we might solve this easily, without taking on the burden of maintaining non-OCaml toolchains ourselves with limited maintainer resources. Opinions and ideas welcome on this thread, and the repository is at: https://github.com/avsm/opam-lang-repo

I’m preparing to release the next semi-annual version of DkML (the MSVC/Windows distribution for OCaml). Among other things new in this version, it has been completely decoupled from the deprecated fdopen repository (thanks @fdopen for doing it for so long!). And from my perspective Windows looks good for OCaml going forward:

• opam 2.2 will be able to stand up a Cygwin / OCaml compiler from the main opam repository
• opam CI + repository are getting mechanisms so that the number of safe-for-Windows packages should grow over time
• OCaml 5 will be getting full MinGW (GCC) and then MSVC support
• Many many packages have accepted MSVC patches

There is one structural problem with DkML … it is tightly coupled to my company (Diskuv) and that is not healthy. In particular, seemingly minor decisions on my part (ex. sticking with OCaml 4 for the foreseeable future) have a large blast radius on the OCaml community.

Are there any Windows users who want to use MSVC + OCaml 5 on a daily basis, and who are also willing to maintain the OCaml 5 part of the distribution? The DkML distribution will still be actively developed (ie. the repository, installer, ease-of-use shims, hosting, testing, and release system), so your maintenance responsibilities should not be excessive. If so, please contact me in the next few days so you can see what goes into the release process.