The Log

Writing a CHIP-8 Emulator from Spec

2026-04-03T00:00:00+00:00

I've been working on Ossature</a>, a spec-driven harness for LLM-based code generation. You write specifications describing what your software should do, and a build system generates code from them one task at a time, with validation and verification at each step. I wrote more about it on the Ossature blog</a>.

To test it on something non-trivial I decided to write a CHIP-8</a> emulator. CHIP-8 seems simple on the surface but has enough subtle behavior to actually test whether generated code holds together. There are known quirks where different interpreters disagree, and tricky state management that trips up both humans and LLMs. The project is called chomp8</a>. It's generated with Ossature in Rust, uses SDL2 for display and audio, and the entire codebase came from three spec files.

</video> </figure>

I split the project into three specs. CORE is the CHIP-8 virtual machine itself, memory, registers, the fetch-decode-execute cycle, all 34 standard instructions. It has zero platform knowledge, no SDL, no window, no sound. This separation means the core is testable in isolation and you could swap SDL for a terminal renderer without touching any of it. PLATFORM is the SDL2 layer, opening a window, drawing pixels, reading keyboard events, playing a buzzer tone. CLI is just glue, argument parsing, ROM loading, and the main loop that ties the other two together at 60 FPS. CORE never imports PLATFORM, communication is one-directional.

CHIP-8 quirks</h2> I used Amp</a> to help me write the specs. It made the process faster but the thinking still had to happen, because CHIP-8 has a bunch of documented ambiguities where original hardware, the COSMAC VIP</a>, and later interpreters all behave differently. The specs had to make explicit choices for each of these and I had to read through multiple references to decide which behavior to implement.
The shift instructions are a good example. The opcode encodes both an `x</code> and y</code> register, but the question is whether you shift Vx</code> directly or shift Vy</code> and store the result in Vx</code>. The original COSMAC VIP did the latter, most modern interpreters expect the former. The spec goes with "shift Vx, ignore Vy".`
`Then there's what I'd call the VF trap. VF is both a general-purpose register and the flag register. If you write VF before computing the result of an instruction and x</code> or y</code> happens to be 0xF</code>, you corrupt the input. You have to compute the result first, then write VF last. Apparently this is the most common CHIP-8 emulator bug.`
`I also added a prev_framebuffer</code> field that isn't part of the standard at all. CHIP-8's XOR-based drawing means games erase a sprite and immediately redraw it one pixel over to animate. Without frame blending you see the erased frame as a flash. More on this one later.`
`The build</h2>`After writing the specs I ran ossature validate</code> to make sure the content matched the SMD format</a> Ossature expects. This is purely structural, no LLM involved, just checking that dependencies resolve and the format is correct. Then I ran ossature audit</code> which sent each spec to an LLM for semantic review looking for ambiguities and gaps. It found a few and I fixed them. After the per-spec audits, Ossature runs a cross-spec audit automatically to check consistency across spec boundaries. The number of fix attempts for both audit and build is configurable. Ossature supports any model provider that Pydantic AI</a> supports, and you can set a different model for different roles, maybe use a more powerful model for auditing and a cheaper one for code generation. For chomp8 I kept it simple and used one model for everything, google/gemini-3.1-pro-preview</code> via OpenRouter. After audit, Ossature produced a build plan with 15 tasks in dependency order. The plan is a TOML file you can read and edit before building. Each task lists what spec sections feed into its prompt, what files from earlier tasks get injected as context, and what verification command runs after generation. The instruction execution task for example got the Cycle and Draw Sprite spec sections plus a chip8 reference document as context, and saw the types and state modules from earlier tasks. But it didn't see anything from the PLATFORM spec. Less context, less room for the model to get confused. The build ran task by task. Each task generates code, runs cargo check</code> or cargo test</code>, and if verification fails a fixer agent reads the errors and tries to repair things. All prompts and responses are saved to .ossature/tasks/</code> for traceability. One thing I found useful was that the strict separation between specs maps well to how you'd actually want to structure the code. Because CORE can't see PLATFORM, the generated code naturally ended up with clean module boundaries. The LLM couldn't accidentally import SDL types in the VM core because those types simply weren't in the prompt. Error handling was more prescriptive than I'd normally write in a spec. The spec says things like "if i + n - 1 > 4095</code>, error before touching the framebuffer." That level of detail feels excessive when writing code by hand, but for LLM generation it turned out to be exactly the right amount. Without it the model would probably have generated something that half-writes to memory before discovering the bounds error. This is the kind of detail that you sort of have to know to put in the spec, but once it's there the LLM handles it fine. The prev_framebuffer</code> I mentioned earlier is a good example of what happens when the spec isn't precise enough. The first build had visible sprite flicker, moving objects would briefly disappear and reappear each frame. The frustrating part was that the spec already anticipated the problem. The CORE spec defined prev_framebuffer</code> and described it as "used for frame blending to eliminate XOR-draw flicker," and the CLI spec had a step to initialize it. But the generated code never actually used it. Neither spec described the concrete algorithm, how to blend, when to snapshot, what to pass to the renderer. The field just sat there unused. The fix was to go back to the specs, not the code. I updated the CORE spec to spell out that display output is computed as framebuffer[i] OR prev_framebuffer[i]</code>, and updated the CLI spec's render step to explicit steps instead of a vague "call platform render with the current VM framebuffer." After rebuilding, the flicker was gone. A field with a descriptive comment is a hint to a human but it's noise to a code generator. If a spec defines a data structure, every reader and writer of that structure needs explicit steps referencing it, or it ends up as dead code in the output. Writing specs takes longer than I initially expected. The format itself is straightforward, but you have to think through every decision before any code exists. That's work you'd normally do while coding, spread across many small decisions you make without really noticing. Pulling it all forward into the spec phase felt slower at first but the generated code came out more coherent because of it. The SMD format also pushes you to be concrete. "Handle invalid input" is the kind of thing I might write in a design doc and move on. But the format wants to know what the input is, what happens on error, what the error message says. I'm not sure this approach makes sense for everything. For a small script or a quick prototype, writing three spec files and running an audit would be overkill. But for something like an emulator where correctness matters and there are dozens of subtle behavioral decisions to make, having them all written down in one place before any code is generated felt like a real advantage. The repo is at github.com/beshrkayali/chomp8</a>, the specs are in the specs/</code> directory if you want to see what the inputs looked like.

