OCaml Weekly News

This is some early work using zig as a cross-compiler for building OCaml cross-compilation systems:

opam-cross-lambda

Status: It is currently severely untested but the aim is to be able to cross-compile to Linux from Windows/Mac/Linux for aarch64 and x86_64 CPU architectures simply by adding an opam repository, and without the need for nix.

Why: The novel aspect is zig, which allows you to cross-compile C code without needing to install or set up a cross-compilation sysroot i.e. glibc, gcc, binutils, kernel headers etc. as zig packages much of the needed headers and symbol information internally.

Next steps: start importing packages (including those with native binaries) into the opam repository overlay, validate them in CI/CD

This approach has led me down some rabbit-holes with a bunch of learning - some interesting points:

• zig uses clang internally, so its effectively testing clang compatibility with OCaml's autoconf + Makefile assumptions about the C compiler
• targeting windows isn't possible with this setup at this time, because flexdll hardcodes mingw binary names (e.g. x86_64-w64-mingw32-gcc) in its Makefile and the flexlink binary (it assumes these exist because targeting mingw32 is always a cross-compilation, even on Windows). It also depends on binutils' windres, which zig does not provide a wrapper for.
• targeting macos x is untested
• as you can see in the CI/CD scripts, setting the ZIG cache directory environment variables is crucial for MacOS because of opam's sandboxing (zig builds its cache in the user's home directory, which is outside the default sandbox)
• although ocamlfind and dune have some cross-compilation support with "toolchains", there are gaps and undocumented assumption
• opam doesn't really support cross-compilation environments well - packages often don't require much change, but you do need to create a <package>-cross-<cross-name> version of every single package - this could be a lot more straightforward and less work with a more cohesive platform strategy for cross-compilation

Alternatives: I'm aware of alternatives in the ecosystem (and indeed have benefitted from):

• ocaml nix overlays - these offer a far better tested and reproducible cross-compilation environment, mostly for systems that can run nix
• opam-cross-windows - lots of little nuggets of build-time information found in here

Thanks everyone for joining! The meetings notes are here: https://github.com/ocaml/dune/wiki/dev-meeting-2025-02-19

Hi everyone!

Once again, the OCaml community has signed up to Outreachy (see past posts)!

Outreachy is a paid, remote internship program. Outreachy promotes diversity in open source and open science. Our internships are for people who face under-representation, and discrimination or systemic bias in the technology industry of their country.

The current round is still ongoing with an intern making great progress on ocaml-api-watch with @NathanReb and @panglesd.

I’m pleased to announce the joint release of js_of_ocaml 6.0.1 and wasm_of_ocaml.

Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js.

Wasm_of_ocaml is a compiler from OCaml bytecode to WebAssembly. It is highly compatible with Js_of_ocaml, so you can compile your programs with wasm_of_ocaml instead of js_of_ocaml and experience overall better performance. It is supported by Dune 3.17, making the switch very easy.

Most significant changes in js_of_ocaml:

• The conversion between Javascript numbers and OCaml floats is now explicit, using functions Js.float and Js.to_float (this is necessary for wasm_of_ocaml which does not use the same representation for JS numbers and OCaml floats)
• Dom_html has been modernized, removing some no longer relevant Js.optdef type annotations
• Effects:
  • add an optional feature of "dynamic switching" between CPS and direct style, resulting in better performance when no effect handler is installed
  • make resuming a continuation more efficient

See the Changelog for other changes.

Regarding wasm_of_ocaml, Tarides also just posted a blog post with some more details about its recent developments, and what kind of performance gains have been observed with it.

I want to insist that building your project to Wasm can be as simple as enabling the wasm mode in dune. To quote the documentation page cited by Jérôme:

(executable (name foo) (modes wasm))

And then request the .wasm.js target:

$ dune build ./foo.bc.wasm.js
$ node _build/default/foo.bc.wasm.js
hello from wasm

Today I conducted a small experiment of using a debugger on a small OCaml program (built using dune). The program is not written by me, does non-trivial things, and is written in such a way that my usual approaches to understand what is going on would require more work than I want to pour in it.

