OCaml Weekly News

Previous Week Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of February 14 to 21, 2023.

Table of Contents

Looking for Ideas for the Package Overview Page on OCaml.org

Sabine Schmaltz asked

We are looking into improving the “Overview/Description” page of a package. Since this is basically the “landing page” of the package, it needs to both look great and include the most relevant info. We want you to be able to estimate at a glance whether the package is one that you might want to use, and to find the most important landmarks (e.g. CHANGES.md, LICENSE.md, Documentation, package homepage) of the package easily.

Share your thoughts about it!

  • What would be useful to see appearing on the page overview page?
  • We’re also very interested in your favorite package overview pages from other languages. Please do share screenshots of package overview pages that you really like to use in this thread. We are compiling a moodboard in order to systematically analyze how to best arrange the content that we have and to be inspired on what looks great while being usable at the same time.

Your opinions matter and your feedback is used to improve our work.

Editor’s note: there were many replies, please follow the archive link above to read them.

prr, a fork of brr for non-browser JavaScript environments

Haochen Kotoi-Xie announced

I’m please to announce the first release of the prr library: prr.0.1.1.

Prr is a fork and a stripped-down version of the widely used JavaScript FFI library brr, which is originally built by @dbuenzli.

There are two major differences between brr and prr:

  1. prr uses dune as its build system. This allows easier vendoring through dune’s vendoring support.
  2. prr includes only non-browser specific components of brr, so that it could be safely used in JavaScript environments like those of Node.js and React Native projects, in addition to targeting web. (In fact this is our motivation to fork brr in the first place.)
    • prr’s README gives an overview of what is included and what is not.

No need to say that we are basically freeloading @dbuenzli and brr contributors’ efforts in building such a wonderful FFI library so special thanks to the contributors of brr.

We will be actively maintain compatibility between prr and brr and closely follow the developments of brr.

To install, simple run opam install prr, list prr as a dependency of your project, and open Prr. Code that previously depends on brr should work without modification if no access to browser specific APIs is used.

Comments and suggestions are mostly welcomed.

ICFP 2023 Artifact Evaluation Committee: call for nominations

Quentin Stiévenart announced

We are looking for motivated people to be members of the ICFP 2023 Artifact Evaluation Committee (AEC). Students, researchers and people from the industry or the free software community are all welcome. The artifact evaluation process aims to improve the quality and reproducibility of research artifacts for ICFP papers. In case you want to nominate someone else (students, colleagues, etc.), please send them the nomination form.

Nomination form: https://forms.gle/RDomoHLv39RnjBUC6

For more information, see the AEC webpage: https://icfp23.sigplan.org/track/icfp-2023-artifact-evaluation

The primary responsibility of committee members is to review the artifacts submitted corresponding to the already conditionally accepted papers in the main research track. In particular, run the associated tool or benchmark, check whether the results in the paper can be reproduced, and inspect the tool and the data.

We expect evaluation of one artifact to take about a full day. Each committee member will receive 2 to 3 artifacts to review.

All of the AEC work will be done remotely/online. The AEC will work in June, with the review work happening between June 5th and June 29th.

Come join us in improving the quality of research in our field!

Best, the Artifact Evaluation chairs: Jannis Limperg and Quentin Stiévenart

New Owl book: Architecture of Advanced Numerical Analysis Systems

Andreas Poisel announced

There is a second book on Owl: Architecture of Advanced Numerical Analysis Systems - Designing a Scientific Computing System using OCaml.

Free download in PDF and ePub formats!

Improvement on the PPX ecosystem documentation

Paul-Elliot announced

From the OCaml survey and several discuss threads, it seems clear that documentation is an important issue in OCaml, especially with PPXs. I’m pleased to announce two improvements on this side: the publication (last summer) of our new “Preprocessors and PPXs” guide on OCaml.org, and the vast enhancement of the ppxlib documentation (very recently).

The ocaml.org guide is targeted at newcomers who don’t know what a PPX is, nor how to use them.

The ppxlib’s documentation is targeted at PPX authors, as well as PPX users who want to know more about the advantages, and what’s under the hood, of ppxlib.

The improvements in the ppxlib’s documentation are:

  • More content: many new sections and explanations were added.
  • More discoverability: Instead of being spread in many API pages, the “general” documentation is gathered in .mld pages focused on a specific topic, such as “matching code”, “good practices”, etc. API pages are focused on the API itself, with links to the relevant sections of the manual.
  • Thanks to odoc, I could also easily add many links from the manual to the API items.
  • Many code snippets did not compile, due to programming typos or outdated API. Those were corrected and improved.
  • The API landing page was very difficult to navigate. It is now more organized, with sections, and docstrings for every toplevel modules.

The manual can still be improved in many ways. There are many sections that could be added or improved. A global navigation bar would help a lot the navigation in the mld pages. I will also add soon a check that code snippets don’t go outdated, using mdx (on .mli first, but also on .mld as soon as the relevant mdx PR is finished and merged!).

