Hi, I'm Tomasz

Being a bit bored and having a some extra time during Christmas motivated me to learn zig. As usual, when learning a new language, you experiment a bit, write some small test programs to discover the syntax and idiomatic ways to solve problems and learn the standard library. One of the fundamental things that you’ll eventually find the need for, sooner or later, is defining abstractions and interfaces, and I was a bit shocked to discover that zig simply doesn’t support that!

Here’s a quick summary of the tools I’ve picked up along the way in 2024 that I continuously find useful. I’ve divided the list into three sections, first one comprised mostly of general shell “helpers” that are part of my day to day workflow one way or another. The second one, focusing on my current nvim setup and the last one listing some tools deployed in my home lab or things I run on my servers that I find useful and worth mentioning as well.

I haven’t got a chance yet to play with asynchronous I/O APIs in any production application so, to fill in that gap I’ve decided to commit some time and experiment with posix AIO and liburing a try. These two are (I think?), at the time of writing, the two most popular APIs to perform asynchronous operations in Linux. This post isn’t a benchmark nor a comparison between the two. It’s just a knowledge summary of the basics behind using these APIs and what I’ve learned along the way.

I’m currently in the process of writing a back-end for a small web application that I plan to deploy in my local environment. The application isn’t really relevant. The important bit is a new trick I learned while working on it. Within the back-end, at some point, I’m parsing an user-agent string. These strings are standardised and should follow the format described by HTTP Semantics. For convenience, I’ve chosen to go with uap-go to parse these strings and here lies the catch.

Lifetime problems As a reminder, I want to start with a classic example of using an invalid this captured in a lambda acting as a delegate . 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 #include <functional> #include <iostream> #include <memory> #include <string> class Item { public: explicit Item(std::string name) : name{name} {} std::function<void()> makeHelloDelegate() { return [this]{ hello(); }; } void hello() const { std::cout << "item: " << name << std::endl; } private: std::string name; }; int main() { auto item = std::make_unique<Item>("pencil"); auto d = item->makeHelloDelegate(); item.

This is a short overview of things added along with c11 and c23 which I find useful or interesting. auto keyword… yet again auto has been repurposed in C23. Originally, it defined a storage duration for local variables (similarly as static) now, comparably as in C++, it can be used for type inference purposes. 1 2 3 4 5 6 7 void foo() { // auto is implied int i = 123; // same thing, auto keyword is redundant auto int j = 123; } In its original purpose, variables marked with auto have their storage automatically allocated and deallocated on scope entry and exit.

c++20 introduced concepts to the standard thanks to which now, we can specify constraints and restrictions on template parameters that a given type, variable or a function template accepts. Similarly as with e.g. virtual classes defining interfaces for a family of types through inheritance, concepts allow creating interfaces for generic code. With concepts, just by looking at the template declaration we know what to expect and what types are accepted. Having a simple template like: