OCaml Weekly News

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!

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!

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… :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:

We just released dune 3.11.1 with the following fixes:

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.

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

  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.

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.

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 (:

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: