Multiple Research Software Engineer positions are available in the Department of Computer Science and Engineering at the Indian Institute of Technology, Madras to develop Multicore OCaml and enable Tezos ecosystem to benefit from Multicore OCaml.
Multicore OCaml comes with a concurrent garbage collector, where the garbage collector and the mutator threads run concurrently. Debugging concurrent GC bugs has been the most frustrating / satisfying (when fixed) part of Multicore OCaml development. rr, a record and replay tool has made debugging concurrent GC bugs a sustainable exercise. In this short post, I’ll describe why.
I am chairing the PC for ML family workshop this year. The PC is happy to invite submissions for the workshop to be held during the ICFP conference week on Thursday 22nd August 2019.
ML family workshop invites submissions touching on the programming languages traditionally seen as part of the “ML family”. However, we are also keen to receive submissions from other related language groups. If you have questions about the suitability of your work for the workshop, please feel free to write an email.
It has been 3 months since I joined IIT Madras and it has been good fun so far. Along with the members of the RISE group, we’ve initiated a project to build secure applications on top of secure extensions of the open-source Shakti RISC-V processor ecosystem. Unsurprisingly, my language of choice to build the applications is OCaml. Given the availability of rich ecosystem of libraries under the MirageOS library operating system for building unikernels, we hope to minimise the amount of unsafe C code that the hardware has to contend with and protect exploits against. As a first step, we have managed to get OCaml programs to run on directly on top of the Shakti processor running in simulation under QEMU and Spike ISA simulators without an intervening operating system.
Over the past few weeks, at OCaml Labs, we’ve deployed continuous benchmarking infrastructure for Multicore OCaml. Live results are available at http://ocamllabs.io/multicore. Continuous benchmarking has already enabled us to make informed decisions about the impact of our changes, and should come in handy over the next few months where we polish off and tune the multicore runtime.
Andrej Bauer and I are editing a special issue of JFP on the theory and practice of algebraic effects and handlers. The CfP is below.
I recently gave a talk on the internals of multicore OCaml GC at Jane Street offices in NYC. The slides from the talk are available online. But I felt that the slides alone aren’t particularly edifying. This post is basically the slides from the talk annotated with notes.
We recently published a paper on concurrent system programming with effect handlers. In this paper, we show that with the help of effect handlers, we could express in direct-style, various interactions of a concurrent program with OS services that typically require callbacks. The question is what do we do about legacy code that uses monadic concurrency libraries such as Lwt and Async. Surely a wholesale rewrite of all Lwt and Async code is a no go. This post is an exploration of some ideas to make Lwt and Async compatible with direct-style code.
One of the key indicators of maturity of a language ecosystem is the ease of building, managing and publishing software packages in that language. OCaml platform has made steady progress in the last few years to this end. While OPAM simplified package (and compiler) management, the developing and publishing packages remained a constant pain point. This situation has remarkably improved recently with the Topkg and Carcass. This post provides a short overview of my workflow for building and publishing an OCaml package using Topkg and Carcass.
Ezirmin is an easy interface over the Irmin, a library database for building persistent mergeable data structures based on the principles of Git. In this post, I will primarily discuss the Ezirmin library, but also discuss some of the finer technical details of mergeable data types implemented over Irmin.