Hello and welcome to my little nock of the internet. Here I have my blog which mainly contain posts about tech, the outdoors, my journey as a PostDoc, cooking, and some times mead brewing.

A bit of background information before you step into my world of crazy. I am Lars, a.k.a. looopTools, a Software Engineer and PostDoc living in East Jutland, Denmark. My research focus on the application of generalised deduplication in real world storage systems. This includes the design, implementation, and evaluation of prototypes and more complex systems. I have 10+ years of experience from industry mainly through student positions, but also as self-employed consultant, or full-time employee. I mainly work in low-level user space, high-level kernel space, and storage systems in general. Besides research and software development, I also love the outdoors and try to go out as often as possible (not enough at the moment) and I am an aspiring author currently working on a few different novels. I also dabble in being a more advance home cook and baker, which you may see some posts about. Finally I like the ancient art of brewing mead, a.k.a. honey wine, and experiment with different flavour combinations and ageing times.

Status of QueryC++

15 March 2022

Last year I started QueryC++ a SQL Query build for modern C++ which allows constructing SQL queries in C++ without using std::string. Making code cleaner, increases maintainability, and reduces the risk of syntax errors.

I released QueryC++ under the BSD3-Clause License and it is still under this license. I chose this license to make QueryC++ as easy as possible for others to use and integrate as part of their software library tools box. This has been great as (at least) one company now are using QueryC++, a fact I am proud of.

Some said that QueryC++ did not receive enough of my attention, and therefore, they could not recommend using it, and it was (in its current state) too limited in terms of functionality. Although I agree on the attention part, I can’t entirely agree with the feature part. In its current state, QueryC++ can be used in production. It actually already is.

In this post, I will outline the current status of QueryC++ and future plans.

Current Status

QueryC++ is current major version is 3, and the perceptive may have realised we skipped version 2. This is explained later, and QueryC++ has moved from C++17 to C++20. We currently offer CMake, Make, and waf.io as build systems, although I know that there is currently work being done to add xmake (I will talk a little about this later).

The focus has since the beginning been on supporting PostgreSQL queries. That is because I mostly use PostgreSQL and often get QueryC++ tested through my work. There is full support for simple SELECT, INSERT, DELETE, and UPDATE queries in PostgreSQL, although not all data types are fully supported yet. This is the current status; I will cover why we skipped version 2.

Skipping Version 2?

This discussion came up with users of QueryC++ during the move from C++17 to C++20. Currently, QueryC++ only support C++20, but some have expressed a desire for C++17 support. But we were unsure how to do that well in the current scheme of things. Some suggested keeping an alternative version of QueryC++ built for C++17 similar to others that run a parallel version scheme, i.e. lower compatibility equals lower semantic version numbers. We are still thinking about this, as QueryC++ doesn’t rely much on C++20 features yet. This means that it is impossible, and therefore this is still up for discussion.

Future plans

Adding Integration Tests

I have been ignorant, and I apologise for the issues this may have caused some (even though only one team reported the issue). For those who do not know, I am dyslexic, and my brain sometimes plays tricks on me when reading results in foreign in FOREIGN KEY being spelled FOREIGN KEY in QueryC++. This error was only discovered recently (fix in version 3.0.5). However, this clearly shows that the tests of QueryC++ are not advanced enough. I will rectify this as soon as possible (although probably first in April). I will extend these tests at the integration test, where queries are run against a live PostgreSQL database and added support for more databases.

Adding more types

We have been at a stalemate about adding additional supported types to QueryC++. This will change during March and April, where more time will be allotted to the development of QueryC++. The focus will still be on adding more PostgreSQL compatible types, but we will also add as many common types along the way as possible. This includes constraints.

More on MariaDB and MySQL

Some have shown interest in support for MariaDB and MySQL; however, the interested party cannot provide development time for adding support to this. Therefore, I officially ask for help in adding support for MariaDB and MySQL.

Conan Package

The Conan package will come; I am just not exactly sure when yet. But it is a priority. I hope to get it done in April or May.

Adding xmake, why?

So I found a new build system called xmake, and I have seen it get some traction in the C++ community. But since QueryC++ already support Make, CMake, and waf.io, I thought this would be enough. However, what xmake is trying to achieve speaks to me, and I would like to support this approach. Therefore, I will add xmake as an additional support build system.