I took notes on this experience, in the hope that it could be of interest to others – maybe I'm doing things wrong and people will let me know, maybe this can help identify potential tooling improvements.

Disclaimer: I am a complete beginner as far as running OCaml debuggers goes. (I have used ocamldebug and gdb irregularly in the past, never heaily, and long forgotten how to use them.)

(modes byte exe)

Nice post, thanks !

A few things I would like to add:

• Time travelling is possible for the native debuggers with rr. At some point it was Linux-only, it might still be the case, but it's very nice to use. I have on some occasions debugged bytecode programs by using rr on it, and with the appropriate gdb/lldb macros to print OCaml values it can be useful (but mostly for debugging the C parts; for problems purely on the OCaml side ocamldebug is still better suited). I use it regularly for native debugging and it's very convenient (it can even help with debugging eisenbugs in parallel programs ! Just run rr record ./my_program several times until the bug triggers, and then rr replay will always replay the same run, including thread interleavings, consistently reproducing the bug).
• I have tried time travelling with ocamldebug in the past and I have hit some serious issues: limited history means that you cannot go very far in the past, and the way it works (by setting checkpoints and replaying from the checkpoint to the required instruction) means that you can often see weird artifacts due to C calls being replayed each time you step back, sometimes breaking the program completely. I'm curious to know if this is just bad luck (or me doing weird things), or if you had similar issues too.
• The Dune__exe stuff is, I believe, dune's misguided attempt to shield users from potential conflicts between files linked in the executable and modules with the same name present in non-wrapped libraries required as dependencies. I suspect that (wrapped false) or something like that in the section of the dune file corresponding to the executable will get rid of it.

It is possible to use ocamlearlybird with dap-mode in Emacs link. The setup uses the same json config file as VSCode. I'm putting my effort into DAP support since that gets cross editor support and I can switch between LLDB/ocamlearlybird.

For Emacs the two main options for DAP support are:

• dap-mode, which ties into lsp-mode and follows that style of things. Uses JSON configuration based off VSCode configuration. The UI elements depend on lsp-mode, so it's a heavier setup and might not play as well with eglot.
• dape, standalone DAP mode with a more minimal approach. I didn't get it working satisfactorily but it seems closer to eglot in philosophy https://github.com/svaante/dape

For both I see the challenges are:

1. Setting up DAP itself reliably and with less fuss. It could be smoother and better documented.
2. Setting up dune builds to generate the right artifacts. Having a direct LSP code action to run a debugger against a particular executable like Rust does would be ideal.
3. Bugs in ocamlearlybird and lack of maintainer time.

It's interesting to hear about users of bytecode debugging, I thought there wouldn't be many people using that.

For example some module names show up as Dune__exe.Foo, and I would prefer to see just Foo.

This is controlled by (wrapped_executables <bool>) in dune-project: https://dune.readthedocs.io/en/latest/reference/dune-project/wrapped_executables.html

Hello! It is my pleasure to announce that F* is once again available on opam for direct installation after a long time. This probably does not mean much to regular users, as there were regular releases on GitHub for some time now. However, the opam release offers a convenient alternative by eliminating the need to separately set up OCaml to compile extracted OCaml code.

From the website - F* is a general-purpose proof-oriented programming language, supporting both purely functional and effectful programming. It combines the expressive power of dependent types with proof automation based on SMT solving and tactic-based interactive theorem proving.

The biggest new thing worth mentioning is perhaps the Pulse DSL for programming with concurrent separation logic. A tutorial is available in the F* book, Proof-oriented Programming in F*. A comprehensive overview of various projects that have utilized F* over the years can also be found on the website.

Feel free to join the Zulip forum for discussions with the developers, researchers, and casual users. Happy writing provably correct programs!

Here are links from many OCaml blogs aggregated at the ocaml.org blog.

• How I fixed Slipshow's worst flaw using OCaml and a monad
• The First Wasm_of_ocaml Release is Out!