OCaml Weekly News

Hello

Here is the latest OCaml Weekly News, for the week of April 23 to 30, 2024.

OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework
I roughly translated Real World OCaml's Async concurrency chapter to eio
Using Property-Based Testing to Test OCaml 5
OCaml Backtraces on Uncaught Exceptions, by OCamlPro
OCaml Users on Windows: Please share your insights on our user survey
Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts
dream-html 3.0.0
DkCoder 0.2 - Scripting in OCaml
Ocaml-protoc-plugin 6.1.0
Other OCaml News
Old CWN

OCANNL 0.3.1: a from-scratch deep learning (i.e. dense tensor optimization) framework

Archive: https://discuss.ocaml.org/t/ann-ocannl-0-3-1-a-from-scratch-deep-learning-i-e-dense-tensor-optimization-framework/14492/8

Lukasz Stafiniak announced

Third time the charm. OCANNL 0.3.3 is out now. I might need to change the name of the project, because of the lint warnings: Possible name collision with packages 'OCADml', 'ocal', 'ocaml'?

I roughly translated Real World OCaml's Async concurrency chapter to eio

Archive: https://discuss.ocaml.org/t/i-roughly-translated-real-world-ocamls-async-concurrency-chapter-to-eio/14548/1

Dennis Dang announced

Repo at https://github.com/dangdennis/rwo-eio/blob/main/lib/rwo_eio.ml

I was inspired by Taride's Make an Eio version of the Async examples in Real World OCaml to translate the Async examples to eio to test out eio's concurrency story. Warning, it's a rough translation. I hardly know OCaml and eio as well as I know my day-job languages :smile: .

There are still a few examples I haven't figured out.

I don't know how to implement copy_blocks. In this section, the example uses an intermediate buffer of some sorts to then copy from reader to writer. For now, I've left that intermediate buffer out.
I can't find an interrupt option in cohttp-eio as well as choice and choose. The book explains that cohttp-async can cancel http requests via an interrupt (see section).
For log_delays, I have yet to solve how to await my own every ticker such that I can await its completion and then log the timer at the end.

Using Property-Based Testing to Test OCaml 5

Archive: https://discuss.ocaml.org/t/blog-using-property-based-testing-to-test-ocaml-5/14550/1

Jan Midtgaard announced

Here's a blog post about how we have been using property-based testing to test OCaml 5: https://tarides.com/blog/2024-04-24-under-the-hood-developing-multicore-property-based-tests-for-ocaml-5/

OCaml Backtraces on Uncaught Exceptions, by OCamlPro

Archive: https://discuss.ocaml.org/t/blog-ocaml-backtraces-on-uncaught-exceptions-by-ocamlpro/14551/1

OCamlPro announced

Here's another one of our heads up about our latest blog release!

Today's topic is about an unintentionally hidden feature of the OCaml dev environmment: backtraces on uncaught exception!

We believe this will be old news to the veteran OCaml devs but could be of much use to the newer Cameleers out there!

Hopefully, you will learn a thing or two from reading this short article, we welcome all feedback in this very thread, thank you for reading!

OCaml Users on Windows: Please share your insights on our user survey

Archive: https://discuss.ocaml.org/t/ocaml-users-on-windows-please-share-your-insights-on-our-user-survey/14554/1

Sudha Parimala announced

Do you use OCaml on Windows? We want to hear from you! Participate in our user survey to share your experiences with the OCaml development environment on Windows. Your feedback is important in helping us understand the current pain points and identify areas for improvement. Whether you're a seasoned OCaml developer or just starting out, your input can make a significant difference.

Please sign up here https://forms.gle/SxRvNaEZXgedxrnR9, and we'll reach out to you.

Graphql_jsoo_client 0.1.0 - library for GraphQL clients using WebSockts

Archive: https://discuss.ocaml.org/t/graphql-jsoo-client-0-1-0-library-for-graphql-clients-using-websockts/14557/1

Hans Ole Rafaelsen announced

I'm glad to announce the release of graphql_jsoo_client.

This is the client side implementation of the GraphQL over WebSocket Protocol. It is mainly intended for use with Dream, which implements the server side. This library supports writing client code in Ocaml, that will run in the browser.

It can be found here.

dream-html 3.0.0

Archive: https://discuss.ocaml.org/t/ann-dream-html-3-0-0/14013/8

Yawar Amin announced

[ANN] dream-html 3.4.1

Add 'livereload' support ie automatically reloading the page in the browser when the Dream server restarts. Useful to run with dune's watch mode for a fast dev cycle.

This is adapted from Dream's own livereload middleware but with a slightly different approach. Full details in the module documentation: https://yawaramin.github.io/dream-html/dream-html/Dream_html/Livereload/

Why reimplement this? It seems that Dream's built-in livereload needs to parse the HTML markup, find its head tag, and dynamically inject the reloader script inside. Since parsing HTML can be pretty tricky and potentially buggy, I decided to manually add the script in the head tag as a strong-typed dream-html node:

head [] [
  ...
  Livereload.script;
  ...
]

DkCoder 0.2 - Scripting in OCaml

Archive: https://discuss.ocaml.org/t/dkcoder-0-2-scripting-in-ocaml/14560/1

jbeckford announced

I'm happy to announce the second release of DkCoder, an OCaml scripting tool.

