OCaml's Avatar

OCaml

@ocaml.org.bsky.social

https://ocaml.org

1,180 Followers  |  15 Following  |  289 Posts  |  Joined: 07.02.2024  |  2.0577

Latest posts by ocaml.org on Bluesky

Preview
Upcoming OCaml Events * OCaml Users and Developers Workshop 2025 // Singapore, Singapore // Oct 17, 2025

#OCaml #OCamlPlanet

01.08.2025 14:38 — 👍 0    🔁 0    💬 0    📌 0
OCaml Weekly News, 29 Jul 2025 * opam 2.4.1 * new tools to keep your projects clean (after AI, or just after yourself) * First beta release for OCaml 5.4.0 * Encoding SAT in OCaml GADTs * Other OCaml News

#OCaml #OCamlPlanet

30.07.2025 18:35 — 👍 0    🔁 0    💬 0    📌 0
Adventures with BuildKit I’ve been doing battle the last few days with Docker, and in particular trying to persuade BuildKit to do what I wanted. I find Docker leans towards being a deployment tool, rather than a development tool which is to say that it’s exceedingly useful for both, but when I encounter problems trying to persuade it to do what I’m after for development, it tends to feel I’m not using it for the purpose for which it was intended. Anyway, maybe documenting the journey will reveal how much of this view is my own ignorance and it will definitely consolidate a few useful tricks in one place ready for next time. Docker shines when I’m at the stage of needing to test multiple configurations or versions of what I’m doing against one bit of code that I’m working on. Its multi-stage builds provide a very convenient and tidy way to fan out a single build tree into multiple configurations (versus, say, using multiple worktrees, etc.) and the BuildKit backend adds parallelism. Couple of that with an unnecessarily large number of CPU cores, more RAM than existed in the world when I was a child, and many terrabytes of cache, and you’re sorted! I’ve been working on meta-programming the installation targets for OCaml’s build system to allow them to do things other than simply installing OCaml (generating opam .install files, cloning scripts and so forth). The commit series for that got plugged into the branch set for Relocatable OCaml and fairly painlessly backported. It’s all GNU make macros and so forth - no type system helping and various bits that have shifted around over the past few releases. I’d devised a series of manual tests for the branch against trunk OCaml, a little bit of glue to generate a Dockerfile, and the testing against the backports could be automated. Our base images are a useful starting point: FROM ocaml/opam:ubuntu-24.04-opam AS base RUN sudo apt-get update && sudo apt-get install -y gawk autoconf2.69 RUN sudo apt-get install -y vim ENV OPAMYES="1" OCAMLCONFIRMLEVEL="unsafe-yes" OPAMPRECISETRACKING="1" RUN sudo ln -f /usr/bin/opam-2.3 /usr/bin/opam && opam update RUN git clone https://github.com/dra27/ocaml.git WORKDIR ocaml That sets up an image we can then use as a fanout for running the actual tests, which is then a whole series of (generated) fragments. The first bit sets up the compiler before my changes: FROM base AS test-4.14-relocatable RUN git checkout 32d46126b2b993a7ac526a339c85d528d3a280cd || git fetch origin && git checkout 32d46126b2b993a7ac526a339c85d528d3a280cd RUN ./configure -C --prefix $PWD/_opam --docdir $PWD/_opam/doc/ocaml --enable-native-toplevel --with-relative-libdir=../lib/ocaml --enable-runtime-search=always --enable-runtime-search-target RUN make -j RUN make install RUN mv _opam _opam.ref The git checkout foo || git fetch origin && git checkout foo is a neat little bit of Docker fu: first try to checkout the commit you need and only if that fails do a Git pull. That means that if something gets changed while developing, only the containers which need to pull will do so, preserving caching (if we re-did the clone in base, it’d invalidate all the builds so far). Then it actually does the battery of tests: RUN git checkout e1794e2548a1e8f6dc11841b0ac9ad159ca89988 || git fetch origin && git checkout e1794e2548a1e8f6dc11841b0ac9ad159ca89988 RUN make install && diff -Nrq _opam _opam.ref && rm -rf _opam RUN git checkout 86ecf4399873045d7eca03560d9ac84eebae38e8 || git fetch origin && git checkout 86ecf4399873045d7eca03560d9ac84eebae38e8 RUN if grep ... RUN if test -n ... RUN git checkout 671122db576cb0e6531cf1fa3b18af225f840c36 || git fetch origin && git checkout 671122db576cb0e6531cf1fa3b18af225f840c36 RUN if grep '^ROOTDIR *=' * -rIl ... RUN git checkout fbf12456dd47d758d1858bd6edf8dd3310a7ca3b || git fetch origin && git checkout fbf12456dd47d758d1858bd6edf8dd3310a7ca3b RUN if grep 'INSTALL_\(DATA\|PROG\)' ... RUN make install && diff -Nrq _opam _opam.ref && rm -rf _opam RUN if test -n "$(make INSTALL_MODE=list ... RUN make INSTALL_MODE=display install RUN make INSTALL_MODE=opam OPAM_PACKAGE_NAME=ocaml-variants install RUN make INSTALL_MODE=clone OPAM_PACKAGE_NAME=ocaml-variants install RUN test ! -d _opam RUN opam switch create . --empty && opam pin add --no-action --kind=path ocaml-variants . RUN opam install ocaml-variants --assume-built The nifty part is that if one individual branch needed tweaking, the script to generate the Dockerfile puts the new commit shas in there and BuildKit then rebuilds just the parts needed. The whole thing then just needs tying together with something that forces the builds to be “necessary”: FROM base AS collect WORKDIR /home/opam COPY --from=test-4.08-vanilla /home/opam/ocaml/config.cache cache-4.08-vanilla COPY --from=test-4.08-relocatable /home/opam/ocaml/config.cache cache-4.08-relocatable COPY --from=test-4.09-vanilla /home/opam/ocaml/config.cache cache-4.09-vanilla COPY --from=test-4.09-relocatable /home/opam/ocaml/config.cache cache-4.09-relocatable COPY --from=test-4.10-vanilla /home/opam/ocaml/config.cache cache-4.10-vanilla COPY --from=test-4.10-relocatable /home/opam/ocaml/config.cache cache-4.10-relocatable ... COPY --from=test-5.2-relocatable /home/opam/ocaml/config.cache cache-5.2-relocatable COPY --from=test-5.3-vanilla /home/opam/ocaml/config.cache cache-5.3-vanilla COPY --from=test-5.3-relocatable /home/opam/ocaml/config.cache cache-5.3-relocatable COPY --from=test-5.4-vanilla /home/opam/ocaml/config.cache cache-5.4-vanilla COPY --from=test-5.4-relocatable /home/opam/ocaml/config.cache cache-5.4-relocatable COPY --from=test-trunk-vanilla /home/opam/ocaml/config.cache cache-trunk-vanilla COPY --from=test-trunk-relocatable /home/opam/ocaml/config.cache cache-trunk-relocatable The purpose of that last step is just to extract something from all the other containers to force them to be built. It worked really nicely, the testing identified a few slips here and there with the commit series, and it was very efficient to re-test it after any tweaks. So… having got that working, I wanted to make sure that changes I’d made to the monster script that reconstitutes Relocatable OCaml back at the beginning of the month were working on all of the older lock files. Partly because things should be always be reproducible, but also because I have needed to go back to older iterations of Relocatable OCaml, I added a lockfile system to it last year. For example, ef758648dd describes the exact branches which contributed to the OCaml Workshop 2022 talk on Relocatable OCaml. It takes a list of branch commands: fix-autogen@4.08 6b37fcefa88a21f5972ca64e1af89e060df6a83c fcommon@4.08 2c36ba5c19967b69c879bc0a9f5336886eb8df6b sigaltstack 044768019090c2aeeb02b4d0fb4ddf13d75be8c6 sigaltstack-4.09@fixup 8302a9cd4f931f232e40078048d02d35a7075f05 fix-4.09.1-configure@4.09 7e1f5a33e0cdd3f051a5c5ab76f1d097270e232e install-bytecode@4.08 1287da77f952166e1c60d93da0e756b2ba7d33b7 win-reconfigure@4.08 162af3f1ff477a6a0e34816fe855ef474c07b273 mingw-headers@4.09 78e3c94924b07ff2941a6313b35fca8bd0fc7ce1 makefile-tweaks@4.09 6a2af5c14176e06275ff4da7dc6a14fd4f49093a static-libgcc@4.11 260ec0f27682822f255f8cf64cf4e4faa6fa8088 config.guess@4.11 7efc39d9bcb943375c35dd024c60e21c8fecda6a config.guess-4.09@4.09 185183104b4d559eb5f24fc1d0d2531976f1ee0e fix-binutils-2.36@4.11 5b1560952044faee8b2502b3595c0598e7402513 fix-mingw-lld@4.11 5443fec22245ff37fda7e2ce8ad554daf11fa0df ... and crunches that to produce a commit series for each required version: backport-5.0 b5c11faed67511e25a2ee9cac953362b6b165a37 backport-4.14 0598df18732107619f4d500f9c372e648b6c0174 backport-4.13 f2cd54453f7c4684af8fdb2c2c1d4b14119d077f backport-4.12 de72889271d8875589a0e9690ab220f9ffcc4eb1 backport-4.11 a15f4a165ae27929fec94e05b65257126883eafd backport-4.10 e95093194d0ec378de3d86033bd011b3d8cb7eb2 backport-4.09 4ee19334d40a5a5c0a69de53a8e77eb3f6fc5829 backport-4.08 52ec6c2f54e9d8c0fb950e7b4a2016ec9a624756 Now, it should always be possible to build a given lock with the stack script from the date it was made, but it’s actually more useful to be able to build it with the latest one - the problem is that occasionally things go wrong. So… I have a Dockerfile a la the one above which tests whether each lock is still buildable. So, what I’d hoped was going to work was to put each lock in an image, just like with the testing, build it with a “known good” version of the script, then add additional RUN lines to each of the images to use a newer version of the stack script and then debug as I went, being able to take advantage of the bootstrap caching from the previous stages so that it wouldn’t be tortuously slow. Docker seemed to have other ideas, though. I guess because there were so many artefacts flying around, some of those intermediate layers were being evicted from the cache. I tried cranking up builder.gc.defaultKeepStorage, but to no avail. I switched to the containerd imagge storage backend and tried using --cache-to, which allows cranking the cache aggressiveness with mode=max. That seemed to work, but at the cost of waiting ages at the end of each build for all the intermediate to be exported. I’d just about given up, but then I had an idea to turn the problem on its HEAD: instead of fighting Docker and trying to convince it that all these intermediate builds were precious, how about making it that the final container (the “collect” bit) actually contained all the artefacts? In this case, the most “precious” artefact that’s wanted is any bootstraps of OCaml done as part of the commit series - they’re computationally expensive to perform, and the stack script already has a trick where it scours the reflog looking for previous instances of the same bootstrap. The base stage is similar to the previous test - but before fanning out, this time another builder stage is added: FROM base AS builder RUN relocatable/.git/modules/ocaml/logs/HEAD && rm -f HEAD COPY

#OCaml #OCamlPlanet

30.07.2025 14:37 — 👍 1    🔁 0    💬 0    📌 0
Conference slide for FUNOCaml 2025 event in Warsaw, Poland on September 15-16. Features a circular photo of Leandro Ostera, a man with curly hair wearing a gray t-shirt, smiling outdoors. The slide announces his talk titled 'State of the OCaml Ecosystem 2025' with description: 'This talk breaks down how the OCaml ecosystem is actually growing by digging into real GitHub data - repo activity, contributor trends, and which libraries are gaining traction. We'll look at the numbers behind OCaml's momentum and what they tell us about where the community and tooling are headed in 2025.'

Conference slide for FUNOCaml 2025 event in Warsaw, Poland on September 15-16. Features a circular photo of Leandro Ostera, a man with curly hair wearing a gray t-shirt, smiling outdoors. The slide announces his talk titled 'State of the OCaml Ecosystem 2025' with description: 'This talk breaks down how the OCaml ecosystem is actually growing by digging into real GitHub data - repo activity, contributor trends, and which libraries are gaining traction. We'll look at the numbers behind OCaml's momentum and what they tell us about where the community and tooling are headed in 2025.'

🐫 Don't miss Leandro Ostera at FUN OCaml 2025 in Warsaw, Sept 15-16!

"State of the OCaml Ecosystem 2025" digs into real GitHub data - repo activity, contributor trends, and which libraries are gaining traction.

See the numbers behind OCaml's momentum and where it's headed.

28.07.2025 11:39 — 👍 15    🔁 6    💬 1    📌 1

we still have free tickets for on-site FUN OCaml 2025 in Warsaw, btw

hurry up and plan your travels!

fun-ocaml.com

28.07.2025 09:52 — 👍 6    🔁 2    💬 0    📌 0
Conference slide for FUNOCaml 2025, September 15-16 in Warsaw, Poland. Shows a talk titled 'Cross-Platform OCaml Projects' by Manas Jayanth, with a pixelated profile photo. The description reads: 'OCaml's ecosystem includes many platform-specific packages that can break portability when transitive dependencies won't work across different operating systems. Manas Yayanth explains how they implemented portable lock files for esy (the Reason/OCaml package manager), ensuring projects can be built cross-platform

Conference slide for FUNOCaml 2025, September 15-16 in Warsaw, Poland. Shows a talk titled 'Cross-Platform OCaml Projects' by Manas Jayanth, with a pixelated profile photo. The description reads: 'OCaml's ecosystem includes many platform-specific packages that can break portability when transitive dependencies won't work across different operating systems. Manas Yayanth explains how they implemented portable lock files for esy (the Reason/OCaml package manager), ensuring projects can be built cross-platform

🚀 Manas Jayanth is presenting "Cross-Platform OCaml Projects" at FUNOCaml 2025 in Warsaw!

They'll share how they implemented portable lock files for esy (Reason/OCaml package manager) to achieve reproducible builds across different operating systems.

📅 Sept 15-16, Warsaw

28.07.2025 11:43 — 👍 4    🔁 3    💬 1    📌 0
Conference slide for FUNOCaml 2025 workshop in Warsaw, Poland on September 15-16. Features a circular photo of presenter Nicolás Ojeda Bär, a smiling man with brown hair wearing a blue shirt. The workshop is titled "Hacking the OCaml Compiler to Add Type Reflection" and describes how LexiFi maintains a powerful fork of the OCaml compiler with type reflection capabilities as an alternative to PPX. The workshop offers hands-on experience implementing a toy version of type reflection in the compiler, serving as both an introduction to the technique and a "compiler hacking 101" experience for those interested in contributing to OCaml's development

Conference slide for FUNOCaml 2025 workshop in Warsaw, Poland on September 15-16. Features a circular photo of presenter Nicolás Ojeda Bär, a smiling man with brown hair wearing a blue shirt. The workshop is titled "Hacking the OCaml Compiler to Add Type Reflection" and describes how LexiFi maintains a powerful fork of the OCaml compiler with type reflection capabilities as an alternative to PPX. The workshop offers hands-on experience implementing a toy version of type reflection in the compiler, serving as both an introduction to the technique and a "compiler hacking 101" experience for those interested in contributing to OCaml's development

🚀 Ready to hack the OCaml compiler?

Join Nicolás Ojeda Bär from LexiFi at FUNOCaml 2025 for "Hacking the OCaml Compiler to Add Type Reflection" - a hands-on workshop where you'll implement type reflection as an alternative to PPX.

📅 Sept 15-16, Warsaw
🔧 Compiler hacking 101

#OCaml #FUNOCaml2025

28.07.2025 11:46 — 👍 5    🔁 2    💬 1    📌 0
Preview
Add Your Own Recipes to the OCaml Cookbook! Are you looking to learn something new about OCaml? Or do you want to contribute to the community in a new way? OCaml.org hosts the OCaml Cookbook, a collection of projects that users can try out, as well as contribute new ones for others to enjoy. This post will introduce you to the concept, show you how to add new recipes, and hopefully leave you inspired to check it out for yourself! Why do We Care About OCaml.org? Tarides supports the maintenance and development of OCaml.org, OCaml’s home on the web. Our engineers have spent significant time collaborating with all corners of the OCaml community to update the website, including improving the design, accessibility, documentation, and much more. We continue to fund projects that implement new features that the OCaml community wants and maintain others that they have come to rely on. As an open-source, collaborative, and shared resource for the ecosystem, OCaml.org is truly a public common. The OCaml Cookbooks are just one example of its many features, which also include tutorials, documentation, news, and an OCaml playground. We encourage more contributors, from sponsors to maintainers, to join the many others in supporting this important resource. What is the OCaml Cookbook? The OCaml Cookbook is a collection of ‘recipes’, instructions on how to complete tasks as part of projects using open source libraries and tools. The same task can have multiple recipes, each with its unique combination of resources. The result is a varied collection of projects that help users adopt new techniques, try new tools, and gain confidence in OCaml. OCaml’s book currently has recipes on compression, single-threaded concurrency, cryptography, and more! OCaml is far from the only language to have a cookbook, and the team was inspired to create one by the popular Rust Cookbook, as well as Go’s Go by Example introduction to the language. How to Contribute The team behind the cookbook are always looking for new contributions, and creating a new recipe is straightforward if you follow the contributing instructions. To add a new recipe to the cookbook, you will need to start by finding the OCaml.org repo on GitHub. To add a recipe to an existing task, find the task in the data/cookbook/tasks.yml section, go to the task’s folder inside data/cookbook/ which will have the same name as the task’s slug, and create an .ml file with the recipe and a YAML header with metadata about the recipe. If the recipe you want to add doesn’t match an existing task, you will need to create a new task first. To add a task you will need to make an entry in the data/cookbook/tasks.yml file. When adding a new task in this file, the title, description, and slug are mandatory fields to fill in, and the task has to be located under a relevant category. You can even create new categories to organise entire groups of new tasks should you wish to do so. Submitting a recipe will create a pull request, which the group of cookbook moderators will review and, if approved, merge into the website. When picking a recipe to contribute, you should bear the general guidelines in mind: choose a task that you think is relevant to a wide audience; write correct, clear, code that compiles without errors; and check that the packages you’ve chosen and the code are ready for use in production. That’s it, you’re ready to publish! What Does a Recipe Look Like? Let’s take a quick look at a recipe in action. The Salt and Hash a Password with Argon2 recipe in the Cryptography section shows you how to use the opam package argon2 to configure password hashing based on OWASP recommendations and Argon2 defaults. Be sure to check out the recipe on OCaml.org for the full context and nice formatting! The recipe includes the code snippets for the configuration: let t_cost = 2 and m_cost = 65536 and parallelism = 1 and hash_len = 32 and salt_len = 10 The hash output length: let encoded_len = Argon2.encoded_len ~t_cost ~m_cost ~parallelism ~salt_len ~hash_len ~kind:ID Generating a salt string: let gen_salt len = let rand_char _ = 65 + (Random.int 26) |> char_of_int in String.init len rand_char Returning an encoded hash string for the given password: let hash_password passwd = Result.map Argon2.ID.encoded_to_string (Argon2.ID.hash_encoded ~t_cost ~m_cost ~parallelism ~hash_len ~encoded_len ~pwd:passwd ~salt:(gen_salt salt_len)) And finally, verifying if the encoded hash string matches the given password: let verify encoded_hash pwd = match Argon2.verify ~encoded:encoded_hash ~pwd ~kind:ID with | Ok true_or_false -> true_or_false | Error VERIFY_MISMATCH -> false | Error e -> raise (Failure (Argon2.ErrorCodes.message e)) let () = let hashed_pwd = Result.get_ok (hash_password "my insecure password") in Printf.printf "Hashed password: %s\n" hashed_pwd; let fst_attempt = "my secure password" in Printf.printf "'%s' is correct? %B\n" fst_attempt (verify hashed_pwd fst_attempt); let snd_attempt = "my insecure password" in Printf.printf "'%s' is correct? %B\n" snd_attempt (verify hashed_pwd snd_attempt) Contribute to the CookBook! We invite you to take a look at the existing recipes up on the website and bring your own contributions to the book. If you have questions or want input on a recipe, OCaml’s Discuss forum is a great place to post to get tips and feedback. Stay in touch with Tarides on Bluesky, Mastodon, Threads, and LinkedIn. We look forward to hearing from you!

#OCaml #OCamlPlanet

26.07.2025 14:38 — 👍 1    🔁 0    💬 0    📌 0
The Saga of Multicore OCaml Jane Street is an electronic trading firm that uses low latency trading systems built in OCaml to provide liquidity to financial markets worldwide. In December 2022, after nearly a decade of development, OCaml 5.0 was released with OCaml’s first multi-core capable runtime. This was an exciting milestone, finally making it possible to write shared-memory parallel programs in OCaml. The new runtime was designed to be easy to adopt: it didn’t disturb OCaml’s FFI, and performance was meant to be only a few percentage points slower in single-core mode. Despite those promising beginnings, switching to runtime-5 within Jane Street was harder than we expected. Indeed, we've only just switched to it this year, after 2.5 years of research and engineering effort. This talk will give an overview of the problems we ran into, and what we learned from the process, including some new ideas that solved some very old problems in the design of OCaml's GC. See other Tech Talks here: https://www.janestreet.com/tech-talks/index.html

#OCaml #OCamlPlanet