Overall, writing documentation has been very smooth for me. I would encourage the community to contribute to the documentation effort: PRs for improvements of ppxlib’s docs are warmly welcome, and I’m sure that’s the case for many packages! It is really a killer feature to have all docs centralized on ocaml.org, and odoc is a great tool for writing both an API and a manual with interconnected links; Let’s make the best use of this!

Thanks a lot to @pitag and @professor.rose for the very valuable and comprehensive reviews, respectively on content and form, which highly improved the quality of the documents! Thanks also a lot to Tarides and Jane Street for sponsoring me to work on this task!

The color associated with OCaml on Github is bad. Let’s make it good

gasche said

I’m reviving this topic because there is now a concrete proposal to change the Github Linguist color for OCaml from “neon green” 3be133 to “orange” ee6a1a. The person proposing the change wants to know whether “the OCaml community” agrees with the proposal and opened a poll:

https://github.com/ocaml/ocaml/discussions/12013

Please go there if you want to give your opinion on the proposed change.

Note: “github linguist” is used to detect which languages are used in git repositories, with summaries shown automically and a color code to display the proportions. This is used on both Github and Gitlab. See for example the “Languages” section at the end of the right column on the webpage https://github.com/ocaml/ocaml.

Note: past discussions in the present thread are irritated by a limitation that one is not allowed to pick a color close to an existing language’s color. My understanding is that this limitation has since been removed, so any choice of color for OCaml would do.

@glennsl you previously proposed a slightly different shade of orange, ef7a08 rather than ee6a1a. If you happen to have a strong opinion on one rather than the other, now would be a good way to voice it on the poll/discussion thread.

Paul Biggar on Darklang

Continuing this thread, Claude Jager-Rubinson said

The recording of Paul’s talk is now available on our website at https://hfpug.org. He discusses rewriting the OCaml codebase at about 30 minutes in. His basic argument was that the F# ecosystem was much stronger – libraries, tooling, etc. What was more interesting to me were some of his criticisms of Rust (which is also the subject of one of his blog posts).

Major updates to kcas in 0.1.8 and 0.2.0

Continuing this thread, Vesa Karvonen announced

I recently held a talk on the work:

k-CAS for sweat-free concurrent programming

See the video and slides, including full speaker’s notes.

OUPS meetup march 2023

zapashcanon announced

The next OUPS meetup will take place on Thursday, 16th of March 2023. It will start at 7pm at the 4 place Jussieu, 75005 Paris.

:warning: :trumpet: It will be in the in the Astier amphitheater in the Esclangon building. :trumpet: :warning:

Please, register on meetup as soon as possible to let us know how many pizza we should order.

For more details, you may check the OUPS’ website .

This month will feature the following talks :

Deux moteurs de recherche pour l’ecosystème OCaml – Arthur Wendling

Sherlocode et Sherlodoc sont deux petits outils pour explorer les nombreux projets publiés sur opam. Le premier permet de `grep` en temps réel leur code source, tandis que le second facilite la recherche dans leur documentation (à la Hoogle). Durant la présentation, on verra que ces outils existent pour satisfaire deux envies : répondre à des questions tordues sur l’usage d’OCaml, mais aussi apprendre à coder ce type de moteur de recherche. On expliquera donc comment les recherches par regex et par type ont été implémentées, grâce à des astuces élégantes empruntées à la littérature… et des hacks douteux qu’il vaudrait mieux ne pas ébruiter.

Creusot a prophetic verifier for Rust – Xavier Denis

Rust is a fairly recent programming language for system programming, bringing static guarantees of memory safety through a strong ownership policy. This feature opens promising advances for deductive verification, which aims at proving the conformity of Rust code with respect to a specification of its intended behavior. We present Creusot, a tool for the formal specification and deductive verification of Rust. Creusot’s specification language features a notion of prophecies to reason about memory mutation. Rust provides advanced abstraction features based on a notion of traits, extensively used in the standard library and in user code. The support for traits is at the heart of Creusot’s approach of verification and specification of programs

Dune 3.7.0

Etienne Millon announced

The dune team is pleased to announce the release of Dune 3.7.0.

As in the previous announce, here is a changelog split in several parts: changes to the dune executable itself (new commands or options, etc) and changes to the dune language. Most of the changes to the latter are only enabled when you opt-in to the new version by specifying (lang dune 3.7) in the corresponding dune-project file. In other words, it should always be safe to upgrade the dune package.

dune executable

  • Added
    • Allow running $ dune exec in watch mode (with the -w flag). In watch mode, $ dune exec the executed binary whenever it is recompiled. (#6966, @gridbugs)
    • Add a dune cache size command for displaying the size of the cache (#6638, @Alizter)
    • Allow $ dune ocaml dump-dot-merlin to run in watch mode. Also this command shouldn’t print “Entering Directory” mesages. (#6497, @rgrinberg)
    • Add native support for polling mode on Windows (#7010, @yams-yams, @nojb, review by @Rucikir and @jbeckford)
    • Auto-detect dune-workspace files as dune files in Emacs (#7061, @ilankri)
    • Allow $ dune utop to load libraries defined in data only directories defined using (subdir ..) (#6631, @rgrinberg)
  • Changed
    • Make dune describe workspace return consistent dependencies for executables and for libraries. By default, compile-time dependencies towards PPX-rewriters are from now not taken into account (but runtime dependencies always are). Compile-time dependencies towards PPX-rewriters can be taken into account by providing the --with-pps flag. (#6727, fixes #6486, @esope)
    • Use colored output with MDX when Dune colors are enabled. (#6462, @MisterDA)
    • Use colored output with GCC and Clang when compiling C stubs. The flag -fdiagnostics-color=always is added to the :standard set of flags. (#4083, @MisterDA)
    • Move $ dune ocaml-merlin -dump-config=$dir to $ dune ocaml merlin dump-config $dir. (#6547, @rgrinberg)
  • Fixed
    • Fix parsing of OCaml errors that contain code excerpts with ... in them. (#7008, @rgrinberg)
    • Fix --trace-file output. Dune now emits a single complete event for every executed process. Unterminated async events are no longer written. (#6892, @rgrinberg)
    • Print missing newline after $ dune exec. (#6821, fixes #6700, @rgrinberg, @Alizter)
    • Fix binary corruption when installing or promoting in parallel (#6669, fixes #6668, @edwintorok)
    • Report an error if dune init ... would create a “dune” file in a location which already contains a “dune” directory (#6705, @gridbugs)
    • Fix the parsing of alerts. They will now show up in diagnostics correctly. (#6678, @rginberg)
    • Print “Leaving Directory” whenever “Entering Directory” is printed. (#6419, fixes #138, @cpitclaudel, @rgrinberg)
    • Remove “Entering Directory” messages for $ dune install. (#6513, @rgrinberg)
    • dune clean should no longer fail under Windows due to the inability to remove the .lock file. Also, bring the implementation of the global lock under Windows closer to that of Unix. (#6523, @nojb)
    • Fix missing dependencies when detecting the kind of C compiler we’re using (#6610, fixes #6415, @emillon)
    • Remove spurious build dir created when running dune init proj ... (#6707, fixes #5429, @gridbugs)
    • Validate the command line arguments for $ dune ocaml top-module. This command requires one positional argument (#6796, fixes #6793, @rgrinberg)
    • Fix dependency cycle when installing files to the bin section with glob_files (#6764, fixes #6708, @gridbugs)
    • Handle “Too many links” errors when using Dune cache on Windows (#6993, @nojb)
    • Pre-emptively clear screen in watch mode (#6987, fixes #6884, @rgrinberg)
    • Allow --sandbox to affect ocamldep invocations. Previously, they were wrongly marked as incompatible (#6749, @rgrinberg)

dune language

  • Added
    • Allow (include_subdirs qualified) for OCaml projects. (#6594, fixes #1084, @rgrinberg)
    • Format dune files when they are named dune-file. This occurs when we enable the alternative file names project option. (#6566, @rgrinberg)
    • Add map_workspace_root dune-project stanza to allow disabling of mapping of workspace root to /workspace_root. (#6988, fixes #6929, @richardlford)
    • Allow the cinaps stanza to set a custom alias. By default, if the alias is not set then the cinaps actions will be attached to both @cinaps and @runtest (#6991, @rgrinberg)
    • Add (using ctypes 0.3). When used, paths in (ctypes) are interpreted relative to where the stanza is defined. (#6883, fixes #5325, @emillon)
  • Changed
    • Stop passing -q flag in dune coq top, which allows for .coqrc to be loaded. (#6848, fixes #6847, @Alizter)
    • Coq native mode is now automatically detected by Dune starting with Coq lang 0.7. (mode native) has been deprecated in favour of detection from the configuration of Coq. (#6409, @Alizter)
    • Accurately determine merlin configuration for all sources selected with copy# and copy_files#. The old heuristic of looking for a module in parent directories is removed (#6594, @rgrinberg)
  • Fixed
    • Fix parsing of the <= operator in blang expressions of dune files. Previously, the operator would be interpreted as <. (#6928, @tatchi)
    • Fix preprocessing with staged_pps (#6748, fixes #6644, @rgrinberg)
    • Fix the parsing of decimal and hexadecimal escape literals in dune, dune-package, and other dune s-expression based files (#6710, @shym)
    • Fix cross compilation configuration when a context with targets is itself a host of another context (#6958, fixes #6843, @rgrinberg)
    • Allow compilation rules to be impacted by (env ..) stanzas that modify the environment or set binaries. (#6527, @rgrinberg)
    • Fix handling of support files generated by odoc. (#6913, @jonludlam)
    • Fix the compilation of modules generated at link time when implicit_transitive_deps is enabled (#6642, @rgrinberg)
    • Fix inline tests with js_of_ocaml and whole program compilation mode enabled (#6645, @hhugo)
    • Fix js_of_ocaml separate compilation rules when --enable=effects ,~–enable=use-js-string~ or --toplevel is used. (#6714, #6828, #6920, @hhugo)
    • Fix js_of_ocaml separate compilation in presence of linkall (#6832, #6916, @hhugo)
    • coqdep is now called once per theory, instead of one time per Coq file. This should significantly speed up some builds, as coqdep startup time is often heavy (#7048, @Alizter, @ejgallego)

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