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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

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