Learn Quantum Computing With Spaced Repetition

Everyone learns differently, but cognitive research shows that you tend to remember things better if you use spaced repetition. That is, you learn something, then after a period, you are tested. If you still remember, you get tested again later with a longer interval between tests. If you get it wrong, you get tested earlier. That’s the idea behind [Andy Matuschak ‘s]and [Michael Nielsen’s] quantum computing tutorial. You answer questions embedded in the text. You answer to yourself, so there’s no scoring. However, once you click to reveal the answer, you report if you got the answer correct or not, and the system schedules you for retest based on your report.

Does it work? We don’t know, but we have heard that spaced repetition is good for learning languages, among other things. We suspect that like most learning methods, it works better for some people than others.

Continue reading “Learn Quantum Computing With Spaced Repetition”

Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?

Software developers won’t ever run out of subjects to argue and fight about. Some of them can be fundamental to a project — like choice of language or the programming paradigm to begin with. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale — like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise.

Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration — and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit.

The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life.

In case of the Linux kernel, that’s of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.

[Linus]’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.

Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn’t call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?

Continue reading “Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?”

Samsung’s Leap Month Bug Teaches Not To Skimp On Testing

Date and time handling is hard, that’s an ugly truth about software development we’ll all learn the hard way one day. Sure, it might seem like some trivial everyday thing that you can easily implement yourself without relying on a third-party library. I mean, it’s basically just adding seconds on top of one another, roll them over to minutes, and from there keep rolling to hours, days, months, up until you hit the years. Throw in the occasional extra day every fourth February, and you’re good to go, right?

Well, obviously not. Assuming you thought about leap years in the first place — which sadly isn’t a given — there are a few exceptions that for instance cause the years 1900 and 2100 to be regular years, while the year 2000 was still a leap year. And then there’s leap seconds, which occur irregularly. But there are still more gotchas lying in wait. Case in point: back in May, a faulty lunar leap month handling in the Chinese calendar turned Samsung phones all over China into bricks. And while you may not plan to ever add support for non-Gregorian calendars to your own project, it’s just one more example of unanticipated peculiarities gone wild. Except, Samsung did everything right here.

So what happened?

Continue reading “Samsung’s Leap Month Bug Teaches Not To Skimp On Testing”

Programming In Plain English

Star Trek had really smart computers, that you could simply tell what you wanted to do and they did it. The [Rzeppa] family has started a plain English compiler. It runs under Windows and appears to be fairly capable.

Plain language programming isn’t exactly a new idea. COBOL was supposed to mimic natural language with statements like:

MULTIPLY HOURS BY RATE GIVING PAYAMOUNT

You could argue this didn’t go over very well, but there is still a whole lot of COBOL doing a whole lot of things in the business world. Today computers have more memory and speed, so programmers have been getting more and more verbose for decades. No more variable names such as X1 and fprdx. Maybe this will catch on.

Continue reading “Programming In Plain English”

Adding WiFi To Black Magic For Wireless GDB Action

[Thoquz] wrote to us about an interesting GitHub project by [Valmantas Palikša] involving the porting of the Black Magic firmware to ESP8266. For those who are unaware, Black Magic Probe is firmware along with a range of official and third-party boards that targets the debugging of Cortex-M and Cortex-A MCUs and SoCs.

With this blackmagic-espidf project, one can use any ESP8266 board that has at least 2 MB of Flash program storage, though 1 MB should be possible if OTA updated are disabled. After flashing the firmware to the ESP8266 board, the GDB server can be reached on TCP port 2022 and UDP 2023, with a serial port available via TCP/23, UDP2323, or via the physical TX0/RX0 pins on the ESP8266.

The target board to be debugged  is hooked up by default to GPIO0 (SWDIO) and GPIO2 (SWCLK) for Serial Wire Debugging, though JTAG is also said to be supported. If set up properly, next one should be able to pop into a fresh remote GDB session:

gdb connection

If you don’t want the WiFi, you can buy a wired one, or just roll your own from any STM32 board that you’ve got kicking around.

Peeking Inside Executables And Libraries To Make Debugging Easier

At first glance, both the executables that a compiler produces, and the libraries that are used during the building process seem like they’re not very accessible. They are these black boxes that make an application go, or make the linker happy when you hand it the ‘right’ library file. There is also a lot to be said for not digging too deeply into either, as normally things will Just Work™ without having to bother with such additional details.

The thing is that both executables and libraries contain a lot of information that normally is just used by the OS, toolchain, debuggers and similar tools. Whether these files are in Windows PE format, old-school Linux a.out or modern-day .elf, when things go south during development, sometimes one has to break out the right tools to inspect them in order to make sense of what is happening.

This article will focus primarily on the Linux platform, though most of it also applies to BSD and MacOS, and to some extent Windows.

Continue reading “Peeking Inside Executables And Libraries To Make Debugging Easier”

Simple Sprite Routines Ease Handheld Gaming DIY

Making your own handheld games is made much easier with [David Johnson-Davies’] simple sprite routines for the Adafruit PyBadge and PyGamer boards. Sprites can be thought of as small, fixed-size graphical objects that are drawn, erased, moved, and checked for collision with other screen elements.

xorSprite() plots an 8×8 sprite, moveSprite() moves a given sprite by one pixel without any flicker, and hitSprite() checks a sprite for collision with any screen elements in a given color. That is all it takes to implement a simple game, and [David] makes them easy to use, even providing a demo program in the form of the rolling ball maze shown here.

These routines work out-of-the-box with the PyBadge and PyGamer, but should be easy to adapt to any TFT display based on the ST7735 controller. The PyGamer is the board shown here, but you can see the PyBadge as it was used to create an MQTT-enabled conference badge.

If you really want to take a trip down the rabbit hole of sprite-based gaming graphics, you simply can’t miss hearing about the system [Sprite_TM] built into the FPGA Game Boy badge.