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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- Attachment #1: Type: text/plain, Size: 29192 bytes --]

Hello

Here is the latest OCaml Weekly News, for the week of November 19 to 26,
2024.

Table of Contents
─────────────────

OCaml 5.2.1 released
smaws preview release, an AWS SDK for OCaml using eio
ppx_deriving_ezjsonm
FUN OCaml now has a YouTube Channel
Terrateam's open source Ocaml repository
OUPS december 2024
Dune dev meeting
Other OCaml News
Old CWN


OCaml 5.2.1 released
════════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-5-2-1-released/15634/1>


octachron announced
───────────────────

  We have the pleasure of announcing the release of OCaml 5.2.1,
  dedicated to the memory of Niels Bohr and Paul Éluard on the
  anniversary of their deaths.

  OCaml 5.2.1 is a collection of safe but import runtime time bug fixes
  backported from the 5.3 branch of OCaml to improve the stability of
  the 5.2 runtime while waiting for the upcoming release of OCaml 5.3.0.

  The full list of bug fixes is available below for more details.

  Happy hacking, Florian Angeletti, for the OCaml team.


Installation Instructions
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The base compiler can be installed as an opam switch with the
  following commands:

  ┌────
  │ opam update
  │ opam switch create 5.2.1
  └────

  The source code for the release is also directly available on:

  • [GitHub]
  • [Inria archive]


[GitHub] <https://github.com/ocaml/ocaml/archive/5.2.1.tar.gz>

[Inria archive]
<https://caml.inria.fr/pub/distrib/ocaml-5.2/ocaml-5.2.1.tar.gz>


Bug Fixes In OCaml 5.2.1 (18 November 2024)
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