25.07.2025 14:37 — 👍 0    🔁 0    💬 0    📌 0
Preview
opam 2.4 release Feedback on this post is welcomed on Discuss! We are extremely happy to announce the release of opam 2.4.0 and encourage all users to upgrade. Please read on for installation and upgrade instructions. Major changes * On opam init the compiler chosen for the default switch will no longer be ocaml-system (#3509) This was done because the system compiler (as-is your ocaml installed system wide, e.g. /usr/bin/ocaml) is known to be under-tested and prone to a variety of bugs and configuration issues. Removing it from the default compiler allows new-comers a more smooth experience. Note: if you wish to use it anyway, you are always able to do it explicitly using opam init --compiler=ocaml-system * GNU patch and the diff command are no longer runtime dependencies. Instead the OCaml patch library is used (#6019, #6052, #3782, ocaml/setup-ocaml#933) Doing this we've removed some rarely used features of GNU Patch such as the support of Context diffs. The new implementation only supports Unified diffs including the git extended headers, however file permission changes via said extended headers have no effect. * Add Nix support for external dependencies (depexts) by adding support for stateless package managers (#5982). Thanks to @RyanGibb for this contribution * Fix opam install with and without options like --deps-only or --show-action having unexpected behaviours (#6248, #5567) such as: * reporting Nothing to do despite dependencies or package not being up-to-date * asking to install the wrong dependencies UI changes * opam show now displays the version number of packages flagged with avoid-version/deprecated gray (#6354) * opam upgrade: Do not show the message about packages "not up-to-date" when the package is tagged with avoid-version/deprecated (#6271) * Fail when trying to pin a package whose definition could not be found instead of forcing interactive edition (e.g. this could happen when making a typo in the package name of a pin-depends) (#6322) New commands / options * Add opam admin compare-versions to compare package versions for sanity checks. Thanks to @mbarbin for this contribution * Add opam lock --keep-local to keep local pins url in pin-depends field (#4897) * Add opam admin migrate-extrafiles which moves all extra-files of an existing opam repository into extra-sources. Thanks to @hannesm for this contribution * The -i/--ignore-test-doc argument has been removed from opam admin check (#6335) Other noteworthy changes * opam pin/opam pin list now displays the current revision of a pinned repository in a new column. Thanks to @desumn for this contribution * Symlinks in repositories are no longer supported (#5892) * Fix sandboxing support in NixOS (#6333) * Add the OPAMSOLVERTOLERANCE environment variable to allow users to fix solver timeouts for good (#3230) * Fix a regression on opam upgrade upgrading unrelated packages (#6373). Thanks to @AltGr for this contribution * Fix pin-depends for with-* dependencies when creating a lock file (#5428) * opam admin check now sets with-test and with-doc to false instead of true * Add apt-rpm/ALTLinux family support for depexts. Thanks to @RiderALT for this contribution * Fix the detection of installed external packages on OpenBSD to not just consider manually installed packages (#6362). Thanks to @semarie for this contribution * Disable the detection of available system packages on SUSE-based distributions (#6426) ystem,dune,beginner,dev,new project Changes * opam switch create [name] will not include compiler packages flagged with avoid-version/deprecated in the generated invariant anymore (#6494). This will allow opam to avoid the use of the ocaml-system package unless actually explicitly requested by the user. The opam experience when the ocaml-system compiler is used is known to be prone to a variety of bugs and configuration issues. * Cygwin: Fallback to the existing setup-x86_64.exe if its upgrade failed to be fetched (#6495, partial fix for #6474) * Fix a memory leak happening when running large numbers of commands or opening large number of opam files (#6484). Thanks to @hannesm for this contribution * Remove handling of the OPAMSTATS environment variable (#6485). Thanks to @hannesm for this contribution Changes * Fixed some bugs in opam install --deps-only (and other commands simulating package pins, such as --depext-only) more visible in 2.4: * When a package pkg is already installed and opam install ./pkg --deps is called, if there is a conflict between the installed pkg dependencies and the definition of the local pkg, the conflict was not seen and the already installed pkg was kept (#6529) * No longer fetch and write the sources when simulating packages that were already pinned (#6532) * opam was triggering the reinstall of the package based on the already pinned packages instead of the expected newly simulated pinned packages (#6501) * opam was using the opam description of the wrong package in some cases (#6535) * Change the behaviour of --deps-only, where it no longer requires unicity of package version between the request and the installed packages. In other words, if you have pkg.1 installed, installing dependencies of pkg.2 no longer removes pkg.1. This also allows to install dependencies of conflicting packages when their dependencies are compliant. (#6520) Windows binary * Improve the prebuilt Windows binaries by including Cygwin's setup-x86_64.exe in the binary itself as fallback, in case cygwin.com is inaccessible (#6538) NOTE: this article is cross-posted on opam.ocaml.org and ocamlpro.com.

#OCaml #OCamlPlanet

24.07.2025 14:37 — 👍 1    🔁 0    💬 0    📌 0
OCaml Weekly News, 22 Jul 2025 * Third outreachy internship blog * opam 2.4.0 is out! * x-ocaml, notebooks as a webcomponent * Dune dev meeting * Lwt.6.0.0~alpha (direct-style) * Other OCaml News

#OCaml #OCamlPlanet

23.07.2025 14:37 — 👍 0    🔁 0    💬 0    📌 0
Preview
Upcoming OCaml Events * OCaml Users and Developers Workshop 2025 // Singapore, Singapore // Oct 17, 2025

#OCaml #OCamlPlanet

22.07.2025 14:38 — 👍 0    🔁 0    💬 0    📌 0
Preview
Learning OCaml: Having Fun with the Fun Module When I started to play with OCaml I was kind of surprised that there was no id (identity) function that was available out-of-box (in Stdlib module, that’s auto-opened). A quick search lead me to the Fun module, which is part of the standard library and is nested under Stdlib. It was introduced in OCaml 4.08, alongside other modules such as Int, Result and Option.1 The Fun module provides a few basic combinators for working with functions. Let’s go over them briefly: * Fun.id Fun.id : 'a -> 'a The identity function: returns its single argument unchanged. * Fun.const Fun.const : 'a -> 'b -> 'a Returns a function that always returns the first argument, ignoring its second argument. * Fun.compose Fun.compose : ('b -> 'c) -> ('a -> 'b) -> 'a -> 'c Composes two functions, applying the second function to the result of the first. Haskell and F# have special syntax for function composition, but that’s not the case in OCaml. (although you can easily map this to some operator if you wish to do so) Also, compose introduced a bit later than the other functions in the module - namely in OCaml 5.2. * Fun.flip Fun.flip : ('a -> 'b -> 'c) -> 'b -> 'a -> 'c Reverses the order of arguments to a two-argument function. * Fun.negate Fun.negate : ('a -> bool) -> 'a -> bool Negates a boolean-returning function, returning the opposite boolean value. Useful when you want to provide a pair of inverse predicates (e.g. is_positive and is_negative) I believe that those functions are pretty self-explanatory, but still below we’ll go over a few examples of using them: (* Fun.id *) Fun.id 42 (* 42 *) (* Fun.const ) let always_hello = Fun.const "hello" always_hello 12345 ( "hello" *) (* Fun.flip ) let subtract a b = a - b let flipped_subtract = Fun.flip subtract flipped_subtract 2 10 ( 8 *) (* Fun.negate ) let is_odd = negate is_even is_odd 5 ( true *) (* Fun.compose ) let comp_f = Fun.compose (fun x -> x x) (fun x -> x + 1) comp_f 5 (* 36 *) Admittedly the examples are not great, but I hope they managed to convey how to use the various combinators. Those are definitely not the type of functions that you would use every day, but they can be useful in certain situations. Obviously I needed id at some point to discover the Fun module in the first place, and all of the functions there can be considered “classic” combinators in functional programming. In practice most often I need id and negate, and infrequently comp and const. Right now I’m struggling to come up with good use-cases for flip, but I’m sure those exist. Perhaps you’ll share some examples in the comments? How often do you use the various combinators? Which ones do you find most useful? I find myself wondering if such fundamental functions shouldn’t have been part of Stdlib module directly, but overall I really like the modular standard library approach that OCaml’s team has been working towards in the past several years.2 The important thing in the end of the day is to know that these functions exist and you can make use of them. Writing this short article will definitely help me to remember this. That’s all I have for you today. Keep hacking! * It was part of some broader efforts to slim down Stdlib and move in the direction of a more modular standard library. ↩ * And obviously you can open the Fun module if you wish to at whatever level you desire. ↩

#OCaml #OCamlPlanet

20.07.2025 18:34 — 👍 0    🔁 0    💬 0    📌 0
Preview
Learning OCaml: Numerical Type Conversions Today I’m going to cover a very basic topic - conversions between OCaml’s primary numeric types int and float. I guess most of you are wondering if such a basic topic deserves a special treatment, but if you read on I promise that it will be worth it. So, let’s start with the basics that probably everyone knows: * you can convert integers to floats with float_of_int * you can convert floats to integers with int_of_float int_of_float 10.5;; - : int = 10 float_of_int 9;; - : float = 9 Both functions live in Stdlib module, which is opened by default in OCaml. Here it gets a bit more interesting. For whatever reasons there’s also a float function, that’s a synonym to float_of_int. There’s no int function, however. Go figure why… Here’s a bit of trivia for you - int_of_float does truncation to produce an integer. And there’s also a truncate function that’s another alias for int_of_float. Again, for whatever reasons it seems there are no functions that allow you to produce an integer by rounding up or down. (although such functions exist for floats - e.g. Float.round, Float.floor and Float.ceil) int_of_float 5.5;; - : int = 5 truncate 5.5;; - : int = 5 5.5 |> Float.round |> int_of_float;; - : int = 6 More interestingly, OCaml 4.08 introduced the modules Int and Float that bring together common functions for operating on integers and floats.1 And there are plenty of type conversion functions in those modules as well: * Int.to_float and Int.of_float * Float.of_int and Float.to_int * Int.to_string and Float.to_string The introduction of the Int and Float modules was part of (ongoing) effort to make OCaml’s library more modular and more useful. I think that’s great and I hope you’ll agree that most of the time it’s a better idea to use the new modules instead of reaching to the “historical” functions in the Stdlib module. Sadly, most OCaml tutorials out there make no mention of the new modules, so I’m hoping that my article (and tools like ChatGPT) will steer more people in the right direction. If you’re familiar with Jane Street’s Base, you’ll probably notice that it also employs similar structure when it comes to integer and float functionality. Which type conversion functions do you prefer? Why? That’s all I have for you today. Keep hacking! * Technically speaking, Float existed before 4.08, but it was extended then. 4.08 also introduced the modules Bool, Fun, Option and Result. Good stuff! ↩

#OCaml #OCamlPlanet

20.07.2025 14:37 — 👍 0    🔁 0    💬 0    📌 0
Cresting the OCaml AI humps I've been hacking with Sadiq Jaffer (^), Jon Ludlam (^) and Ryan Gibb (^) on various approaches to improving the agentic coding experience for OCaml. We jotted down our notes in a draft paper to keep track of everything going on, including summarising previous experiments with Qwen3 for FoCS. Since then, there's been a flurry of extra activity from others which we need to integrate! * Marcello Seri started pushing to my vibe coded OCaml MCP library, making him user number 2 of that! * Then Thibaut Mattio announced a bunch of software, starting with a collection of libraries and tools for numerical computing and machine learning and also another MCP server. I haven't had a chance to try the MCP server yet, but I hope I can retire mine... * Thomas Gazagnaire started hacking on an agent-friendly merlint tool that spots common problems in style and choices and gives CLI feedback in a style easily consumed by claude. I've started using it despite its pre-alpha status. * Jon Ludlam's been getting the opam embeddings into shape to be suitable as an MCP server that can search the entire opam ecosystem. odoc v3 has also gone live after lots of work, and David Sancho's support for Markdown odoc output on which makes this process easier. This is all fairly straightforward MCP work that improves the short-term experience. We'll get to the RL-VR ideas later... If anyone else is hacking on something agent related do post on OCaml Discuss and let us know! I'm hoping to update the paper later in August to roundup the efforts above.

#OCaml #OCamlPlanet

20.07.2025 02:36 — 👍 4    🔁 1    💬 0    📌 1
Sometimes it’s just knowing where to tap @@ -44,6 +44,8 @@ # the lines involved in the conflict, which is arguably worse #/Changes merge=union +testsuite export-ignore + # No header for text and META files (would be too obtrusive). .md typo.missing-header README typo.missing-header First time users of OCaml on Windows: 25% speedup on switch creation. All platforms gain a benefit, even if it’s much smaller. As both rustup and uv have taught us: don’t do stuff you don’t need to (uv) and making Windows better usually benefits Linux, or at least doesn’t make it worse (rustup). PR to follow soon: it turns out it’s worth tapping a few more times, but then a little bit of soldering is needed…

#OCaml #OCamlPlanet

19.07.2025 22:29 — 👍 2    🔁 0    💬 0    📌 0
Into the sunset or into the dawn? Earlier this year, I returned to the Computer Laboratory at the University of Cambridge, as part of the Energy and Environment Group, combining with my work at Tarides. It’s been something of a whirlwind, which doesn’t look like it’ll be abating just yet, but there’s still been the odd chance to consider where things are and where we might be headed. I’m minded of a scene from an opera I performed a few years ago in Hannover. In the second act of Henrico Leone (🦁, rather than 🐫, but hey), Henrico’s wife, Metilda, in a vision sees her husband defeated in battle: Your browser does not support the audio tag. Morirò fra strazi e scempi e dirassi, ingiusti dei, che salvando i vostri templi io per voi tutto perdei. Dying, Henrico manages one last scream (almost literally in the opera; the role is portrayed by an alto castrato), declaring, “I will die amidst torment and destruction and it will be said, unjust gods, that in saving your temples I lost everything for you.”. Agentic coding and the end of the programmer? OxCaml and the end of OCaml? @dra27 switching from Windows to macOS? Fortunately, the vision is, as visions often are, a Mirage. Henrico, luckily for a three act opera, has not been killed in Act II (he survived a shipwreck at the beginning of the opera, so he – along with the metaphor – is doing quite well!). My feeling, set down in 2025 ready for me to laugh at, um, later in 2025 (or hopefully a few years down the line), is that we’ll still be here for some time to come; programming in OCaml. For me, the challenges and requirements on the ecosystem presented by our new AI tooling seem very little different from the challenges and requirements we had before. I’ve often (and not entirely originally) remarked that Windows doesn’t usually throw up portability problems, it’s more that it shines a light and exaggerates unfortunate parts of a system’s design (expecting to keep databases in gazillions of flat files, assuming there’s only one directory separator character, assuming there’s one root file system, etc., etc.). So too the needs of LLMs shine a light on our stateful packaging systems (which we already knew were too stateful), on the pain of package-to-library-to-module namespacing, on the need for aggressive caching of previous build results to be able to explore a search space. Looking at stats from 2022 (the 2024 report doesn’t appear to contain an updated statistic), one can glean that most of GitHub’s 420+ million repositories are written in around 500 different programming languages. My entirely ill-educated guess is that there’s not going to be the breadth of either existing material (for training) or even need to give your favourite agent the ability to synthesise the programming language as well as the program any time soon! I’m excited to see what’s happening and going to be happening with OxCaml. There are several great features which have already made it from Jane Street over to OCaml, and I fully expect the next few releases of OCaml to be reminiscent of OCaml 4.10+, as Multicore OCaml features started to migrate over to mainline OCaml. Also reminiscent of Multicore OCaml are things like missing Windows support! Plus ça change, plus c’est la même chose, I guess, but then keeping these things going is very much what drives me. For better or worse, I don’t really seem to change (although I do occasionally use macOS 😁) I have always regarded my working life as divided between my work as a singer in the performing arts and my work as an engineer/scientist in technology. More recently, perhaps with a middle-aged tendency to muse, I see the common thread in me between the two and conclude that, despite my best efforts as a geeky child, I act more artistically than scientifically. Performing is deeply personal. It is also a service for an audience and one’s skill, one’s expertise, one’s talent is poured into the perfecting of that performance in the service of its audience. For me, everything leading up to it (learning, practice, rehearsal, etc.) is profoundly irrelevant next to the artefact of the performance itself and the sole purpose of that preparatory work (however satisfying and enjoyable!) is the perfecting of that artefact for that service of performance. My personal realisation is that this idea of service has always underpinned my drive in technology as well. From my very earliest days dabbling with setting up school computer networks, from the first software systems I programmed, the work was fascinating and the challenges stimulating, but it was and is driven by the pursuit of the perfect, or right, system in the service of its users. But what of the art itself? Standing in my office now, with computers both in front and behind me, beside me are shelves of scores and piles of other music. I can’t easily count the number of times I have performed the major works of Bach and Handel over the last two decades, but at each repeat performance, I strive to achieve a closer perfection of that art from the one which preceded it - serving both the audience and the art. And here I find the service of the art-e-fact - the maintenance of that which one has written or which one has done. I don’t abandon that which I haven’t yet perfected and which still has an audience. Perhaps it is this service of the art in the service of others which has driven and continues to drive my desire to improve our small corner of the world of technology, rather than necessarily to produce other things with it. Although it really is nice to get to do that occasionally, too. Which in a meandering sort of a way is where the last year, and in particular this last 3-4 months, have been. Relocatable OCaml was an idea formulated over a few hours of thinking and writing in 2019, and in fact originally conceived during a rehearsal. Showing that it was a technically viable idea was done over a few weeks of hacking in 2021. Getting it to a stable state such that it could be demonstrated across the three major platforms on all current releases of OCaml was done over a few months of feverish work in 2022. You can possibly see where this is going: getting it to an upstreamable state where it can be maintained for the future has taken the next order of magnitude in time, it would appear! I’ve already written in some detail what it’s supposed to do. Why it matters seems to touch so many areas for so many users. With Relocatable OCaml, opam switches can be created to your heart’s content, wasting neither CPU time and energy to build the same compiler again, nor disk space to store it, and without having to wait until we can morph the entire ecosystem to another different way of doing things instead. Likewise, in Dune, the compiler can finally be treated as any other package and cached between projects. Engineers working on the compiler itself can now drop in a replacement development compiler into an opam switch without having to curse and rebuild it with the correct prefix for that switch. For users, it Just Works™, and hopefully in a few years’ time newcomers will wonder how it could ever not always have been that way. When the curtain comes down on this performance, hopefully all its users will applaud through some measure of decreased grumpiness and increased productivity. Hopefully the coffee market will not be too impacted by the lack of opam switch create-induced breaks. Hopefully the distance to perfection will be a little smaller. And I’ll look to the next performance. We aren’t done yet.

