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.sche...@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.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