The first release was about install ease: a couple clicks and four (4) minutes later you and your Windows and macOS users can start scripting. All users, including glibc-based Linux desktop users, can also use their Unix shells or Windows PowerShell. OCaml does not need to be pre-installed. Just copy and paste two lines (you'll see some in this post) and your script is running and your project is editable with OCaml LSP.

This second release is about technical ease. The three "big" ideas in this release are:

You don't write build files. If that sounds like /bin/sh that is intentional.
Almost every OCaml file is a script you can run. If that sounds like how Python scripts are almost indistinguishable from Python modules, that is intentional.
Almost every OCaml file can be referenced with a fully-qualified name. If that sounds like Java packages that is intentional.

Here are some examples:

(one of my own scripts) The incomplete but growing DkCoder documentation is written in a script: https://diskuv.com/dksdk/coder/2024-intro-scripting/. The documentation is a side-effect of running tests.

In a Unix shell or in PowerShell, the following will a) run tests using tezt, b) collect outputs, c) generate HTML documentation, and then d) serve the doc page on a tiny_httpd webserver for a quick preview:
```
git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/DkHelloScript.git

./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --serve
```
The following will print mixed Markdown/HTML that I can render and publish with a static site generator to a website:
```
./DkHelloScript/dk DkRun_V0_2.Run -- DkHelloScript_Std.Y33Article --doc --doc-format markdown
```
(someone else's) The Bogue demo game Snoke written by @sanette was "ported" to DkCoder. The port did not change a single line of the original code. I did re-arrange the directory structure (recall that there is a Java-like package mechanism underneath DkCoder) and I did add an extra .ml file. Run:
```
git clone --branch V0_2 https://gitlab.com/diskuv/samples/dkcoder/SanetteBogue.git

./SanetteBogue/dk DkRun_V0_2.Run -- SanetteBogue_Snoke.Snoke
```

The remaining items for DkCoder before a 1.x release: auto-downloading remote libraries (mostly done), meta/codegen tools (in progress), conditional compilation (in design), and a security policy (in design).

But right now DkCoder is at a reasonable enough point that I can now recommend using it for your own scripts. With the usual caveats that this is a 0.x release.

I'd like some feedback, especially on pain points and missing must-have features.

Tech Details (if interested)

Very simplistically, DkCoder is a high-level build system that transparently manages lower-level build systems (today that is Dune). I think (?) DkCoder is the first build system to use the codept OCaml dependency analyzer. Huge huge thanks to @octachron for that tool.

The rather boring driver pipeline is:

Seed a "universe" of modules with the single .ml file the user wants to run from the ./dk CLI, or seed with all the .ml files if run through OCaml LSP.
Let codept analyse any module references inside the current universe. Any missing modules are located and added to the universe. Rinse and repeat until there is a closed universe with no more missing module references.
Generate and/or incrementally update the build files. Each .ml file is mapped to a single OCaml .cma library.
Run the chosen build tool (ie. Dune) and execute the code.

What does that pipeline give us? Even in this early 0.2 release you get some unusual benefits:

Step 2: The missing modules can be created implicitly. The Snoke game has font, image and sound assets. By using Tr1Assets.LocalDir in the code DkCoder automatically creates a module that has all the assets (think ocaml-crunch). If a script does not need the assets, the codept analysis knows it doesn't use Tr1Assets, and the assets won't waste time getting built.
Step 3: The one-to-one .ml/.cma correspondence means DkCoder can apply a unique set of compiler flags to each .ml file. You get the Java-like package structure by opening a unique set of modules per .ml with -open flags (nit: I also used implicitly created directory modules to let you navigate the packages in your source code).
Step 4: You can take the generated dune-project and dune files, tweak them and run them outside of DkCoder. That means you are not locked into DkCoder! You can alternatively do what I did with Snoke: make your project compatible with both regular dune (/ocamlbuild/etc.) and DkCoder. Either way, you only need to deal with two issues that arise from DkCoder's bytecode compilation and prebuilt C libraries: a) build C dependencies yourself, and b) tell Dune to switch from bytecode mode to native code mode. If you are a mildly experienced Linux/OCaml user who understands the terms "opam", "pkg-config", "depexts", and "dune-configurator", this is a low bar.

Script references:

Ocaml-protoc-plugin 6.1.0

Archive: https://discuss.ocaml.org/t/ann-ocaml-protoc-plugin-6-1-0/14566/1

Anders Fugmann announced

I'm happy to announce the release of Ocaml-protoc-plugin version 6.1.0 Ocaml-protoc-pluginis a plugin for google's protobuf compiler (protoc) that generates an idomatic ocaml mapping and (de-)serialization functions based on .proto files. The library aims to be 100% compliant implementation of the protobuf specification.

The 6.1.0 (and 6.0.0) release introduces Json serialization and deserialization based on protobuffers guidelines and the ability to copy comments from .proto into ocaml generated code for improved documentation as well as numerous bug fixes and other improvements.

Full changelog since release 5.0.0

6.1.0: 2024-04-25

Fix name resolution leading to wrongly mapped names
Fix codegen bug causing the plugin to reject valid protobuf
Add preliminary support for melange though disabling eager evaluation of serialize and deserialize functions when not using native or bytecode backends
Fix missing cflags when compiling test c stub
Make Map tests compatible with older versions of protoc
Fix negative integer test failues due to a bug in older versions of protobuf (google) c lib

6.0.0: 2024-04-13

New features
- Implement json serialization and deserialization (#5)
- Support special json mapping for google types (#9)
- Add deprecation annotations for deprecated fields, services etc (#8)
- Add option to prefix generated files with their package name
- Copy documentation from proto files into generated ocaml bindings
Bug fixes
- Fix file output name if files contains a '-'
- Resolve bug for Request/Response module aliases leading to generating uncompilable code. (#21)
- Fix codegen bug for messages without fields and setting singleton_records = true (#20)
- In Services, the package field is now correctly set to None if the service if not defined in a package scope (#24)
Misc changes
- Unify serialization and deserialization spec and optimize oneof handling
- Simplify types used in code generation to improve readaility
- *Replace val name': unit -> string with val name: unit -> string which will only return the full protobuf name
- Optimize merge functions by applying eager evaluation
- Change signature of to_proto' to return unit and not a writer
(* indicates breaking change)
Notes

Message.name': unit -> string has been renamed to Message.name: unit -> string, and is now contains the fully qualified protobuf message name. Before the name was the ocaml module name of the message.

Service.Message signature has been deprecated and replaced with Spec.Message signature. Service.Message is now an alias for Spec.Message and will be removed in future releases.

Other OCaml News

From the ocaml.org blog

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

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