| From: |
| Alan Schmitt <alan.schmitt-AT-polytechnique.org> |
| To: |
| "lwn" <lwn-AT-lwn.net>, caml-list-AT-inria.fr |
| Subject: |
| Attn: Development Editor, Latest OCaml Weekly News |
| Date: |
| Tue, 17 Oct 2023 09:46:58 +0200 |
| Message-ID: |
| <m2zg0heln1.fsf@mac-03220211.irisa.fr> |
Hello
Here is the latest OCaml Weekly News, for the week of October 10 to 17,
2023.
Table of Contents
─────────────────
Hiring Functional Software Engineers (OCaml or Haskell) in Paris, France!
OCaml Hacking Day at Tarides Chennai
qcheck-lin and qcheck-stm 0.2
dune 3.11.0
runtime_events_tools 0.5.0
Gospel 0.2.0
Talk about declarative rhythm-machines with `Fry' and FRP @ Copenhagen
Deprecating ocaml-migrate-parsetree in favor of Ppxlib, also as a Platform tool
Old CWN
Hiring Functional Software Engineers (OCaml or Haskell) in Paris, France!
═════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/hiring-functional-software-en...>
Christian announced
───────────────────
Hey team! Tweag is hiring a Functional Software engineer with
Experience in OCaml or Haskell, if you’re fluent in ant of these
languages please feel free to apply. This is an onsite position at our
client offices located in Paris, France. (Hybrid model can be
discussed in the interview process)
If you want to lear more and how to apply please follow this link
where you’ll see all the information: <https://grnh.se/51d5e65b3us>
Any questions let me know!
OCaml Hacking Day at Tarides Chennai
════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ocaml-hacking-day-at-tarides-...>
Sudha Parimala announced
────────────────────────
We’re running an OCaml Hacking event at the Tarides office in Chennai
on the 21st of October.
We’re excited to hack on a diverse range of OCaml projects, including
the compiler, concurrency libraries, and tooling, as well as
benchmarking projects. Folks from Tarides will be around to assist
with questions and support participants.
This is an in-person event in Chennai. For more details and
registration, please visit <https://forms.gle/9vNd4UyJejqJR5sMA>.
Looking forward to seeing some of you there!
<https://global.discourse-cdn.com/business7/uploads/ocaml/...>
qcheck-lin and qcheck-stm 0.2
═════════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm...>
Jan Midtgaard announced
───────────────────────
FYI, we just rolled out a 0.3 release of `qcheck-lin', `qcheck-stm',
and `qcheck-multicoretests-util':
<https://github.com/ocaml-multicore/multicoretests/release...>
The release should be available in an opam repo near you shortly…
:wink:
The 0.3 release brings 3 “usability improvements” to `STM' and `Util'
and a `Lin' search improvement that should reduce memory allocation.
• #400: Catch and delay exceptions in `STM'’s `next_state' for a nicer
UX
• #387: Reduce needless allocations in `Lin'’s sequential consistency
search, as part of an `Out_channel' test cleanup
• #379: Extend the set of `Util.Pp' pretty-printers and teach them to
add break hints similar to `ppx_deriving.show'; teach `to_show' to
generate truncated strings when `$MCTUTILS_TRUNCATE' environment
variable is set
• #368: Switch `STM_domain.agree_prop_par_asym' from using
`Semaphore.Binary' to using an `int Atomic.t' which improves the
error rate across platforms and backends
Happy testing! :smiley:
dune 3.11.0
═══════════
Archive: <https://discuss.ocaml.org/t/ann-dune-3-11-0/13173/2>
Etienne Millon announced
────────────────────────
We just released dune 3.11.1 with the following fixes:
Fixed
╌╌╌╌╌
• Fix `dune rpc' commands on Windows (#8806, fixes #8799, @nojb)
• Fix `inline_tests' when the partition list is empty (#8849, fixes
#8848, @hhugo)
runtime_events_tools 0.5.0
══════════════════════════
Archive:
<https://discuss.ocaml.org/t/ann-runtime-events-tools-0-5-...>
Sudha Parimala announced
────────────────────────
I’m happy to announce the release of [runtime_events_tools.0.5.0].
OCaml 5.0 introduced a new [ring-buffer based tracing system] with low
overheads. This eliminated the need for a separate tracing runtime and
added the ability to keeping tracing on by default. The OCaml runtime
uses this tracing system to track GC events. OCaml 5.1 went further to
include [support for custom events].
Runtime events tools through `olly', provides functionality to grok
the data provided by the runtime tracing system.
Olly has two modes; `trace' , and `gc-stats'
*olly trace*
┌────
│ $ olly trace example.trace example.exe
└────
Records runtime traces in fuchsia and json formats. The trace files
can be visualised with [ui.perfetto.] or `json' trace with
[chrome://tracing](chrome://tracing).
Here’s a sample trace rendered in perfetto.
<https://global.discourse-cdn.com/business7/uploads/ocaml/...>
*olly gc-stats*
Provides information about GC time and latencies.
┌────
│ $ olly gc-stats "binarytrees5_multicore.exe 2 20"
│
│ Execution times:
│ Wall time (s): 2.61
│ CPU time (s): 4.63
│ GC time (s): 2.93
│ GC overhead (% of CPU time): 63.18%
│
│ GC time per domain (s):
│ Domain0: 1.59
│ Domain1: 1.34
│
│ GC latency profile:
│ #[Mean (ms): 0.76, Stddev (ms): 1.56]
│ #[Min (ms): 0.00, max (ms): 15.68]
│
│ Percentile Latency (ms)
│ 25.0000 0.00
│ 50.0000 0.01
│ 60.0000 0.04
│ 70.0000 0.28
│ 75.0000 0.66
│ 80.0000 1.40
│ 85.0000 2.44
│ 90.0000 3.16
│ 95.0000 3.62
│ 96.0000 3.79
│ 97.0000 4.06
│ 98.0000 4.73
│ 99.0000 6.29
│ 99.9000 13.59
│ 99.9900 15.68
│ 99.9990 15.68
│ 99.9999 15.68
│ 100.0000 15.68
└────
New features in this release:
• /Support for fuchsia format/: Stores the trace in binary format,
making the trace files 4x smaller in size, on an average.
• /gc-stats mode/: In addition to latency percentiles, GC stats
provide more insights, such as GC time and GC time spent per domain.
• /Custom events support/: Not only can you trace GC events, but now
you can also trace your own events
<https://global.discourse-cdn.com/business7/uploads/ocaml/...>
/Trace for a recursive fibonacci function/
Note that if you see non-terminating events in your traces, you might
want to include this compiler patch –
<https://github.com/ocaml/ocaml/pull/12583>.
[runtime_events_tools.0.5.0]
<https://opam.ocaml.org/packages/runtime_events_tools/runt...>
[ring-buffer based tracing system]
<https://github.com/ocaml/ocaml/pull/10964>
[support for custom events] <https://github.com/ocaml/ocaml/pull/11474>
[ui.perfetto.] <https://ui.perfetto.dev/>
Gospel 0.2.0
════════════
Archive: <https://discuss.ocaml.org/t/ann-gospel-0-2-0/13236/1>
Nicolas Osborne announced
─────────────────────────
We are very happy to announce the release 0.2.0 of `gospel'!
Gospel is a tool-agnostic behavioural specification language for
OCaml. It allows you to write strongly typed contract-based
specifications for your OCaml libraries (for a reasonable subset of
OCaml). Gospel’s syntax has been designed to be easy to learn for an
OCaml programmer. You can access the documentation [here].
This release adds two main features, a `gospel dumpast' command and a
`gospel.ppx' ppx rewriter to display Gospel specification as
documentation with `odoc'.
Some minor extensions have been added to the language itself:
• a `with' construct to name a variable in type invariants referring
to a value of the specified type,
• `int' literals,
• anonymous functions now support both patterns in arguments and
return type annotations,
• unit result in function headers,
• constants can now be referenced in specifications,
• infix operators are now accepted in specification headers.
Parser, preprocessor, and error messages have been improved. In
particular the preprocessor can now handle large files and locations
are properly tracked. Pattern matches are now also checked for
exhaustiveness and redundancy.
We have made a number of improvements and bugfixes in the type checker
as well as some minor modifications in the Gospel standard library.
Finally, the documentation has been revised.
[here] <https://ocaml-gospel.github.io/gospel/>
Talk about declarative rhythm-machines with `Fry' and FRP @ Copenhagen
══════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/talk-about-declarative-rhythm...>
rand announced
──────────────
I’m happy to announce that I’m doing a talk on [`Fry'] at [meetup for
functional copenhageners] @ 24. october. `Fry' is a small library that
enables declarative definitions of rhythm-machines etc. together with
FRP (`React'). These can be interactive, generative, experimental -
what ever you fancy. Recently I’ve used it for a polyrhythmic machine
(`pmmd') based on bpm-modulation, that I’m planning on releasing as
modular synthesizer hardware.
A couple of concepts from `Fry' that are interesting, which you can
see from its [examples]:
• [a DSL for creation/composition of envelopes]
• [bpm-modulation of beats]
• [FRP is excellent at programming with time]
Also, OCaml with first class modules + module functors + FRP, map
elegantly to the semantics of [modular synthesizers]. Simply:
• a `unit event' maps to a [control-voltage] (CV) trigger
• a `float signal' maps to CV
• a module functor maps to a modular synth module taking CV-in,
exposing CV-out
If you are near Copenhagen - hope to see you (:
[`Fry'] <https://github.com/rand00/fry>
[meetup for functional copenhageners]
<https://www.meetup.com/moedegruppefunktionellekoebenhavne...>
[examples] <https://github.com/rand00/fry/tree/main/examples>
[a DSL for creation/composition of envelopes]
<https://github.com/rand00/fry/blob/main/examples/envelope...>
[bpm-modulation of beats]
<https://github.com/rand00/fry/blob/main/examples/beat_mod...>
[FRP is excellent at programming with time]
<https://github.com/rand00/fry/blob/main/examples/advanced...>
[modular synthesizers]
<https://en.wikipedia.org/wiki/Modular_synthesizer>
[control-voltage] <https://en.wikipedia.org/wiki/CV/gate>
Deprecating ocaml-migrate-parsetree in favor of Ppxlib, also as a Platform tool
═══════════════════════════════════════════════════════════════════════════════
Archive:
<https://discuss.ocaml.org/t/rfc-deprecating-ocaml-migrate...>
Sonja Heinze announced
──────────────────────
Hello everyone :wave:
We’re planning to deprecate [ocaml-migrate-parsetree] (OMP) finally.
OMP forms part of the [OCaml Platform], so we can’t and wouldn’t just
do that without the approval of the community. So first a bit of
context:
[ocaml-migrate-parsetree]
<https://github.com/ocaml-ppx/ocaml-migrate-parsetree>
[OCaml Platform] <https://ocaml.org/docs/platform>
What is OMP anyways?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
OMP used to be an extremely important project in the
meta-programming-related chunk of OCaml’s ecosystem. Since the
introduction of [extension nodes] and [attributes] in OCaml 4.2 in
2014, meta-programming in OCaml is most commonly done on OCaml’s
parsetree. The caveat: The parsetree is extended and modified between
OCaml minor versions, meaning that handling the OCaml parsetree
directly is unstable. OMP came to the rescue by introducing a concept
we call _versioned parsetrees_ (or versioned ASTs) together with
migrations between those fixed versions of the parsetree, allowing the
workflow
<https://hackmd.io/_uploads/H13pahLWp.png>
That workflow allows one PPX to guarantee compatibility with multiple
compiler versions (here, PPX = PreProcessor eXtension stands for the
meta-programming instance). That was extremely important at the time
to introduce a more version-flexible ecosystem and to reduce the
maintenance burden of PPXs!
OMP also provided the concept of a _driver_, which is one single
binary driving the applicatoin of all PPXs. Without that, using n PPXs
would mean copying the workflow pictured above n times. That’s an
incredible performance overhead. The OMP driver took care of applying
all PPXs, so fewer parsetree migrations and less communication between
different processes were necessary (before: one process per PPX).
[extension nodes] <https://v2.ocaml.org/manual/extensionnodes.html>
[attributes] <https://v2.ocaml.org/manual/attributes.html#start-section>
Why was OMP not enough?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
However, the OMP driver was still duplicating parsetree migrations,
and it did one whole parsetree pass per PPX. And because of the
latter, the outcome of the preprocessor phase used to depend on the
order of PPXs, which didn’t follow any semantically relevant or
otherwise reasoned pattern. The reason why it would have been
extremely complicated to improve the OMP driver further was that each
PPX chose its own versioned parsetree version. There was no agreement
between different PPXs.
◊ Ppxlib
So the solution was to have the PPXs agree on one versioned parsetree
version. That’s what [Ppxlib] does. It also does a lot more by
providing an extensive API to write PPXs easily and others, but the
main point here is that it consolidates a consistent PPX ecosystem wrt
parsetree versions. The way it does so is by exposing one fixed
versioned parsetree version that all PPXs are defined against.
Thanks to that, the Ppxlib driver can get rid of unnecessary parsetree
migrations, and it can merge a whole bunch of PPXs into one AST pass,
improving performance and guaranteeing a clear order of PPX
transformations. Also important: Having all PPXs on the same versioned
parsetree version, makes it easy to have them all on the one of the
latest OCaml version. For details I’m not going into, that’s the only
(reasonable) way to have the PPXs support the latest compiler syntax
features, so that’s a huge advantage of Ppxlib as well.
Ppxlib still isn’t perfect and comes with its own little set of
problems, but it does solve the mentioned big problems of performance
overhead, unclear composition semantics,
parsetree-version-fragmentation among different PPXs, and lack of
latest compiler syntax support. So by now, the whole OCaml opam
ecosystem has shifted from OMP to Ppxlib (more below).
The latest update on the state of Ppxlib, also including info about
OMP and the ecosystem’s transition from one to the other [is this one
from 2021]. All Ppxlib maintainers have very very little time for
communication and similar. If a new update would be strongly
appreciated, let us know. For here, let’s focus on OMP:
[Ppxlib] <https://github.com/ocaml-ppx/ppxlib>
[is this one from 2021]
<https://discuss.ocaml.org/t/an-update-on-the-state-of-the...>
What does it mean to deprecate OMP?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
Given that by now, OMP’s maintenance is held at the bare bare minimum
anyways, deprecating it would only have one clear impact:
◊ Real-life
We’d stop adding new compiler support, so the last supported compiler
would be OCaml 5.0. Concretely: We won’t add the new versioned
parsetrees and migrations for the new compilers anymore.
◊ Formalities
We’d also mark the OMP opam packages as deprecated, and we’d move OMP
to the Deprecate section in the [set of OCaml Platform tools] (now
it’s in the Sustained section).
[set of OCaml Platform tools] <https://ocaml.org/docs/platform>
Is it ok to deprecate OMP?
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
You tell us :) Here’s some info:
◊ Opam packages
All packages on opam have moved to Ppxlib now. There’s only [a
hand-full of packages that formally still depend on OMP], but all of
that seems to be formal left-overs in the opam files, a left-over test
dependency or similar. I’ve opened issues on those packages,
mentioning the potential upcoming deprecation of OMP, and nobody has
complained.
[a hand-full of packages that formally still depend on OMP]
<https://ocaml.org/p/ocaml-migrate-parsetree/latest#used-by>
◊ Distribution packages
There are still a few distributions that keep on packaging OMP on
their distribution, e.g. there’s [OMP on Debian], [OMP on Fedora] and
[OMP on Arch]. However, the reason for that seems merely historical
(with unquestioned inertia): There are no reverse dependencies on
Debian or Fedora. On Arch, there are a few reverse dependencies, none
of them still being relevant in the present. I’ll reach out to the
three respective package managers. If anyone has any info or relevant
context about this, please share it!
[OMP on Debian]
<https://tracker.debian.org/pkg/ocaml-migrate-parsetree>
[OMP on Fedora]
<https://packages.fedoraproject.org/pkgs/ocaml-migrate-par...>
[OMP on Arch]
<https://aur.archlinux.org/packages/ocaml-migrate-parsetree>
◊ Users/community
And this is where we’re asking for feedback. Does it sound good to
everyone to deprecate OMP? We do have the strong impression that
pretty much everyone has moved to Ppxlib, but if you think we’re
missing something important, please let us know (or, just use this
opportunity to say something nice about OMP :slight_smile: ).
◊ Original author and current maintainer
Obviously, the current maintainer/“sustainer” (me) thinks it’s good to
deprecate OMP finally. And the original author, @let-def, is behind it
as well.
Btw, @let-def, thanks a lot for this crucial piece of OCaml software!
It contains a lot of really good ideas, concepts, and implementation
details! Even once deprecated, it will persist - partly quite
literally inside Ppxlib in the form of the versioned parsetrees, the
migrations, and parts of the driver.
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
to the [caml-list].
[Alan Schmitt]
[send me a message] <mailto:alan.schmitt@polytechnique.org>
[the archive] <https://alan.petitepomme.net/cwn/>
[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>
[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>
[Alan Schmitt] <https://alan.petitepomme.net/>
