#lang lua

I’m currently working on a macOS app that’s built with Racket and allows the user to write small scripts to process and filter some data. While Racket is definitely my preferred language and I could easily use it for these scripts, my target audience for this app would probably appreciate a more familiar language. I decided to use Lua. So, last weekend I was faced with a choice1 between writing FFI bindings for Lua or implementing a #lang in Racket.

Screencast: SwiftUI + Racket

I’ve been playing with embedding Racket CS in desktop apps off and on for a while and today I recorded a little screencast demoing some of the stuff I’ve been working on. Here it is on YouTube:

Announcing racket-crontab

Earlier this week, Jesse Alama brought up the topic of scheduling cron jobs with koyo and we both agreed that it would be nice if koyo had built-in support for that sort of thing. So, I wrote crontab, a little library for parsing cron-style schedules and executing code based on them. On top of that functionality, I’ve added a new koyo/crontab module to koyo that integrates with the component system.

Announcing racket-kafka

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.

Parallelizing the Racket Web Server

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?

Announcing dbg

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.

Announcing gui-easy

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!

Improvements in koyo 0.9

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.