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

Alan Schmitt
2025-02-25T10:36:28Z

[-- Attachment #1: Type: text/plain, Size: 25836 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of February 18 to 25,
2025.

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

Early work experimenting with zig as a cross-compiler for OCaml
Dune dev meeting
Outreachy June 2025
Js_of_ocaml 6.0.1 / Wasm_of_ocaml
Bytecode debugging in OCaml 5.3
New F* release on opam (2025.02.17)
Other OCaml News
Old CWN

Early work experimenting with zig as a cross-compiler for OCaml
═══════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/early-work-experimenting-with-zig-as-a-cross-compiler-for-ocaml/16151/1>

Chris Armstrong announced
─────────────────────────

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

[using zig as a cross-compiler]
<https://ruoyusun.com/2022/02/27/zig-cc.html>

[opam-cross-lambda]
<https://github.com/chris-armstrong/opam-cross-lambda>

[ocaml nix overlays] <https://github.com/nix-ocaml/nix-overlays>

[opam-cross-windows]
<https://github.com/ocaml-cross/opam-cross-windows/tree/main/packages>

Dune dev meeting
════════════════

Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/24>

Continuing this thread, art-w announced
───────────────────────────────────────

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

Outreachy June 2025
═══════════════════

Archive: <https://discuss.ocaml.org/t/outreachy-june-2025/16154/1>

Patrick Ferris announced
────────────────────────

Hi everyone!

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

[past] <https://discuss.ocaml.org/t/outreachy-summer-2023/11159>

[posts]
<https://discuss.ocaml.org/t/outreachy-december-2024-round/15223>

What is Outreachy?
──────────────────

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.

[ocaml-api-watch] <https://github.com/ocaml-semver/ocaml-api-watch>

Important Dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

For this next round, the important dates are as follows (these are
always subject to some change):

• Feb 26 - Community sign up deadline :white_check_mark:
• Mar 7 - [Mentor project description deadline]
• Mar 10 to Apr 8 - Contribution period
• Jun 2 to Aug 29 - Internship period

Our next deadline is for mentors to sign up to the OCaml community
with a project idea. Please do consider being an Outreachy mentor. If
you have any questions or ideas you can always reach out to me
directly. If you need a refresher of past projects, there's a
dedicated page on the OCaml website: <https://ocaml.org/outreachy>.

The OCaml community is currently able to financially support Outreachy
internships thanks to the generous support of [Tarides] and
[Janestreet].

Thanks! :camel:

[Mentor project description deadline]
<https://www.outreachy.org/communities/cfp/ocaml/>

[Tarides] <https://tarides.com>

[Janestreet] <https://www.janestreet.com>

Js_of_ocaml 6.0.1 / Wasm_of_ocaml
═════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-js-of-ocaml-6-0-1-wasm-of-ocaml/16160/1>

Jérôme Vouillon announced
─────────────────────────

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.

[Wasm_of_ocaml]
<https://opam.ocaml.org/packages/wasm_of_ocaml-compiler/>

[supported by Dune 3.17]
<https://dune.readthedocs.io/en/stable/wasmoo.html>

[Changelog]
<https://github.com/ocsigen/js_of_ocaml/blob/master/CHANGES.md>

Olivier Nicole then added
─────────────────────────

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
└────

[a blog post]
<https://tarides.com/blog/2025-02-19-the-first-wasm-of-ocaml-release-is-out/>

Bytecode debugging in OCaml 5.3
═══════════════════════════════

Archive:
<https://discuss.ocaml.org/t/bytecode-debugging-in-ocaml-5-3/16177/1>

gasche announced
────────────────

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.)

TL;DR:
╌╌╌╌╌╌

Bytecode debugging with OCaml 5.3 and dune:

• works fine in Emacs/Tuareg, as it did in the past
• works okay in vscode using ocamlearlybird
• could be improved with a bit more targeted work, some of it probably
easy (and some of it hard)

If I understand correctly, no one is specifically working on this
right now. Let me take this occasion to thank the people who
contributed to all these tools (Tuareg, ocamldebug, ocamlearlybird,
vscode+ocaml integration, dune, etc.).

Why a debugger?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

I am looking at an OCaml program that I did not write, and does
interesting and complex things. I would like to build my understanding
of how it works by observing the flow of values in some parts of the
program, on concrete examples of interest.

I am unfamiliar with debuggers and tried other things first:

1. I considered modifying the code to print the values it encouters at
runtime. But the program does not define pretty-printers for its
values, and writing them is cumbersome. (I could probably use
`deriving' to produce debuggers more easily.)

2. My next move is usually `dune utop': instead of running the
program, I can call its library functions via the toplevel on small
examples. But this particular program is only a binary, it was not
split as a library and a binary, and splitting it would be
non-trivial.

When "printf debugging" and "play in the toplevel" are not immediately
within reach, it may be time to try a debugger. They should let us
stop at a given point in the program, print values, and move around in
the execution trace to better understand what is going on.

Running a debugger in general
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

To run a debugger on OCaml programs, one has to choose between a
bytecode debugger, `ocamldebug', and native debuggers such as `gdb'
and `lldb'.

Native debuggers are not OCaml-specific and likely to be better
documented, have more integrated tooling etc., but they are more
low-level and don't know as much about OCaml programs; in particular
they're not so good at printing values.

On the other hand `ocamldebug' can print OCaml values, and it is a
time-travel debugger that supports going backward in time; but it
relies on running the bytecode executable that is probably 10x slower
than the native executable. It is also probably worse when debugging
cross-language programs, for example using the FFI.

I would not try `ocamldebug' to debug performance-sensitive programs,
programs in production, and in particular to debug anything resembling
a segmentation fault. But it should offer a nice experience for
pure-OCaml programs during their development.

The Coq/Rocq maintainers have long been using `ocamldebug' to
understand their software, a large OCaml program with tricky bugs and
non-trivial performance requirements. They rely on specific tooling to
make it nicer – autoloaded scripts, customized pretty-printers. So
there is evidence that `ocamldebug' can work well when integrated
inside a project development workflow. (Here the program I want to
debug has /not/ had any such written, so it will be more barebones.)

Getting a bytecode executable from Dune
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Before going any further, you need to ask `dune' to generate bytecode
executables, by adding

┌────
│ (modes byte exe)
└────

to the `executable' stanza. Then you run `dune build', and when
invoking the debugger you will need to manually pass the path to the
bytecode program, for example `_build/default/bin/main.bc'.

IDE integration
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Running `ocamldebug' directly is doable but not great. Just like it's
nice when IDEs let you jump to the location of a compilation error,
you really want the debugger to show you "where" it is in the program
execution by showing you a program point in your programming
editor. (`ocamldebug' will print the source line where it is at, so
it's not too bad, but still noticeably less pleasant, and typing
movement commands one by one gets old fast.)

I considered two approaches to running a bytecode debugger for OCaml
programs:
• run `ocamldebug' from Emacs/Tuareg
• run `ocamlearlybird' from VsCode

◊ ocamlearlybird in vscode

I first decided to use ocamlearlybird from vscode.

I opened vscode (which is not my usual editor) and tried to use `Run >
start debugging' directly… and it didn't work well. You need to
configure things manually, and the vscode interface did not tell me
that, it would show nothing and appear not to work as expected but
without much help.

The better way to configure vscode+earlybird is to… read the
documentation first. I recommend:

1. Read the [vscode-ocaml-platform README.md] about how to setup
things.
2. then read the [ocamlearlybird README] (which also links to the
README above), in particular watch the short demo, to know what to
expect when the interface works. The README documents the field of
the `launch.json' file that you have to write to describe how to
invoke the debugger, and this is helpful.

After reading this, I knew how to tweak the `launch.json' file so that
the debugger would pass command-line arguments to the program, and it
started working correctly.

Unfortunately `ocamlearlybird' does not current support time-travel
([issue]), so it is only possible to stop at breakpoints and move
forward in time, while I was expecting to run until a failure and then
go backward in time, as I usually do with `ocamldebug'. At this point
I decided to go back to my familiar Emacs.

[vscode-ocaml-platform README.md]
<https://github.com/ocamllabs/vscode-ocaml-platform#debugging-ocaml-programs-experimental>

[ocamlearlybird README]
<https://github.com/hackwaly/ocamlearlybird?tab=readme-ov-file>

[issue] <https://github.com/hackwaly/ocamlearlybird/issues/78>

◊ Points to improve

When trying to "run the debugger" without having configured a
specific bytecode program, the vscode UI appears to work but does
nothing. For example it is possible to add breakpoints, etc., and
then clicking "run" does nothing that I can see.

I wish there was clearer feedback when things are not setup and
there is no chance that it will work. This would also be a good time
to point me to the online documentation – from within the IDE – so
that the process is more discoverable.

◊ ocamldebug in Emacs

At this point I had already set things up to build a bytecode
executable in Dune, so things were easy: `M-x ocamldebug' and there
you go. There is [documentation in the user manual], which was
probably written more than a decade ago, and it mostly reads just fine
today.

(Note: some of the documented keybindings do not work: `C-c C-k' is
documented as stepping back in the manual, but it is not supported by
Tuareg ([issue]).)

Moving around program execution is fun, printing values works okay –
the next step for convenience would be to install custom printers to
get nice output.

[documentation in the user manual]
<https://ocaml.org/manual/5.3/debugger.html>

[issue] <https://github.com/ocaml/tuareg/pull/227>

◊ Points to improve

1. Emacs jumps to source code to follow the program execution in the
debugger; but on every movement in the execution trace it asks me
again whether I want `src/foo.ml' instead of
`_build/default/src/foo.ml', and this is annoying. (Sometimes I
did not observe this behavior, not sure why.)

2. Dune includes various wrapping/mangling of module names that show
up in the `ocamldebug' printing, and can be annoying at time. For
example some module names show up as `Dune__exe.Foo', and I would
prefer to see just `Foo'. I think it should be possible to
hard-code some more de-Dune-mangling logic in the debugger's
pretty-printer, and ideally we could even make them
user-configurable or dune-configurable a bit.

3. If I print an AST from an execution point that does not have
`open Ast' in its typing environment, the AST is printed like
`Dune__exe.Ast.Let (Dune__exe.Ast.Var "x", ...)'. It would be
nice to omit the `Dunne__exe' part, but ideally I should also be
able to tell the debugger: "let's open `Ast' locally from now on
when you print values", so that it prints in a more readable way
by default.

Vincent Laviron replied
───────────────────────

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.

Tim McGilchrist also replied
────────────────────────────

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.

[link]
<https://lambdafoo.com/posts/2024-03-25-ocaml-debugging-with-emacs.html>

Nicolas Ojeda Bar also replied
──────────────────────────────

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>

New F* release on opam (2025.02.17)
═══════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/ann-new-f-release-on-opam-2025-02-17/16179/1>

Chandradeep Dey announced
─────────────────────────

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!

[website] <https://fstar-lang.org/>

[Zulip forum] <https://fstar.zulipchat.com/>

Other OCaml News
════════════════

>From the ocaml.org blog
───────────────────────

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!]

[the ocaml.org blog] <https://ocaml.org/blog/>

[How I fixed Slipshow's worst flaw using OCaml and a monad]
<https://choum.net/panglesd/undo-monad/#step2torevisit>

[The First Wasm_of_ocaml Release is Out!]
<https://tarides.com/blog/2025-02-19-the-first-wasm-of-ocaml-release-is-out>

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
to the [caml-list].

[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>

[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>

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

[-- Attachment #2: Type: text/html, Size: 38002 bytes --]