[cwn] Attn: Development Editor, Latest OCaml Weekly News
Alan Schmitt
alan.schmitt at polytechnique.org
Tue Apr 11 05:41:37 PDT 2023
Hello
Here is the latest OCaml Weekly News, for the week of April 04 to 11,
2023.
Table of Contents
─────────────────
OCAML’23: The OCaml Users and Developers Workshop
Ldp 0.1.0
Dune 3.7.0
cmarkit 0.1.0 – CommonMark parser and renderer for OCaml
ocamlmark – An ocamldoc to CommonMark bi-directional translation
kcas and kcas_data 0.2.4 for lock-free concurrent programming
Low-hanging fruit for a PR contribution to the OCaml runtime code (C code)
Wed, Apr 12 @ 7pm U.S. Central: Jonah Beckford on “What distributing OCaml on Windows gave me (and you)”
zbg: Zero Bullshit Git
Old CWN
OCAML’23: The OCaml Users and Developers Workshop
═════════════════════════════════════════════════
Archive:
<https://sympa.inria.fr/sympa/arc/caml-list/2023-04/msg00004.html>
Oleg announced
──────────────
The OCaml Users and Developers Workshop: ACM SIGPLAN Workshop
September 9, 2023 (Saturday) Seattle, WA, USA and also online (two
days after main ICFP)
Call for presentations: <https://icfp23.sigplan.org/home/ocaml-2023>
Talk proposal submission deadline: Thursday June 1st, 2023
(Please redistribute widely.)
The OCaml Users and Developers Workshop brings together the OCaml
community, including users of OCaml in industry, academia, hobbyists
and the free software community.
OCaml 2023 will be co-located with ICFP 2023, which will take place in
Seattle, US. We aim to organize it as a hybrid event, so that people
can attend and even give talks remotely: talks will be streamed in
real-time, and virtual participants will be able to chat and ask
questions in writing.
Scope
╌╌╌╌╌
Presentations and discussions will focus on the OCaml programming
language and its community. We aim to solicit talks on all aspects
related to improving the use or development of the language and its
programming environment, including, for example (but not limited to):
• compiler developments, new backends, runtime and architectures
• practical type system improvements, such as (but not limited to)
GADTs, first-class modules, generic programming, or dependent types
• new library or application releases, and their design rationales
• tools and infrastructure services, and their enhancements
• prominent industrial or experimental uses of OCaml, or deployments
in unusual situations.
Presentations
╌╌╌╌╌╌╌╌╌╌╌╌╌
It will be an informal meeting with no formal proceedings. The
presentation material will be available online from the workshop
homepage. The presentations may be recorded, and made available at a
later time.
The main presentation format is a workshop talk, traditionally around
20 minutes in length, plus question time, but we also have a poster
session during the workshop – this allows to present more diverse
work, and gives time for discussion. The program committee will decide
which presentations should be delivered as posters or talks.
Submission
╌╌╌╌╌╌╌╌╌╌
To submit a presentation, please register a description of the talk
(about 2 pages long) at
<https://icfp23-ocaml.hotcrp.com/>
providing a clear statement of what will be provided by the
presentation: the problems that are addressed, the solutions or
methods that are proposed.
LaTeX-produced PDFs are a common and welcome submission format. For
accessibility purposes, we ask PDF submitters to also provide the
sources of their submission in a textual format, such as .tex sources.
Reviewers may read either the submitted PDF or the text version.
Important dates
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Thursday 1st June (any time zone): Abstract submission deadline
• Thursday 6h July: Author notification
• Saturday 9th September: OCaml Workshop
ML family workshop and post-proceedings
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
The ML family workshop, held on the previous day, deals with general
issues of the ML-style programming and type systems, focuses on more
research-oriented work that is less specific to a language in
particular (OCaml). There is an overlap between the two workshops, and
we have occasionally transferred presentations from one to the other
in the past. The authors who feel their submission fits both workshops
are encouraged to mention it at submission time and/or contact the
Program Chairs.
Program Committee
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Kenichi Asai (Ochanomizu University, Japan)
• Jonah Beckford (Diskuv Inc, US)
• Raja Boujbel (OCamlPro, France)
• Chris Casinghino (Janestreet, US)
• Nathanaelle Courant (OCamlPro, France)
• Jacques Garrigue (University of Nagoya, Japan)
• Kiran Gopinathan (National University of Singapore, Singapore)
• Oleg Kiselyov (Tohoku University, Japan)
• Benoit Montagu (INRIA, France)
• Sudha Parimala (Tarides, India)
• Matija Pretnar (University of Ljubljana, Slovenia)
• Jonathan Protzenko (Microsoft Research Redmond, US)
• Claude Rubinson (University of Arizona, US)
• Gabriel Scherer (INRIA, France)
Questions and contact
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Please send any questions to the chair:
Gabriel Scherer (gabriel.scherer at gmail.com)
Ldp 0.1.0
═════════
Archive: <https://discuss.ocaml.org/t/ann-ldp-0-1-0/11895/1>
Zoggy announced
───────────────
I’m pleased to announce the first release of [OCaml-ldp], which
includes
• the [`ldp'] package to build [LDP] (Linked Data Platform)
applications, runnable either in standalone program (using packages
[`ldp_tls'] or [`ldp_curl']) or in the browser (using package
[`ldp_js'] with js_of_ocaml).
• the [`solid'] package, providing a library to interact with [SOLID]
pods,
• the [`solid_server'] package, providing an experimental SOLID
server,
• the [`solid_tools'] package, including some basic command-line tools
to interfact with SOLID servers and a library to develop other
tools.
The packages should be available in opam soon.
[OCaml-ldp] <https://framagit.org/zoggy/ocaml-ldp>
[`ldp'] <https://zoggy.frama.io/ocaml-ldp/refdoc/ldp/index.html>
[LDP] <http://www.w3.org/TR/ldp/>
[`ldp_tls'] <https://zoggy.frama.io/ocaml-ldp/refdoc/ldp_tls/index.html>
[`ldp_curl']
<https://zoggy.frama.io/ocaml-ldp/refdoc/ldp_curl/index.html>
[`ldp_js'] <https://zoggy.frama.io/ocaml-ldp/refdoc/ldp_js/index.html>
[`solid'] <https://zoggy.frama.io/ocaml-ldp/refdoc/solid/index.html>
[SOLID] <https://solidproject.org/>
[`solid_server']
<https://zoggy.frama.io/ocaml-ldp/refdoc/solid_server/index.html>
[`solid_tools']
<https://zoggy.frama.io/ocaml-ldp/refdoc/solid_tools/index.html>
Dune 3.7.0
══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-7-0/11474/4>
Etienne Millon announced
────────────────────────
We just released a point release that fixes some issues:
3.8.0 is planned to be released in May.
3.7.1 (2023-04-04)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
• Fix segfault on MacOS when dune was being shutdown while in watch
mode. (#7312, fixes #6151, @gridbugs, @emillon)
• Fix preludes not being recorded as dependencies in the `(mdx)`
stanza (#7109, fixes #7077, @emillon).
• Pass correct flags when compiling `stdlib.ml`. (#7241, @emillon)
• Handle “Too many links” errors when using Dune cache on Windows. The
fix in 3.7.0 for this same issue was not effective due to a typo.
(#7472, @nojb)
cmarkit 0.1.0 – CommonMark parser and renderer for OCaml
════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-cmarkit-0-1-0-commonmark-parser-and-renderer-for-ocaml/11900/1>
Daniel Bünzli announced
───────────────────────
It’s my pleasure to announce the first release of the Cmarkit library.
Cmarkit parses the [CommonMark specification]. It provides:
• A CommonMark parser for UTF-8 encoded documents. Link label
resolution can be customized and a non-strict parsing mode can be
activated to add: strikethrough, LaTeX math, footnotes, task items
and tables.
• An extensible abstract syntax tree for CommonMark documents with
source location tracking and best-effort source layout preservation.
• Abstract syntax tree mapper and folder abstractions for quick and
concise tree transformations.
• Extensible renderers for HTML, LaTeX and CommonMark with source
layout preservation.
Cmarkit is distributed under the ISC license. It has no dependencies.
This first release benefited from a grant from the [OCaml software
foundation]. Funding from my few but faithfull [donators] is also
paramount to get these tedious bits out for release. Thank you all for
your support.
• Homepage: <https://erratique.ch/software/cmarkit>
• Docs: <https://erratique.ch/software/cmarkit/doc> (or `odig doc
cmarkit')
• Install: `opam install cmarkit' (once this [PR] is merged)
Daniel Bünzli then added
────────────────────────
Since someone is going to ask here’s my biased comparison between
`cmarkit' and [`omd'], the only other OCaml commonmark parser I’m
aware of.
This is based on what I see [here] and what I fell on in using the
`omd' tool.
1. `cmarkit' takes the whole document as input, `omd' can work line by
line on input channels. Note however that in practice due to how
CommonMark parsing works you need it in memory anyways and wait for
the end of input to trigger inline parsing.
2. `cmarkit' should conform to the CommonMark spec, all conformance
tests pass. I don’t think `omd' does since U+0000 doesn’t seem to
be replaced by U+FFFD and in general it seems to forgo UTF
decoding.
3. `cmarkit' provides location tracking and source layout information
in the AST `omd' does not.
4. `cmarkit' fails on 3/22 (2/22 in OCaml 5) of the `cmark'
[pathological tests]. `omd' fails on 17/22 of them.
5. From commonmark to html on a large 12Mo md file, `cmarkit' seems
slightly faster (26%) than `omd' (even when locs and layout it’s
still 10% faster). But no scientific benchmark was performed. Nor
particular attention was paid to that. Nor is it likely to be
important in practice (unless you are in charge of rendering all
the READMEs of a code hosting platform).
6. `cmarkit' has renderers to CommonMark (layout preserving) and
LaTeX. `omd' hasn’t, but it has one to sexp which `cmarkit' hasn’t.
7. `cmarkit' renderers are extensible and partially redefinable. `omd'
ones aren’t.
8. `cmarkit' lets client customize link label definition and
resolution which allows to embed data binding DSLs in the very
flexible label syntax. `omd' has no such thing.
9. `cmarkit'’s AST is extensible. `omd'’s one is not.
10. `cmarkit' as per node extensible metadata. `omd' uses a
polymorphic scheme.
11. `cmarkit' has AST mappers and folders. `omd' has no such thing.
12. `cmarkit' has no dependencies. `omd' depends on a bunch of other
packages.
13. `cmarkit' and `omd' support different syntax extensions. It is
unclear which ones are supported by `omd', for `cmarkit' see the
docs.
14. `cmarkit' reuses the CommonMark spec vocabulary and the docs are
fully hyperlinked into the specification to help you understand
the terrible morass you are dealing with.
15. `cmarkit', the tool provided with the library, is a bit more
featureful than the `omd' (or reference `cmark') tool. Notably
(with enough options specified :–) support is provided to output
full HTML and LaTeX documents that are ready to read and render.
In general I’d say `omd' is fine if you are just interested in taking
a CommonMark string to a default CommonMark rendering. If you are
interested in making systems that integrate CommonMark as a medium
that you process and play with you will be better off with `cmarkit'.
Finally it should be noted that `omd' was started in darker times when
no CommonMark specification existed. Having spent a significant amount
of time on `cmarkit' /with/ a specification one can only appreciate
the thoughness of the initial effort.
[`omd'] <https://github.com/ocaml/omd>
[here] <https://ocaml.org/p/omd/latest/doc/Omd/index.html>
[pathological tests]
<https://github.com/dbuenzli/cmarkit/blob/main/test/pathological.ml>
ocamlmark – An ocamldoc to CommonMark bi-directional translation
════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/poc-ocamlmark-an-ocamldoc-to-commonmark-bi-directional-translation/11901/1>
Daniel Bünzli announced
───────────────────────
As a show-off for the [recently announced cmarkit]. I have devised
`ocamlmark', a bi-directional translation between [`ocamldoc'] and
[CommonMark] with the least amount of CommonMark extensions possible.
It is defined in [this document].
This unreasonable hack benefited from a grant of the [OCaml Software
Foundation]. It was however not solicited by The Foundation and does
not represent any endorsement by The Foundation.
A fully functional proof of concept[^1] implementation on
`odoc-parser' can be found in [this PR]. If you want to try it you
should be able to:
┌────
│ opam pin odoc --dev
│ opam pin add cmarkit https://erratique.ch/repos/cmarkit.git # or opam install cmarkit
│ opam pin add odoc-parser https://github.com/dbuenzli/odoc-parser#ocamlmark
└────
It allows you to write your OCaml docstrings and `.mld' files in
`ocamlmark'. Both `ocamlmark' and `ocamldoc' syntaxes are supported
transparently by [sniffing] each comment for a syntax.
If `ocamlmark' is detected, `cmarkit' is used to parse the comment and
the resulting abstract syntax tree is translated to `ocamldoc'’s one.
Thanks to precise source location tracking on both sides all errors
reported by `odoc' should be reported correctly in `ocamlmark'
constructs.
This shows how to use `cmarkit'’s label [resolvers] to good effect.
Namely to provide the counter part to `ocamldoc' extensive
cross-reference linking capabilities by allowing to specify them with
the same syntax – save for the braces – in CommonMark’s link labels.
Personally I’m not really convinced it’s a good idea, doc QA and
readability are concerns, see the [tradeoffs]. But I’d just thought
I’d put that on the table for discussion; sometimes it’s better to
think we could have it rather than have it ;–)
[^1]: Except for missing support for @-tags and `odoc' latest addition
(math and tables, but they are supported by `cmarkit') it is
reasonably complete.
[recently announced cmarkit]
<https://discuss.ocaml.org/t/ann-cmarkit-0-1-0-commonmark-parser-and-renderer-for-ocaml/11900?u=dbuenzli>
[`ocamldoc'] <https://ocaml.org/manual/ocamldoc.html#ss:ocamldoc-syntax>
[CommonMark] <https://spec.commonmark.org/current>
[this document]
<https://github.com/dbuenzli/odoc-parser/blob/ocamlmark/doc/ocamlmark.md>
[OCaml Software Foundation] <http://ocaml-sf.org/>
[this PR] <https://github.com/ocaml-doc/odoc-parser/pull/15>
[sniffing]
<https://github.com/dbuenzli/odoc-parser/blob/ecf8f06c8b08a0c366b69cff799bfa0b36489281/src/ocamlmark.ml#L4-L42>
[resolvers]
<https://erratique.ch/software/cmarkit/doc/Cmarkit/Label/index.html#resolvers>
[tradeoffs]
<https://github.com/dbuenzli/odoc-parser/blob/ocamlmark/doc/ocamlmark.md#advantages>
kcas and kcas_data 0.2.4 for lock-free concurrent programming
═════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-kcas-and-kcas-data-0-2-4-for-lock-free-concurrent-programming/11907/1>
Vesa Karvonen announced
───────────────────────
I’m happy to announce that the [`kcas'] package now has a
[`kcas_data'] companion package that provides implementations of
compositional lock-free data structures implemented using `kcas'.
What is [`kcas']?
*kcas* provides an implementation of atomic lock-free
multi-word compare-and-set (MCAS), which is a powerful
tool for designing concurrent algorithms.
On top of the efficient multi-word compare-and-set algorithm, `kcas'
provides compositional transactional programming interfaces that can
make it much easier to implement concurrent algorithms.
The first version of the new [`kcas_data'] package includes domain
safe [`Hashtbl'], [`Queue'], and [`Stack'] data structures that all
mimic the corresponding `Stdlib' module interfaces and can be more or
less be used as drop-in replacements *when domain safety is needed*.
The `kcas_data' data structures also provide transactional interfaces
that allow one to compose new lock-free operations with any other
`kcas' based transactions. For example, given a `queue' and a `stack'
one can atomically take an element from the `queue' and push it to the
`stack' using a transaction written in direct style via explicit
transaction log passing as follows:
┌────
│ let tx ~xt =
│ match Queue.Xt.take_opt ~xt queue with
│ | None -> ()
│ | Some value ->
│ Stack.Xt.push ~xt stack value
│ in
│ Xt.commit { tx }
└────
Aside from offering composability, the provided data structures should
give good performance and scalability compared to protecting all
accesses of unsynchronized `Stdlib' data structures using locks.
Feel free to give the new `kcas_data' package a spin!
I would also like to encourage people to try and implement more
compositional lock-free data structures using `kcas'. It is fairly
straightforward to translate textbook imperative data structures using
`kcas' to make them domain safe and lock-free and the project [README]
comes with many examples.
Note that while the `kcas_data' package is currently in the [`kcas']
repository, it might later be moved to be a part of the repository
that is currently called [`lockfree'].
[`kcas'] <https://opam.ocaml.org/packages/kcas/>
[`kcas_data'] <https://opam.ocaml.org/packages/kcas_data/>
[`kcas'] <https://github.com/ocaml-multicore/kcas/#readme>
[`kcas_data']
<https://ocaml-multicore.github.io/kcas/0.2.4/kcas_data/Kcas_data/index.html>
[`Hashtbl']
<https://ocaml-multicore.github.io/kcas/0.2.4/kcas_data/Kcas_data/Hashtbl/index.html>
[`Queue']
<https://ocaml-multicore.github.io/kcas/0.2.4/kcas_data/Kcas_data/Queue/index.html>
[`Stack']
<https://ocaml-multicore.github.io/kcas/0.2.4/kcas_data/Kcas_data/Stack/index.html>
[README] <https://github.com/ocaml-multicore/kcas/tree/0.2.4#readme>
[`kcas'] <https://github.com/ocaml-multicore/kcas>
[`lockfree'] <https://github.com/ocaml-multicore/lockfree/pull/67>
Low-hanging fruit for a PR contribution to the OCaml runtime code (C code)
══════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/low-hanging-fruit-for-a-pr-contribution-to-the-ocaml-runtime-code-c-code/11914/1>
gasche announced
────────────────
I’m the shepherd for the upstream compiler issue
<https://github.com/ocaml/ocaml/issues/12037> , which is about a
potential code improvement noticed by `gcc -fanalyzer'. The issue has
somewhat-detailed explanations of what could be done to solve it
nicely.
If you have been looking for an opportunity to contribute to the
upstream OCaml compiler, this may be one. This is in the runtime code,
implemented in C, and `extern.c' is the marshaller (what runs when you
use `output_value' or `Marhsal.to_string').
Assuming you are already familiar with C and typical git+github
workflows, but have never contributed to the OCaml compiler codebase,
here would be a time estimate:
• 1h to get familiar with the github/ocaml repository (clone it,
configure it, build it, etc.; I am assuming that you are not trying
to program from a Windows machine, which may be harder), which
includes skimming
<https://github.com/ocaml/ocaml/blob/trunk/CONTRIBUTING.md> and
<https://github.com/ocaml/ocaml/blob/trunk/HACKING.adoc>
• 1h-2h to write an initial patch that you are happy with and send a
PR
• 1h-3h of addressing CI issues and review comments
Wed, Apr 12 @ 7pm U.S. Central: Jonah Beckford on “What distributing OCaml on Windows gave me (and you)”
════════════════════════════════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/wed-apr-12-7pm-u-s-central-jonah-beckford-on-what-distributing-ocaml-on-windows-gave-me-and-you/11926/1>
Claude Jager-Rubinson announced
───────────────────────────────
Please join the Houston Functional Programming User Group next
Wednesday, April 19 at 7pm U.S. Central time (midnight UTC) when Jonah
Beckford (@jbeckford) will discuss his work on developing Diskuv OCaml
(DkML).
As everybody who’s been following DkML’s development is aware, Jonah’s
work on bringing OCaml and it’s toolchain to Windows is incredibly
impressive. In this talk, he’ll discuss why he decided upon this path,
the challenges that he faced and how he overcame them, and his ongoing
and future work, including the OCaml SDK that he will release this
year.
If you’re in the Houston area, you can join us in person. Otherwise,
please join us via Zoom. Compete details, including his abstract and
Zoom connection info are available on our website at
[https://hfpug.org].
[https://hfpug.org] <https://hfpug.org>
zbg: Zero Bullshit Git
══════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-zbg-zero-bullshit-git/11929/1>
Dmitrii Kovanikov announced
───────────────────────────
Good morning everyone! :sunrise:
I’ve started learning OCaml only recently, and I would like to share
my OSS project with everyone:
• [:sparkles: `zbg' — Zero Bullshit Git]
I’ve been using `git' for many years, and I came up with a workflow
that works perfectly for me but it was tedious to type all the
commands manually, and `.gitconfig' aliases weren’t powerful enough.
So I decided to package my workflow into a CLI tool. I also added
prettier versions of some commands. Maybe you’ll enjoy them too :hugs:
I started learning OCaml only recently; this is my first OSS project
with OCaml. Before that, I was mostly using Haskell for the last 7
years. Still, I would greatly appreciate suggestions on improving the
code, making it more idiomatic, utilizing OCaml tooling, and
everything else. Feedback is welcome!
There’s still some work to be done in `zbg', so if you want to have
fun and join the development, have a look at [open issues].
[:sparkles: `zbg' — Zero Bullshit Git] <https://github.com/chshersh/zbg>
[open issues] <https://github.com/chshersh/zbg/issues>
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/20230411/14d01909/attachment-0001.html>
More information about the caml-news-weekly
mailing list