#OCaml #OCamlPlanet

19.07.2025 18:34 — 👍 1    🔁 0    💬 0    📌 0
Odoc 3 is live on OCaml.org! Odoc 3 is live on OCaml.org! * published 2025-07-14 As of today, Odoc 3 is now live on OCaml.org! This is a major update to odoc, and has brought a whole host of new features and improvements to the documentation pages. Some of the highlights include: * Source code rendering * Hierarchical manual pages * Image, video and audio support * Separation of API docs by library A huge amount of work went into the Odoc 3.0 release, and I'd like to thank my colleagues at Tarides, in particular Paul-Elliot and Jules for the work they put into this. But the odoc release happened months ago, so why is it only going live now? So, the doc tool itself is only one small part of getting the docs onto ocaml.org. Odoc works on the cmt and cmti files that are produced during the build process, and so part of the process of building docs is to build the packages, so we have to, at minimum, attempt to build all 17,000 or so distinct versions of the packages in opam-repository. The ocurrent tool ocaml-docs-ci, which I've previously written about, is responsible for these builds and in this new release has demonstrated a new approach to this task, where we attempt to do the build in as efficient a way as possible by effectively building binary packages once for each required package in a specific 'universe' of dependencies. For example, many packages require e.g. cmdliner.1.3.0 to build, and some require a specific version of OCaml too. So we'll build cmdliner.1.3.0 once against each version of OCaml required -- but only once, which is in contrast to how some of the other tools in the ocurrent suite work, e.g. opam-repo-ci. Once the packages are built, we then run the new tool odoc_driver to actually build the HTML docs. In addition to this, a new feature of Odoc 3 is to be able to link to packages that are your direct dependencies - so for example, the docs of odoc contain links to the docs of odoc_driver, even though odoc_driver depends upon odoc. This, whilst sounding easy enough, required some radical changes in the docs ci, which I promise I will write about later! The builds and the generation of the docs is all done on a single blade server, called sage with 40 threads, 2 8TiB spinning drives and a 1.8TiB SSD cache, and it produces about 1 TiB of data over the course of a couple of days. The changes required to this part of the process since odoc 2.x were primarily myself and Mark Elvers Once the docs are built, how do they get onto ocaml.org? Odoc itself knows nothing about the layout and styling of ocaml.org, so the HTML it produces isn't suitable to be just rendered when a user requests particular docs. What happens is that odoc produces, as well as a self-contained HTML file, a json file with the body of the page, the sidebars, the breadcrumbs and so on as structured data, one per HTML page, which are then served from sage over HTTP. When a user requests a particular docs page, the ocaml.org server will request that json file from sage, then render this with the ocaml.org styling, then send it back to the user. As odoc 3 moved a fair bit of logic from ocaml.org into odoc itself, there were quite a few changes that needed to be made to the ocaml.org server to integrate this into the site. This work was mostly done by Paul-Elliot and myself, with a lot of help from the ocaml.org team, in particular Sabine Schmaltz and Cuihtlauac Alvarado. So, quite a lot of integration and infrastructure work was required to get the new docs site up and running, and I'm very happy to see this particular task concluded! Continue reading here

#OCaml #OCamlPlanet

19.07.2025 14:37 — 👍 2    🔁 0    💬 0    📌 0
Fireworks and things Thanks to some targetted optimisations in the script which manages Relocatable OCaml’s various branches, I’d vastly improved the turn-around time when making changes to the patch-set and propagating them through the various tests and backports. On Tuesday night, the entire set of branches was green in CI (they’re sat here with green check marks and everything). All that was to be needed on Wednesday was to quickly update the opam packaging to take advantage of Relocatable-awesomeness and plumb it all together. The 2022 version of the packages for Ljubljana I knew contained a hack for searching a previous switch, but I’d already investigated a more principled approach using opam’s build-id variable, so it would just be a matter of plumbing that in and using the cloning mechanism already in that script. And then I opened that scripts which I’d hacked together ready for the talk in 2022 in Ljubljana. I vaguely remember getting that all working at some ungodly hour of the morning. The final clone is an unsightly: # Cloning SOURCE="$(cat clone-from)" cp "$SOURCE/share/ocaml/config.cache" . mkdir -p "$1/man/man1" cp "$SOURCE/man/man1/"ocaml* "$1/man/man1/" mkdir -p "$1/bin" cp "$SOURCE/bin/"ocaml* "$1/bin/" rm -rf "$1/lib/ocaml" cp -a "$SOURCE/lib/ocaml" "$1/lib/" with no attempt to check the file lists 😭 Sorting out the installation targets in OCaml’s build system is on my radar, but was not on my “Relocatable OCaml blockers” TODO list. We were so close Alas, the things which you can get away for a demo in a conference talk aren’t quite the same as for actually maintained software. Ho hum - on the plus side, Wednesday and Thursday’s hacking now yields a version of OCaml which can generate opam install files properly, and which can therefore be co-opted to produce the cloning script actually required. Onwards and upwards, apparently now with memes…

#OCaml #OCamlPlanet

18.07.2025 18:34 — 👍 0    🔁 0    💬 0    📌 0
Using Kyutai's low latency audio models on macOS in one command I've just taken Kyutai's speech-to-text model for a spin on my Mac laptop, and it's stunningly good. As background, this is what the prolific Laurent Mazare has been hacking on; he has made a ton of contributions to the OCaml community as well, such as ocaml-torch and starred in a very fun Signals to Threads episode on machine learning at Jane Street back in 2020. You can get the microphone-to-speech running on your Mac in a few commands, assuming you have uv installed (which you should!). git clone https://github.com/kyutai-labs/delayed-streams-modeling cd delayed-streams-modeling uvx --with moshi-mlx python scripts/stt_from_mic_mlx.py It understands my accent near perfectly; if that isn't a machine learning miracle, I don't know what is! I'm looking forward to trying this out more with our Low power audio transcription with Whisper project over the summer with Josh Millar and Dan Kvit.

#OCaml #OCamlPlanet

18.07.2025 14:38 — 👍 1    🔁 0    💬 0    📌 0
OCaml Weekly News, 15 Jul 2025 * OCaml Language Committee: an update on a policy for conflicts of interest * OCaml intern for Claudius * An example for every OCaml package * Esa 0.1.0 - Enhanced Suffix Arrary(and further plans) * Tutorial: cut and pasting code * QCheck 0.24 * New Odoc-3-Generated Package Documentation is Live on OCaml.org * Lwt.6.0.0~alpha (direct-style) * MirageOS on Unikraft * Other OCaml News

#OCaml #OCamlPlanet

16.07.2025 14:37 — 👍 2    🔁 0    💬 0    📌 0
Conference presentation slide for FUNOCaml 2025 event in Warsaw, Poland on September 15-16. Features a circular photo of Paul-Elliot Angles d'Auriac, a person with shoulder-length wavy hair wearing round glasses and drinking from a blue cup. The slide announces a talk titled "Slipshow: A Full-Featured Presentation Tool in OCaml" and describes how Slipshow is a presentation tool originally written in JavaScript but rewritten in OCaml, featuring a runtime engine, compiler, collaborative editing website, VSCode extension, and standalone application. The talk explores how OCaml enabled a single developer to create and maintain such a comprehensive project.

Conference presentation slide for FUNOCaml 2025 event in Warsaw, Poland on September 15-16. Features a circular photo of Paul-Elliot Angles d'Auriac, a person with shoulder-length wavy hair wearing round glasses and drinking from a blue cup. The slide announces a talk titled "Slipshow: A Full-Featured Presentation Tool in OCaml" and describes how Slipshow is a presentation tool originally written in JavaScript but rewritten in OCaml, featuring a runtime engine, compiler, collaborative editing website, VSCode extension, and standalone application. The talk explores how OCaml enabled a single developer to create and maintain such a comprehensive project.

Paul-Elliot Angles d'Auriac:

Slipshow: A Full-Featured Presentation Tool in OCaml

FUN OCaml 2025 | Warsaw | Sept 15-16

How one developer rewrote a JavaScript presentation tool in OCaml, creating a platform with runtime engine, collaborative editing, VSCode extension & app.

16.07.2025 13:00 — 👍 10    🔁 5    💬 0    📌 0
Conference talk slide for FUNOCaml 2025 in Warsaw, Poland (September 15-16). Features a circular photo of speaker Xavier Van de Woestyne wearing glasses and a dark hoodie. The talk title is "Generating Static Websites the Functional Programming Way" and describes how the presentation examines limitations of popular static site generators like Jekyll, Zola, and Hugo for complex sites, exploring static site generation through build systems theory and showcasing YOCaml, a static site framework written in OCaml using functional programming abstractions.

Conference talk slide for FUNOCaml 2025 in Warsaw, Poland (September 15-16). Features a circular photo of speaker Xavier Van de Woestyne wearing glasses and a dark hoodie. The talk title is "Generating Static Websites the Functional Programming Way" and describes how the presentation examines limitations of popular static site generators like Jekyll, Zola, and Hugo for complex sites, exploring static site generation through build systems theory and showcasing YOCaml, a static site framework written in OCaml using functional programming abstractions.

Xavier Van de Woestyne

"Generating Static Websites the Functional Programming Way"

at #FUNOCaml 2025!

Exploring limitations of Jekyll/Hugo/Zola for complex sites + introducing YOCaml — a static site framework in OCaml using functional abstractions

📅 Sept 15-16 | Warsaw

16.07.2025 12:28 — 👍 11    🔁 5    💬 0    📌 0
Conference slide for FUNOCaml 2025 in Warsaw, Poland on September 15-16. Features a circular photo of speaker Dmitriy Kovalenko, a man with glasses and light hair wearing a dark jacket over a white shirt, photographed outdoors. The slide announces his talk titled 'OxCaml From a System Engineer's Point of View' with description: 'Dmitriy Kovalenko, a systems programmer experienced with Rust, C, and Zig, explores 0xCaml as a potential addition to his toolkit. He investigates how 0xCaml compares to native OCaml and other systems languages, then tests it by building codiff, a high-performance image comparison library with 0xCaml, sharing his findings and lessons learned from the experience.'

Conference slide for FUNOCaml 2025 in Warsaw, Poland on September 15-16. Features a circular photo of speaker Dmitriy Kovalenko, a man with glasses and light hair wearing a dark jacket over a white shirt, photographed outdoors. The slide announces his talk titled 'OxCaml From a System Engineer's Point of View' with description: 'Dmitriy Kovalenko, a systems programmer experienced with Rust, C, and Zig, explores 0xCaml as a potential addition to his toolkit. He investigates how 0xCaml compares to native OCaml and other systems languages, then tests it by building codiff, a high-performance image comparison library with 0xCaml, sharing his findings and lessons learned from the experience.'

FUNOCaml 2025 Talk

"OxCaml From a System Engineer's Point of View"

📅 Sept 15-16, Warsaw

Dmitriy Kovalenko (Rust/C/Zig dev) evaluates 0xCaml for systems programming through building odiff, a high-performance image comparison library.

Comparative analysis + practical insights

16.07.2025 09:39 — 👍 9    🔁 3    💬 0    📌 0
Preview
Fun OCaml 2025: Warsaw - September 15+16, 2025 Fun OCaml 2025 is a 2 days open source hacking event dedicated to OCaml enthusiasts and professionals around the globe! Let's get together for an exhilarating event packed with creativity, innovation,...

register for free to join us in Warsaw at fun-ocaml.com

or watch the YouTube livestream on September 15 + 16!

16.07.2025 09:24 — 👍 3    🔁 2    💬 0    📌 0
Conference poster for FUNOCaml 2025 workshop in Warsaw, Poland on September 15-16. Features a circular photo of Lukasz Stafiniak, a bearded man with shoulder-length hair. The workshop is titled 'Train a Reinforcement Learning Agent for the Game Sokoban in Raven/OCANNL' and describes covering reinforcement learning basics, building game environments, neural network models (CNN or transformer), training infrastructure, and exploring GRPO (Group Relative Policy Optimization) algorithms and connections to language model training.

Conference poster for FUNOCaml 2025 workshop in Warsaw, Poland on September 15-16. Features a circular photo of Lukasz Stafiniak, a bearded man with shoulder-length hair. The workshop is titled 'Train a Reinforcement Learning Agent for the Game Sokoban in Raven/OCANNL' and describes covering reinforcement learning basics, building game environments, neural network models (CNN or transformer), training infrastructure, and exploring GRPO (Group Relative Policy Optimization) algorithms and connections to language model training.

Exciting news! Lukasz Stafiniak will lead a hands-on RL workshop at #FUNOCaml2025 in Warsaw (Sept 15-16)! 🐫

Learn to train a Sokoban game agent using Raven/OCANNL - covering neural networks, GRPO algorithms, and connections to LLM training 🤖🎮

