Grasp Kotlin’s Coroutines With This Short Tutorial

Kotlin is a relatively new programming language; a derivative of Java with lots of little handy functional bits such as coroutines. [Foalyy] is porting an app to Android and learning Kotlin at the same time, and after wrapping their mind around coroutines, has written up a concise five-part tutorial on them.

Coroutines in Kotlin are a way to simplify writing asynchronous code, which is code that doesn’t necessarily execute in the order it is written. Coroutines are like light-weight threads that can be launched and managed easily, making it simpler to bridge together blocking and non-blocking code. (However, coroutines are not threads. They are more akin to suspending functions that play very well together.)

[Foalyy] found that the official Kotlin documentation on coroutines went into great detail on how coroutines function, but wanted a more bottom-up approach to understanding how they work and can be used. Luckily for anyone who thinks the same way, [Foalyy] wrote it all up and begins with a great recap of important elements, but if you prefer you can jump straight to the examples.

Kotlin has been around for a while, and readers with sharp memories may recall it was featured in this excellent introduction to what neural networks are and how they work.

Assembly Language For Real

We all probably know that for ultimate control and maximum performance, you need assembly language. No matter how good your compiler is, you’ll almost always be able to do better by using your human smarts to map your problem onto a computer’s architecture. Programming in assembly for PCs though is a little tricky. A lot of information about PC assembly language dates back from when assembly was more common, but it also covers old modes that, while still available, aren’t the best answer for the latest processors. [Gpfault] has launched a series on 64-bit x86 assembly that tries to remedy that, especially if you are working under Windows.

So far there are three entries. The first covers setting up your toolchain and creating a simple program that does almost nothing. But it is a start.

Continue reading “Assembly Language For Real”

Frances Allen Optimised Your Code Without You Even Knowing

In 2020, our digital world and the software we use to create it are a towering structure, built upon countless layers of abstraction and building blocks — just think about all the translations and interactions that occur from loading a webpage. Whilst abstraction is undoubtedly a great thing, it only works if we’re building on solid ground; if the lower levels are stable and fast. What does that mean in practice? It means low-level, compiled languages, which can be heavily optimised and leveraged to make the most of computer hardware. One of the giants in this area was Frances Allen, who recently passed away in early August. Described by IBM as “a pioneer in compiler organization and optimization algorithms,” she made numerous significant contributions to the field. Continue reading “Frances Allen Optimised Your Code Without You Even Knowing”

Don’t Let Endianness Flip You Around

Most of the processor architectures which we come into contact with today are little-endian systems, meaning that they store and address bytes in a least-significant byte (LSB) order. Unlike in the past, when big-endian architectures, including the Motorola 68000 and PowerPC, were more common, one can often just assume that all of the binary data one reads from files and via communication protocols are in little-endian order. This will often work fine.

The problem comes with for example image formats that use big-endian formatted integers, including TIFF and PNG. When dealing directly with protocols in so-called ‘network order’, one also deals with big-endian data. Trying to use these formats and protocol data verbatim on a little-endian system will obviously not work.

Fortunately, it is very easy to swap the endianness of any data which we handle. Continue reading “Don’t Let Endianness Flip You Around”

Busting GPS Exercise Data Out Of Its Garmin-controlled IoT Prison

If you take to the outdoors for your exercise, rather than walking the Sisyphusian stair machine, it’s nice to grab some GPS-packed electronics to quantify your workout. [Bunnie Huang] enjoys paddling the outrigger canoe through the Singapore Strait and recently figured out how to unpack and visualize GPS data from his own Garmin watch.

By now you’ve likely heard that Garmin’s systems were down due to a ransomware attack last Thursday, July 23rd. On the one hand, it’s a minor inconvenience to not be able to see your workout visualized because of the system outage. On the other hand, the services have a lot of your personal data: dates, locations, and biometrics like heart rate. [Bunnie] looked around to see if he could unpack the data stored on his Garmin watch without pledging his privacy to computers in the sky.

Obviously this isn’t [Bunnie’s] first rodeo, but in the end you don’t need to be a 1337 haxor to pull this one off. An Open Source program called GPSBabel lets you convert proprietary data formats from a hundred or so different GPS receivers into .GPX files that are then easy to work with. From there he whipped up less than 200 lines of Python to plot the GPS data on a map and display it as a webpage. The key libraries at work here are Folium which provides the pretty browsable map data, and Matplotlib to plot the data.

These IoT devices are by all accounts amazing, listening for satellite pings to show us how far and how fast we’ve gone on web-based interfaces that are sharable, searchable, and any number of other good things ending in “able”. But the flip side is that you may not be the only person seeing the data. Two years ago Strava exposed military locations because of an opt-out policy for public data sharing of exercise trackers. Now Garmin says they don’t have any indications that data was stolen in the ransomware attack, but it’s not a stretch to think there was a potential there for such a data breach. It’s nice to see there are Open Source options for those who want access to exercise analytics and visualizations without being required to first hand over the data.

Beyond Printf(): Better Logging Practices For Faster Debugging

All of us who do some programming know that logging is a time-tested way to output messages about the internal state of our code. With varying degrees of adjustable granularity, these messages allow us to keep track of not only the state of the application, but also its overall health. When things do end up going FUBAR, these log messages are usually the first thing we look at as a software equivalent of a Flight Data Recorder in an airplane.

Spending some time and care in not only designing the logging system, but also in deciding what should be logged and at what level, can make our future self appreciate life a lot more. We’re all familiar with the practice of ‘printf-debugging’, where logging is added as part of the usual post-crash autopsy as one tries to figure out what exactly went wrong. It’s one way of doing it, and eventually it works, but we can do much better.

People are lazy, and you’re only going to stick to good logging practices if they are at least as easy if not easier than sprinkling printf() statement throughout the code. Yet at the same time we want to be able to handle things like log levels and newlines without too much extra typing. The most successful logging libraries are built with this

Continue reading “Beyond Printf(): Better Logging Practices For Faster Debugging”

The rust language logo being branded onto a microcontroller housing

Will 2020 Be The Year Of Rust In The Linux Kernel?

One problem with modern programming languages is the reach their overly enthusiastic early adopters have nowadays thanks to the internet. As a result, everyone else’s first encounter with them are oftentimes some crude, fanboyish endeavors to rewrite every single established software project in that shiny new language — just because — which may leave an off-putting taste behind. However, Rust certainly seems to have outgrown this state by now, and with its rising popularity within the general developer population, it’s safe to say it will stick around. Will it fully replace C one day? Probably not, but there’s a big chance for coexistence, and [Nick Desaulniers] got the ball rolling for that within the Linux kernel.

Now, before you storm off pledging your allegiance to C by finding a new operating system: nothing is happening yet. [Nick] simply tested the waters for a possible future of Rust within the Linux kernel code base, which is something he’s planning to bring up for discussion in this year’s Linux Plumbers Conference — the annual kernel developer gathering. The interesting part is [Linus Torvalds]’s respone on the LKML thread, which leaves everyone hoping for a hearty signature Rust rant akin to his C++ one disappointed. Instead, his main concern is that a soft and optional introduction of the support in the build system would leave possible bugs hidden, and therefore should be automatically enabled if a Rust compiler is present — essentially implying that he seems otherwise on board.

We’ll see what comes of it, but with Rust language team lead [Josh Triplett] stating that enhancements benefiting and advancing a kernel integration are certainly imaginable for Rust itself, we might see interesting collaborations coming up in the near future. If you don’t want to wait for that and use Rust already today in a user-land driver, check out this 35c3 talk. And if that doesn’t go far enough for you, here’s a whole (non-Linux) kernel written in Rust.