OCaml Weekly News

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

This alpha introduces a new option to initialise opam on Windows: remove the need of a preexisting Cygwin and propose to install an internal Cygwin install managed by opam.

You’ll find more information in the blog post and a more detailed view in the release note.

As mentioned in the original post, that was a preview for a few months. Jan 2022 was long ago, and I didn’t get any feedback that anybody was using it.

Regardless, I rolled up the cross-compiling functionality into the dkml-base-compiler package. But a huge dose of caution … cross-compiling is not officially supported by OCaml! And unlike when I originally wrote the post, I now actively use my non-free DkSDK CMake product because, among other things, it wraps dkml-base-compiler cross-compiling into a “normal” IDE push-button experience (in fact, as we speak I’m helping some high schoolers use Android Studio to cross-compile OCaml into their Android Java app). So if you use dkml-base-compiler for its cross-compiling features, make sure you have intermediate-advanced comfort with the OCaml compiler, and be comfortable with getting your own support.

Here is what you’ll need if you (or anyone searching in the future) are that intermediate-advanced compiler user and want to get dkml-base-compiler working in your environment:

• Make sure you read and understand https://diskuv-ocaml.gitlab.io/distributions/dkml/doc/CompilingInDepth.html. There are sharp edges. If that content is too difficult to follow, you should rethink whether you want to do cross-compilation using dkml-base-compiler directly
• The 1.0 branch of the non-free DkHelloWorld project has which environments can cross-compile. For example, pipeline 873507690 (which will disappear) shows Android and macOS x-compiles. If you are looking at this post in the distant future to see what other environments have been added, try looking for future 1.1 and 2.0 (etc.) branches
• Since I don’t yet synchronize DkML with the central opam repository, build the latest dkml-base-compiler by adding the https://github.com/diskuv/diskuv-opam-repository#readme repository
• The main source code is https://github.com/diskuv/dkml-compiler#readme
• It did (and should) build on all the opam platforms, plus Windows MSVC. But for the dkml-base-compiler package, and many other DkML packages, I don’t try to maintain GitHub Actions / GitLab CI anymore. Doing CI on my internal machines is vastly more efficient, and I can’t justify doing that level of waste.

All the best!

We just released dune 3.9.2. This bugfix-only release contains two platform-specific changes: one fixes the Dune cache on Windows, and the other one completes the fix on Linux when sendfile is not available. This makes Dune available where user directories are encrypted using ecryptfs for example.

I added a few notes on how to try Wasocaml. Don’t expect everything to work now as this was indeed a quick prototype (more on this below).

The goal of Wasocaml was to convince the Wasm-GC working group of the usefulness of i31ref because we knew it would be needed by OCaml. Without this work they may had been removed from the proposal. We presented the work in January to the working group. In March we also presented this work at the Dagstuhl seminar on the foundations of WebAssemby which was the opportunity to discuss with some active members of the Wasm community such as Andreas Rossberg, Ben Titzer and Conrad Watt. In April, the Guile compiler to Wasm-GC was also presented and it was also using i31ref. Having two languages using i31ref convinced the working group. This is what allows Wasm_of_ocaml to use i31ref today. :slight_smile:

Wasocaml is also the first compiler for a real-world functional languages to Wasm-GC. We developed many strategies for the memory representation of values. For now we only presented two of them (more are coming!) and they should work for other languages/compilers. Wasm_of_ocaml and Guile are using similar techniques to what we presented.

A little bit more about the differences between Wasocaml and Wasm_of_ocaml… First, Wasm_of_ocaml being a tool external to the compiler, it is of course easier to deploy quickly. Wasocaml starts from Flambda and will thus benefit all the optimizations that are missing from the bytecode. Binaryen will be able to recover some performances but it has its limits. Moreover, Wasocaml is going to play nicely with separate compilation. Also, Wasm_of_ocaml is limited in its value representation choice (it must represent blocks as an eqref array) whereas Wasocaml can use more sophisticated representations.

Also note that none of the two are actually usable in a production today. They both depends on many Wasm extenstions (typed function references, GC, tail-call, exception handling, string reference…) that are not yet available in browsers (you can use them in chrome if you turn some experimental flags on).

Alongside all the future works that @lefessan described, I’m also formalizing the compilation of flambda to Wasm-GC with a proper semantics.

On a related note, we indeed implemented Owi, a Wasm interpreter written in OCaml. It was a way to experiment with language extensions. Currently, our main work on the interpreter is to add the possibility to do symbolic execution of Wasm code (aka whitebox fuzzing). This allows to automatically find input values that lead to a crash in the program. The nice thing is that it allows to find bugs in code written in another language and compiled to Wasm (e.g. C).

There’s a new release of Brr and Note.

Brr is an ISC licenced toolkit for programming browsers with the js_of_ocaml compiler. Note is an experimental ISC licensed library for functional reactive programming.

If finally got to split away the Note FRP stuff from Brr. The brr package therefore no longer depends on the note package. If you used the brr.note library it now lives in note.brr. Accordingly the toplevel module names were changed from Brr_note* to Note_brr*.

Among other things, the Brr release also brings a revamped Uri module which was a bit broken. Have a look the release notes before upgrading if you are using it. Thanks to Max Lang for noticing and helping to fix that.

Best,

Daniel

A big thanks to my donators.

Happy to announce a new release of hilite, a small library to perform build-time syntax highlighting of some common (in the OCaml world) programming languages. Hilite performs the syntax highlighting on OCaml.org (see for example https://ocaml.org/docs/lists). It has a useful Hilite.Md.transform function which will rewrite code blocks for you (i.e. transform : Omd.doc -> Omd.doc). I may, in the not too distant future, drop Omd in favour of Cmarkit.

Happy highlighting :camel: :art:

I’d like to announce the first release of htmlit (docs):

Htmlit is an OCaml library providing simple but subtle combinators for generating HTML fragments and pages.

Htmlit is distributed under the ISC license. It has no dependencies.

Install: opam install htmlit (once this PR is merged).

Best,

Daniel

A big thanks to my donators.

How would you compare Htmlit to tyxml,

Htmlit does not try to type your HTML. To get a good compositionality story, it does a few tricks on class and style attribute specifications and supports direct fragment splicing in element childrens.

tyxml tries to type your HTML which I find totally unusable in practice. I tried the tyxml approach during some time in first decade of the century after @thomega came up with the technique twenty years ago.

I moved away from it quite quickly to prefer to treat HTML as an untyped assembly language rather than try to put lipstick on a pig. In my opinion the technique has terrible type and refactoring usability and still doesn’t prevent you of generating invalid HTML (e.g. no guarantee on id uniqueness). Honestly when you are dealing with the web, generating valid HTML is the least of your problem.

what was the motivation for creating Htmlit?

That was a long time ago; the copyright says 2016 but I’m pretty sure I used that in some more primitive form much before. The motivation is in the summary: to have a simple and usable library for generating HTML fragments or pages to send over the wire or store on your file system.

I would like to advertise the release of Forester 2.2.1 on opam, which is an OCaml utility to develop “Forests”, which are densely interlinked mathematical websites / Zettelkästen similar to the Stacks Project or Kerodon. An example of a “Forest” is my own website.

Package: https://opam-5.ocaml.org/packages/forester/

Forester is potentially of technical interest to this community as it makes use of new OCaml 5 features like effect handlers, as well as certain functions from domainslib.

Hi everyone! I’m happy to share updates on new releases of multicore libraries. KC’s blog post provides an excellent overview of the big picture and how the developments in the compiler, libraries and tooling fit together.