Funding

The funding from Aarhus University will end by the end of March. Therefore, I may start seeking for funds for the development of QueryC++ although currently it is still not needed.

This is the current status and a small peak of the future plans of QueryC++.

./Lars

Rectangle - What macOS is missing

03 January 2022

This is not a review, it is simply a recommendation of an awesome application

rectangle I am both a Linux and (to somes surprise) a macOS user, and switch betweeen Fedora with Gnome as DE and macOS on a daily basis. Therefore, I try to setup both my Linux and macOS box to work in similar fashions and one thing I had been missing on macOS for a while was sending windows to one side of the screen like META + left/right-arrow under Gnome or sending a window to another display.

Now I wrote I had been missing it for a while, indicating that I have solved the problem. Well I have not solved the problem myself by coding, no, no. I found an application and this is Rectangle an application for macOS developed by Ryan Hanson. And to be honest this application solves all my needs on macOS and then some, in extension to do so much more. I have been using Rectangle since the May of 2019 and I honestly have loved it ever since.

It is highly configurable and allows you to record alternative key-bindings if you need it (I have not found the need). Additionally, it is very light on resource usage, a problem I have had with alternatives. Furhtermore, Rectangle is open source (github.com/rxhanson/Rectangle) which have allowed me to look through the code and though I have not been through all the code I have been through some, and I like what I see.

Therefore I whole heartly recommend Rectangle to any macOS user.

./Lars

Slack drops support for Fedora and here is why it doesn't matter

08 November 2021

In the Fedora community, there have been some confusions since this was seen by different users Slack drops Fedora support March 2022. However, this is a truth with modifications and sometimes the Fedora. The support is actually only being dropped for native RPM package for Fedora (and RedHat). Slack will still be available to be used through the browser just as it always has been.

What is all the fuss about then? There is still support right? Indeed, but some reason people prefer the desktop applications. This means that people have been in a slight panic, about what happens next. Well the answer is pretty easy… Use the Slack Flatpak instead. There is no reason to panic just use Flatpak.

Additionally, more and more distros, including Fedora, seems to be moving away from native packages, to systems such as Flatpak and Snap. SO moving to these tools is simply a good idea. But why the are moving to these at all? The reason is to ease the lives of maintainers. Currently making a (“proper”) release for every distribution is really time consuming, to you a deb package, RPM, what ever ArchLinux uses, and so on. With Flatpack or alternative, you need one release and it will (is supposed) to work across all distributions,

So that Slack drops the native RPM package doesn’t matter, they still support Flatpack and at the moment that is actually more important than a native package.

This is my take on it at least.

-Lars

Query C++ a simpel SQL query builder for C++ version 1.1.0

04 October 2021

I have been a bit silent with it, except for release information on Twitter and LinkedIN. But I would like to (more) publicly introduce QueryC++ or QueryCpp (which ever you prefer) which I released in version 1.1.0 last week.

The purpose of QueryC++ is to reduce the usage of std::string for having SQL commands exposed as raw text strings in C++.

Let us assume that we are working with PostgreSQL and use libpqxx for executing commands in the database. Then if we want to create a user table where the user has an id, a first name, and a last name. Afterwards we insert two users, using a single insert, using std::string it could look something like this:

#include <string>

#include <pqxx/pqxx>

int main(void)
{
    pqxx::connection con; // Assume setup
    std::string query = "CREATE TABLE user (id PRIMARY KEY SERIAL, first_name VARCHAR(255), last_name VARCHAR(255))";
    pqxx::work tx1(con);
    tx1.exec(query);
    tx1.commit();

    query = "INSERT INTO user(first_name, last_name) VALUES ('john', 'doe'), ('jane', 'doe')";
    
    pqxx::work tx2(con);
    tx2.exec(query);
    tx2.commit();
}

It is not bad, but it for sure is not pretty. First of all, if we want to make a change to the table, we need to find where in the “long” SQL string we need to change it and two, if we make a syntax error we have to redo it again.

Secondly, this is example is not difficult to read, but SQL can be if it becomes more complex.

Thirdly, when I write C++ I prefer to write C++ and not some other language embedded in strings. Which is the main reason I started QueryC++. So how would the above code look in QueryC++, well it will look like this:

#include <querycpp/querycpp.hpp>
#include <pqxx/pqxx>

int main(void)
{
    querycpp::column id("id", querycpp::type::postgres::numerical::SERIAL, 
                              {querycpp::constraints::PRIMARY});
    querycpp::column first_name("first_name", querycpp::type::common::string::VARCHAR, {"255"});
    querycpp::column last_name("last_name", querycpp::type::common::string::VARCHAR, {"255"});
    
    querycpp::table user_table("user", {id, first_name, last_name});
    
    querycpp::query user_query(user_table);
    
    pqxx::connection con; // Assume setup
    
    user_query.CREATE();
    
    pqxx::work tx1(con);
    tx1.exec(user_query.str());
    tx1.commit();
    
    // Clear the currently build query
    user_query.clear(); 
    
    std::vector<std::vector<std::string>> users;
    user.push_back({"John", "Doe"});
    user.push_back({"Jane", "Doe"});
    
    user_query.INSERT({first_name, last_name}, users);
    
    pqxx::work tx2(con);
    tx2.exec(user_query.str());
    tx.2.commit();
}

So what did QueryC++ give us besides more code?

  • First it gave us individual columns, where we are able to handle constraints separately for each column.
  • Then it gave us a table and a query object
  • The ability to create the table
    • and neatly insert multiple elements into the table

All in all QueryC++ gave us a program that is easier to read, written in C++, and we work directly with objects. Additionally, if we want to change a specific column, we do not have to go hunting in a string, we do get compile time errors or even intellisense errors if we make a spelling mistake. From my perspective QueryC++ provides pretty good benefits.

FAQ

A few (already) frequently asked questions.

What is the license? It is BSD version 3, check the LICENSE file for more information.

Why are functions all caps? are you crazy? a) Yes I am crazy that should not come as a surprise and b) Even though I am only publicly know contributor to QueryC++. There are a few people who are “beta” testers. One of the main thing people requested was actually to have methods in all caps, to mirror how the write SQL in general. Additionally and also an excuse is that SQL keywords such as and are reserved in C++ and we “get around” this by having our functions in all caps.

Can I contribute to QueryC++? Yes you can and I am working on code style guide and setting up the general workflow. Be a bit patient, please!.

Can I make request? Yes, open an issue ticket and we/I will take a look. If we deem it a feature that should be in QueryC++ we will add it as soon as we get the change.

Who funds this? Technically Aarhus University Department of Electrical and Computer Engineering, but “only” limited. I have been allowed to work on QueryC++ during work hours as I am using QueryC++ in my research and when I find something I need for my research that is missing, then I can added it.

Why waf first? I focus on waf as build system first, because it is the one I am use to and use myself. However, CMake should fully work now.

Why no Conan package? It is coming I SWEAR! Maybe even in version 1.2.0 but I am not promising that!

./Lars

I prefer Ruby over Python... sorry

19 September 2021

For some reason people tend to assume I prefer Python over all other languages since I am an academic researcher. This has a) always been weird to me and b) it is not true.

One of the main reasons people think I prefer Python is the quick turn around from idea to “product”. Which apparently is preferable if your are researcher, that is true but language such as Ruby, Crystal, Java, and C# offers this as well, in my opinion and there for Python is not “better” compared to these languages on that note.

The second big assumption is that because I am researcher I must be using numpy, pandas, matplotlib and Jypyter Notebook. Well fun fact, I use none of them. I use to be a heavy user of numpy, matplotlib, and Jupyter notebooks. But as I did less and less data analysis, numpy fell out of my tool box. Matplotlib got replaced by pgfplots, and finally I replaced Jupyter Notebook with Emacs’s Org-mode. The later may sound weird to some, but most of my stuff is in org-mode already and I could easily enough replicate the behaviour I need. Finally, I have never done complex enough data analysis that Pandas was ever on my radar as an every day tool, though it may be in the future.

But may main reason for moving away from the tools, was actually not the tools, they are awesome! My main issue was Python. I have worked at companies, such as Chocolate Cloud Aps and is currently working for a company, that does most of the work in Python. Both through such jobs and my academic journey, I have come to the conclusion “I don’t really like Python”

./Lars