Week 45: what’s everyone hacking on this week?

I thought I’d continue @avsm’s idea from last week and ask everyone what they’re hacking on this week. (I’ll post my own answer later.)


I’m hacking in an horrible badly designed macro-oriented language without any form of hygiene or sanity.

In other words, I’m preparing the slides for my PhD defense. It involves a lot of TikZ and beamer.

Fortunately, the content is about cool OCaml stuff. :stuck_out_tongue:


After last week’s adventure with reading input from tsdl, now working on exposing a common input interface for my Mirage library.

The greatest common denominator between my input backends turned out to be keyboard scancodes, so now I’ve dived into “literature” about USB-HID, PS/2, IBM XT S/1, X11 and the like, working on some sort of approximation of a US keyboard module mapping scancodes to keycodes / keysyms.

I’m also enjoying the flur of interesting posts on this forum, and going through various cutting-edge experimental flu cures such as “ginger tea” and “sleeping at night.” :slight_smile:


Hey, that’s a horribly designed macro language created by a winner of the ACM Turing Award who invented vast amounts of CS from whole cloth! :stuck_out_tongue_winking_eye:

Though I’ll totally agree his taste in macro languages was horrible. I wish it wasn’t far too late to fix TeX.

I’m working on a few things:

  • Continuing the cross compilation work stated last week.

  • Patching utop and its dependency code to be 4.06.0 compatible

  • Smaller jbuilder improvements like fixing $ jbuilder rules


I mainly procrastinate my actual work with DNS - the Domain Name System. Over the past half year I started from scratch and had the goal to implement a recursive resolver. This is working since a few months fine on my laptop, but I’m not sufficiently satisfied to put it online (yet).

