defn.io

Announcing Ruckus

Tue, 31 Mar 2026 11:21:00 +0300

I'm happy to announce the public release of Ruckus, a Racket IDE for iPhone and iPad. Check it out and let me know what you think!

Ruckus is open source and based on Noise. The frontend was coded almost entirely by Claude Code, with a lot of architecture guidance and code review from me. The project was on the back of my mind for a while, but I probably would never have started it were it not for CC becoming quite good at (what I find to be) mundane tasks like this.

My workflow was¹ pretty simple. I would come up with a task and tell CC to expand on it and write a plan to disk. Then I would ask it to perform the task. It would summarize what it was about to do and I'd correct it or tell it to go ahead. After it finished a first pass at a task, I'd review the changes and concurrently ask it to review them itself, either by running the /simplify command or by telling it to "Ultrathink² and review the pending changes for issues and refactoring opportunities." While I don't have a counterexample to compare with, my instinct is that this took overall less time than it would've had I done everything manually -- which is not something I would've felt even a few months ago with the state of the art at the time.

I realize this is sounding like an ad for Anthropic, but I'm actually ambivalent about these tools. On one hand, I love the act of programming and I feel similarly to Greg Knauss. On the other hand, they are becoming genuinely useful, so I guess I'll continue to use them for work I don't feel like doing for now.

It has since evolved to something more complicated that I'll write about someday. But the version released today was built almost entirely following this workflow. ↩
ultrathink is a keyword that temporarily turns on maximum thinking effort. It only works interactively, so I would keep repeating more or less the same phrasing after each task. At one point, I even considered adding a keyboard macro for it. ↩

SO_KEEPALIVE Slow (?) on macOS

Thu, 31 Jul 2025 08:00:00 +0300

Update: Mystery solved!

Pete Kazmier reached out over e-mail asking if I could share some packet captures of the problem. I sent them to him, and he figured out the issue.

The Racket implementation was passing the wrong level to setsockopt, namely IPPROTO_TCP instead of SOL_SOCKET. The particular combination of the values of IPPROTO_TCP and SO_KEEPALIVE on macOS happens to map to a configuration where the use of TCP options is disabled altogether. See Pete's explanation on GitHub.

When I made my reproduction I, of course, didn't think to double check that the original setsockopt call was correct in the first place 🤦🏻‍♂️.

Original post below.

[Tested on macOS 14, 15 and 26.]

It turns out that enabling SO_KEEPALIVE on a socket on macOS slows operations through that socket to a crawl.

I noticed this while looking into a performance issue with downloads for Podcatcher. I set up a remote server¹ to download a 1GB file, and saw it was much slower than curl or even Python's requests library. Then, I minimized the test down to a plain Racket TCP client:

#lang racket/base

(require racket/port
         racket/tcp)

(define-values (in out)
  (tcp-connect "<HOST>" 8000))

(fprintf out "GET /1gb.bin HTTP/1.1\r\n")
(fprintf out "Connection: close\r\n")
(fprintf out "\r\n")
(tcp-abandon-port out)
(read-line in)
(time (copy-port in (open-output-nowhere)))

Which, to my surprise, was also slow. Eventually, I tested it on a Linux Docker container, and that was performing as expected. Then, I tested it on a macOS machine running Racket 8.15, and that was also performing well.

In version 8.17, Racket enabled SO_KEEPALIVE for all TCP sockets by default, and that turns out to be the culprit. For whatever reason, only on macOS, if you turn on SO_KEEPALIVE on a socket (client or server), operations on that socket slow down significantly (2x-4x between machines on the same WiFi network and a lot more when more hops are involved²).

Here's a minimal C client program that reproduces the problem. To test it, on a remote server, generate a large file by running dd:

dd if=/dev/zero of=1gb.bin bs=1MB count=1024

Then, serve it using Python:

python -m http.server --bind 0.0.0.0 8000

On a Mac, compile and execute the following code, replacing the HOST and PORT strings with appropriate values for your test:

#include <arpa/inet.h>
#include <netinet/tcp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

const char *HOST = "<HOST>";
const char *PORT = "<PORT>";