Playing IF Games with Natural Language 2025-11-14T00:00:00+00:00 I've been experimenting with the idea of integrating LLMs with text-adventure and interactive fiction games in a couple of different ways, most are not yet ready (and will probably take a long time for anything useful to come out of them if any) but one area I wanted to share is introducing LLMs at the parser layer of the engine or the VM. From the minimal experience I have with the world of IF (other than just playing some games), the traditional parser is both the charm and possibly the barrier to IF games. You need to learn the syntax and figure out what verbs the game understands (some might be defaults/common and some might be custom to the game), but mostly you have to phrase things in a very specific way. For example "take key" works but "grab it" does not, even though technically both mean the same thing. But the game really just needs a normalized command like "take key" or "go north", and doesn't (or shouldn't) care about how the player phrased it. So basically the interpretation of what the player meant is really just an I/O problem, not a game logic problem. So this is where the idea came from: what if we use an LLM to handle that interpretation? This experiment is built on top of Andrew Plotkin's</a> CheapGlk and Glulxe. I forked both and added a thin layer in the Glk library that intercepts user input and sends it to an OpenAI-compatible API for interpretation, then passes it back to the game as if the user wrote it. The API reads the last few lines of game output for context, tries to figure out what the player probably meant, and returns a "normalized" command (of course that might be more difficult than it seems because LLMs don't "think", but it does actually seem to work most of the time) and that's it. The VM doesn't change, the game files don't change, nothing changes except the an additional step to parse out the intent of the player before it gets passed back to the game. Here's a demo playing Tom Devereaux's "Try Again"</a>: </figure> </a> When you type something like "let's go through that metal door", the Glk library sends it to the LLM with context about the current scene (the bunker description, the objects you can see), gets back "go through metal door", and passes that to the game. The system reads room descriptions and object lists to understand context. When you say "take it" after opening a box with a pistol inside, it knows you mean "take pistol". When you say "read them" in front of a filing cabinet with multiple entries, it starts with the first one. Say "and the next one" and it continues the sequence. This means existing games work without modification. Almost nothing changed in Glulxe itself. I added OpenSSL to the build configuration and linked against the modified CheapGlk. The entire LLM integration lives in the Glk library, which seemed reasonable to me since Glk's job is to handle input and output. One interesting side effect is that because some LLMs are multilingual, you can play in different languages. The game still receives English commands but you could type in Swedish or transliterated Arabic and it would work the same way. I wanted to answer a few questions with this: Can LLM interpretation make IF more accessible without destroying what makes it interesting? Does it preserve the puzzle-solving nature or does it just become "tell the AI what you want and it figures it out"? Can spatial reasoning be extracted from text descriptions well enough to understand what "go through that metal door" means in context? I think some answers will take more time to figure out but at least I can try playing some games now and see how it works. There are some obvious issues though. Interpretation isn't always perfect or consistent. LLM calls add latency and API costs can become high if you're playing for hours. You're dependent on external service availability unless you run a local model. Model quality varies a lot too. I've had good results with google/gemini-2.5-flash</code> but smaller models need significant finetuning to be useful (though I think this is probably where this idea should go next, a specialized finetuned SLM for parsing user input specifically for text-adventure games). Although this is just a proof of concept, I tried to handle some edge cases. Some games ask for raw string input like your character's name, you can wrap your input in brackets to skip LLM processing. When you try to take something that's fixed in place, it passes that through and lets the game respond naturally. The experiment is done entierly by adjusting Andrew Plotkin's CheapGlk to call the external LLM provider. After building both CheapGlk and Glulxe, you add a configuration file at ~/.glk_llm.conf</code> with the API endpoint you want to use, key, model, and a few other settings. You can use OpenAI, OpenRouter, local Ollama, or whatever supports the OpenAI chat completions format. Is it actually fun? I have to play some more to be able to answer that, but it probably depends on what you want from IF. If you enjoy the puzzle of figuring out the parser itself, this removes that layer entirely. If you find the parser frustrating and just want to explore the story, with my limited test run with some games I found this to help a lot. The interpretation adds a different kind of uncertainty though. Sometimes the LLM makes unexpected choices about what you meant, which can be amusing or annoying depending on the situation. I'm treating this as a prototype to explore these questions, not as a real feature or contribution. The code is minimal and possibly rough in places and there are definitely improvements to be made. But it's functional enough to play through games and see how it feels. If you want to try it yourself, check out the repos: Glulxe fork</a> and CheapGlk fork</a>. Build instructions and configuration details are in the READMEs. Update (2025-11-17) Added a WebAssembly (WASM) build to make testing easier. Instructions are in the READM, but I put up a hosted version: https://beshr.com/webglulxe/</a>.</li> LLM API calls happen client-side in the browser via JavaScript.</li> To run your own version, build both CheapGlk and Glulxe to WASM as described in the README.</li> </ul> Freedom in Open Source 2025-10-03T00:00:00+00:00 I've watched the open source world from a bit of a distance over the last 20 years while learning to code and getting paid doing it (the first project I put out there, BackuPod</a>, was uploaded to SourceForge in 2007, I was a novice Python programmer.) To me it seemed like the conversation at the time was dominated by people like Richard Stallman and his ideas about software freedom. It was all about the developer's freedom to see the code, change it, and share it. It was a powerful statement against proprietary software, supportive of hackerdom</a> and the natural urge to tinker with things. Then you had Eric S. Raymond talking about the "bazaar" model, where all these individual developers working on their own things would somehow create something amazing. I didn't really understand all this exactly back then, but what drew me to the idea was this focus on the creator's liberty and ability (or even expectation) on the user to know what they're using well enough and to be able to adjust it if they want, even if in a minimal way. The freedom was for the developer to build what they wanted, not necessarily to serve a massive userbase, but also for the userbase to feel like they're not stuck using whatever the developer wanted them to use or do on their machines. But as I progressed and learned more, open source appeared like an exclusive club with its own language and rules, and I never really broke in. I've contributed a patch here and there, felt happy about getting praised publically, used countless libraries of course, and dontated money to support those I used most, but I never became a "maintainer" or a core part of any project, and non of my open source projects drew a lot of attention. And honestly, looking at the state of things today, I'm pretty happy that things turned out this way. The whole dynamic between the freedom of the creator and the duty to the user has become a real mess. This individualistic spirit is still there in a lot of projects but it's getting crushed under the weight of modern expectations. It might seem strange but I think what happened (and sort of the origin of the problem) is that open source won. It's not a niche hobby anymore. It's a fundamental infrastructure piece of the entire global tech economy. The Linux kernel, Apache, Python, and a random JavaScript library you've never heard of power a million websites. Corporations, governments, everyone depends on this stuff. And that dependency has created a strange shift in perception. Users start to see these projects not as a gift from a stranger but as a product. They treat it like commercial software and expect commercial-level support, reliability, and a roadmap that suits their needs. This created a perceived obligation to serve, which was never part of the original deal as I see it. The first thing this directly led to is the maintainer's burden. Most of these projects are run by one person (or a tiny team) in their spare time. They're not getting paid, or if they are it's not much. They carry the costs, the time spent debugging, the mental energy of planning new features, and the emotional toll of dealing with the public (good or bad comments). I've seen issue trackers that would make your skin crawl. The constant stream of demands, the entitlement, the pressure to add some feature that only one company needs. I personally can't imagine dealing with large projects like this without burning out. And when a maintainer finally puts their foot down and says "no", they get backlash. They're called rude, or a gatekeeper for simply exercising the very autonomy that open source was supposed to be about. I think those who do maintain large projects and still seem sane have somehow managed to luck out into walking the fine line, but who knows maybe there are a few with a secret process that worked for them. Part of the problem is this myth of the "community". We talk about the open source community as if it's some kind of democracy where everyone gets a vote, some utopia where people are somehow friends just because they both use Rust or Python. Back when I was doing a lot of Python on daily basis, I never felt part of the community and it always rubbed me the wrong way when I see people talk about it online. Most projects are a benevolent dictatorship or an oligarchy. One person or a small group makes the final call. But the collaborative rhetoric, all the talk about "getting involved" and "contributions welcome", gives users a sense of entitlement I think. They feel if they open an issue they deserve a dialogue, that their feature request should be seriously debated. They don't see the hundred other users making competing demands, or the fact that the maintainer's vision for the project might just be different from theirs, or that they could just be wrong (this topic might deserve a post on its own). And now of course with AI and LLM-generated code, there's an increasing number of patches and security-reports that are all fake or entirely LLM generated, wasting maintainers time, and there's also a decent amount of new "projects" that are: open source, from afar seem like they're something decent and useful, have nice READMEs and CI badges, 100% test coverage, etc... but are actually just junk and half-assed ideas someone auto generated to flex some muscle. The world of open source development and programming also suffered the popularity of attention economy, people treating themselves as brands and trying to get their name out their any way they can to carve themselves a slice of attention people give to things online, with zero fucks given about the quality of what they're doing. Of course there's a whole spectrum of governance models trying to deal with this. You have the classic benevolent dictator for life like Linus Torvalds with the kernel, and then you have more consensus-driven projects like Debian. Some new ones will probably be needed for the LLM era (if it lasts). But for the vast majority of small or medium sized projects there is no formal governance. The decisions will be made on the fly, which will just lead to more conflict. Some projects try to manage this with strict contributor guidelines, but the attempt to reach a balance feels like we've already given up on the original meaning of open-source imho. Not to be too negative, but I don't think there's a fix here really. The way things are going, I think we'll inevitably see a more fragile software supply chain, where progress is dictated by corporate funding and not individual creativity, which is sad because it'll push the ecosystem back towards a more centralized, commercially-controlled model that the free software movement originally fought against, but who knows. GroupTab 2025-09-24T00:00:00+00:00 The macOS app switcher (Cmd+Tab) is one of those things that's just there and works well enough most of the time. But once you’re juggling a dozen apps, cycling a single list gets slow, and it becomes tedious to keep flipping back and forth between apps just to keep their order as you'd like it to be. The idea of having groups of apps (as rows) in the switcher felt natural to me once I implemented a quick PoC while working on Sudecku</a> a few months ago. Now I'm happy to share that I've developed that PoC into a proper app, GroupTab is a minimal grouped app switcher for macOS, so you can organize apps into visual rows and jump between groups quickly. I think it’s great for anyone who keeps many apps running simultaneously. The app is $1.99, but I'm making it free until September 26 so you can try it and see if it actually improves your workflow. Get it on the Mac App Store</a>. More screenshots and details on the website</a>. Would love to hear any feedback if you get a chance to try it. Announcing Sudecku 2025-08-26T00:00:00+00:00 I'm thrilled to finally share something I've been working on for months. Sudecku ⊕</label> is a game that combines the timeless logic of Sudoku with the strategic depth of deck-building. My wife and I enjoy playing Sudoku together, but she recently discovered the world of advanced puzzle variants through the Cracking the Cryptic YouTube channel. Watching Simon and Mark tackle these incredible spin-offs with killer cages, thermometers, arrows, and countless other rule variations was genuinely exciting. Each variant added fascinating new layers of logical thinking to the standard 9×9 grid. The idea of Sudecku came up randomly, but initally it was very basic. I thought it'd be interesting to play Sudoku with playing cards and have some way to cheat by using power cards that are sort of like Uno's action cards. The rest was the result of constant tweaking and testing while developing the game. My wife gets a lot of credit for game play testing and coming up with ideas for how to make the game play fun and challenging. The name "Sudecku" is her idea as well! Honestly, the name is a major reason why I kept working on it, because it felt like a shame to waste such a good name. What makes me most proud isn't just the mechanics, it's how the game feels. Whether you're a Sudoku veteran or someone who's never touched a logic puzzle, every puzzle offers those satisfying "aha!" moments. The strategic layer adds depth without overwhelming the core puzzle-solving joy that makes Sudoku so addictive. This is technically my first personal iOS app. Writing Sudecku, I got to learn some Swift and some SpriteKit. I wrote earlier this month</a> about some of what I learned. There's something deeply satisfying about seeing months of Swift code come together into fluid gameplay, especially when you're building something you genuinely want to play yourself. You can check it out on the App Store</a> or learn more on the game's website</a>. This has been a true passion project, I'd love to hear what you think! Feel free to reach out with any comments. Notes on Swift From Building an iOS Game 2025-08-03T00:00:00+00:00 Update: The game is now available</a>! For the past few months I've been working on an iOS game. It's almost finished now but I still would like to polish some aspects a bit more and look into what's happening with iOS 26 and the new Games app before I publish it, to ensure things works well for everyone. I don't want to give too many details just yet, but I can say it's a puzzle/card game. I will post more details when the game is available (hopefully within the month), stay tuned! I think Swift is a fantastic language. Every new aspect I explored felt well-thought-out by the language designers. I was also pleasantly surprised by some smaller features that, while probably inconsequential in the grand scheme, I found neat, like argument labels, which as far as I know, are unique to Swift. ⊕</label> The idea is that argument labels can enhance code readability because they allow descriptive external names that clarify the purpose of parameters when calling the function. This makes some function calls a bit easier to understand and more self-documenting. By separating external and internal names, I could use concise internal names within the function body while maintaining names that explain the context from where it's called . It's pretty neat! func sendMessage(to recipient: String, content message: String) { print("Sending '\(message)' to \(recipient).") } sendMessage(to: "Alice", content: "Hello, how are you?") </code></pre> Below are some of the features and patterns that really stood out to me. I'm sure some of these exist in other languages or frameworks but I don't think I've seen them done exactly this way. Enums</h2> I found myself using enums far more extensively than I've done before in other languages, especially with their advanced capabilities. Using String raw values for enums was incredibly practical. It allowed for type-safe references to asset names without relying on error-prone magic strings. The compiler catches typos, making changes quick and easy. enum MusicTrack: String { case mainMenuMusic = "MainMenu.mp3" case gameplayMusic = "GameplayLoop.mp3" } let trackName = MusicTrack.mainMenuMusic.rawValue // "MainMenu.mp3" </code></pre> It was also very nice to be able to represent different data types within a single enum. For CardType</code> for example, having cases like .number(String)</code> and .powerup(PowerupType)</code> meant that each card type could carry its specific data directly. This meant that I didn't need complex class hierarchies or multiple optional properties. It's much cleaner this way. enum PowerupType: String, Codable { case extraTime = "Extra Time" case scoreMultiplier = "Score Multiplier" } enum CardType: Codable, Equatable { case number(String) case powerup(PowerupType) } let myCard = CardType.number("7") let powerCard = CardType.powerup(.scoreMultiplier) </code></pre> Swift's switch statements, especially with enums that have associated values, enforce exhaustive handling. If I added a new PowerupType</code>, the compiler would immediately flag all switch statements that needed updating. This compile-time guarantee was very useful for preventing runtime bugs easily and made it simple for me to work on various aspects of the game in small chunks.⊕</label> When I introduced PowerCard</code>s I didn't come up with all the ideas I wanted to do at once, and I wouldn't have wanted to write them then anyway. It was very nice that I could add a new power card type to the enum whenever I get a new idea then have Xcode point out all the places I needed to update. func handleCard(_ card: CardType) { switch card { case .number(let value): print("Number card with value: \(value)") case .powerup(let type): print("Powerup card of type: \(type.rawValue)") } } </code></pre> Properties</h2> For properties like MusicManager.volume</code> or isMuted</code>, the didSet</code> observer allowed me to automatically persist the new value to UserDefaults</code> and trigger an update to the audio player. This pattern keeps the logic for reacting to a property change directly co-located with the property itself. This pattern of using didSet</code> observers also helped encapsulate the "what happens when this changes" logic, which reduced the need for explicit method calls every time a property is modified. This made the code more self-contained and easier to keep up to date as I progressed, for example, or changed how scoring works. class MusicManager { var volume: Float = 0.5 { didSet { UserDefaults.standard.set(volume, forKey: "musicVolume") updatePlayerVolume() } } private func updatePlayerVolume() { // Logic to set actual player volume print("Volume set to \(volume)") } } let manager = MusicManager() manager.volume = 0.7 // didSet is automatically called here </code></pre> I used computed properties for things like MusicManager.isPlaying</code> (derived from the underlying AVAudioPlayer</code>'s state) and currentTrackName</code> (derived from currentTrack</code>) to prevent redundant storage and ensure consistency. The value is always fresh. class MusicManager { var musicPlayer: AVAudioPlayer? // Assume this exists var currentTrack: MusicTrack? var isPlaying: Bool { return musicPlayer?.isPlaying ?? false } var currentTrackName: String? { return currentTrack?.rawValue } } </code></pre> Using computed properties in classes to read from and write to UserDefaults</code> was particularly effective. It made persistent data feel like a regular stored property, simplifying access and modification while handling the UserDefaults</code> interaction internally. struct Stats { static var cardsPlayed: Int { get { return UserDefaults.standard.integer(forKey: "cardsPlayedCount") } set { UserDefaults.standard.set(newValue, forKey: "cardsPlayedCount") } } } // Usage: Stats.cardsPlayed += 1 // Reads, increments, writes back </code></pre> Optional Chaining (?) and Nil Coalescing (??)</h2> These are fundamental for safe handling of optional values and significantly improve code readability. Optional chaining (?) allows for concise and safe access to properties or methods on optional values. If any part of the chain is nil, the entire expression evaluates to nil without crashing. This is far cleaner than nested if let statements for simple access. Nil coalescing (??) is a clean way to provide a default value if an optional is nil. Together, optional chaining and nil coalescing drastically reduce the boilerplate associated with nil checks. It's much nicer to have code that's direct and easier to follow, especially when coming back to a function after a few weeks. var playerNode: SKNode? // Could be nil var gameScene: SKScene? // Could be nil // Optional chaining: playerNode?.position.x = 100 // Only sets if playerNode is not nil gameScene?.presentScene(SKScene()) // Only presents if gameScene is not nil // Nil coalescing, scoreText default to "0" if totalStatsData is nil let scoreText = totalStatsData?.getFormattedScore() ?? "0" </code></pre> weak and unowned References</h2> Understanding and correctly applying weak and unowned was critical for memory management, especially with closures and SpriteKit animation-related code blocks. I faced some trouble with retain cycles, obviously. In SpriteKit for example, with nodes, timers, and completion handlers, it's easy to create strong reference cycles that lead to memory leaks and crashes that are hard to track. ⊕</label> What's more annoying is that these crashes did not happen in the simulator, but only on real and slightly older hardware and never with dev builds. Using [weak self]</code> in capture lists for (like Timer</code> callbacks or SKAction</code> completion blocks) is good for safer access to various variables in closures (with a guard let self = self else { return })</code> for example). If self</code> is deallocated, the weak</code> reference becomes nil</code>. class GameScene: SKScene { var gameTimer: Timer? func setupTimer() { gameTimer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: true) { [weak self] timer in // Safely unwrap self. If GameScene is deallocated, self will be nil. guard let self = self else { timer.invalidate() // Stop the timer if scene is gone return } self.updateGameTime() // Safely call method on self } } func updateGameTime() { // game time update logic print("Game time updated.") } } </code></pre> Building this game was a lot of fun, if you're interested in checking it out, check back here in a month or two, currently waiting for the tax agency in Sweden to finish my paper work. Using nix-darwin 2025-05-02T00:00:00+00:00 As I've recently switched to macOS</a>, I decided to configure my system using nix-darwin</a>. I've played around with Nix and NixOS before, and I'm in no way an expert, but I like the idea of declaratively defining my system config. It makes it easier to revert things back to the way they were at a certain point, and to track what sort of changes I've made over the years, aside from quicker setup when I need to start from scratch again. For my dotfiles (zsh</code>, wezterm</code>, tmux</code>, etc...) I went with simply symlinking things (with nix-darwin's activationScripts</code>) rather than having it managed in a more Nix-y way. I'd like to keep the mental load of learning things that I don't interact with every day to a minimum, because I'm bound to forget, and as much as I enjoy configuring my tools, my aim has always been to do as much as necessary to reach a point where I touch my config less and less (the last time I made a change to my emacs config was 2022</a>, but I took the opportunity to overhaul it now as I've migrated all my config to a single repo). My system config and other dotfiles are here: https://github.com/beshrkayali/system</a>. Using Nix-Darwin</h2> It was surprisingly easy to set things up with nix-darwin. Since I use Homebrew, and nix-darwin doesn't manage installing it, I had to install that manually. First, installing Nix itself, the README recommended using either Nix (via Nix installer from Determinate Systems</a>) or Lix (which I've never heard of before). The README also recommended installing the vanilla upstream Nix (by answering no to installing Determinate Nix). I created a flake.nix</code> and split my config into a separate fdarwin.nix</code> module, as I've seen many people do. The Config</h2> Configurations docs are available online on nix-darwin's github pages</a>, or locally by running the darwin-help</code> command. </blockquote> One of my favorite aspects of nix-darwin is the ability to declaratively set macOS system preferences: # System defaults system.defaults = { screencapture.location = "~/Pictures/screenshots"; SoftwareUpdate.AutomaticallyInstallMacOSUpdates = true; NSGlobalDomain = { AppleKeyboardUIMode = 3; }; dock = { autohide = true; orientation = "left"; show-process-indicators = false; show-recents = false; static-only = true; tilesize = 32; }; finder = { AppleShowAllExtensions = true; ShowPathbar = true; FXEnableExtensionChangeWarning = false; FXPreferredViewStyle = "clmv"; ShowStatusBar = true; }; }; </code></pre> I've also enabled the nifty Touch ID auth for sudo commands security.pam.services.sudo_local.touchIdAuth = true; </code></pre> Most of my tools are installed via Homebrew (with nix-darwin's Homebrew integration), but I still install a few essential core packages via environment.systemPackage</code>: environment.systemPackages = with pkgs; [ wget curl git htop ripgrep ]; </code></pre> and for Homebrew (I'll probably change what's installed frequently, check on github</a> for latest): homebrew = { enable = true; onActivation = { autoUpdate = true; cleanup = "zap"; }; brews = [ /* CLI tools */ ]; casks = [ /* GUI applications */ ]; masApps = { /* App Store applications */ }; }; </code></pre> The cleanup = "zap"</code> setting is to remove any manually installed Homebrew packages not defined in my config, keeping things clean and predictable. I've also configured automatic garbage collection cleanups to run weekly. nix.gc = { automatic = true; interval = { Hour = 3; Minute = 15; Weekday = 7; # Sunday }; options = "--delete-older-than 7d"; }; </code></pre> Rather than managing symlinks manually, I used nix-darwin's activationScripts</code>. Ironically, this might be the most complicated part of my config. But it's straightforward. We first set up variables for the home directory and repository path, then define an array of symlinks as source-target pairs (covering configuration files for nix-darwin</code> itself, Emacs</code>, and other dotfiles). The mkSymlinkCmd</code> function generates shell commands for each symlink to handle various edge cases, like removing existing symlinks and creating timestamped backups of existing files before replacing them. This function is then mapped across all symlinks and joins the results. system.activationScripts.extraActivation.text = let homeDir = config.users.users.beshr.home; repoPath = "${homeDir}/src/system"; # Define symlinks as source -> target pairs symlinks = [ # Format: [source target] # - Nix Darwin ["${repoPath}/nix-darwin" "/etc/nix-darwin"] # - Emacs ["${repoPath}/emacs" "${homeDir}/.emacs.d"] # - Other dotfiles ["${repoPath}/wezterm.lua" "${homeDir}/.wezterm.lua"] ["${repoPath}/zshrc.zsh" "${homeDir}/.zshrc"] ["${repoPath}/tmux.conf" "${homeDir}/.tmux.conf"] ["${repoPath}/gitconfig" "${homeDir}/.gitconfig"] ]; # Function to generate symlink commands mkSymlinkCmd = link: let source = builtins.elemAt link 0; target = builtins.elemAt link 1; in '' # For ${source} -> ${target} if [ -L "${target}" ]; then echo "Removing existing symlink at ${target}..." rm "${target}" elif [ -e "${target}" ]; then echo "Backing up existing file at ${target}..." mv "${target}" "${target}.backup-$(date +%Y%m%d-%H%M%S)" fi echo "Creating symlink: ${source} -> ${target}" mkdir -p "$(dirname "${target}")" ln -sfn "${source}" "${target}" ''; in '' echo "Setting up symlinks..." ${builtins.concatStringsSep "\n" (map mkSymlinkCmd symlinks)} echo "Symlink setup complete!" ''; </code></pre> I'm quite satisfied with this hybrid approach. I benefit from Nix's declarative system-wide configuration and package management, while maintaining flexibility with my dotfiles that remain easily editable outside the Nix ecosystem. Switching to macOS again 2025-04-29T00:00:00+00:00 I've switched to Macbook Pro as my main personal computing device again. The last time I used a Mac OS fulltime for personal computing was around 2012, after which I transitioned to a Thinkpad X1 Carbon. I used Arch Linux with i3 initially, then later Sway, and I was quite satisfied with the setup I had developed over the years. During this period, I've owned two different X1 Carbon generations (4th and 7th), and both were excellent at first. My primary frustration with these devices is how quickly they developed issues. On my first Thinkpad, an entire column of keys including 9, O, L, and . stopped functioning after a couple of years of daily use. I tried replacing the keys thinking that the problem was with the mechanism, but had no success. Other than that, the trackpad on these laptops was extremely imprecise and finicky, but the trackpoint worked great (after the initial learning curve). Unfortunately, even the trackpoint began to deteriorate in quality after the first year. The little red piece of rubbery plastic started get loose and became less reliable. I think my usage was fairly standard, these laptops are designed for power users after all, but the build quality turned out to be significantly lacking in my experience. I decided to purchase a newer model, which I used for several years. This time, issues began with the fan, which would randomly stop working. I had it serviced once (a technician came to my office and replaced the fan), but it began failing again just a couple of weeks later. Around the same time, the screen started to flicker and randomly go black, to the point where it became almost impossible to use it as a laptop. At that point, I'd grown frustrated with the entire Thinkpad lineup. I expected premium quality to match their premium price. I continued using this last Thinkpad in docked mode for a while, eventually resorting to Arch on WSL on my Windows PC (which performed surprisingly well). My experience probably doesn't reflect the quality of the entire Thinkpad lineup, but I wasn't going to keep trying, these devices aren't cheap. My experience with Apple's laptop build quality has been exceptional in the past, and I've been using an M1 Pro for work since 2020 (though most of the time I was connected to a remote linux VM) and it still looks and functions perfectly. So I recently decided to purchase one of the new M4 models for my personal daily driver and settled on the M4 Pro with 24GB of RAM and 512GB of storage. This configuration seemed to offered a good balance between price and future-proofing for me. I'm not the biggest fan of macOS and sort of wary of the possible redesign</a>, but it still suites me better than Windows, and I can navigate my way around customizing things better. Apple's Vision 2023-06-07T00:00:00+00:00 Yesterday at WWDC 2023 Keynote, Apple unveiled its first "spatial computing" device "Vision Pro". I had never heard of this term before, but apparently it's been defined (since 2003) by Simon Greenwold</a> as "human interaction with a machine in which the machine retains and manipulates referents to real objects and spaces". There's not a lot to say about the technical details yet. I think the most intriguing aspects for me are the catadioptric lenses and the R1 chip and how it processes the camera/sensor feed in real-time. The foveated rendering, and how they've handled gaze and hand gesture tracking in the OS. A few thoughts came to my mind while watching the announcement. Firstly, it looks like a snorkeling mask! Jokes aside though, the technical aspects that make it all work together are very interesting for sure, and the device is seductive and obviously manufactured with high quality material and attention to detail. At this point most people know that Apple does some of the most impressive marketing in the world. With that being said, the last couple of WWDC keynotes gave me a weird ominous creepy feeling with all the fake smiling and the excessive amount of happiness some people have for "stickers in Messages" and the formulaic talking points they use. Secondly, I don't think this is a productivity device as they're selling it as, at least not in its current form. As someone commented on HN, the number of displays one has on their real desk and their size is usually not a major factor of productivity for most people, it's their neck movement and the pain it entails. If you have to twist your body around while sitting behind a desk (assuming you're typing) you're probably not going to want to move your neck a lot, so it's probably just easier to do it without having any extra weight on your head (actually we don't know the weight yet). I think this will be a consumption device first and foremost. To watch movies, play games, or do those weird meditation/sleeping rituals. I doubt that anyone who's not a millionaire would be willing to fork $3500 for a toy, but people keep buying the latest iPhones while complaining they can't afford to save for buying a house, so I'm not sure what will happen. Thirdly, people are slowly but surely gaining more awareness about the unintentional effects of various tech gadgets on our lives. I can't imagine why an average person who thinks of themselves as "mindful" of their tech usage would be interested in this. Many design aspects of Vision Pro cater to the idea of being "more present" with others (from the fake eyes</a> on the outward front display, to Share Play in visionOS</a>, but if someone wants to maintain presence with others, why not just take it off when they're talking to them? If your goal is to watch a movie with others, why not meet up IRL? Maybe the "cool factor" is gripping. But surely not at this price? Even if they fix the battery and the price in the next couple of versions, I think it'll be hard to convince people to act like it's normal to sit and talk with someone wearing a diving mask in their living room, with 12 different cameras vaguely pointing in their direction, right? Most would feel weirded out with just one camera pointing in their direction. There are many questions that will be answered in time, like what will happen if that magnetic battery cable gets unplugged unintentionally? Will the whole device turn off? Will they sell bigger batteries or a "wall-plug" option? How will the tracking work in various light conditions? Will Apple make a smaller AR-only option that's actually more like glasses rather than some high-tech gas mask? I don't know how this will go, it's interesting to witness it though. Many people are glued to their phone and it's difficult to find anyone walking around without earbuds, it's hard to imagine that there was a time when people didn't do that, how did this transformation even happen? It feels like this could be a good opportunity to see how that transformation takes place in real-time. If this vision of Apple fails, then it fails, as I would expect honestly, unless they manage to sell it to the military</a> somehow. If it succeeds and becomes a lucrative market, we'll probably see a Google version (sort of Daydream 2.0) and developers will rush to make apps and money. Meta will "pivot" and also make an AR thing. Will most people own one of these in 2035? Will it be normal to have 4 or 5 people sitting around a living room jacked up to Apple's Vision just like how it's (almost) normal now to do the same with phones. That sounds like a lonely and sad future, but at least we would've had an opportunity to witness how this transformation took place. Writing Better 2023-04-21T00:00:00+00:00 Over the past decade or so in my career, I have come to recognize the importance of writing well. This includes writing better emails, instant messages on IRC/Slack/Teams, documentation, and any other type of writing. I believe that the key to writing effectively is to be able to communicate an idea in a straightforward and precise way. This is something I have noticed in my work as a programmer, but I believe it can be applied to any field. The point is not necessarily just for the benefit of others who are on the receiving end, but also for my own sake in actually saying what I intend to say and get others to understand it. I have seen many colleagues and friends communicate in a less-than-ideal way and I have felt both sympathetic and at-times vexed for their confused and hazy way of putting forward an idea. It's mostly sad when they actually have a good idea but they just can't bother (or just don't have the ability) to think about it and write it clearly. I often find myself replying "Do you mean ...?" when someone asks me a question. Using uncommon slang, lacking capitalization or punctuation can also affect the intelligibility of a request, this is especially the case for people whose first language is not English. I'm not a grammar pedant and English is not my first language. I'm not arguing that people should never miss a comma or a full stop, I certainly do that all the time, but there's something to say for sure about how some of these rules at least can help in structuring ideas and thoughts. I suppose what I'm arguing for here is not that we should all practice writing and respect grammar rules, but more that we should understand the value of clearly conveying thoughts in writing, especially in non-formal contexts in a work environment (like during chats or quick-meetings). It's very easy to lose on potentially useful discussions that get missed (or dismissed) because they are slurred or down right incomprehensible. Introduction Chapters 2023-04-16T00:00:00+00:00 I have recently identified a habit of mine whereby I tend to skip reading introductory chapters of books, at times only resorting to skimming through it in search of salient information. However, I have noticed that when I eventually take the time to read it word for word, it can offer valuable insights and contextual understanding of the material presented. It is, however, essential to exercise selectivity when reading to determine the relevant content, depending on the type of book. While reference books are intended to provide quick and easy access to pertinent information, narrative books such as biographies, histories, and essay collections are to be read cover-to-cover. The issue with introductory chapters is that they are frequently weighed down by superfluous and trivial details that detract from the substance of the topic. It is expected that introductory chapters should provide contextual information, set expectations, and clarify the author's thesis and main ideas. The ideal introductory chapter for me would be characterized by brevity, clarity, and a critical analysis of the subject matter, as opposed to being overly promotional or generic in its approach. The ones that I am annoyed by the most are the ones that are over-the-top funny or witty. While skipping (or skimming) introductory chapters may seem like a time-saving trick, it often results in missing out on valuable insights and context that can enhance understanding of the book. Therefore, it is essential for authors to be mindful of the purpose of an introduction chapter, and be more selective in determining the relevant content and tone. On note taking with Zettlekasten 2023-03-15T00:00:00+00:00 I found out about the Zettlekasten note taking method</a> in early 2021 and got interested in learning more about it. So I started using it with Emacs using using Org-roam</a> and Deft</a>, and a quick config</a> I threw together. I synced my notes to my Nextcloud instance. After a few months of on-and-off usage, I found that learning how to properly employ Zettlekasten in my daily scenarios required me to go out of my way to remember to take notes in a Zettlekasten-y way. It took daily practice and regular usage for the method to become ingrained. Aside from the time it took to get comfortable with org-roam</code> itself, I found that it can be a lot of dull work to employ the idea of fleeting note taking and regular sessions of connecting between the notes and rearranging them, keeping what's needed and trashing the frivolous. I do a lot of research on various topics that I'm interested in, but I haven't managed to employ it as a note taking method consistently enough while working on larger projects. I like the fact that I can use something like org-roam</code> within Emacs, but it can also be awkward at times as I usually have other things opened there and switching around between code buffers and lots of note buffers can get annoying. Having simple markdown permanent note files that are: longer, more conceptual, and more free-form always seemed to be a better option for me. I could restructure the little paragraphs and sentences in a single project file faster and easier. I didn't find actual use for the "connected web of thoughts" idea other than the cool visual it can provide. Looking over the notes that I have written so far, I think I can discard about 90% of them. But I was also very happily surprised to find a few quotes I liked from a book I was reading, a couple of bookmakrs, and some bits of random articles I have read and decided to preserve for some reason. Currently I think of it like a diary for my laptop. It helps me remember what I did previously and connect the dots of where I started and ended on a specific topic (with roam-tags</code>). I'd like to write a simple program at some point to combine between the idea of being able to create, collect and connect smaller notes in a Zettlekasten-manner, and being able to quickly rearranged together into a longer note format format automatically. I'd also like to be able to start multiple instances of this program together, one for each project basically for better brain-space isolation. Useful links</h5> Org-roam: https://orgroam.com</a></li> My emacs setup: https://github.com/beshrkayali/emacs</a></li> Deft: https://jblevins.org/projects/deft/</a></li> Setting up Org-roam with Deft: https://www.orgroam.com/manual.html#Full_002dtext-search-with-Deft</a></li> </ul> "Glitch" Journalism 2022-11-13T00:00:00+00:00 Using the term "glitch" when it comes to issues related to software or technology in general is bad journalism. The term is used by journalists, politicians (and unfortunately, technicians and specialists) as a way to gloss over the details of what exactly is the cause of an issue. A simple example to make the point. Suppose you have to make an important phone call one morning at 08:00 exactly but you forgot to charge your phone the night before. When you woke up your phone was dead so you couldn't make the call. It's not the end of the world of course, but it's also your responsibility to have remembered to charge your phone. Saying that you couldn't call because of a glitch with your phone or charger is not an acceptable excuse. In reality, the term is mainly used as a way to conceal human error and make it seem like the bug couldn't be helped and it's no one's fault. A quick example: