I’ve had a lot of people using my unicode library utf8.h since its release - thanks to all who’ve found the library useful and provided feedback! One of the things that I’d scrimped on previously was my support for case-insensitive comparisons for letters beyond those in ASCII. I knew little about this, but when a user requested that my library also supported accented latin characters, and later greek symbols, I jumped to the occassion to add support.

I’ve long been after a cross-platform way to launch processes and interact with them for use from C & C++. After a brief scouring of the interwebs, I didn’t find any that matched my criteria: No build system dependencies. Works in C and C++. Works on Windows, Linux and macOS. Single header (or at least single header / single source file). So I did what I always do when confronted with this issue - I wrote my own!

One component of Codeplay’s ComputeAorta that I manage is our high precision maths library Abacus. One major component of Abacus, and in fact all math libraries, are a requirement to have remez reduced polynomial approximations of functions. In the past we’ve made use of Maple, Mathematica, lolremez, our own fork of lolremez, and to be honest none of them have been satisfactory to our needs. We want a scriptable solution that we can use to bake the generated polynomials automatically into Abacus with minimal user intervention.

LLVM comes with a really useful set of options LLVM_USE_CRT_ which allows you to specify a different C RunTime (CRT) when compiling with Visual Studio. If you want to be able to compile LLVM as a release build, but compile some code that uses it in debug (EG. our ComputeAorta product that allows customers to implement OpenCL/Vulkan on their hardware insanely quickly), Visual Studio will complain about mixing the differing version of the CRT.

I gave a talk on Friday 13th of October 2017 at the Khronos Munich Chapter titled ‘OpenCL to Vulkan: A Porting Guide’. I covered how to port from the OpenCL API to the Vulkan API, some common problems our customers have faced, and how to fix them. The slides are available here. The talk covered some of the major pitfalls our customers have had in porting OpenCL applications to Vulkan, and also briefly covered the work we did in collaboration with Google and Adobe - clspv.