❌

Normal view

Mind-bending self-replicating GIF code prints an exact copy of itself, is both a program and its own visual output β€” champion coder shows off 'Piet Quine' technique

9 August 2026 at 12:40

Champion coder Yusuke Endoh has been flexing their esoteric programming muscles on social media. Their latest confection is a Piet Quine – a GIF image that prints itself. In other words, the GIF is both the code and the precise result after running the code.

If you haven’t quite grasped the enormity of this feat from the title, it is worth breaking down the respective definitions of both Piet and Quine in a computer programming context. Piet is an esoteric programming language in which programs look like complex, colorful, tiled artwork. Inventor David Morgan-Mar named it after Piet Mondrian, the famous founder of the neoplasticism artistic movement. Such artwork is immediately recognizable with its bold squares and rectangles bordered by heavy black lines. Smaller Piet GIFs look a bit more Mondrian-y to me, but also look more like colorful QR codes than paintings.

Endoh has created a Quine, graphically. In computer coding, a Quine is a program that produces a copy of its own source code without any external input. This can be quite a tricky feat, even when confined to the world of ASCII text. A requirement of this coding art is that the output is a character-for-character identical representation of the input. It must not simply read its own file to do the duplication task.

When merging the two ideas above, together, things get a whole lot more complicated. However, the top-linked blog and the embedded video shine a light on the task at hand and how Endoh succeeded. Specifically, the video shows Piet Quine running. The Piet interpreter scans the source GIF image in a β€˜load data’ phase, followed by a read of the GIF file header and palette info. The challenge here, raising the task above text Quines, is that the GIF folds in binary data, compression, and an awkward flow – they must all be handled deliberately to end up with the desired result.

A key thing to understand about the source image is that it includes a separately interpreted data part, compressed with an adaptive run-length encoding, and a code part. Endoh says that they managed to actually first achieve this way back in 2009, but the GIF was very tall, so not ideal for visual appreciation. The developer decided to ask Claude Code to analyze and reconstruct the original script and build a β€˜landscape’ Piet Quine. Even with AI's help, it wasn’t easy to refine the design to the compact finished GIF seen in this article and video. Only after much work on shrinking the visuals and coaching Claude was the GIF shoehorned into the finished 4:3 landscape image (252 x 189 pixels).

Finally, Endoh reveals that a driving force behind their Piet Quine development efforts was the wish to raise awareness of the 2026 Obfuscated Programming Language Design Contest, which is running right now. If you can, please design an esoteric programming language and submit it! Endoh is one of the judges, and you have until October 1 to make your submission(s).

NSPasteboard Crashes When Handling File Promises

3 August 2026 at 21:35

Wade Tregaskis:

NSPasteboard mutates itself simultaneously from the main thread and the global concurrent Dispatch pool, w.r.t. to its internal type cache. This is surprisingly trivial to reproduce (sample code below) by just dropping, e.g. a file promise (such as by opening a PNG in Preview, revealing the thumbnails sidebar, and then dragging the thumbnail onto the sample project’s window).

[…]

Since this bug causes semi-random memory corruption, it manifests in a large number of ways – not all of which are all that helpful.

[…]

SwiftUI’s onDrop(of:isTargeted:perform:) method makes no claims or promises as to what thread / queue it executes the closure on, and in fact according to the anonymous Apple engineer it never executes the closure on the main thread.

Now, while that may be the intent, the reality of that is wrong – in my experience it always executes the closure on the main thread (which makes a lot of sense to me as drag-and-drop event handling in AppKit has always been on the main thread in practice).

Apple also told him that NSPasteboard is not safe to use outside the main thread, even though that’s not documented, it’s not @MainActor, and Apple’s own code does do that.

❌