Hi, I'm Tomasz

I’ve recently stumbled upon an article about a “modern” C development environment. It caught my attention; sounds like a good read and potentially a way to learn something new and refresh the good old rusty C skills, so I thought. Unfortunately, it was quite to the contrary, leaving a bitter taste at the end. There’s a lot of stuff I disagree with and frankly some that should be killed with a shovel and buried deep in the ground before it spreads like a disease and make C development even more miserable than it already is.

As it’s probably obvious by now, I’m not a fan of CMake. I don’t like the weird syntax, the verbosity of the language, the flawed concept of multistage build system generation and external dependency management which seems like an after thought.

I can’t deny though, that CMake is very popular and has a lot of traction so, it’s the necessary evil until we all, as an industry, decide on some other solution.

Some time ago, I wrote a piece about CMake. It was more of a rant, written in the heat of the moment, after being frustrated by some of CMake’s idiosyncrasies. Ironically, it has become one of the most read posts on this blog, which is a bit disappointing. I would like to believe that there are far more interesting and useful posts available here but it is what it is.

My concluding issue in that post was related to dependency management between a set of CMake projects which comprised a “stack”. Recently, having to work with cmake once again, I’ve discovered CMake’s ExternalProject - which mitigates that problem significantly.

This post is part of a WebAssembly series focused on WASM and C++. The goal is to gain a thorough understanding of how WebAssembly works, how to use it as a compilation target for C++ code and hopefully have fun along the way. So, stick with me for this exciting journey.

Recap

In the previous post, I’ve compiled Lua interpreter to WASM using emscripten and successfully run it using node. There was a problem running the same code in the browser as blocking IO is not possible. Today I’m gonna try to address this issue and run Lua interpreter in the browser.

This post is part of a WebAssembly series focused on WASM and C++. The goal is to gain a thorough understanding of how WebAssembly works, how to use it as a compilation target for C++ code and hopefully have fun along the way. So, stick with me for this exciting journey.

Recap

In the previous instalment of this series, we’ve learned that WASI is an interface enabling exposure of system APIs to WASM modules. WASI is implemented by all relevant WASM runtimes; I’ve also provided an example of what needs to be done to implement WASI polyfills by hand and how to use more mature and complete implementation of WASI polyfills in the browser.

In this post I’m gonna discuss how to use binfmt_misc to build and run non-native docker images that you can build on your PC and deploy to your target machine like e.g. raspberry pi.

What’s binfmt_misc?

binfmt_misc stands for miscellaneous binary formats and in short, it allows to run non-native binaries (through the help of a format associated interpreter) on the host system just as they were native.

Although it is strongly criticised for its bloat, create-react-app is often a go to when starting a new React project. I like to start things from the bottom up, adding things up as I need them so, I prefer a minimalistic approach.

It’s actually very easy to setup a bare-bones React project using parcel. Here’s how to do it.

Initialise npm project

mkdir react-minimal
cd react-minimal
npm init -y
mkdir src

Some adjustments are needed to package.json. I’m gonna change the main to source, pointing to the index.html of my project. I’m gonna create an empty src/index.html for the interim.