With all the buzz surrounding Vulkan and its ability to make graphics more shiny/pretty/fast, there is one key thing seems to have been lost in the ether of information - Vulkan isn’t just a graphics API, it supports compute too! Quoting the specification (bold added for effect): Vulkan is an API (Application Programming Interface) for graphics and compute hardware And: This specification defines four types of functionality that queues may support: graphics, compute, transfer, and sparse memory management.

While at GDC I got a feature request from the awesome folks over at Blastbay Studios requesting that they could feed an allocator to json.h, my JSON parsing library. This has long been on my TODO list, so I took the opportunity of a plane ride back from San Francisco to the Isle of Skye to remedy the situation! The latest master version of json.h changes the signature of json_parse_ex to include two new fields: alloc_func_ptr and user_data.

Most of my company projects have a requirement that we run clang-format on all commits to keep a consistent style. Unfortunately, I’m as forgetful as the fabled goldfish (which actually isn’t that forgetful it turns out) so I often forget to run clang-format. After the umpteenth time of forgetting and suffering some quite deepseated rage from my colleagues, I decided to investigate a way to automate the process. It turns out git has a really cool feature introduced in 1.7.0 to specify a folder of hooks, such that when you run git clone or git init to create a new local copy of a repository, it will as part of the creation process take a copy of these ‘template’ git hooks and use them in the repository.

In a previous post (Partial) Simplified JSON support in json.h I covered the partially added simplified JSON support I had added to json.h. One of the things I covered was my unwillingness to implement two of the features of simplified JSON, commas being optional and replacing : with =. I argued that both of these were unnecessary and stupid additions to the library. I was wrong. The immediate feedback I received detailed good reasons why these were useful, but more importantly - why did I half-arse implementing a feature that was requested by a user!

So as you may (or may not) already know - I’ve written two tiny C libraries - utf8.h and json.h. One of the questions that most plagued me when writing these libraries was ‘How should I write the tests for them?’ I could put them in a separate repository, I could put them within the repository, should I create a new testing framework every time? It would be useful to be able to have test cases spread across multiple files… and the thoughts went on and on.