Tags

WyWeb (my software that is running this website right now) uses uWSGI to communicate with the server. Previously, WyWeb was a loose collection of python files that needed to be run in a virtualenv and started with a separate uWSGI command and a configuration file. This was fine when WyWeb was fairly bare bones and only used by me, but as I began to expand its functionality, I wanted to easily share it with others. Having people clone a git repo, manage dependencies, manually set up systemd services, and configure a server is too much to ask. Luckily, I found uWSGI’s official documentation on how to embed a python script in a standalone binary! Unluckily, the instructions are out-of-date at best, objectively wrong at worst, and written in a tone so intolerable that I thought I had been catapulted back to the heckin’ epicsause year of our Lord 2010. Luckily for you I am recording my steps for success so that hopefully you can be spared the torment I have endured.

Notcurses is a modern TUI library written by Nick Black (who you may see around the net as dankamongmen or some equally dank designation). As Dank himself will tell you, the older ncurses library is beautifully documented, rigorously tested, and very well supported. It is, however, quite old tracing its history back to at least 1982, and as such lacks some modern features such as thread-safety. I had been using the venerable ncurses for my fireplace program - a use case that it was never designed to handle. Overall ncurses does a good job, but there is occasional tearing and artifacts. Notcurses solved all the graphical glitches beautifully, and performance was noticeably improved. The problem is that just about the only other person using notcurses is Nick Black himself, and while his documentation is extensive, it is mostly source code snippets with few examples. Hopefully this article will provide a nice jumping-off point for the absolute beginner.

Computers are these machines that we have engineered to be totally deterministic. No matter how many times a computer is provided with with some input, it should always give the same output. This is why glitch art is so fascinating - it happens when computers dont work the way they are supposed to. Of course computers crap out all the time, but that is usually due to poor programming for end-user applications. Actual data corruption is much rarer, and can both wreak havoc and be utterly entrancing.

I am a fan of useless terminal commands. Cowsay, Figlet, and pipes.sh have all brought me hours of joy. But I had always dreamed of having my own fireplace in the terminal to keep me warm during those cold late-night coding sessions. Sure, I had tried a few (aafire comes to mind), but none of them ever really suited me. They all had their own problems - opening in a new window, no color, lame effect, etc. Finally, I could bear it no longer; It had been a while since I had given myself a frivolous challenge, and my cold terminal had nearly given me frostbite. There was but one option: I would build my very own fireplace. And to make it a real challenge, I would do it without any googling.

One of the first “real” programs I ever wrote would encrypt a message using a substitution cipher and (more impressively) decrypt an encoded message without knowing the encryption key. Perhaps the first thing I had to come up with was an algorithm to take a cipher key that was used to encode a message, and transform it so that it could then be used do decode the ciphertext back into plaintext. I was aware of ROT-13’s property that if applied once to the plaintext, and again to the output ciphertext, it would yield the original plaintext. That is, ROT-13 is its own inverse. However, this is not the case for all possible keys, so I needed to find a more general algorithm.