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 prr, a fork of brr for non-browser JavaScript environments ICFP 2023 Artifact Evaluation Committee: call for nominations New Owl book: Architecture of Advanced Numerical Analysis Systems Improvement on the PPX ecosystem documentation The color associated with OCaml on Github is bad. Let’s make it good Paul Biggar on Darklang Major updates to kcas in 0.1.8 and 0.2.0 OUPS meetup march 2023 Dune 3.7.0 Old CWN Looking for Ideas for the Package Overview Page on OCaml.org ════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/looking-for-ideas-for-the-package-overview-page-on-ocaml-org/11416/1> 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 ══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-prr-a-fork-of-brr-for-non-browser-javascript-environments/11419/1> 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. [prr] <https://kxc.dev/prr> [prr.0.1.1] <https://opam.ocaml.org/packages/prr/prr.0.1.1/> [brr] <https://erratique.ch/software/brr> [vendoring support] <https://dune.readthedocs.io/en/stable/dune-files.html#vendored-dirs-since-1-11> [README] <https://github.com/kxcdev/prr/blob/main/README.md> [We] <https://kxc.dev> ICFP 2023 Artifact Evaluation Committee: call for nominations ═════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/icfp-2023-artifact-evaluation-committee-call-for-nominations/11430/1> 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 ═════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/new-owl-book-architecture-of-advanced-numerical-analysis-systems/11434/1> 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! [Architecture of Advanced Numerical Analysis Systems - Designing a Scientific Computing System using OCaml] <https://link.springer.com/book/10.1007/978-1-4842-8853-5> Improvement on the PPX ecosystem documentation ══════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-improvement-on-the-ppx-ecosystem-documentation/11438/1> 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! [guide] <https://ocaml.org/docs/metaprogramming> [ppxlib documentation] <https://ocaml.org/p/ppxlib/0.29.1/doc/index.html> [ocaml.org guide] <https://ocaml.org/docs/metaprogramming> [ppxlib’s documentation] <https://ocaml.org/p/ppxlib/0.29.1/doc/index.html> [mdx] <https://github.com/realworldocaml/mdx> [PR] <https://github.com/realworldocaml/mdx/pull/377> The color associated with OCaml on Github is bad. Let’s make it good ════════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/the-color-associated-with-ocaml-on-github-is-bad-lets-make-it-good/5597/19> 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. [3be133] <https://www.color-hex.com/color/3be133> [ee6a1a] <https://www.color-hex.com/color/ee6a1a> [ef7a08] <https://www.color-hex.com/color/ef7a08> Paul Biggar on Darklang ═══════════════════════ Archive: <https://discuss.ocaml.org/t/paul-biggar-on-darklang/11370/6> 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). [https://hfpug.org] <https://hfpug.org> Major updates to kcas in 0.1.8 and 0.2.0 ════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-major-updates-to-kcas-in-0-1-8-and-0-2-0/11392/2> 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. [video] <https://www.youtube.com/watch?v=1z8PshvWOF8> [slides] <https://gist.github.com/polytypic/3214389ad69b16d28b957ced86e1b1a4#k-cas-for-sweat-free-concurrent-programming> OUPS meetup march 2023 ══════════════════════ Archive: <https://discuss.ocaml.org/t/oups-meetup-march-2023/11470/1> 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 [register on meetup ] <https://www.meetup.com/fr-FR/ocaml-paris/events/291637370> [OUPS’ website ] <https://oups.frama.io> Dune 3.7.0 ══════════ Archive: <https://discuss.ocaml.org/t/ann-dune-3-7-0/11474/1> 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. [the previous announce] <https://discuss.ocaml.org/t/ann-dune-3-6-0/10811> 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]. [Alan Schmitt] [send me a message] <mailto:alan.schm...@polytechnique.org> [the archive] <https://alan.petitepomme.net/cwn/> [RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <https://alan.petitepomme.net/>
_______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly