> I'm curious if you have any tips on using patch and diff effectively to 
> manage source code, perhaps in the context of a small team (2-3 people)?

Quilt can serve as a practical example of what to do. It's a collection of 
scripts for patch-based workflows, predating Git. It essentially automates 
all the otherwise-manual work of running diff and patch yourself.

https://wiki.debian.org/UsingQuilt
http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf

Even in a world dominated by Git, Quilt still has its uses. Unlike Git, 
it's great for maintaining an independent, local patchset on top of an 
upstream code base. StGit attempts to be the best of both, being like Git 
where you need Git and like Quilt where you need Quilt, and studying it

> You sort of buried the lead :) waiting until the end to mention the very 
> cool Asteroids demo!

Heh, given your comment I've decided to move the video to the top of the 
article so that hopefully it more quickly grabs attention.

> This will be a nice dependency-less OpenGL and sound tutorial for me.

Note that it's OpenGL 1.1 since I wanted to keep it really simple. It's 
good enough for some things, like an Asteroids clone, but not everything. 
This is the last version of OpenGL directly supported by Windows, and so 
it's very easy to use. Later versions require accessing extensions, 
creating multiple OpenGL contexts, and using an OpenGL loader. I've worked 
all that out, too, in large part thanks to the OpenGL wiki, and I should

The workaround for MSYS2 in 475c111 interacts badly with a long-standing
bug in GNU Make where it avoids spawning a shell when it believes it can
handle a command itself as a sort of Bourne shell emulation. Since
"command" is typically implemented as a special shell built-in and not
an actual program, and GNU Make does not implement this built-in in its
Bourne shell emulation, GNU Make's shell function fails to invoke it
properly, resulting in an error:

    make: command: Command not found

One work-around is to set a custom shell that is not "/bin/sh" so that
GNU Make does not assume any particular shell semantics. For instance:

    make SHELL=dash
[message trimmed]

At least for C and C++, unless there are specific constraints — such as 
printing intermediate results not computed by FFT, or more likely, strict 
floating point error rounding (i.e. -fno-fast-math) — compilers are free 
to do this per the abstract machine. Only the DFT outputs are observable, 
not the inner workings.

IMHO, a compiler that transforms a generic DFT into FFT without having 
been programmed for that specific pattern is entering AI territory. I've 
noted in the past[1] that I've been a little freaked out at just how far 
optimizer reasoning can go. Both GCC and Clang can optimize non-tail 
recursive algorithms into iterative algorithms — without it being some 
specific algorithm — and your DFT example is really just a sophisticated 
version of this idea.

> --input-files *.jpg

This has no way to indicate where the arguments stop such that option 
processing can continue, so this option must go last. If it must go last, 
then these are really just positional arguments. If you do choose some 
sentinel to mark the end (perhaps "--") then there's the risk of an 
argument unintentionally matching as a sentinel, such as blog expansion. 
As you noted, stopping at the first option-like argument (a la argparse) 
is similarly unsound.

You mentioned repeated arguments, probably the most conventional way to 
supply multiple arguments for a particular option. For instance, there's 
ffmpeg's -i option. Though as you also noticed, this isn't friendly to 
globbing.

You can reflect cl-defstruct to convert records to plists. For instance:

(cl-defstruct poi name category latitude longitude)

(defun struct-to-plist (struct)
  (cl-loop for i upfrom 1
           for (slot . _) in (cdr (cl-struct-slot-info (type-of struct)))
           collect (intern (concat ":" (symbol-name slot)))
           collect (aref struct i)))

Then, say, convert to JSON:

(json-encode
 (struct-to-plist

I know almost nothing about Org, so I can't really help with that part. As 
for Elfeed itself, bind T in elfeed-search-mode-map to your new function. 
In your function use elfeed-search-selected to get the struct for the 
entry under the point, interrogate it using elfeed-entry-* accessors, then 
call the appropriate Org functions with what you found. As a convenience, 
you might also want your function to advance the point to the next line so 
that you can quickly make a sequence of decisions for all visible entries.

Thanks, Dimitrije! I've learned something new, so my exercise continues to 
serve its purpose. My mistake seems really obvious after having it spelled 
out. Alternative to your suggested fix, it seems HMAC would have rescued 
this MAC as well. I'd have been better off skipping the "swap" trick 
altogether and just relying on that.

Thanks for sharing your article, Rusty! Your list of downsides are all 
true and accurate.

> I'd be interested in hearing your opinion about locking subranges of a 
> large overall purgeable allocation.

If you're talking about adding this as a feature to my library, that 
implementation exists primarily as a proof of concept for my article, so 
outside of fixing defects I consider it frozen. The idea isn't that 
anyone would rely directly on my repository like a package. Instead, 
they would copy and embed it into their project, taking ownership of 
their fork — with the ubiquity of per-language package managers, a dying 
art these days — and making modifications if necessary to support that 
project. Or they would build their own using mine as a guide, e.g. when

> It also is more computationally expensive to display HTML emails, 
> requiring more power and newer hardware, reinforcing the "buy a new 
> one" upgrade loop

IMHO, this is a much larger issue than the rather insignificant extra 
server and network resources spent handling HTML emails vs. plain text. 
So much perfectly good hardware is routinely turned into e-waste simply 
because it cannot interoperate with an increasingly and unsustainably 
resource-hungry web ecosystem. It's something that really bothers me.