int sendstr(int sock, const char *str) {
  return send(sock, str, strlen(str), 0);
}

int main(void) {
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    if (sock < 0) {
        perror("socket");
        return 1;
    }

    int enable = 0; // Set to 1 to slow to a crawl
    if (setsockopt(sock, IPPROTO_TCP, SO_KEEPALIVE, &enable, sizeof(enable))) {
      perror("setsockopt");
      close(sock);
      return 1;
    }

    struct sockaddr_in server_addr;
    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_port = htons(atoi(PORT));

    if (inet_pton(AF_INET, HOST, &server_addr.sin_addr) <= 0) {
        perror("inet_pton");
        close(sock);
        return 1;
    }

    if (connect(sock, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) {
        perror("connect");
        close(sock);
        return 1;
    }

    sendstr(sock, "GET /1gb.bin HTTP/1.1\r\n");
    sendstr(sock, "Connection: close\r\n");
    sendstr(sock, "\r\n");

    char buf[65536];
    size_t nread, total = 0;
    do {
      nread = recv(sock, buf, sizeof(buf), 0);
      total += nread;
      printf("%ldMiB\r", total/1024/1024);
    } while (nread > 0);
    printf("%ldMiB\n", total/1024/1024);

    close(sock);
    return 0;
}

Change the enable flag to 1 and then run it again to see the difference.

For Racket, the fix is going to be to turn off SO_KEEPALIVE on macOS. I've sent a report to Apple (FB19250856) about this problem. Maybe they'll have an idea about what's going wrong here.

The issue doesn't occur over loopback. ↩
In my test with the 1gb file on a remote server, the slowdown was between 20x and 40x. ↩

What is Racket DOING???

Fri, 30 May 2025 07:35:00 +0300

A neat feature of the JVM is that, out of the box, you can send a running JVM process a SIGQUIT signal and it'll dump stack traces for all running threads to stdout. The output looks like this. It can be really handy when you're trying to debug a live system.

Racket doesn't have this feature, but you can build something like it yourself by combining some of the introspection tools the runtime system provides to you. Given a Racket thread, you can get its continuation marks, using the continuation-marks procedure:

> (continuation-marks (thread void))
#<continuation-mark-set>

With a set of marks in hand, you can get an approximate stack trace by calling continuation-mark-set->context:

> (continuation-mark-set->context
   (let ([thd (thread (λ () (let loop () (sleep 5) (loop))))])
     ;; Give the thread a chance to activate.
     (sync (system-idle-evt))
     (continuation-marks thd)))
(list (cons #f (srcloc 'string 2 20 53 42)))

The result is a list of pairs of procedure names (or #f if a procedure name is not available, as above) and source locations. Converting that list to a textual stack trace is straightforward.

The next step is to get a list of all running threads. All threads in Racket are managed by a custodian. If you have access to a custodian and its parent, you can ask for all of the objects managed by that custodian by calling custodian-managed-list.

> (define root (current-custodian))
> (current-custodian (make-custodian root))
> (define thd (thread (lambda () (let loop () (sleep 5) (loop)))))
> (custodian-managed-list (current-custodian) root)
'(#<thread>)

The result may include custodians subordinate to the custodian you're querying:

;; ... continued from above
> (define child (make-custodian))
> (define thd-of-child
    (parameterize ([current-custodian child])
      (thread (lambda () (let loop () (sleep 5) (loop))))))
> (custodian-managed-list (current-custodian) root)
'(#<thread> #<custodian>)

So, you have to collect the list of threads recursively by dispatching on the types of the values in the list:

;; ...continued from above
> (define thds
    (let loop ([v (current-custodian)])
      (cond
        [(thread? v) (list v)]
        [(custodian? v) (loop (custodian-managed-list v root))]
        [(list? v) (apply append (map loop v))]
        [else null])))
> thds
'(#<thread> #<thread>)

With that, you can print stack traces for all threads reachable from the topmost custodian your program or library has access to.

This is now a a built-in feature of dbg. The client has a new dump-threads procedure that returns a string representing the stack traces of all the threads accessible by the debugging server in a process¹ and the GUI displays that same information under a new "Threads" tab.

More specifically, in a place, since each place has its own custodian tree. ↩

Sharing Data Between Widgets and iOS Apps

Sun, 13 Apr 2025 09:31:00 +0300

Following up on the previous post, another thing that's not well-documented when it comes to implementing widgets on iOS is how to share data between the widget and the main app.

The widget is supposed to be small and efficient so loading all your models in there seems wrong (and the extension probably(?) can't even access the app's sandboxed database).

The documentation mentions using network requests a bunch, presumably because a lot of these widgets are expected to be used to display remote data, but what about if you want to keep everything local?

The best solution I've found so far is to use UserDefaults with a shared app group. I created a new app group (Target Settings -> Signing & Capabilities -> Add Capability -> App Groups) and added both the main app target and the widget extension target to it.

Then, I made some Codable structs that are shared between the two targets and a coordinator, also shared between the targets, that reads and writes those structs as JSON through a UserDefaults(suiteName: "app-group-id") instance.

Finally, whenever something relevant to the widgets happens in the app, an event listener updates the shared data and calls WidgetCenter's reloadAllTimelines method to have the system instruct the widgets to reload the next time they're rendered. As far as I can tell, reloading the timelines is always deferred, so calling reloadAllTimelines multiple times in a row won't cause issues.

Performing Widget Intents in-app on iOS

Sun, 13 Apr 2025 09:09:00 +0300

I'm currently adding widgets to Podcatcher and one issue I've run into that's not very well documented is how to trigger an App Intent — for example, to start playing a Podcast — from a widget, ensuring that the intent is performed in the app.

There are two problems that need to be solved:

The intent has to be a part of both the main app target and the widget extension target. How do we avoid including all of the app's dependencies in the widget extension?
Since the intent is going to be included in both targets, after we solve 1), how do we ensure that the intent gets run inside the main app process.

To solve the first problem, I added an Active Compilation Condition (Build Settings -> Swift Compiler - Custom Flags -> Active Compilation Conditions) to the main app target for both Debug and Release builds. I called it MAIN_APP. With the flag in place, I can conditionally compile the perform method of the intent so that it only does stuff when invoked within the app:

struct TogglePlaybackIntent: AppIntent {
  nonisolated static let title: LocalizedStringResource = "Toggle Playback"
  nonisolated static let description = IntentDescription("Plays/pauses the Podcatcher queue.")

  @MainActor
  func perform() async throws -> some IntentResult {
#if MAIN_APP
    // actual playback code here
#endif
    return .result()
  }
}

This way, I can include the intent in the extension target and refer to it in a button without bringing in all the other deps (models, audio engine, etc.) that are needed to actually play a podcast.

To solve the second problem, you have to either set the openAppWhenRun member to true within your intent implementation, or have the intent implement the AudioPlaybackIntent instead of AppIntent. The latter was more appropriate for this particular intent, so that's what I did:

- struct TogglePlaybackIntent: AppIntent {
+ struct TogglePlaybackIntent: AudioPlaybackIntent {

DSLs for Safe iOS/watchOS Communication

Sun, 16 Feb 2025 08:00:00 +0200

I'm currently writing an Apple Watch counterpart app for Podcatcher.

The Watch Connectivity framework that iOS apps use to communicate with watchOS apps offers a limited API for communication: you can either send untyped dictionaries or arbitrary byte strings between the two.

In a large app, you want more structure than that framework offers. One approach you can take is to encode shared structs as JSON and pass them around as byte strings, manually writing all the boilerplate code to ensure that a response to a certain message decodes to the right type, and so on. A better approach is to write a little DSL to declare all the message and response types and use that information to generate code to handle the encoding/decoding boilerplate and to ensure that the right message handlers are implemented on either side. In Podcatcher, that currently looks like this:

(define-enum AppPlaybackState
  [empty]
  [paused
   {item : (Delay WatchQueueItem)}
   {progress : UVarint}
   {duration : UVarint}]
  [playing
   {item : (Delay WatchQueueItem)}
   {progress : UVarint}
   {duration : UVarint}])

(define-record WatchQueueItem
  [podcast-title : String]
  [episode-id : UVarint]
  [episode-title : String]
  [episode-progress : UVarint]
  [episode-duration : (Optional UVarint)]
  [enclosure-path : (Optional String)]
  [completed? : Bool]
  [order : UVarint])

(define-record WatchQueue
  [items : (Listof WatchQueueItem)])

(define-watch-rpcs
  WatchMessage ;; watch -> app messages
  [get-playback-state : AppPlaybackState]
  [go-backward : Bool]
  [go-forward : Bool]
  [pause : Bool]
  [play {episode-id : UVarint} : Bool]
  [resume : Bool]
  [sync-queue {local-items : (Listof WatchQueueItem)} : WatchQueue]
  [want-files {episode-ids : (Listof UVarint)} : Bool])

This takes advantage of Noise's define-enum and define-record to generate Swift enums and structs that can be serialized and deserialized to and from byte strings. On top of that functionality, the define-watch-rpcs macro declares what all the watchOS to iOS messages are and generates:

an enum representing the messages,
code to send a message from the watch app to the phone app,
a protocol for handling those messages in the phone app and
code to wire up the message-receiving side to the protocol implementation.

The generated WatchMessage enum looks like this:

public enum WatchMessage: Readable, Sendable, Writable {
  case getPlaybackState
  case goBackward
  case goForward
  case pause
  case play(UVarint)
  case resume
  case syncQueue([WatchQueueItem])
  case wantFiles([UVarint])

  // ser/de code elided
}

The generated code for sending these messages from the watch app to the phone app looks like this:

extension WCSessionManager {
  func getPlaybackState() async throws -> AppPlaybackState {
    return try await send(message: WatchMessage.getPlaybackState)
  }

  func goBackward() async throws -> Bool {
    return try await send(message: WatchMessage.goBackward)
  }

  func goForward() async throws -> Bool {
    return try await send(message: WatchMessage.goForward)
  }

  func pause() async throws -> Bool {
    return try await send(message: WatchMessage.pause)
  }

  func play(episodeId: UVarint) async throws -> Bool {
    return try await send(message: WatchMessage.play(episodeId))
  }

  func resume() async throws -> Bool {
    return try await send(message: WatchMessage.resume)
  }

  func syncQueue(localItems: [WatchQueueItem]) async throws -> WatchQueue {
    return try await send(message: WatchMessage.syncQueue(localItems))
  }

  func wantFiles(episodeIds: [UVarint]) async throws -> Bool {
    return try await send(message: WatchMessage.wantFiles(episodeIds))
  }
}

The generated protocol for handling these messages in the phone app looks like this:

protocol WatchMessageHandler {
  func getPlaybackState(session: WCSession) -> AppPlaybackState
  func goBackward(session: WCSession) -> Bool
  func goForward(session: WCSession) -> Bool
  func pause(session: WCSession) -> Bool
  func play(session: WCSession, episodeId: UVarint) -> Bool
  func resume(session: WCSession) -> Bool
  func syncQueue(session: WCSession, localItems: [WatchQueueItem]) -> WatchQueue
  func wantFiles(session: WCSession, episodeIds: [UVarint]) -> Bool
}

Finally, the generated code to wire receiving the messages to an implementation of the protocol looks like this:

extension AppDelegate: WCSessionManagerDelegate {
  nonisolated func handle(session: WCSession, watchMessage message: WatchMessage) -> any Writable {
    switch message {
    case .getPlaybackState:
      return getPlaybackState(session: session)
    case .goBackward:
      return goBackward(session: session)
    case .goForward:
      return goForward(session: session)
    case .pause:
      return pause(session: session)
    case .play(let episodeId):
      return play(session: session, episodeId: episodeId)
    case .resume:
      return resume(session: session)
    case .syncQueue(let localItems):
      return syncQueue(session: session, localItems: localItems)
    case .wantFiles(let episodeIds):
      return wantFiles(session: session, episodeIds: episodeIds)
    }
  }
}

The watch app sends the phone app a message by calling one of the methods defined in the WCSessionManager extension. The phone app handles the message in its implementation of the WatchMessageHandler protocol and returns a response.

That short define-watch-rpcs declaration from the first code snippet saves me a lot of manual typing and error-prone wiring up of things. When I add a new message case to the WatchMessage enum, all I have to do is implement its associated handler. If I forget to do that, the app doesn't compile.

You can find the full implementation of the define-watch-rpcs macro and its associated codegen procedures in this gist.

Now that Swift also has macros in the language, you could probably write a DSL like this directly in Swift, but I just used what I know, and Swift macros look somewhat clunky compared to what Racket offers.

Batch Inserts in PostgreSQL

Sat, 15 Feb 2025 11:40:00 +0200

I recently added support for batch inserts to koyo and thought I'd make a quick post about it. Here's what it looks like to use this feature:

(define ib
  (make-insert-batcher
   #:on-conflict '(do-nothing (ticker))
   'tickers
   '([isin "TEXT"]
     [ticker "TEXT"]
     [added_at "TIMESTAMPTZ"])))
(with-database-connection [conn db]
  (for ([(isin ticker added-at) (in-sequence datasource)])
    (ib-push! ib conn isin ticker added-at))
  (ib-flush! ib conn))

You create a batcher, tell it what table to insert the data into and what columns to insert, then push data into it and flush it at the end. Pushing may trigger a flush when too many rows have accumulated, according to an optional #:batch-size argument.

In the past, when I built a batcher like this, I did it by accumulating the row data into an array and, on flush, generating an INSERT statement with a row-wise set of placeholder parameters. Like this:

INSERT INTO tickers(
  isin, ticker, added_at
) VALUES
  ($1, $2, $3),
  ($4, $5, $6),
  ...
  ($(n*3+1), $(n*3+2), $(n*3+3))

This works fine for the most part, but it has a couple of problems. First, the maximum number of parameters to an insert statement in Postgres is 65536, so at most 65k/n-columns rows may be batched in memory before a flush is required. Second, this has the obvious problem that every flush requires sending a new, long query to the database, so this approach can't easily leverage prepared statements. The latter doesn't seem to have a huge impact, but it's still some unnecessary inefficiency.

This time around, I decided to buffer the values in column-wise arrays. On flush, those arrays are passed to the insert statement directly and I use UNNEST to turn them into a virtual table to insert from. That looks like this:

INSERT INTO tickers(
  isin, ticker, added_at
) SELECT * FROM UNNEST(
  $1::TEXT[],
  $2::TEXT[],
  $3::TIMESTAMPTZ[]
) AS t(isin, ticker, added_at)

So, the end result is a much shorter query that can be prepared ahead of time and reused between flushes. It also means we can buffer more rows in memory before flushing. The only disadvantage is that the batcher needs to know what the individual column types are ahead of time, hence the last positional argument to make-insert-batcher.

iOS Media Center Progress Jank

Sun, 26 Jan 2025 15:00:00 +0200

If you listen to podcasts on iOS, chances are you've noticed an issue some apps have when displaying the playing episode's progress in the media center. For example, notice how in the video below, playback pauses at 0:39, then skips forward in real time to 0:45 when I hit resume, before the app finally resets the elapsed time back to 0:38.

Pictured is one of the most popular iOS apps¹ for playing podcasts, but others I've tested have this issue as well. Podcatcher used to also have this problem until a couple months ago.

The reason this happens is because the iOS Now Playing view calculates the playback position automatically according to the last elapsed time and playback rate values it was given. That seems sensible as a performance optimization, and it would normally be fine, but it appears that the media center doesn't take into account the time that the item spends being paused.

One workaround is to set the playback rate to 0 before pausing and to reset it and the elapsed time before resuming. That works fine for most apps, but isn't quite right in Podcatcher's case since the playback rate may be constantly varying when the Trim Silence feature is turned on. Instead, I always set the playback rate to 0 and manually update the elapsed time as part of the audio engine tap that keeps track of playback.

internal func updateMediaCenterProgress() {
  let center = MPNowPlayingInfoCenter.default()
  var info = center.nowPlayingInfo ?? [String: Any]()
  info[MPMediaItemPropertyPlaybackDuration] = duration
  info[MPNowPlayingInfoPropertyElapsedPlaybackTime] = progress
  // The info center computes its own elapsed time based on the
  // playback rate. So, to avoid visual discrepancies between it and
  // our own progress tracking, always set the playback rate to 0.
  info[MPNowPlayingInfoPropertyPlaybackRate] = 0.0
  center.nowPlayingInfo = info
}

Since the tap was already running in the background during playback, this approach doesn't seem to have had any measurable impact on power consumption² and the accuracy improvement is well worth it to me, even though it feels somewhat gross to be working against the intent of the media center API.

Identity elided to protect the innocent. ↩
And Podcatcher is already much better in this area than other apps in the space. ↩

How Podcatcher Does Transcriptions

Sat, 4 Jan 2025 16:25:00 +0200

About a month ago, I added transcription support to Podcatcher. For example, here's a transcript of the latest episode of the Vergecast, and another one from AppStories.

Years ago, I bought an M1 Mac Mini and, in the intervening time, I haven't done much with it besides keep it on my desk. So, I figured I'd put it to work for this purpose. I initially reached for Apple's Speech Framework, but SFSpeechRecognizer turned out to be both surprisingly slow – on that particular machine, it transcribes at about a 1-to-1 ratio of audio time to wall clock time –, and pretty inaccurate. I spent some time evaluating other alternatives and eventually settled on OpenAI's open source Whisper model. In particular, since I'm not yet at a point where it makes sense to spend money on a machine with a powerful GPU to perform these transcriptions, I'm currently using the tiny.en variant of the model. Running two concurrent transcriptions at a time, on the CPU, I can get the model to transcribe about 30-60 minutes of podcast time for every 5 minutes of wall clock time. The accuracy is acceptable, though far from perfect. Eventually, I'll probably run one of the larger models to redo them if the app gets traction.

The actual guts of the transcriber are fairly simple. At its core, it's a small Racket script that shells out to Python to run the Whisper model. It runs in a loop where it leases transcriptions-to-be-done from the server, downloads the podcast enclosure, runs Whisper on it to produce an SRT file and then uploads the resulting output back to the server using the lease token it receives at the beginning. If the lease expires before the transcriber has a chance to upload it, the server just ignores the request.

The server prioritizes recent English-language podcasts and keeps track of leases in a Postgres table. A cron job removes leases from the table after 24 hours in case one of the transcriber processes gets stuck or crashes in the middle of transcribing. It hasn't actually crashed yet, but we did have a brief power outage recently, so I suppose that counts.

On the client side, the app and the website request the SRT data from the server, parse it (SRT is a simple line-oriented text format) and display it. The iOS app uses the timing information in the file to sync transcripts to playback, which works in general, but can go off the rails when a podcast uses dynamic ad insertion.

Platform-Specific Resources in SwiftPM

Sun, 24 Nov 2024 09:00:00 +0200

Noise packages Racket & Chez Scheme boot files¹ for all the platforms it supports. Originally, that was just x86-64 and arm64 macOS, but when I added iOS support, that extended to include arm64 iOS. These boot files take up about 45MB for each arch+os pair and the way I originally distributed them was placing them all in a boot folder and adding them to the resources list for the core Noise target.

That worked fine, but it seemed like a waste to lug around an extra 90MB of data that would never be used inside my iOS apps. Looking at the PackageDescription docs, there doesn't appear to be a way to filter resources by platform. There is an exclude property on Targets, which I tried to use by making the Package.swift script manipulate the target at runtime, but I couldn't figure out a way to get that working with cross-compilation.

Next, I tried writing a SwiftPM build tool plugin to remove files based on the target platform, but plugin execution is sandboxed and I couldn't figure out a way to move the boot files out of the package context².

Finally, I settled on just making separate targets for macOS and iOS. Each target contains its respective boot files and the main target conditionally depends on the platform-specific targets. I really wanted to avoid this approach because it's somewhat ugly and it means I have to manually wire things around that the build system should be able to do for me, but, for now, this seems like the most sensible approach.

Object files that contain the Racket and Chez Scheme runtime. ↩
As I'm writing this, I wonder if I could've combined the exclude property and a build tool plugin to define a folder into which I could've moved the unneeded boot files during the build. ↩