Racket-Vulkan: Contributor Content, CLI, and Flexible Code Generation

racket-vulkan is evolving in pretty exciting ways, and more oppurtunities are popping up to improve it than I can handle alone. I should start with a blanket thank you to the volunteers who A) offered use of their systems, B) opened PRs, or C) simply told me how excited they were about the project.

I added contributor documentation to show the techno-operational needs of the project and current priorities. The single biggest need is additional Vulkan applications. I’m still in the process of porting code from vulkan-tutorial.com to render a triangle using GLFW. At least with that, enough evidence will exist to show support for presentation with swap chains and compute pipelines. So cool!

Another key development is a new CLI called ravk. That’s short for racket-vulkan, and is pronounced “Ravick” (to sound a little like “Havoc”). ravk exposes a pluggable Racket code generation machine and a Vulkan specification manager to the end user. Why is this great? Because if the racket-vulkan source code ends up out of date, you can still use it to generate up to date Vulkan bindings. In other projects I’ve seen, if language bindings for Vulkan are out of date, then users depend on a maintainer to fix that. With my approach, users don’t have to wait on me if I’m focused on something else.

The “pluggable code generation machine” is nothing more than a collection of specialized Racket modules that take a Vulkan specification and generate a small selection of code against assumptions it is free to make. This is important because Vulkan specifications evolve organically, and even backwards-compatible changes might force you to reassess an approach. Doing so was hellishly difficult with a monolithic code generator.

Finally, I’ve submitted the porject to the Racket Game Jam. It’s not an actual game, but I need feedback whenever I can get it.

Some future developments include continuous integration, a stable set of bindings, opt-in type safety and convenience functions, a #langs for system requirements, and a shader #lang to produce SPIR-V modules. That’s a LOT of work, but this is the kind of project where that doesn’t feel intimidating.

If you are interested in following or supporting the project, please watch it on Github. I’m shifting gears to focus on maintainability and stability, and then new features will come.