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.

I was watching Systems with JT the other day and he demoed a hobby operating system called skiftOS. During the demo he ran one of the built-in apps called “neko” which looks like a clone of an old Windows “pet” program I remember from my childhood, also called “neko” (or “neko32”). It’s a really simple program: when you start it up, a cute little kitten shows up on your screen and starts running around, trying to catch your mouse cursor.

Close enough.

I’ve been working on a Wasm implementation in Racket for the past couple of weeks and have recently reached a neat milestone.

Inspired by Brian Adkins’ RacketCon talk from yesterday, I decided to record a screencast on what it’s like to write a little web application using my not-quite-a-web-framework, koyo. You can watch it over on YouTube and you can find the resulting code on GitHub. It’s unscripted and I don’t go too deep on how everything works, but hopefully it’s easy enough to follow and I’ve left the various mistakes I’ve made in since it’s usually helpful to watch someone get out of a tricky situation so look forward to those if you watch it!

Someone recently asked about how to deploy Racket web apps on the Racket Slack. The most common answers were install Racket on the target machine, then ship your code there or use Docker (basically a “portable” variant of option 1). I wanted to take a few minutes today and write about my preferred way of deploying Racket apps: build an executable with the application code, libraries and assets embedded into it and ship that around.