From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Hermes.metastack.local (172.16.0.8) by Hermes.metastack.local (172.16.0.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32 via Mailbox Transport; Tue, 17 Oct 2023 08:47:35 +0100 Received: from Hermes.metastack.local (172.16.0.8) by Hermes.metastack.local (172.16.0.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.32; Tue, 17 Oct 2023 08:47:35 +0100 Received: from exchange.romulus.metastack.com (172.16.0.21) by Hermes.metastack.local (172.16.0.8) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.2507.32 via Frontend Transport; Tue, 17 Oct 2023 08:47:35 +0100 Received: from romulus.metastack.com ([172.16.0.20]) by exchange.romulus.metastack.com (8.14.2/8.14.2) with ESMTP id 39H7lOsq008085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Oct 2023 08:47:24 +0100 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id 39H7lDRm008069 for ; Tue, 17 Oct 2023 08:47:14 +0100 Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 17 Oct 2023 09:47:12 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id DC5ACE0CD7; Tue, 17 Oct 2023 09:47:11 +0200 (CEST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 6D8E8E00B7 for ; Tue, 17 Oct 2023 09:47:09 +0200 (CEST) Received: from mx1.polytechnique.org ([129.104.30.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Oct 2023 09:47:08 +0200 Received: from mac-03220211.irisa.fr (mac-03220211.irisa.fr [131.254.21.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 8FD7B561298; Tue, 17 Oct 2023 09:46:58 +0200 (CEST) From: Alan Schmitt To: lwn , "caml-list@inria.fr" Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Thread-Topic: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Thread-Index: AQHaAM4xBMAqBcZ6LUi2W//XQ6Lunw== Sender: "caml-list-request@inria.fr" X-MS-Exchange-MessageSentRepresentingType: 2 Date: Tue, 17 Oct 2023 08:46:58 +0100 Message-ID: Keywords: Sent to dra-news@metastack.com,Marked bulk,MetaStack - Lists,MetaStack List-Help: List-Subscribe: List-Unsubscribe: Reply-To: Alan Schmitt Content-Language: en-GB X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: Hermes.metastack.local X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-Exchange-Organization-Network-Message-Id: fc4f7d52-7648-496d-954f-08dbcee553f4 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-scanned-by: MIMEDefang 2.65 on 62.31.23.242 received-spf: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@sympa.inria.fr) identity=helo; client-ip=128.93.162.160; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="postmaster@sympa.inria.fr"; x-conformance=spf_only x-ironport-av: E=Sophos;i="6.03,231,1694728800"; d="scan'208,217";a="131601438" x-spam-flag: No, tests=bogofilter, spamicity=0.375818, queueID=0389056129D x-ironport-anti-spam-filtered: true x-loop: caml-list@inria.fr x-no-archive: yes Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 OCaml Weekly News

OCaml Weekly News

Previous We= ek Up Next We= ek

Hello

Here is the latest OCaml Weekly News, for the week of October 10 to 17, = 2023.

Hiring Functional Software Engineers (OCaml or Haskell) in Par= is, France!

Archive: https://discuss.ocaml.org/t/hiring-functional-software-engineers-ocaml-or-h= askell-in-paris-france/13221/1

Christian announced

Hey team! Tweag is hiring a Functional Software engineer with Experience= in OCaml or Haskell, if you=92re fluent in ant of these languages please f= eel 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=92ll see all the information: https://grnh.se/51d5e65b3us

Any questions let me know!

qcheck-lin and qcheck-stm 0.2

Archive: https://discuss.ocaml.org/t/ann-qcheck-lin-and-qcheck-stm-0-2/12301/2 <= /p>

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/releases/tag/0.3 The = release should be available in an opam repo near you shortly=85 :wink:

The 0.3 release brings 3 =93usability improvements=94 to STM and Util and a Lin search improvement that should reduce me= mory allocation.

  • #400: Catch and delay exceptions in STM=92s next_sta= te for a nicer UX
  • #387: Reduce needless allocations in Lin=92s sequenti= al 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 trun= cated strings when $MCTUTILS_TRUNCATE environment variable is set
  • #368: = Switch STM_domain.agree_prop_par_asym from using Semapho= re.Binary to using an int Atomic.t which improves the error rate across platforms an= d 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, @noj= b)
  • 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-0/13235/1

Sudha Parimala announced

I=92m 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 th= e need for a separate tracing runtime and added the ability to keeping trac= ing on by default. The OCaml runtime uses this tracing system to track GC e= vents. OCaml 5.1 went further to include support for = custom events.

Runtime events tools through olly, provides functionality t= o 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=92s a sample trace rendered in perfetto.

3D=

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, m= aking 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 3D"a3=

    Trace for a recursive fibonacci function

Note that if you see non-terminating events in your traces, you might wa= nt to include this compiler patch =96 https://github.com/oc= aml/ocaml/pull/12583.

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 you= r OCaml libraries (for a reasonable subset of OCaml). Gospel=92s 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 comma= nd and a gospel.ppx ppx rewriter to display Gospel specification as doc= umentation with odoc.

Some minor extensions have been added to the language itself:

  • a with construct to name a variable in type invariants ref= erring to a value of the specified type,
  • int literals,
  • anonymous functions now suppor= t both patterns in arguments and return type annotations,
  • unit result in function headers,
  • constants can now be ref= erenced in specifications,
  • infix operators are now accepted in spe= cification headers.

Parser, preprocessor, and error messages have been improved. In particul= ar the preprocessor can now handle large files and locations are properly t= racked. Pattern matches are now also checked for exhaustiveness and redunda= ncy.

We have made a number of improvements and bugfixes in the type checker a= s well as some minor modifications in the Gospel standard library. Finally,= the documentation has been revised.

Talk about declarative rhythm-machines with Fry a= nd FRP @ Copenhagen

Archive: https://discuss.ocaml.org/t/talk-about-declarative-rhythm-machines-with-fry= -and-frp-copenhagen/13238/1

rand announced

I=92m happy to announce that I=92m 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, generat= ive, experimental - what ever you fancy. Recently I=92ve used it for a polyrhythmic machine (pmmd) based on bpm-modulation, that I=92m planning on releasing as modular sy= nthesizer hardware.

A couple of concepts from Fry that are interesting, which y= ou can see from its examples: =

Also, OCaml with first class modules + module functors + FRP, ma= p elegantly to the semantics of modular synth= esizers. 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 (:

Deprecating ocaml-migrate-parsetree in favor of Ppxlib, also a= s a Platform tool

Archive: https://discuss.ocaml.org/t/rfc-deprecating-ocaml-migrate-parsetree-in-favo= r-of-ppxlib-also-as-a-platform-tool/13240/1

Sonja Heinze announced

Hello everyone :wave:

We=92re planning to deprecate ocaml-migrate-parsetree (OMP) finally. OMP forms part of the OCaml Platform, so we can=92t and wouldn=92t just do that without the a= pproval of the community. So first a bit of context:

What is OMP anyways?

OMP used to be an extremely important project in the meta-programming-re= lated chunk of OCaml=92s ecosystem. Since the introduction of extension nodes= and attri= butes in OCaml 4.2 in 2014, meta-programming in OCaml is most commonly = done on OCaml=92s parsetree. The caveat: The parsetree is extended and modi= fied between OCaml minor versions, meaning that handling the OCaml parsetree directly is unstable. OMP came to the re= scue by introducing a concept we call versioned parsetrees (or versioned ASTs) t= ogether with migrations between those fixed versions of the parsetree, allo= wing the workflow

3D"H13pahLWp.p=

That workflow allows one PPX to guarantee compatibility with multiple co= mpiler versions (here, PPX =3D PreProcessor eXtension stands for the meta-p= rogramming 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=92s an incredible performance overhead. The OMP driver took care of applying all PPXs, so fewer parsetre= e migrations and less communication between different processes were necess= ary (before: one process per PPX).

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 out= come of the preprocessor phase used to depend on the order of PPXs, which d= idn=92t 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 P= PXs.

  • Ppxlib

    So the solution was to have the PPXs agree on one versioned parsetree ve= rsion. That=92s what Ppxlib does. It also do= es 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 ecosyste= m wrt parsetree versions. The way it does so is by exposing one fixed versioned parsetree version that all P= PXs are defined against.

    Thanks to that, the Ppxlib driver can get rid of unnecessary parsetree m= igrations, and it can merge a whole bunch of PPXs into one AST pass, improv= ing 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 on= e of the latest OCaml version. For details I=92m not going into, that=92s t= he only (reasonable) way to have the PPXs support the latest compiler synta= x features, so that=92s a huge advantage of Ppxlib as well.

    Ppxlib still isn=92t perfect and comes with its own little set of proble= ms, but it does solve the mentioned big problems of performance overhead, u= nclear composition semantics, parsetree-version-fragmentation among differe= nt 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=92s transition from one to the other is this one from 2021. All Ppxlib maintainers have very very little tim= e for communication and similar. If a new update would be strongly apprecia= ted, let us know. For here, let=92s focus on OMP:

What does it mean to deprecate OMP?

Given that by now, OMP=92s maintenance is held at the bare bare minimum = anyways, deprecating it would only have one clear impact:

  • Real-life

    We=92d stop adding new compiler support, so the last supported compiler = would be OCaml 5.0. Concretely: We won=92t add the new versioned parsetrees= and migrations for the new compilers anymore.

  • Formalities

    We=92d also mark the OMP opam packages as deprecated, and we=92d move OM= P to the Deprecate section in the set of OCaml Platform tools= (now it=92s in the Sustained section).

Is it ok to deprecate OMP?

You tell us :) Here=92s some info:

  • Opam packages

    All packages on opam have moved to Ppxlib now. There=92s only a hand-full of packages that formally still depend on OMP, but all of t= hat seems to be formal left-overs in the opam files, a left-over test depen= dency or similar. I=92ve opened issues on those packages, mentioning the po= tential upcoming deprecation of OMP, and nobody has complained.

  • Distribution packages

    There are still a few distributions that keep on packaging OMP on their = distribution, e.g. there=92s OMP on D= ebian, 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 Fedo= ra. On Arch, there are a few reverse dependencies, none of them still being= relevant in the present. I=92ll reach out to the three respective package managers. If anyone has any info or re= levant context about this, please share it!

  • Users/community

    And this is where we=92re asking for feedback. Does it sound good to eve= ryone to deprecate OMP? We do have the strong impression that pretty much e= veryone has moved to Ppxlib, but if you think we=92re missing something imp= ortant, 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/=93sustainer=94 (me) thinks it=92s goo= d 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 Ppxl= ib 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=92ll 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.