A GPT language model can only use about 4,000 words of context when generating its next words. The resources required for generation in a GPT increase significantly as this “context window” expands. Unlike a normal Google search which takes milliseconds to run, generating responses in ChatGPT, for example, takes on the order of seconds. That’s expensive.

I’d not thought through the implications of this limited number of tokens a GPT large language model can use when generating its output. As Allen Pike explains in A 175-Billion-Parameter Goldfish, as well as dollar-cost, this has deep effects.

I couldn’t help falling for the higgledy-piggledy, nature-encrusted look of these moss-covered wooden tiles on a building in Leigh Woods, on the outskirts of Bristol.

It’s no secret that I spend time customising my workspace. More recently, that has involved creating my own VS Code theme. Further in the past, it was a bit more hardcore, involving writing code that replaced core parts of the Windows experience. I’ll write some more on that one day soon, I hope: Windows shells saw great creativity in UX for the few years they were tenable (Windows 95 through XP), but sailed under most people’s radar.

For today, we’ll look at a smaller part of that fascination: fonts. Specifically, fonts for coding. I was set to this by Tim Bray’s Monospace and More Mono, a small excursion into ten or so monospaced fonts.

I can’t resist an excursion into ten or so monospaced fonts.

In 2003, this site was hacked and the content was lost. This is why there are no posts from before 2003, despite my registering the domain and running the site since 2001.

I don’t have anything written down about what happened. The site’s code was probably the very first web application I wrote, likely in 2001. Back then, I’d written dx13’s backend in original ASP, using Javascript (I was writing server-side JS a whole eight years before node.js was even named node, fellow hipsters 😬). It was running on a shared virtual server and backed by a MySQL database. What exactly went wrong is lost to time, but I came across a clue today.

Since 2019 this site has been built with Hugo. Until today I used a Makefile target, included as an addendum for historical interest. I decided this morning that I’d switch this over to use GitHub actions and write up the experience.

This post was going to be substantially longer, presumably containing a load of stuff about creating a custom GitHub action that used a customised container with Hugo inside, figuring out how to get the site published to the gh-pages branch, then committing it and pushing it. I thought committing back to a different branch in the repository from within the GitHub Actions runtime might end up being harder than I expected. At any rate, I figured the post would be quite helpful and fancy.

But it turns out that last July GitHub added the ability to use GitHub Actions directly to publish to GitHub pages, bypassing the gh-pages branch completely. There is even a template for using Hugo. Creating a workflow from that template worked first time 👌.

That was quick – and I suggest anyone still using a Makefile target or custom action switch over. It’s a nice system. I can now publish to the site from a Git client on my phone. Should I ever want to.