◊ Runtime System:

  • [#13207]: Be sure to reload the register caching the exception
    handler in `caml_c_call' and `caml_c_call_stack_args', as its value
    may have been changed if the OCaml stack is expanded during a
    callback.  (Miod Vallat, report by Vesa Karvonen, review by Gabriel
    Scherer and Xavier Leroy)
  • [#13252]: Rework register assignment in the interpreter code on m68k
    on Linux, due to the %a5 register being used by GLIBC.  (Miod
    Vallat, report by Stéphane Glondu, review by Gabriel Scherer and
    Xavier Leroy)
  • [#13268]: Fix a call to test in `configure.ac' that was causing
    errors when LDFLAGS contains several words.  (Stéphane Glondu,
    review by Miod Vallat)
  • [#13234], [#13267]: Open runtime events file in read-write mode on
    ARMel (ARMv5) systems due to atomic operations limitations on that
    platform.  (Stéphane Glondu, review by Miod Vallat and Vincent
    Laviron)
  • [#13188]: fix races in the FFI code coming from the use of
    `Int_val(...)'  on rooted values inside blocking questions / without
    the runtime lock.  (Calling `Int_val(...)' on non-rooted immediates
    is fine, but any access to rooted values must be done outside
    blocking sections / with the runtime lock.)  (Etienne Millon, review
    by Gabriel Scherer, Jan Midtgaard, Olivier Nicole)
  • [#13318]: Fix regression in GC alarms, and fix them for Flambda.
    (Guillaume Munch-Maccagnoni, report by Benjamin Monate, review by
    Vincent Laviron and Gabriel Scherer)
  • [#13140]: POWER back-end: fix issue with call to
    `caml_call_realloc_stack' from a DLL (Xavier Leroy, review by Miod
    Vallat)
  • [#13370]: Fix a low-probability crash when calling `Gc.counters'.
    (Demi Marie Obenour, review by Gabriel Scherer)
  • [#13402], [#13512], [#13549], [#13553]: Revise bytecode
    implementation of callbacks so that it no longer produces dangling
    registered bytecode fragments.  (Xavier Leroy, report by Jan
    Midtgaard, analysis by Stephen Dolan, review by Miod Vallat)
  • [#13502]: Fix misindexing related to `Gc.finalise_last' that could
    prevent finalisers from being run.  (Nick Roberts, review by Mark
    Shinwell)
  • [#13520]: Fix compilation of native-code version of
    systhreads. Bytecode fields were being included in the thread
    descriptors.  (David Allsopp, review by Sébastien Hinderer and Miod
    Vallat)


  [#13207] <https://github.com/ocaml/ocaml/issues/13207>

  [#13252] <https://github.com/ocaml/ocaml/issues/13252>

  [#13268] <https://github.com/ocaml/ocaml/issues/13268>

  [#13234] <https://github.com/ocaml/ocaml/issues/13234>

  [#13267] <https://github.com/ocaml/ocaml/issues/13267>

  [#13188] <https://github.com/ocaml/ocaml/issues/13188>

  [#13318] <https://github.com/ocaml/ocaml/issues/13318>

  [#13140] <https://github.com/ocaml/ocaml/issues/13140>

  [#13370] <https://github.com/ocaml/ocaml/issues/13370>

  [#13402] <https://github.com/ocaml/ocaml/issues/13402>

  [#13512] <https://github.com/ocaml/ocaml/issues/13512>

  [#13549] <https://github.com/ocaml/ocaml/issues/13549>

  [#13553] <https://github.com/ocaml/ocaml/issues/13553>

  [#13502] <https://github.com/ocaml/ocaml/issues/13502>

  [#13520] <https://github.com/ocaml/ocaml/issues/13520>


smaws preview release, an AWS SDK for OCaml using eio
═════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-smaws-preview-release-an-aws-sdk-for-ocaml-using-eio/15635/1>


Chris Armstrong announced
─────────────────────────

  I'm pleased to announce the first preview release for the [smaws]
  library (`0.1~preview1').

  *[smaws]* provides AWS bindings for OCaml using the modern [eio]
   library for effects-based concurrency handling.


[smaws] <https://github.com/chris-armstrong/smaws>

[eio] <https://github.com/ocaml-multicore/eio>

Links
╌╌╌╌╌

  • [Installation and Usage instructions]
  • [Examples]


[Installation and Usage instructions]
<https://chris-armstrong.github.io/smaws/smaws-clients/>

[Examples]
<https://github.com/chris-armstrong/smaws/tree/main/awssdklib_examples>


Whats in this release
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  This release includes SDKs for some AWS services and is intended to
  demonstrate its API.

  It is not production ready, lacking important features such as full
  API documentation EC2/ECS instance metadata authentication, retry and
  timeout handling, etc. It also needs support for the other internal
  AWS API types to extend coverage across most AWS services.


Motivation
╌╌╌╌╌╌╌╌╌╌

  I wanted to build an AWS SDK using modern effects-based
  concurrency. I've built similar bindings for ReScript and ReasonML in
  the past (some of the code is in fact ported across) but this is the
  first OCaml-native bindings I've created.

  Unlike similar projects in the OCaml ecosystem, it uses the newer
  Smithy definitions to generate its bindings instead of the Python
  botocore definitions. These should be better supported by AWS in the
  future with richer API definitions.


What's next
╌╌╌╌╌╌╌╌╌╌╌

  My next task is to finish off API documentation generation, and then
  expand support for all the authentication methods and other API types
  that will allow this to be used with most AWS services.


ppx_deriving_ezjsonm
════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ppx-deriving-ezjsonm/15637/1>


Patrick Ferris announced
────────────────────────

  I'm happy to announce the release of `ppx_deriving_ezjsonm' (based off
  of [ppx_deriving_yaml]). The two libraries share a common definition
  of a "`value'" which made the reuse of the existing deriver possible
  for a simple JSON deriver.

  ┌────
  │ opam update
  │ opam install ppx_deriving_ezjsonm
  └────

  The [documentation is online].

  This library may come in handy when your dependency cone already
  includes `ezjsonm'. If that is not the case, you would probably have
  better luck in the `yojson' ecosystem of tools.

  Happy JSON-ing :camel:


[ppx_deriving_yaml]
<https://github.com/patricoferris/ppx_deriving_yaml/>

[documentation is online]
<https://patricoferris.github.io/ppx_deriving_yaml/ppx_deriving_ezjsonm/index.html>


FUN OCaml now has a YouTube Channel
═══════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/fun-ocaml-now-has-a-youtube-channel/15639/1>


Sabine Schmaltz announced
─────────────────────────

  I just created a YouTube channel for FUN OCaml. :sparkles: :camel:

  The talk recordings from the conference in Berlin on September 16 +
  17, 2024 are now available for viewing!

  <https://www.youtube.com/@FUNOCaml/featured>

  If you can, commenting, liking, or subscribing helps us to make these
  videos more visible and easier to find on YouTube, so big thanks for
  everyone who helps us with this! :orange_heart: :camel:

  For people who avoid YouTube: The videos will also be made available
  on watch.ocaml.org.


Terrateam's open source Ocaml repository
════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/terrateams-open-source-ocaml-repository/15645/1>


Malcolm announced
─────────────────

  A few years ago my friend and I started a company called [Terrateam],
  which does infrastructure orchestration on GitHub.  Being that I am an
  Ocamler and we are a lean company, we chose to use Ocaml as our
  primary language.  We recently went open source and I'm posting the
  link here to contribute an example of an actual company using Ocaml.
  A real repository.

  The code can be found [here].

  There a few things to note about the repo:

  1. It's a mono repo, so while many of the libraries in there are
     generic, they are not really individually consumable as is.
  2. We have our own concurrency framework (more on that below).
  3. We use our own build library (pds, which is in opam).
  4. The code is in flux all the time so things change rapidly.

  Why did we build our own concurrency framework?

  Disclaimer: Yet another concurrency framework? Yep!  Do I expect
  anyone to use it? Nope, and that's ok.  It is designed for our needs.
  It's meant to be maintainable by one person.  It's not meant to
  compete with Lwt or Async for mind share.  If it grows, great, if it
  doesn't, I'm happy still.

  Our concurrency framework is called "Asynchronous Building Blocks"
  (Abb).  It started over a decade ago when I was frustrated with a few
  things:

  1. I wanted kqueue support in Async, but (at the time) Async required
     modifying a handful of repos to support it and it just wasn't
     obvious how.
  2. Lwt supported kqueue, but for no good reason, I just didn't like
     Lwt.  Part of it was how failure worked in Lwt and other part is
     just it didn't fit my aesthetic.  That isn't a ding against Lwt,
     just personal preference.
  3. I wanted as much of it to be implemented in Ocaml as possible.  As
     it stands now, the only C code is `libkqueue' which is a little
     shim to to allow kqueue code to run on Linux, otherwise everything
     is in Ocaml.
  4. I didn't like how neither Async nor Lwt really supported
     cancelling operations.  I wanted that to be part of the framework,
     not an ad-hoc feature per library.  Coming from Erlang, cancelling
     is really important to me and part of how I think about writing
     concurrent software.  I was bummed that (last I looked) Eio
     explicitly rejected cancelling.
  5. I also wanted a little experiment of "what if the concurrency
     library exposed a syscall interface like an OS?"  So a lot of the
     interface is meant to look low-level (I don't think this idea
     really panned out or made Abb meaningfully different).
  6. I also just like having my own frameworks.

  Add a dash of naivete, "how hard can it be to build a concurrency
  framework?", I started my own.  First commit was Mar 9, 2013.

  Much of the concurrency monad is based on an unreleased library called
  `Fut' by @dbuenzli

  Over time, Abb matured to where I could use it in my personal
  projects.  And by the time we decided to make Terrateam, I felt it was
  good enough for production.  And it's been running production traffic
  for a few years now.

  One, unexpected, benefit of Lwt and Async existing in the community is
  that adding a third one isn't that hard.  Almost all libraries that
  want to be used support both, and that usually means that they have a
  generic interface.  Cohttp and Dns are examples.  So I could use
  existing libraries for things I didn't want to or don't feel I could
  reasonably implement myself.

  I've also used Abb as a foundation my web framework called Brtl
  (pronounced Brutal) which is both a backend framework build on Cohttp
  and a frontend framework built on Brr.  It really doesn't do anything
  fancy, like Dream, it's pretty low level and focused on being simple.

  The good:

  1. It works!  At least, for me.
  2. Given that I wrote very single line of code, debugging and bug
     fixing (which is less and less) is very easy.  I also have a really
     great mental model of how it works.
  3. I like that I can just cancel a whole graph of async work if it's
     no longer needed.
  4. The future's library works in FreeBSD, Linux, and JavaScript.
  5. The test coverage is pretty darn high.  This is because it's a
     pretty intricate thing to implement so I had to implement a lot of
     tests to stay sane.

  The bad:

  1. Performance is not anything special.  I don't think this is a
     fundamental flaw, it's just that it is as fast as I need it to be
     right now.
  2. Some of the API is a awkward if you don't know the system.  Or
     names are long, like `Abb_future_combinators'.
  3. The multi-target build story kind of sucks.  I think that might be
     a bigger issue with the pds build system but for now in the web
     framework you have to use `Abb_js' rather than `Abb' for
     everything.
  4. There are definitely some corners cut in, especially around file
     IO, but that's OK, we don't do much file IO.
  5. Explicitly takes advantage in that everything runs in a single
     thread.  So implicitly going multi-threaded would probably break
     things.

  Future work:

  There really isn't a lot of future work.  For the most part: Abb is
  done.  Or should I say the interface is done.  Yes, it will need
  updates to fight bit rot, but there isn't much more for it to do.  It
  runs your code concurrently, the end.

  However, as Ocaml5 becomes more of a thing, it will need to take
  advantage of that.  I haven't really thought about how to do it.  One
  item I have in my to-do list is to evaluate if Picos could be a base
  layer for Abb.  Abb is a layered approach so really you only need to
  implement the `Abb_intf.S' interface and everything above that should
  Just Work (given single threaded semantics).  I think any future work
  to support multi core will probably need an explicit "this crosses a
  thread boundary" API.  Abb will get there, eventually, but right now
  it doesn't need to.

  Effects will obviously have a big impact, I have no idea what that'll
  do for Abb.  I hope I can transition it slowly to supporting effects
  but I don't want to look at effects until it's in the type system.

  Some, perhaps, libraries of interest in the repo:

  1. [Abb_scheduler_kqueue] - The most used scheduler.  It implements
     the [Abb_intf] interface.
  2. [Abb_scheduler_select] - A simpler select-based scheduler.  This is
     meant to be used any place kqueue is not supported and also as
     demo.
  3. [Pgsql_io] - An implementation of the PostgreSQL protocol.
  4. [Githubc2] - An automatically generated GitHub REST library
     generated from their JSON Schema.  This actually has no Abb
     dependency, just implements the API serializing/deserializing.
  5. [OpenAPI CLI] - This generates a library (see Githubc2) from an
     OpenAPI spec.  It is, absolutely, a bit of a rats nest, but it
     works.  We chose to do code-gen for this because I didn't want to
     be blocked when compiling based on different compiler versions as
     we're using `Ast_helper'.  Ocaml, the code, is more stable than
     Ocaml, the compiler API.

  There is a bunch of other stuff in there.  If you decide to poke
  around and have any questions, feel free to ask.  I can promise: not
  every decision in there is well thought out or coherent.


[Terrateam] <https://terrateam.io>

[here] <https://github.com/terrateamio/terrateam>

[Abb_scheduler_kqueue]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_scheduler_kqueue>

[Abb_intf]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_intf>

[Abb_scheduler_select]
<https://github.com/terrateamio/terrateam/tree/main/code/src/abb_scheduler_select>

[Pgsql_io]
<https://github.com/terrateamio/terrateam/tree/main/code/src/pgsql_io>

[Githubc2]
<https://github.com/terrateamio/terrateam/tree/main/code/src/githubc2>

[OpenAPI CLI]
<https://github.com/terrateamio/terrateam/tree/main/code/src/openapi_cli>


OUPS december 2024
══════════════════

  Archive: <https://discuss.ocaml.org/t/oups-december-2024/15654/1>


zapashcanon announced
─────────────────────

  CAUTION: the time has been changed from 7pm to 6:30pm

  The next OUPS meetup will take place on *Thursday, 12th of December*
  2024. It will start at *6:30pm* at the *4 place Jussieu* in Paris. It
  will be in the in the *Esclangon building* (amphi Astier).

  Please, *[register on meetup ]* as soon as possible to let us know how
  many pizza we should order.

  For more details, you may check the [OUPS’ website ].

  This time we'll have the following talks:

  *Snapshottable Stores – Clément Allain & Gabriel Scherer (@gasche)*

  We say that an imperative data structure is *snapshottable* or
  *supports snapshots* if we can efficiently capture its current state,
  and restore a previously captured state to become the current state
  again. This is useful, for example, to implement backtracking search
  processes that update the data structure during search.

  Inspired by a data structure proposed in 1978 by Baker, we present a
  *snapshottable store*, a bag of mutable references that supports
  snapshots. Instead of capturing and restoring an array, we can capture
  an arbitrary set of references (of any type) and restore all of them
  at once. This snapshottable store can be used as a building block to
  support snapshots for arbitrary data structures, by simply replacing
  all mutable references in the data structure by our store
  references. We present use-cases of a snapshottable store when
  implementing type-checkers and automated theorem provers.

  Our implementation is designed to provide a very low overhead over
  normal references, in the common case where the capture/restore
  operations are infrequent. Read and write in store references are
  essentially as fast as in plain references in most situations, thanks
  to a key optimisation we call *record elision*. In comparison, the
  common approach of replacing references by integer indices into a
  persistent map incurs a logarithmic overhead on reads and writes, and
  sophisticated algorithms typically impose much larger constant
  factors.

  The implementation, which is inspired by Baker's and the OCaml
  implementation of persistent arrays by Conchon and Filliâtre, is both
  fairly short and very hard to understand: it relies on shared mutable
  state in subtle ways. We provide a mechanized proof of correctness of
  its core using the Iris framework for the Coq proof assistant.
  [/details]

  *Safe, expressive and efficient programming of FPGAs circuits – Loïc
   Sylvestre*

  FPGAs (Field-Programmable Gate Arrays) are reconfigurable digital
  circuits: their behavior can be customized by logic synthesis of
  specification at the so-called register transfer level (RT level), in
  hardware description languages such as VHDL or Verilog. FPGAs are well
  suited to implement reactive systems, directly as synchronous circuits
  interacting with the external environment via I/O pins – the logic
  synthesizer ensuring that timing constraints are met, given the FPGA
  clock frequency. FPGAs are also used to implement hardware
  accelerators ; however, RT-level descriptions of transformational
  systems (or “computations”) – with latencies of several clock cycles –
  are difficult to debug, maintain and manually optimize. High-Level
  Synthesis (HLS) offers a simpler way of expressing computations, using
  a programming language compiled at the RT level. The advantage of this
  approach is to keep the implementation details hidden from the
  programmer, leaving the compiler responsible for scheduling
  computations over time. However, this leads to a loss of control over
  temporal behavior and therefore safety and efficiency for the circuits
  generated. As embedded systems, especially those based on FPGAs, need
  to perform more and more computations, while interacting with their
  environment, this thesis proposes a programming model to combine
  hardware description (data-flow oriented) and general-purpose parallel
  computation (control-flow oriented) using a synchronous approach. This
  programming model forms the basis for the design and implementation of
  Eclat, a functional-imperative, parallel and synchronous programming
  language, compiled to VHDL. Eclat is sufficiently precise to describe
  synchronous circuits at the RT level. It facilitates the programming
  of hardware accelerators, with a clear and predictable temporal
  semantics by which to exploit time-space trade-offs. Any Eclat program
  is reactive, with a mechanism for embedding computations within
  programs and thereby mix computation and interaction. Eclat also
  offers shared memory (in the form of RAM blocks), with deterministic
  concurrency. It is used to develop programming abstractions such as
  algorithmic skeletons and virtual machine implementations for
  high-level languages. This addresses, at various levels, the need to
  run general-purpose algorithms within FPGA-based reactive embedded
  applications.

  After the talks there will be some pizzas offered by the [OCaml
  Software Foundation] and later on we’ll move to a pub nearby as usual.


[register on meetup ]
<https://www.meetup.com/fr-FR/ocaml-paris/events/304726885>

[OUPS’ website ] <https://oups.frama.io>

[OCaml Software Foundation] <https://ocaml-sf.org>


Dune dev meeting
════════════════

  Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/17>


Etienne Marais announced
────────────────────────

  Hi camelers! :camel: We will hold our regular Dune dev meeting on
  Wednesday, November, 27th at 16:00 CET. As usual, the session will be
  one hour long.

  Whether you are a maintainer, a regular contributor, a new joiner or
  just curious, you are welcome to join: these discussions are opened!
  The goal of these meetings is to provide a place to discuss the
  ongoing work together and synchronise between the Dune developers
  :ok_hand:


:calendar: *Agenda*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  The agenda is available on the [meeting dedicated page]. Feel free to
  ask if you want to add more items in it.


[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2024-11-27>


:computer: *Links*
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  • Meeting link: [zoom]
  • Calendar event: [google calendar]
  • Wiki with information and previous notes: [GitHub Wiki]


[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>

[google calendar]
<https://calendar.google.com/calendar/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319%40group.calendar.google.com>

[GitHub Wiki] <https://github.com/ocaml/dune/wiki#dev-meetings>


Other OCaml News
════════════════

From the ocaml.org blog
───────────────────────

  Here are links from many OCaml blogs aggregated at [the ocaml.org
  blog].

  • [Universal React in OCaml - David Sancho Moreno - FUN OCaml 2024]
  • [Using odoc to Write Documentation - Paul-Elliot Anglès d'Auriac -
    FUN OCaml 2024]
  • [How the Multicore Garbage Collector works - Sudha Parimala - FUN
    OCaml 2024]
  • [MirageOS - Developing Operating Systems in OCaml - Hannes Mehnert -
    FUN OCaml 2024]
  • [The Story Behind the Fastest Image Comparison Library - Dmitriy
    Kovalenko - FUN OCaml 2024]
  • [Easy GADTs by Repeating Yourself - Eduardo Rafael - FUN OCaml 2024]
  • [Maybe OCaml Was the Friends We Made Along the Way - Dillon Mulroy -
    FUN OCaml 2024]
  • [OCANNL, the `neural_nets_lib` - Lukasz Stafiniak - FUN OCaml 2024]
  • [Learning OCaml with Tiny Code Xmas - Michael Dales - FUN OCaml
    2024]
  • [Let Signals in OCaml - Rizo Isrof - FUN OCaml 2024]
  • [A 'Melange' of Tooling Coming Together - Antonio Monteiro - FUN
    OCaml 2024]
  • [Building Incremental and Reproducible Data Pipelines - Patrick
    Ferris - FUN OCaml 2024]
  • [The Future of Dune - Leandro Ostera - FUN OCaml 2024]
  • [Advanced Code Navigation in OCaml-LSP]
  • [opam 2.3.0 release!]


[the ocaml.org blog] <https://ocaml.org/blog/>

[Universal React in OCaml - David Sancho Moreno - FUN OCaml 2024]
<https://www.youtube.com/watch/Oy3lZl2kE-0?version=3>

[Using odoc to Write Documentation - Paul-Elliot Anglès d'Auriac - FUN
OCaml 2024] <https://www.youtube.com/watch/Qzf_ZB1TKLQ?version=3>

[How the Multicore Garbage Collector works - Sudha Parimala - FUN OCaml
2024] <https://www.youtube.com/watch/fgdB_9DcJj4?version=3>

[MirageOS - Developing Operating Systems in OCaml - Hannes Mehnert - FUN
OCaml 2024] <https://www.youtube.com/watch/g7Kl5mRDCDo?version=3>

[The Story Behind the Fastest Image Comparison Library - Dmitriy
Kovalenko - FUN OCaml 2024]
<https://www.youtube.com/watch/hTAvAKolWd8?version=3>

[Easy GADTs by Repeating Yourself - Eduardo Rafael - FUN OCaml 2024]
<https://www.youtube.com/watch/-XYO_ILJG2M?version=3>

[Maybe OCaml Was the Friends We Made Along the Way - Dillon Mulroy - FUN
OCaml 2024] <https://www.youtube.com/watch/1HlIHPa38gY?version=3>

[OCANNL, the `neural_nets_lib` - Lukasz Stafiniak - FUN OCaml 2024]
<https://www.youtube.com/watch/1J2XyHLb2J0?version=3>

[Learning OCaml with Tiny Code Xmas - Michael Dales - FUN OCaml 2024]
<https://www.youtube.com/watch/2ZswyN4aP2o?version=3>

[Let Signals in OCaml - Rizo Isrof - FUN OCaml 2024]
<https://www.youtube.com/watch/34bceAuSRXE?version=3>

[A 'Melange' of Tooling Coming Together - Antonio Monteiro - FUN OCaml
2024] <https://www.youtube.com/watch/3oCXT-ycHHs?version=3>

[Building Incremental and Reproducible Data Pipelines - Patrick Ferris -
FUN OCaml 2024] <https://www.youtube.com/watch/6mxx2j1jmhE?version=3>

[The Future of Dune - Leandro Ostera - FUN OCaml 2024]
<https://www.youtube.com/watch/7_bv3EvQANY?version=3>

[Advanced Code Navigation in OCaml-LSP]
<https://tarides.com/blog/2024-11-20-advanced-code-navigation-in-ocaml-lsp>

[opam 2.3.0 release!]
<https://ocamlpro.com/blog/2024_11_13_opam_2_3_0_releases>


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/>


[-- Attachment #2: Type: text/html, Size: 39744 bytes --]