Stoneshard is a turn-based RPG with nice 2D graphics and elaborate
role-playing system. Unfortunately, the Linux support is a bit messy and if you
happen to play it on Ubuntu 20.04, it will tell you it cannot find
libcrypto.so.1.0.0. Common advice is to symlink libcrypto.so.1.1.0 however
that is not even necessary because the game does not depend on it anyway. Hence,
the cleaner way is just to patch the game binary, for example using
patchelf:
$ git clone https://github.com/NixOS/patchelf && cd patchelf
$ ./bootstrap.sh && ./configure && make && sudo make install
$ patchelf --remove-needed libcrypto.so.1.0.0 <path-to-stoneshard>/game/StoneShard
$ patchelf --remove-needed libssl.so.1.0.0 <path-to-stoneshard>/game/StoneShard
Then you can run the game just fine. I still wonder what the crappy build system
of that game is doing though …
As we all know public services are often underfunded or public websites more
often than not of questionable usability. The waste calendar for the
municipality of Karlsruhe is somewhere in between. It is not bad but not of much
help for your fellow scavengers who like to re-use thrown away goods. For the
past three years, I scraped that site with a small Python script and dumped
a CSV file that people could use to plan their hunts. This worked well enough
but I always only updated it begrudgingly because I was asked to do it rather
than because I wanted to do it.
But I am motivated to hone my programming skills, so I took this little
project, rewrote it in Rust, extracted road and date data and dumped
everything into a small static site based on Vue and Leaflet.js. So, if you
want to schedule your next hunt or find out where to play Pokémon GO in
Karlsruhe without being disturbed, here is your chance.
As easily witnessed, content frequency of the blog is at an all-time low. So
what’s better than increasing it by writing about switching from Jekyll to
Zola? Why, you ask? First, Jekyll is the only reason I have Ruby and gazillion of
Jekyll dependencies installed even though I don’t understand a lick of the
language. Second, every time there is a Jekyll update, I have to do something
about some plugin breakage or live with some new warnings about this and that.
Third, considering the application scope of a static site generator, it’s
incredibly slow.
Actually, there was no urgency but I read about Zola and was hooked because it’s
supposed to be fast (it is, taking a mere 100 ms to re-generate this blog) and
it uses the same templating technology I used for splat. I won’t bore you
with the conversion details but just want to point out this rewrite script
which converts the Jekyll front matter which is written in YAML to TOML which is
required by Zola.
All in all it was a straightforward conversion and I hope Zola will backing this
blog for the next nine years as Jekyll did in the past.
Static site generators for blogs and similar ad-ladden static “content” is the
hot shit for years now. Probably because it’s a simple enough task to tackle
with even superficial knowledge of the language du jour. Because of that and the
number of people hosting their own photos being in the low single digits, static
site generators for photo galleries are not a hot topic. For years, I have used
Sigal and even contributed a few patches here and there. Color me surprised
when I updated to the latest version and learned that I had to update my carefully
crafted theme and configuration to continue using that. Well, not with me! I am
stupid enough to use my superficial knowledge of Rust to come up with splat, an
alternative static site generator that will never break themes. Promised 🤞
C and C++ is known for its abysmal dependency and build system situation. For
historic reasons a build system has not been standardized thus low level build
tools such as make and ninja as well high-level build tool generators such
as Autotools, CMake, meson and entire build frameworks like bazel have come and
gone throughout the years.
A lesser known build generator is
coremake. And lets be honest: it is a
horrible, underdocumented piece of shit written in hard-to-follow spaghetti C. I
would not even call it a build system generator it is more a static generator
tool that reads its own undocumented domain-specific language (which is actually
not that bad because like meson it can only declare dependencies) written in
.proj files and a so-called “platform” file that, amusingly, ends in .build.
That platform file is does not just specify a certain tool
chain and maybe CFLAGS but is a hodge podge of that and instructions how to
generate output. As you can tell from the official repo, insane people have done the
insane and written generator code for Android, make, Visual Studio and
whatnot.
Since, the make backend defaults to recursive Makefiles (booo), I was
tempted to add one more to the whatnots and that is
ninja. Some may know it as the default backend of
meson and an optional backend of CMake. Anyhow, on a
scale of 1 (make) to 10 (bazel) in terms of stuff, it ranges somewhere between
0.01 and 0.02 thus all logic must come from a meta build system. And to spare
you the work of figuring this out, here is something for the second
advent which allows you doing this
Adding basic ninja support to coremake was a small adventure. Although ninja’s
description language is super easy to follow, figuring out coremake’s quirks
concerning scoping and path makes you want to puke and I am certain I have only
scratched 5% of the disgusting surface.