Fixing up Stoneshard dynamic link issues

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 …


A waste calendar and map

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.

P.S.: thanks Karlsruhe for that splendid API /s


Going Zola

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.


Splat

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 🤞


ninja backend for coremake

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

$ coremake ninja-clang-linux_86_64
$ ninja
$ ninja -t compdb > compile_commands.json

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.