[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt
2021-01-26T13:25:09Z

[-- 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 – instead of - . 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 --]