[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Feb 21 02:19:27 PST 2023
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.schmitt at 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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/caml-news-weekly/attachments/20230221/69796af9/attachment-0001.html>
More information about the caml-news-weekly
mailing list