In The Missing Guide to Racket’s Web Server, I said that dispatch/servlet is equivalent to: 1 2 3 (lambda (start) (lambda (conn req) (output-response conn (start req)))) That was an oversimplification. It does apply its start argument to incoming requests and it does take care of writing the responses to the appropriate connections, but it has another important job: to handle responses returned from continuations and to dispatch incoming requests to captured continuations.

A little over a year ago, I wrote about how you could use the GitHub’s new-at-the-time Actions feature to test Racket code. A lot has changed since then, including the release of a completely revamped version of GitHub actions and so I thought it was time for an update. A Basic Package Say you’re working on a Racket package for computing Fibonacci sequences. Your main.rkt module might look something like this:

Racket’s package manager doesn’t currently have the notion of locking package sets to specific versions1 per project so, as someone who operates a couple production Racket applications, I’ve been concerned about the possibility that new deployments could introduce bugs in production due to changing dependencies. To solve this problem, over the past weekend I’ve put together a service that creates daily snapshots of the official package catalog. You can find it at racksnaps.

For a project that I’m working on, I have a custom flake id spec that allows me to generate unique, sortable identifiers across computers without any sort of synchronization. The ids themselves can be encoded down to 16 bytes and I wanted to store them in Postgres. A good way to do that is to leverage Postgres’ UUID data type, which lets you efficiently store any 16 byte quantity in a way that can be indexed reasonably well.

Yesterday, I announced rackcheck, my new property-based testing library for Racket and I wanted to do a quick dive into one of the examples in the rackcheck repo where a simple web API is integration tested using PBT. You can find the full example here. The app being tested is a simple leaderboard HTTP API with 3 endpoints: GET /players: lists all the registered players in order from highest score to lowest.

I’ve been playing around with property-based testing in Racket this past week. I started by forking the existing quickcheck library to try and add support for shrinking, but I quickly realized that I’d have to make a number of breaking changes to get it to work the way I wanted so, in the end, I decided to start a new library from scratch. The library is called rackcheck and you can grab it off of the package server.

Racket’s built-in web-server package is great, but parts of it are low-level enough that it can be confusing to people who are new to the language. In this post, I’m going to try to clear up some of that confusion by providing some definitions and examples for things beginners might wonder about. Servlets A servlet is a function from a request to a response. It has the contract: 1 (-> request?

I’d been meaning to play with Racket’s built-in sandboxing capabilities for a while so yesterday I sat down and made Try Racket. It’s a web app that lets you type in Racket code and run it. The code you run is tied to your session and each session is allocated up to 60 seconds of run time per evaluation, with up to 128MB of memory used. Filesystem and network access is not permitted and neither is access to the FFI.

/u/myfreeweb pointed out to me in a lobste.rs thread yesterday that Racket compiles just fine on aarch64 and that led me down a rabbit hole trying to get Racket running inside an iOS application. I finally succeeded so I figured I’d write down my findings in hopes of helping future Racketeers (myself included) going down this path! Compile Racket for macOS A recent-enough version of Racket is required in order to compile Racket for iOS.

A couple of days ago, I released a native macOS application called Remember. It is a small, keyboard-driven application for stashing away notes/reminders for later. One of the cool things about it from a programming nerd perspective is that, while it is a completely native Cocoa application whose frontend is built with Swift, the core business logic is all in Racket! Why not use racket/gui? I started out with a proof of concept that used Racket for the GUI, but I realized that I’d have to write a bunch of Objective-C FFI code to get the UI to look the way I wanted (a carbon copy of Spotlight) and it seemed like it would be a pain to try and integrate DDHotKey and to add support for launching at login into a package that is easy to distribute.