Buffered output typically comes in two flavors: fully buffered
and line buffered. If output goes to a terminal then the implementation
automatically selects line buffering, flushing its buffer when a line is
completed so that it reaches the user immediately. Otherwise it fully
buffers, holding output until the buffer is full or an explicit flush
event at some arbitrary point in the future. Line buffering is a common
bottleneck in non-interactive terminal applications such that it’s worth
redirecting output to a file or pipe in order to avoid it. It doesn’t
have to be this way. We can have our cake and eat it, too: promptly
delivering lines to a terminal at fully-buffered speeds.
I’ve been fascinated with local LLMs for a couple of years now.
The better open weight models, including some that inference on regular,
higher-end consumer hardware at tolerable speeds, are now reliable enough
to handle simpler programming tasks. This requires a coding harness, but
so far this year I’ve been disappointed by all the harness offerings. For
inexplicable reasons most are built with web stacks, and consume enormous
amounts of memory. At its core a coding harness is essentially curl glued
to popen(). This should not require gigabytes of RAM. So I built my own:
Prospero. It’s written in my C++ style with a snappy Dear
ImGui docking interface. It uses around two orders of magnitude
fewer resources than other harnesses without sacrificing features.
I spent a week creating a new deflate implementation from scratch in C
named tugz to provide an Info-ZIP-compatible zip program for
w64devkit 2.10.1 (released today). I also replaced busybox-w32’s
deflate-based unzip, gzip, gunzip, and zcat apps as well. My new
deflate performs much better than zlib and on par with libdeflate.
In general the new programs are substantially faster and produce slightly
smaller outputs than the BusyBox equivalents, which is optimized for size
than speed after all, but also compared to the original gzip and Info-ZIP
you get in a typical Linux distribution. The tugz programs are
CRT-free (inspect them with peports!) with first-class Windows
support and better Unicode handling.
My blog began as a blosxom (Perl) site running on a VPS. In 2011 I
moved to the new GitHub Pages, with the site generated statically
by Jekyll (Ruby) on a GitHub server. It was a no-brainer: easier,
faster, and cheaper, better in every way. After 15 years of Jekyll, and
spurred by a post on m4, this week I replaced it with a new,
custom-built static site generator, dubbed ssg, in “C with
templates” C++20. The ~8KLoC source closely follows my personal coding
style including templated arenas and slices, zero
dependencies, and a libc-free core. It’s wicked fast, and a complete, cold
generation of my blog takes 150ms on my MacBook. That is, it’s done
before Ruby would even reach Jekyll’s entry point. It’s a been a great,
real-world demonstration of the effectiveness of my coding philosophy.
The past year has been exciting for w64devkit, which like any software
distribution is never complete. Peter0x44 joined as co-maintainer, and
has pushed the project in good, new directions, with ideas I would never
have considered. Many of his improvements have gone back upstream, and so
you may benefit even if you don’t use w64devkit. I’d like to touch on the
various odds and ends from the past year.
Stars! is a 1995 4X game (explore, expand, exploit, exterminate)
for 16-bit Windows 3.1 that I first played ~28 years ago. While Windows is
famously backwards compatible, it’s notoriously difficult to play Stars!
today. Windows x64 cannot run 16-bit applications, and playing requires
either retro hardware or emulation (otvdm, DOSBox), sometimes
paired with Wine. My new, exciting solution, Stars!VM, or
Stars! Virtual Machine, embeds a custom 80286 emulator and a Win16
to Win32 bridge. As native Win32, the game looks and feels exactly as it
did originally, except sporting a modern file chooser and 4k scaling. It’s
indistinguishable from a genuine 32-bit or 64-bit port of the game,
especially with the original 16-bit game embedded inside the VM
executable.
Readers will be familiar with Mask-Step-Index (MSI) hash tables, a
technique for building fast, open-addressed hash tables in a dozen lines
of code. If multiple threads or processes access an MSI table with
at least one still inserting elements, care must be taken to avoid data
races. This article will show how to add atomic operations to MSI tables
in order to support different concurrency constraints.
This past Tuesday I typed C-x C-c in Emacs for the last time after 20
years of daily use. Though nearly half that time was gradually
retiring it, switching to modal editing, then to Vim. Emacs is a platform,
and I’d grown accustomed to its applications, especially those I built
myself. There was no particular hurry, so replacements came slowly. With
my newly-acquired superpowers I could knock out the last two pieces
in a few days’ work, namely M-x calc with stackcalc and
Elfeed with Elfeed2. I’m especially excited about the
latter because it already exceeds the original. Both are multi-platform,
native C++ GUI applications using native UI components.
The new w64devkit release two weeks ago is the first to be code-signed
with my identity, verified by Microsoft’s certificate chain. Currently
only the release packaging is signed — the self-extracting archive and
its payload — but I will soon code-sign individual EXEs and DLLs within
the distribution. In fact, all Windows builds of my project releases
have been code-signed the past two weeks, including dcmake, and so
should everything going forward. My signing identity builds reputation
with each download, so users will have an easier time with SmartScreen,
and security software generally. Azure Artifact Signing creates the
actual signature, but the rest is done with new infrastructure I built
myself, aas-sign. As is often the case, the existing options were
deficient for my needs, so I had to build it myself.
CMake has a --debugger mode since 3.27 (July 2023),
allowing software to manipulate it interactively through the Debugger
Adaptor Protocol (DAP), an HTTP-like protocol passing JSON messages.
Debugger front-ends can start, stop, step, breakpoint, query variables,
etc. a live CMake. When I came across this mode, I immediately conceived a
project putting it to use. Thanks to recent leaps in software engineering
productivity, I had a working prototype in 30 minutes, and by the
end of that same day, a complete, multi-platform, native, GUI application.
I named it dcmake (“debugger for CMake”). I’ve tested it on macOS,
Windows, and Linux. Despite only being couple days old, it’s one of the
coolest things I’ve ever built. Prior to 2026, I estimate it would have
taken me a month to get the tool to this point.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.