16.07.2025 09:23 — 👍 9    🔁 3    💬 1    📌 0
Preview
Secure Internet Services with OCaml and MirageOS · Success Stories A worker-owned collective leverages OCaml and MirageOS to build secure, high-performance, and resource-efficient software solutions

Full Story: ocaml.org/success-stor...

14.07.2025 08:04 — 👍 2    🔁 0    💬 0    📌 0
Preview
Secure Internet Services with OCaml and MirageOS · Success Stories A worker-owned collective leverages OCaml and MirageOS to build secure, high-performance, and resource-efficient software solutions

New Success Story: Secure Internet Services with OCaml and MirageOS 🔒

Robur, a worker-owned collective, builds secure, high-performance, and resource-efficient software solutions!

OCaml's static typing eliminates runtime errors with predictable performance - perfect for system-level programming.

14.07.2025 08:04 — 👍 13    🔁 3    💬 1    📌 2
Preview
Introducing Jane Street's OxCaml Branch! Jane Street is a well-known OCaml powerhouse. They have a reputation for expertise and a long history of supporting the open-source community. Jane Street have been developing experimental features on a branch of OCaml, using them in production internally, and preparing them to be shared with the rest of the ecosystem. These extensions are now bundled and distributed together under the name OxCaml. We are always excited about projects that bring new features to OCaml and improve it for its users. This post will give you an overview of the different features being developed under the OxCaml umbrella and how Tarides is collaborating with Jane Street on the project. What is OxCaml OxCaml is an open-source branch of OCaml that incorporates several extensions designed to help write multicore and high-performance OCaml code. Jane Street relies on OCaml’s sweet spot. OCaml lets you write code quickly, code that is performant, code that solves complex problems, and code that can be trusted, thanks to its strong focus on correctness-by-construction. However, like any language, OCaml has its limits. When writing low-latency code, you'd like the garbage collector not to kick in at inopportune moments. While this may seem like a niche use case, it is a niche that matters to Jane Street. With OCaml 5, OCaml code can exploit shared-memory parallelism. Shared-memory parallel programming also leads to data races. Because noticing and debugging data races is difficult, code review isn’t sufficient to trust multicore code in mission-critical contexts. OxCaml extensions have three main goals: * Enable writing correct-by-construction multicore code; * Enable writing low-latency code in OCaml instead of a GC-free language; * Raise the overall level of performance. Last but not least, all those goals should be achieved without moving OCaml away from its sweet spot. Furthermore, according to its website, OxCaml’s primary design goals are to be “safe, convenient, [and] predictable”. Safety makes developers more productive and ensures they ship correct code. Convenience means using OCaml’s type system and type inference to provide adequate choice and control without adding complexity. Predictability involves retaining the aspects of OCaml that make it easy for developers to understand how their code will perform simply by looking at it, which requires keeping performance details explicit at the type level. The OxCaml branch is open-source and welcomes new users. However, the extensions are experimental and not guaranteed to be stable or backwards compatible. Your feedback is needed to fine-tune the experience and improve the various new features. You can provide feedback by making issues on the OxCaml GitHub repo or discuss it in the #oxcaml channel in the OCaml community discord server. Open-source tools and libraries provided by Jane Street now come in two flavours. The default targets classic OCaml. The with-extensions branch targets OxCaml. For instance, Jane Street's successful Base library has a with-extensions branch. Jane Street also provides an opam repository with OxCaml compatibility patched versions of the packages. How Tarides is Helping Tarides takes part in the processes around OxCaml in two ways: by providing platform support for working with and distributing OxCaml code, and by helping to upstream some of its features into mainline OCaml. Tarides has adapted OxCaml features to the official compiler codebase and taken part in design discussions with the OCaml maintainers to ensure that the features integrate well into the existing compiler. Sometimes, the upstream compiler will have features that OxCaml doesn’t have yet, which overlap with OxCaml’s extensions, so care is needed to handle everything as seamlessly as possible and in a backwards-compatible way. The OCaml 5.4 features labelled tuples and immutable arrays are two recent examples which have been upstreamed from OxCaml with Tarides’s assistance. For future releases, Tarides will be part of the design discussions for upstreaming new features, like "include functor", polymorphic parameters, module strengthening, and possibly more. Experimental Extensions Let’s take a look at the different extensions that are part of OxCaml: * Modes: Modes are deep properties of values that are tracked by the OxCaml compiler. They are similar but distinct from types. While types describe what a value is, modes describe how they can be used. Each value in OxCaml has a mode (plus its type). OxCaml permits type signatures to be decorated with modes, restricting how that value may be used. As an example, the linear modality on a function says that the function may be invoked at-most-once. This property is distinct from the type of the function. * Stack Allocations: With OxCaml, more values can be allocated on the stack instead of on the heap, which improves performance by reusing cache lines and reducing the cache footprint. The compiler uses a value’s locality to determine whether it is local and, therefore, can be allocated on the stack or global and needs to go on the heap. * Unboxed Types: This extension gives users more options on how their data is represented in memory and registers. Unboxed types introduce the concept of layouts. Every type has a layout, with a number of base layouts available to the type system. * Data-Race-Free Parallelism: There are a number of new features centred on OCaml’s support for multiple domains, including extending the mode system to track the concurrent use of values to improve safety during concurrency and introducing higher-level parallelism primitives. * Kinds: This adds a new system that extends the type system by adding “types” to types, that's what a kind is, a type's “type”. Two words are used to avoid confusion, as kinds don't have allocated values at runtime; only types do. Kinds have several components, among them layout, which describes the shape of the data at runtime and modal bounds, which assign limits on the mode's value may be assigned to. * Uniqueness: A mode that designates values that should only have a single reference pointing to them. By guaranteeing that only one reference will be consumed, the mode prevents bugs like the use-after-free segfault. There’s a Jane Street blog post, as well as a post by KC Sivaramakrishnan about using Uniqueness and its features. * Comprehensions: This extension introduces ‘comprehensions’, which is a syntactic form that uses mathematical set-builder notation to build lists and arrays. * Other Extensions: There are several more smaller extensions as part of OxCaml. These include immutable arrays, labelled tuples, polymorphic parameters, and more! Looking to the Future In light of the public release, we encourage OCaml users to try OxCaml and share their feedback. The best place to discuss OxCaml is the #oxcaml channel on the OCaml community discord server. Engineers from Jane Street and Tarides working on OxCaml regularly hang out in the channel and would be delighted to hear feedback. The explicit goal of OxCaml is to iterate over these features and eventually upstream them to OCaml. Tarides has experience shepherding and successfully upstreaming Multicore OCaml, which was a multi-year effort to bring in native support for concurrency and parallelism to OCaml. Just as with Multicore OCaml, Tarides' goal is to make it easy for the community to work with OxCaml, gather feedback, iterate on the design with Jane Street engineers and help upstream the features to OCaml over the coming years. If we are successful with the upstreaming efforts, we believe that OCaml will fill an important gap in the design space for programming languages. We would like you to be part of this effort! Stay in Touch You can connect with us on Bluesky, Mastodon, Threads, and LinkedIn or sign up for our mailing list to stay updated on our latest projects. We look forward to hearing from you!

#OCaml #OCamlPlanet

11.07.2025 14:37 — 👍 2    🔁 1    💬 0    📌 0
Preview
Secure and Verifiable Online Voting Platform · Success Stories VCAST is a French company providing transparent and verifiable online voting solutions, built on the foundation of the open-source Belenios voting system. Their platform enables organizations to condu...

Full Story: ocaml.org/success-stories/secure-and-verifiable-online-voting-platform

11.07.2025 12:42 — 👍 3    🔁 0    💬 0    📌 0

@ocaml.org is following 15 prominent accounts