For the past month or so, I’ve been working on implementing a pure-Racket client for Apache Kafka. Yesterday, it reached a point where it can do the bare minimum you would expect from it: produce data and join consumer groups to consume data. Kafka has a fairly large feature-set so there’s a ton left to do, but I figure this is a good time to announce the library and get feedback.

Racket provides support for concurrency via lightweight threads, which the web server leverages to handle requests, spawning one such thread per incoming request. At the runtime level, these threads run concurrently but not in parallel (i.e., only one thread is active at any one time). Parallelism is available in Racket via Places: distinct instances of the Racket runtime running in separate OS threads that communicate via message passing.

The web server doesn’t do anything with places, so, by default, all Racket web servers run in a single OS thread. That isn’t a big deal since you can run one web server process per core and place a reverse proxy like Nginx in front to load balance between the processes. But what if you don’t want to do that? Is there a way to use the web server in conjunction with places despite the web server lacking explicit support for them?

I recently ran across Matthew D. Miller’s “Survey of the State of GUI Programming in Lisp” series on implementing a small GUI application across various LISP implementations. The first article in that series uses racket/gui, so I figured I’d take a stab at porting that implementation to gui-easy. You can find my port here.

Yesterday, I gave a talk about gui-easy at the eleventh RacketCon! You can find a recording of the talk on YouTube and a transcript below. Day two of the conference is starting in a little under a couple of hours so join us if you like!

I recently started working on a remote debugging/monitoring tool for Racket programs. It comes with a TCP server for exposing debugging information, a client implementation, and a GUI that builds upon those two things. You run the server as part of your application and then connect to it via the UI to debug things. Currently, it provides insights into GC pauses, current memory usage by data type, and a way to run and visualize performance profiles.

These past couple of months, I’ve been working on a library for building declarative GUIs in Racket. It’s called gui-easy and it works by wrapping racket/gui. See the examples directory to get an idea about how it’s meant to be used, or watch the demo below: The library is still a work in progress so expect some breaking changes. If you use it, let me know what you think!

Recently, Daniel Holtby improved the implementation of racket/rerequire, which, in turn, inspired me to improve koyo’s own code-reloading implementation. Version 0.9 (released today) no longer restarts the application process on every change and, instead, uses dynamic-rerequire to only reload the modules that change as well as any modules that depend on them. On Matchacha, which is about 11k lines of Racket code (excluding whitespace), this improves reload times by 5 to 10x, depending on the modules being reloaded.

After hacking on redis-lib for a bit on Sunday, I decided to write a general-purpose resource pooling library that I can re-use between it and http-easy and I recorded the process. You can check it out on YouTube: You can find the library on GitHub. One particularly interesting bit about the library, that I did not to record, is that the tests are all property-based. I might do another screencast at some point to talk about how they work and the bugs they found in my original implementation (from the video).

I decided to write a library for storing koyo sessions in Redis today and I recorded the process. If that sounds appealing, you can check it out on YouTube:

As of iOS 14.4, non-debugged builds (i.e. ones run outside of XCode) fail with a dynamic code signing error and there is no way to work around this at the moment.

A couple of weeks ago, I started working on getting Racket CS to compile and run on iOS and, with a lot of guidance from Matthew Flatt, I managed to get it working (with some caveats). Those changes have now been merged, so I figured I’d write another one of these guides while the information is still fresh in my head.