From: Alan Schmitt <alan.schmitt@polytechnique.org> To: "lwn" <lwn@lwn.net>, "cwn" <cwn@lists.idyll.org>, caml-list@inria.fr, comp@lists.orbitalfox.eu Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Date: Tue, 26 Jan 2021 14:25:08 +0100 [thread overview] Message-ID: <87wnvz96ff.fsf@m4x.org> (raw) [-- Attachment #1: Type: text/plain, Size: 31437 bytes --] Hello Here is the latest OCaml Weekly News, for the week of January 19 to 26, 2021. Table of Contents ───────────────── How to get pleasant documentation for a library using Dune? Alt-Ergo 2.4.0 release First release of Art - Adaptive Radix Tree in OCaml perf demangling of OCaml symbols (and a short introduction to perf) Decimal 0.2.1 - arbitrary-precision decimal floating point Basic GitLab CI configuration OCaml Office Hours? json-data-encoding 0.9 VSCode OCaml Platform v1.6.0 release 0.3.0 of drom, the OCaml project creator Old CWN How to get pleasant documentation for a library using Dune? ═══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/how-to-get-pleasant-documentation-for-a-library-using-dune/7121/1> gasche announced ──────────────── I'm working to publish a small library using Dune. The documentation automatically generated by `dune build @doc' looks fairly unpleasant to me, as I don't see an easy way to explain what the library is about. I'm creating this topic in case I am missing something simple, and to get other people to share their library-documentation practices or examples. Problem description ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ For the sake of the example let's imagine that the library is called `Foo' and contains three modules `A', `B' and `C'. I'm using the standard dune approach of wrapped modules, so I get three compilation units `Foo.A', `Foo.B', `Foo.C'. Each module has a `.mli' file with documentation comments. When I run `dune build @doc', dune generates an `index.html' file with basically no content, pointing to a `foo/index.html' file with basically no content, pointing to a `foo/Foo/index.html' looking like this: Up – foo » Foo *Module `Foo'* `module A : sig ... end' `module B : sig ... end' `module C : sig ... end' It's easy to skip the first two pages, and use the third page as a landing page for the documentation of my library. However, this landing page is not very pleasant: 1. It should explain what the library is about. 2. It should briefly describe what each module does, so that users know which module they want to look at first. (Point 2 is especially important with "wrapped libraries", where it's not necessarily obvious which of the several modules is the main entry point with the important functions to look at first. In comparison, in a design where the "entry point" is in the `Foo' module, with `Foo.A' and `Foo.B' as more advanced submodules (or `Foo_A' and `Foo_B' in the old days) the user is guided to look at `Foo' first.) My problem is: what should I change in my Dune setup to be able to do this? I have read the [dune documentation on documentation], but I could not find an answer to this question. [dune documentation on documentation] <https://dune.readthedocs.io/en/stable/documentation.html> Rough ideas ╌╌╌╌╌╌╌╌╌╌╌ Roughly I see two ways to get what I want, that I have not tried yet: 1. I could write my own landing page for the library as a separate `doc.mld' file, use the `(documentation)' stanza to get it included in the built documentation, and use this as the entry point into my library. 2. In could write my own `foo.ml' module instead of using Dune's default wrapped-module scaffolding, inserting my own `module A = Foo__A' aliases, with documentation comments in the standard style. Then I suppose that `foo/Foo/index.html' would get this content in the way I expect. They feel a bit complex to me, and (2) involves the tedious work of redoing the wrapping logic myself. I guess that (1) is not so bad, and I would be inclined to do this if it was documented somewhere as the recommended approach. (Maybe there is some odoc option that would help solve this problem?) Examples from other people? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Do you have a library built using dune with nice documentation? If so, can you show the documentation and the corresponding sources (in particular dune setup)? Thibaut Mattio replied ────────────────────── I think the documentation of [Streaming] is a great example of the option 1 you describe. The corresponding Dune setup can be found [here] That's also the approach we took for [Opium's documentation], although the index page is certainly not as impressive as Streaming's. [Streaming] <https://odis-labs.github.io/streaming/streaming/index.html> [here] <https://github.com/odis-labs/streaming/blob/master/streaming/dune> [Opium's documentation] <https://rgrinberg.github.io/opium/opium/index.html> gasche then said ──────────────── Thanks! It looks like these systems rely on an undocumented feature of the `(documentation)' stanza (or odoc), which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. The opium documentation also [uses] the `{!modules: modulename ...}' markup directive, which is a way to include the module index within this manually-written landing page without having to duplicate the markup. Streaming¹ uses [inline html] instead to get a nicer-looking result, but it is too much effort. Maybe there is a better way, or the tools could be improved to make this easier. ¹: I'm ashamed to admit that I wasn't aware of this very nice library [Streaming], am I consuming the wrong sources of information on the OCaml ecosystem? Finally, the Opium documentation manifestly has a short synopsis for each module in its listing, which corresponds to my "It should briefly describe what each module does" requirement. I believe that this comes from the first line of the first documentation comment of the module. There are module-global documentation comments in the library I'm working on, but they do not include such first-line headers. Once I have the impression of understanding what is a good way to do this, I may try to contribute better documentation in `dune'. [uses] <https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74> [inline html] <https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68> [Streaming] <https://odis-labs.github.io/streaming/streaming/index.html> Gabriel Radanne replied ─────────────────────── It looks like these systems rely on an undocumented feature of the `(documentation)' stanza (or odoc), which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. I confirm this feature is here to stay, is the right one to customize your index page, and in the future will benefit from good support from odoc directly. The opium documentation also [uses] the `{!modules: modulename ...}' markup directive, which is a way to include the module index within this manually-written landing page without having to duplicate the markup. Streaming¹ uses [inline html] instead to get a nicer-looking result, but it is too much effort. Maybe there is a better way, or the tools could be improved to make this easier. I would strongly advise to use the `modules' markup directive, and to suggests output improvements on odoc's bug instead of hacking HTML together. We could absolutely add the synopsis of the module here, for instance. [uses] <https://github.com/rgrinberg/opium/blob/2a89e35/opium/doc/index.mld#L72-L74> [inline html] <https://github.com/odis-labs/streaming/blob/ee5d82a/streaming/index.mld#L32-L68> Daniel Bünzli then said ─────────────────────── which is that a user-provided `index.mld' file will implicitly replace the automatically-generated `index.mld' file, giving a reasonably natural result. This is also the correct way to customize the landing page of your package for `odig' generated doc sets, see [here] for more information. I confirm this feature is here to stay, is the right one to customize your index page, and in the future will benefit from good support from odoc directly. There's an open issue about that [here]. [here] <https://erratique.ch/software/odig/doc/packaging.html#odoc_api_and_manual> [here] <https://github.com/ocaml/odoc/issues/297> Alt-Ergo 2.4.0 release ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-alt-ergo-2-4-0-release/7134/1> OCamlPro announced ────────────────── We are pleased to announce a new release of Alt-Ergo! Alt-Ergo 2.4.0 is now available from [Alt-Ergo’s website]. An associated opam package will be published in the next few days. This release contains some major novelties: • Alt-Ergo supports incremental commands (push/pop) from the[ smt-lib] standard. • We switched command line parsing to use[ cmdliner]. You will need to use –<option name> instead of -<option name>. Some options have also been renamed, see the manpage or the documentation. • We improved the online documentation of your solver, available[ here]. This release also contains some minor novelties: • .mlw and .why extension are depreciated, the use of .ae extension is advised. • Add –input (resp –output) option to manually set the input (resp output) file format • Add –pretty-output option to add better debug formatting and to add colors • Add exponentiation operation, ** in native Alt-Ergo syntax. The operator is fully interpreted when applied to constants • Fix –steps-count and improve the way steps are counted (AdaCore contribution) • Add –instantiation-heuristic option that can enable lighter or heavier instantiation • Reduce the instantiation context (considered foralls / exists) in CDCL-Tableaux to better mimic the Tableaux-like SAT solver • Multiple bugfixes The full list of changes is available [here]. As usual, do not hesitate to report bugs, to ask questions, or to give your feedback! [Alt-Ergo’s website] <https://alt-ergo.ocamlpro.com/> [ smt-lib] <https://smtlib.cs.uiowa.edu/> [ cmdliner] <https://erratique.ch/software/cmdliner> [ here] <https://ocamlpro.github.io/alt-ergo/> [here] <https://ocamlpro.github.io/alt-ergo/About/changes.html> First release of Art - Adaptive Radix Tree in OCaml ═══════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-first-release-of-art-adaptive-radix-tree-in-ocaml/7142/1> Calascibetta Romain announced ───────────────────────────── I'm glad to announce the first release of [`art'], an implementation of [the Adaptive Radix Tree] in OCaml. The goal of this library is to provide a data-structure such as `Map.S' (and keep the order) with performances of `Hashtbl.t'. [`art'] <https://github.com/dinosaure/art> [the Adaptive Radix Tree] <https://db.in.tum.de/~leis/papers/ART.pdf> Performances ╌╌╌╌╌╌╌╌╌╌╌╌ `art' uses [Bechamel] as a tool for micro-benchmarking and it compares performances about [insertion] and [lookup]. As you can see, about insertion, `art' is definitely more fast than `Hashtbl.t'. For the _lookup_ operation, we are slightly more fast than the `Hashtbl.t'. The main advantage comparing to `Hashtbl.t' is the ability to use `maximum~/~minimum' or to `iter' over the whole data-structure with a certain order. On details, benchmarks use a normal distribution of `strings' about their lengths. As a practical example where `art' will be better than `Hashtbl.t' is when you want to _index_ several words (such as email addresses). [Bechamel] <https://github.com/mirage/bechamel> [insertion] <https://dinosaure.github.io/art/bench/insert.html> [lookup] <https://dinosaure.github.io/art/bench/find.html> Tests ╌╌╌╌╌ Of course, the library provide [a fuzzer] and tests have a coverage of: 91.93 % [a fuzzer] <https://github.com/dinosaure/art/blob/master/fuzz/fuzz.ml> Read Optimized Write Exclusion - ROWEX ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Even if it's not a part of the package, the distribution comes with _lock-free_ implementation of `art': `rowex'. This implementation comes from [a research paper] about data-structure and atomic operations. ROWEX provides a _persistent_ implementation which manipulates a file to store the whole data-structure. The goal is to provide an _indexer_ free to be manipulated by several processes in parallel. Currently, the implementation of ROWEX in OCaml is not well-tested and it is no distributed. It does not take the advantage of [ocaml-multicore] (but it should) but outcomes are good and the development will be more focus on this part. So feel free to play with it a bit :+1:. [a research paper] <https://db.in.tum.de/~leis/papers/artsync.pdf> [ocaml-multicore] <https://github.com/ocaml-multicore/ocaml-multicore> perf demangling of OCaml symbols (and a short introduction to perf) ═══════════════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-perf-demangling-of-ocaml-symbols-a-short-introduction-to-perf/7143/1> Fabian announced ──────────────── As a project sponsored by the [OCaml software foundation], I've worked on demangling OCaml symbols in [perf]. Some screenshots are below. The work is currently being upstreamed. In the meantime, it can be used as follows: ┌──── │ git clone --depth=1 https://github.com/copy/linux.git │ # or: │ # wget https://github.com/copy/linux/archive/master.tar.gz && tar xfv master.tar.gz │ cd linux/tools/perf │ make │ alias perf=$PWD/perf │ # or copy perf to somewhere in your PATH └──── Your distribution's version of perf will also work for the examples below, but will have less readable symbols :-) [OCaml software foundation] <https://ocaml-sf.org/> [perf] <https://perf.wiki.kernel.org/index.php/Main_Page> Short intruction to perf ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Perf is a Linux-only sampling profiler (and more), which can be used to analyse the performance profile of OCaml and other executables. When compiling with ocamlopt, add `-g' to include debug information in the executable. dune does this automatically, even in the release profile. To start a program and record its profile: ┌──── │ perf record --call-graph dwarf program.exe └──── Or record a running program: ┌──── │ perf record --call-graph dwarf -p `pidof program.exe` └──── Then, view a profile using: ┌──── │ perf report # top-down │ perf report --no-children # bottom-up └──── Within the report view, the following keybindings are useful: • `+': open/close one callchain level • `e': open/close entire callchain • `t': Toggle beween current thread and all threads (e.g., only `dune', `ocamlopt', etc.) Or generate a flamegraph: ┌──── │ git clone https://github.com/brendangregg/FlameGraph │ cd FlameGraph │ perf script -i path/to/perf.data | ./stackcollapse-perf.pl | ./flamegraph.pl > perf-flamegraph.svg └──── You may need to run the following command to allow recording by non-root users ([more infos]): ┌──── │ echo 0 | sudo tee /proc/sys/kernel/perf_event_paranoid └──── [more infos] <https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html#unprivileged-users> Sources ╌╌╌╌╌╌╌ • [Profiling OCaml code] • <https://perf.wiki.kernel.org/index.php/Tutorial#Sampling_with_perf_record> • <http://www.brendangregg.com/perf.html#FlameGraphs> Before: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/9/95433869e4d55c6c822a096a901483304d44338d_2_1380x602.png> After: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/3/3bf847ea23608973644175927e09d4d039ab720e_2_1380x602.png> Bottom-up: <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/0/01042663ccf66e8b955723fae3cd1c6ff9e0b029_2_1380x602.png> Flamegraph (cropped): <https://aws1.discourse-cdn.com/standard11/uploads/ocaml/optimized/2X/c/c8e3e0f5b9e1d879198892395529ebb3c339c791_2_1380x602.png> [Profiling OCaml code] <https://github.com/ocaml-bench/notes/blob/master/profiling_notes.md> Decimal 0.2.1 - arbitrary-precision decimal floating point ══════════════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/decimal-0-2-1-arbitrary-precision-decimal-floating-point/7144/1> Yawar Amin announced ──────────────────── Happy to announce that `decimal' 0.2.1 has been [pubished on opam]. `decimal' is a port of [Python's `decimal' module] to OCaml and implements the [General Decimal Arithmetic Specification]. However note that it is a port in progress–basic arithmetic and rounding functions have been ported, but I am still working on powers and logs. The ported functions pass the same unit test suite that the Python version does (with some minor modifications). Another caveat: currently the library is only supported on 64-bit architectures due to (exponent) overflow issues on 32-bit. If anyone is willing to test and fix overflows on 32-bit, I am more than happy to accept PRs. Here's an example of using the module: ┌──── │ (* Rosetta Code Currency Example *) │ │ (* Demo purposes, normally you'd prefix module name or local open *) │ open Decimal │ │ let hamburger_qty = of_string "4_000_000_000_000_000" │ let hamburger_amt = of_string "5.50" │ let milkshake_qty = of_int 2 │ let milkshake_amt = of_string "2.86" │ │ (* Shortcut to divide 7.65 by 100 *) │ let tax_rate = of_string "7.65e-2" │ │ let subtotal = hamburger_qty * hamburger_amt + milkshake_qty * milkshake_amt │ let tax = round ~n:2 (subtotal * tax_rate) │ let total = subtotal + tax │ │ let () = Format.printf "Subtotal: %a │ Tax: %a │ Total: %a\n" pp subtotal pp tax pp total └──── You can get the package with: `opam install decimal'. Minimum OCaml version 4.08. [pubished on opam] <http://opam.ocaml.org/packages/decimal/> [Python's `decimal' module] <https://docs.python.org/3/library/decimal.html> [General Decimal Arithmetic Specification] <http://speleotrove.com/decimal/decarith.html> Basic GitLab CI configuration ═════════════════════════════ Archive: <https://discuss.ocaml.org/t/basic-gitlab-ci-configuration/3327/25> gasche announced ──────────────── After a long ci-golfing adventure (83 tests), I got a `.gitlab-ci.yml' file that I think is reusable and useful for small projects / libraries: • project: <https://gitlab.com/gasche/gitlab-ocaml-ci-example> • configuration file: <https://gitlab.com/gasche/gitlab-ocaml-ci-example/-/blob/main/.gitlab-ci.yml> Features: • It is project-agnostic, so it should work unchanged for your own (simple) projects. • It caches the opam dependencies. • It builds the project, runs the tests and builds the documentation. • Several compiler versions can be tested in parallel. • It provides an easy way to upload the documentation as "Gitlab project Pages". CI times are satisfying: on very small libraries I observe a 11mn job time on the first run (or when cleaning the opam cache), and 2mn job time on following runs. The expected usage-mode of this CI configuration is that you copy it in your own project. If you find that you need/want additional features, ideally you would try to write them in a project-agonistic way and contribute them back to the example repository. This configuration does not use @smondet's trick of generating a docker image on the fly. I think this would be an excellent idea to get more reliable caching, but it is too complex for me and I don't see how to do it in a maintainable and project-agnostic way. Current status ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I wrote this CI configuration over the week-end, and have not used it much. I expect it to keep evolving somewhat before it stabilizes. Feedback from other people trying to use the configuration would be warmly welcome. Aside on `_build' caching ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I also implemented caching of dune's `_build' data, inspired by the [data-encoding] example of @raphael-proust. I don't need it for my small projects (dune build is 3s, compared to 1m setting up the Docker image), but I thought it would make the CI configuration scale better to larger projects. When I tested this CI configuration, I discovered that caching the dune `_build' data does not work as well as I had expected. (Tracking issue: [dune#4150]). I can tell because I am asking dune to tell me about what it is rebuilding (`dune build --display short'). I suspect that projects that cache the `_build' data *without* logging what dune (re)builds are also not caching as much as they think they are. (But then maybe the use of a fixed-compiler OPAM image, as data-encoding is using, solves the issue.) [data-encoding] <https://gitlab.com/nomadic-labs/data-encoding/-/blob/master/.gitlab-ci.yml> [dune#4150] <https://github.com/ocaml/dune/issues/4150> official CI template? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I considered submitting this CI configuration as an "OCaml Gitlab CI template" to go with the official list of "blessed" CI templates in [the documentation]. But reading the [Development guide for Gitlab CI/CD templates] convinced me that my CI configuration is nowhere ready to serve this role. Gitlab developers apparently expect that users will be able to "include" those CI templates by pointing to their URL, and then tune it for their own use-case (without modifying it) by performing some (unreasonable?) inheritance tricks using whatever those configurations offers as abstraction/inheritance/extension/overriding mechanism. Let's just say that this is next-level CI configuration writing, and that my script is not ready for this. [the documentation] <https://docs.gitlab.com/ee/ci/examples/README.html#cicd-templates> [Development guide for Gitlab CI/CD templates] <https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/cicd/templates.md> OCaml Office Hours? ═══════════════════ Archive: <https://discuss.ocaml.org/t/ocaml-office-hours/7132/4> Deep in this thread, UnixJunkie said ──────────────────────────────────── In addition to mailing lists and discuss, there is also an IRC channel where people can interact with some ocaml experts in a more "interactive" manner (<irc://irc.freenode.net/#ocaml>) json-data-encoding 0.9 ══════════════════════ Archive: <https://discuss.ocaml.org/t/ann-json-data-encoding-0-9/7157/1> Raphaël Proust announced ──────────────────────── On behalf of [Nomadic Labs], I'm happy to announce the release of json-data-encoding version 0.9. The code is hosted on Gitlab: <https://gitlab.com/nomadic-labs/json-data-encoding> It is distributed under GNU LGPL with linking exception. The documentation is available online: <https://nomadic-labs.gitlab.io/json-data-encoding/> The package is available under opam: `opam install json-data-encoding' json-data-encoding is a library to define encoder/decoder values to translate OCaml values to JSON and back. It also generates JSON schemas so you can document the value representation. It can use either Ezjsonm or Yojson as backends. The version 0.9 has the following new features: • more tests • memoisation of fixpoint encoding to avoid repeated computations • support for `format' field for string schemas (see <https://json-schema.org/understanding-json-schema/reference/string.html#format>) (contributed by @levillain.maxime) • fixed integer bound printing in schemas (bug report by @pw374) • support for json-lexeme streaming (see details below) • support for inclusion/exclusion of default-value fields during serialisation (contributed by @levillain.maxime) • improved union-of-object schemas (contributed by @levillain.maxime) One major difference with the previous release is the inclusion of a lexeme-streaming JSON constructor. Specifically, the function ┌──── │ val construct_seq : 't encoding -> 't -> jsonm_lexeme Stdlib.Seq.t └──── generates a sequence of `Jsonm.lexeme' (the . This sequence is lazy (in the sense of `Stdlib.Seq' not of `Stdlib.Lazy') and it paves the way to a similar feature in `data-encoding'. An interesting feature of sequences is that they can be used in Vanilla OCaml settings as well as Lwt/Async settings where they allow user-driven yielding in between elements. [Nomadic Labs] <https://nomadic-labs.com/> VSCode OCaml Platform v1.6.0 ════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-vscode-ocaml-platform-v1-6-0/7164/1> Rudi Grinberg announced ─────────────────────── On behalf of the vscode-ocaml-platform team, I'm pleased to announce 1.6.0. This release contains a new activity tab for managing opam switches developed by @tmattio. We hope you find it useful. Change log: ┌──── │ - Highlight token aliases in Menhir associativity declarations (#473) │ │ - Activate the extension when workspace contains OCaml, Reason sources or │ project marker files. (#482) │ │ - Add `ocaml.useOcamlEnv` setting to determine whether to use `ocaml-env` for │ opam commands from OCaml for Windows (#481) │ │ - Fix terminal creation when using default shell and arguments (#484) │ │ - Add an OCaml activity tab. │ │ The activity tab provides three views: the available switches, the build │ commands and an Help and Feedback section with links to community channels. │ │ - Support `eliom` and `eliomi` file extensions (#487) │ │ - Fix ocaml/ocaml-lsp#358: automatic insertion of an inferred interface was │ inserting code incorrectly on the second switch to the newly created (unsaved) │ `mli` file. If the new `mli` file isn't empty, we don't insert inferred │ interface (#498) └──── release 0.3.0 of drom, the OCaml project creator ════════════════════════════════════════════════ Archive: <https://discuss.ocaml.org/t/ann-release-0-3-0-of-drom-the-ocaml-project-creator/7166/1> Fabrice Le Fessant announced ──────────────────────────── We are pleased to release version 0.3.0 of `drom', the OCaml project creator. `drom' is born from a simple observation: every time you create a new OCaml project, you spend time searching and copy-pasting files from other projects, adapting them to the new one. `drom' does that for you: it comes with a set of predefined skeleton projects, that you can easily configure and adapt to your goal. It's as easy as: ┌──── │ $ drom new │ # check the list of skeletons │ $ drom new PROJECT_NAME --skeleton SKELETON_NAME │ $ cd PROJECT_NAME │ $ emacs drom.toml │ # ... edit basic description, dependencies, etc. ... │ $ drom project │ $ drom build └──── Thanks to contributors (Maxime Levillain and David Declerck), the list of project skeletons for drom 0.3.0 has grown: • OCaml projects: library menhir mini_lib mini_prg ppx_deriver ppx_rewriter program • C Bindings: c_binding ctypes_foreign ctypes_stubs • Javascript projects: js_lib js_prg vue wasm_binding and you can easily contribute your own: for example, `gh:USER/SKELETON' will trigger the download of the `USER/SKELETON' project from Github as a template for your new project. `drom' is available from `opam': `opam update && opam install drom.0.3.0' <https://github.com/ocamlpro/drom> Enjoy ! 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@polytechnique.org> [the archive] <http://alan.petitepomme.net/cwn/> [RSS feed of the archives] <http://alan.petitepomme.net/cwn/cwn.rss> [online] <http://lists.idyll.org/listinfo/caml-news-weekly/> [Alan Schmitt] <http://alan.petitepomme.net/> [-- Attachment #2: Type: text/html, Size: 49515 bytes --]
next reply other threads:[~2021-01-26 13:25 UTC|newest] Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-26 13:25 Alan Schmitt [this message] -- strict thread matches above, loose matches on Subject: below -- 2022-05-24 8:04 Alan Schmitt 2022-05-17 7:12 Alan Schmitt 2022-05-10 12:30 Alan Schmitt 2022-05-03 9:11 Alan Schmitt 2022-04-26 6:44 Alan Schmitt 2022-04-19 5:34 Alan Schmitt 2022-04-12 8:10 Alan Schmitt 2022-04-05 11:50 Alan Schmitt 2022-03-29 7:42 Alan Schmitt 2022-03-22 13:01 Alan Schmitt 2022-03-15 9:59 Alan Schmitt 2022-03-01 13:54 Alan Schmitt 2022-02-22 12:43 Alan Schmitt 2022-02-08 13:16 Alan Schmitt 2022-02-01 13:00 Alan Schmitt 2022-01-25 12:44 Alan Schmitt 2022-01-11 8:20 Alan Schmitt 2022-01-04 7:56 Alan Schmitt 2021-12-28 8:59 Alan Schmitt 2021-12-21 9:11 Alan Schmitt 2021-12-14 11:02 Alan Schmitt 2021-11-30 10:51 Alan Schmitt 2021-11-16 8:41 Alan Schmitt 2021-11-09 10:08 Alan Schmitt 2021-11-02 8:50 Alan Schmitt 2021-10-19 8:23 Alan Schmitt 2021-09-28 6:37 Alan Schmitt 2021-09-21 9:09 Alan Schmitt 2021-09-07 13:23 Alan Schmitt 2021-08-24 13:44 Alan Schmitt 2021-08-17 6:24 Alan Schmitt 2021-08-10 16:47 Alan Schmitt 2021-07-27 8:54 Alan Schmitt 2021-07-20 12:58 Alan Schmitt 2021-07-06 12:33 Alan Schmitt 2021-06-29 12:24 Alan Schmitt 2021-06-22 9:04 Alan Schmitt 2021-06-01 9:23 Alan Schmitt 2021-05-25 7:30 Alan Schmitt 2021-05-11 14:47 Alan Schmitt 2021-05-04 8:57 Alan Schmitt 2021-04-27 14:26 Alan Schmitt 2021-04-20 9:07 Alan Schmitt 2021-04-06 9:42 Alan Schmitt 2021-03-30 14:55 Alan Schmitt 2021-03-23 9:05 Alan Schmitt 2021-03-16 10:31 Alan Schmitt 2021-03-09 10:58 Alan Schmitt 2021-02-23 9:51 Alan Schmitt 2021-02-16 13:53 Alan Schmitt 2021-02-02 13:56 Alan Schmitt 2021-01-19 14:28 Alan Schmitt 2021-01-12 9:47 Alan Schmitt 2021-01-05 11:22 Alan Schmitt 2020-12-29 9:59 Alan Schmitt 2020-12-22 8:48 Alan Schmitt 2020-12-15 9:51 Alan Schmitt 2020-12-01 8:54 Alan Schmitt 2020-11-03 15:15 Alan Schmitt 2020-10-27 8:43 Alan Schmitt 2020-10-20 8:15 Alan Schmitt 2020-10-06 7:22 Alan Schmitt 2020-09-29 7:02 Alan Schmitt 2020-09-22 7:27 Alan Schmitt 2020-09-08 13:11 Alan Schmitt 2020-09-01 7:55 Alan Schmitt 2020-08-18 7:25 Alan Schmitt 2020-07-28 16:57 Alan Schmitt 2020-07-21 14:42 Alan Schmitt 2020-07-14 9:54 Alan Schmitt 2020-07-07 10:04 Alan Schmitt 2020-06-30 7:00 Alan Schmitt 2020-06-16 8:36 Alan Schmitt 2020-06-09 8:28 Alan Schmitt 2020-05-19 9:52 Alan Schmitt 2020-05-12 7:45 Alan Schmitt 2020-05-05 7:45 Alan Schmitt 2020-04-28 12:44 Alan Schmitt 2020-04-21 8:58 Alan Schmitt 2020-04-14 7:28 Alan Schmitt 2020-04-07 7:51 Alan Schmitt 2020-03-31 9:54 Alan Schmitt 2020-03-24 9:31 Alan Schmitt 2020-03-17 11:04 Alan Schmitt 2020-03-10 14:28 Alan Schmitt 2020-03-03 8:00 Alan Schmitt 2020-02-25 8:51 Alan Schmitt 2020-02-18 8:18 Alan Schmitt 2020-02-04 8:47 Alan Schmitt 2020-01-28 10:53 Alan Schmitt 2020-01-21 14:08 Alan Schmitt 2020-01-14 14:16 Alan Schmitt 2020-01-07 13:43 Alan Schmitt 2019-12-31 9:18 Alan Schmitt 2019-12-17 8:52 Alan Schmitt 2019-12-10 8:21 Alan Schmitt 2019-12-03 15:42 Alan Schmitt 2019-11-26 8:33 Alan Schmitt 2019-11-12 13:21 Alan Schmitt 2019-11-05 6:55 Alan Schmitt 2019-10-15 7:28 Alan Schmitt 2019-09-03 7:35 Alan Schmitt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87wnvz96ff.fsf@m4x.org \ --to=alan.schmitt@polytechnique.org \ --cc=caml-list@inria.fr \ --cc=comp@lists.orbitalfox.eu \ --cc=cwn@lists.idyll.org \ --cc=lwn@lwn.net \ --subject='Re: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).