While looking into how to configure it, I stumbled upon nsupdate (https://tools.ietf.org/html/rfc2136) (if you add TSIG https://tools.ietf.org/html/rfc2845 you even get authentication) :slight_smile: It turns out, a configurable resolver (to be used in a similar fashion as DNSmasq or your system resolver) needs a complete authoritative nameserver next to it for your local overlays.

I went down the rabbit hole, and by now have a primary nameserver (which receives all updates via nsupdate), a secondary nameserver (which waits for notify https://tools.ietf.org/html/rfc1996 from the primary to request a SOA and if there’s a newer serial, start a zone transfer https://tools.ietf.org/html/rfc5936 - both authenticated with TSIG above).

And I just succeeded in the first non-trivial setup:

  • primary NS with example zone containing itself and two keys (transfer and update)
  • secondary NS with the same transfer key, nothing else
  • client (nsupdate from the ISC BIND project) which sends an update frame: add example 300 ns ns2.example ; add ns2.example 300 a (authenticated with the update key) to the primary
  • primary sending a notify to the new secondary
  • secondary requests the SOA of example from the primary (authenticated with the transfer key)
  • primary answering with an authenticated SOA
  • secondary - based on the fact that it does not have the example zone with equal serial in the SOA, requesting a zone transfer from the primary (authenticated with the transfer key)
  • primary answering the zone transfer with an authenticated zone
  • secondary receiving the zone, and now serving it

this may be half the way down, extensions I’d like to have include incremental zone transfer, authentication via TLS, adding keys via nsupdate as well (that should work, but haven’t tried), persistent storage in a (read-only, written by the nameserver) git repository, going back to my resolver implementation and revise it once more, integrate the zone file parser from ocaml-dns, DNSSec (signing and validation), multicast-DNS (“bonjour” / “zeroconf”), …

but first I’ll polish the existing parts, do some more interoperation tests with available server and client software, and put the code publicly accessiblle. And/or go back to my TCP work :wink:


Very nice to hear about so many interesting projects :slight_smile:

Regarding my current projects: I am working on Ramen a template engine for static websites. This started initially just as a toy to refresh my own website (as I never managed to grasp how Jekyll works properly) but I am now happy enough with the result so I am planning to extend the tool to work well with MirageOS/Irmin (and support less static settings).

I also enjoy reviewing @dinosaure’s mega-PR on ocaml-git. Hopefully we will be able to merge it soon and have a full non-blocking Git server in pure OCaml (yay!)


Last week I didn’t answer because I was also mostly dealing with paperwork and paper-work (now on

But I’ve been pushing the development of Genspio; implementing the future work mentioned in my talk at OCaml 2017: the EDSL now has different types for byte-arrays and C-like strings (PR #60).

Now improving the documentation and the API:
Started having fun with src/examples/small.ml which is a module that generates another OCaml module that runs a bunch of examples and itself generates Markdown documentation … “sooo meta” …
So far it generates this.
Pretty happy with jbuilder for that one, staying away from ppx and generating the jbuild files, but using code generators within the build works pretty well out of the box.


I’ve had a look at the bulk build logs for 4.05 -> 4.06, and knocked up a script to list some of the build failures.

Help triaging and porting some of the failures would be appreciated :slight_smile: It can either be done by porting the library to support -safe-string, or by constraining the opam metadata for older releases to available: [ ocaml-version < "4.06.0" ] to stop it from being selected on the new compiler. I’ll post a more detailed blog post later this week once the build logs are tidied up and running regularly.


As part of the filesystems stuff, I am playing around with modular filesystem libraries. Current version is:


Supports mounting via Fuse, passthrough-to-local-filesystem, in-memory, and over-the-network, and any combination that makes sense (eg Fuse mounted NFS client communicating with NFS server serving files via passthrough-to-local on the server). The code is also parameterized over the monad (eg Lwt, or just a plain step monad).

Still a WIP, but nearly there.

(NOTE NFS here means “network filesystem”, not THE NFS that we all know.)


Is it possible to somehow avoid generating the jbuild files on genspio? Generating the build like that makes the library harder to vendor than necessary and genspio looks like a very useful tool.

Would be nice to know how vanilla jbuilder is limiting you

@rgrinberg I want to be able to describe the whole build in one single hackable OCaml file without any redundancy. Like,

let version = "0.0.1-dev"

let main_libs = [

has to appear only once; and then be used to build everything including what’s built without jbuilder (like parts of the documentation, or generating *.opam files, which are sadly checked into the repo).

Generating the build like that makes the library harder to vendor than necessary

In what way can a ./configure step make the library harder to vendor?

BTW, with my “music” side-projects, I have been using jbuilder's composability (i.e. I have a big private repo with git-subtrees of the open-source projects); and ./configure steps that generate jbuild files are not a problem, it’s the opposite, it’s easier to manage and scales better.
(It’s https://gitlab.com/smondet/vimebac https://gitlab.com/smondet/vecosek etc)

In a world where all the packages use jbuilder, you can simply use $ opam source to fetch a bunch of repos and run $ jbuilder build in the root directory. You don’t have to remember which repositories have a configure step and which don’t. Obviously it’s just an inconvenience, but it’s one that is hard to work around automatically without looking at the details of each project.

Other people have also brought up the point that maintaining a single build file for your projects is more natural. And I tend to agree if the alternative is to duplicate information between the build files. But there are clear benefits to having an own jbuild file per directory as well.

I’m building a URL shortener with three components: a GraphQL API for management, the actual redirector, and a React.js based interface (maybe using Reason).

I’m brand new to OCaml with my only functional programming experience being going through Learn You a Haskell for Great Good and doing a tiny project with it a few years ago. Really enjoying OCaml, it’s feeling pretty natural to me. Just wish there were better database libraries.

I’m currently using ocaml-mariadb and it’s been great except for not being able to run concurrent queries despite supporting Lwt. The other relational DB libraries I’ve looked at all seem to have major drawbacks or are immature (want Lwt and jbuilder support). I’d be happy to know if I missed one; I don’t need to use MariaDB.

That said, the OCaml community in the Reason discord channel have been great and super helpful. I’m excited and hopeful for my future with OCaml.


If I get time this week, I will be implementing static HTML generation for Logarion. Spent a bit of time removing Batteries dependency.

Also made a small patch for To.ml to build on 4.06, but have no idea if it still maintained. If anyone knows about the situation there, let me know.

1 Like

This week: how do I staged computation? /o\

I’m fixing some bugs in mirage-net-xen’s netback support so that mirage-firewall on QubesOS works with HVM client VMs (which are the default on Qubes 4) and with disposable VMs.


I’m really glad to hear this, it will bring ocaml dns closer to where go-dns is.

1 Like