This past May I put together my own C and C++ development distribution for Windows called w64devkit. The entire release weighs under 80MB and requires no installation. Unzip and run it in-place anywhere. It’s also entirely offline. It will never automatically update, or even touch the network. In mere seconds any Windows system can become a reliable development machine. (To further increase reliability, disconnect it from the internet.) Despite its simple nature and small packaging, w64devkit is almost everything you need to develop any professional desktop application, from a command line utility to a AAA game.

Python asyncio has support for asynchronous networking, subprocesses, and interprocess communication. However, it has nothing for asynchronous file operations — opening, reading, writing, or closing. This is likely in part because operating systems themselves also lack these facilities. If a file operation takes a long time, perhaps because the file is on a network mount, then the entire Python process will hang. It’s possible to work around this, so let’s build a utility that can asynchronously open and close files.

This article was discussed on Hacker News and critiqued on Wandering Thoughts (2, 3).

Command line interfaces have varied throughout their brief history but have largely converged to some common, sound conventions. The core originates from unix, and the Linux ecosystem extended it, particularly via the GNU project. Unfortunately some tools initially appear to follow the conventions, but subtly get them wrong, usually for no practical benefit. I believe in many cases the authors simply didn’t know any better, so I’d like to review the conventions.

This article was discussed on Hacker News.

A common situation in asyncio Python programs is asynchronous initialization. Some resource must be initialized exactly once before it can be used, but the initialization itself is asynchronous — such as an asyncpg database. Let’s talk about a couple of solutions.

Ever since I worked out how to render video from scratch some years ago, it’s been an indispensable tool in my software development toolbelt. It’s the first place I reach when I need to display some graphics, even if it means having to do the rendering myself. I’ve used it often in throwaway projects in a disposable sort of way. More recently, though, I’ve kept better track of these animations since some of them are pretty cool, and I’d like to look a them again. This post is a showcase of some of these projects.

This week I was debugging a misbehaving Python program that makes significant use of Python’s asyncio. The program would eventually take very long periods of time to respond to network requests. My first suspicion was a CPU-heavy coroutine hogging the thread, preventing the socket coroutines from running, but an inspection with pdb showed this wasn’t the case. Instead, the program’s author had made a couple of fundamental mistakes using asyncio. Let’s discuss them using small examples.

This article was discussed on Hacker News.

As a computer engineer, my job is to use computers to solve important problems. Ideally my solutions will be efficient, and typically that means making the best use of the resources at hand. Quite often these resources are machines running Windows and, despite my misgivings about the platform, there is much to be gained by properly and effectively leveraging it.

Sometimes targeting Windows while working from another platform is sufficient, but other times I must work on the platform itself. There are various options available for C development, and I’ve finally formalized my own development kit: w64devkit.

This article was discussed on Hacker News.

Suppose you’re writing a command line program that prompts the user for a password or passphrase, and Windows is one of the supported platforms (even very old versions). This program uses UTF-8 for its string representation, as it should, and so ideally it receives the password from the user encoded as UTF-8. On most platforms this is, for the most part, automatic. However, on Windows finding the correct answer to this problem is a maze where all the signs lead towards dead ends. I recently navigated this maze and found the way out.

This article was discussed on Hacker News.

I’ve noticed a small pattern across a few of my projects where I had vectorized and parallelized some code. The original algorithm had a “push” approach, the optimized version instead took a “pull” approach. In this article I’ll describe what I mean, though it’s mostly just so I can show off some pretty videos, pictures, and demos.

I had recently lamented that due to Go’s strict module security policy it was unreasonably difficult to experiment and practice with modules. Modules can only be fetched from servers with valid TLS certificates, including both the module path and repository servers. Setting up a small, local experiment meant creating a certificate authority, generating and signing certificates, and installing these all in the right places. I’d much rather relax Go’s security policy for the experiment.

As a result of that complaint, I learned that the upcoming Go 1.14 has as a new feature: GOINSECURE. It’s like the old -insecure option, but safer due to being finer grained: a whitelist of exceptions. It’s exactly what I needed. Since then I’ve been using it to run small module experiments. It started as some scripts, but I eventually formalized it into its own little project.

https://github.com/skeeto/go-module-testbed [requires Go 1.14]