(I’ve decided to follow a more agile workflow: instead of creation a “one post covers the whole topic”-post, to post also updates for each step. Article will be therefore edited while “doing”)
Last week I’ve cleaned Qt-includes for a larger project. Like
#include how it should be. With proper indirection, so that the Qt-library handles how and where the class is implemented.
A colleauge raised the question, why not use
#include to be even more precise and to see the used module directly (needed for the CMakeLists or qmake).
First step: identify all used Qt-includes
$ git grep "include <Q" | cut -d : -f 2 | sort -u
# include <QApplication>
# include <QAtomicInt>
# include <QDebug>
# include <QFileDialog>
# include <QHBoxLayout>
Greps all includes starting with an uppercase Q; then split the result at the “:”; then sort und make it unique
Second step: create a replacement-list and a (python?) script which does this for all .h/.cpp-files
Problem was that I initialized some doubles with 0.0 and then hoped that the imported values are assigned, which does not happen always. So a check was needed. But checking
if(0.0 == x) is a really bad idea. MinGW will tell you too (as other compilers).
So I was searching for a proper way to check against 0.0. And then I found a better idea: initialize with NaN and use the standard-check against this. Much better!
// init them with NaN to prevent later issues
qDebug() << "uninitialized"; // todom remove
(addendum: I know, a variant would be the best to fix the given task.)
Three weeks ago, while being in the garden, I noticed that there is no network connectivity except by superslow EDGE. Of course, three walls block the Wifi-router, but what about one repeater which is closer and just shielded by one wall? Also I remembered having read about the usage of some ESP-nodes for that. I don’t like the approach of buying some closed-source-product.
Short research yielded the project from martin-ger on Github, which I wanted to use. I was surprised that nothing for the ESP32 is available (only for ESP8266). So I tracked down my single ESP8266 (LoLin, NodeMCU, not sure which revision, but with CH340G-USB-connect and as DevKit (mingling with pulldown-resitors would add another layer of complexity, which I am not sure I want to tackle).
Turns out I could not flash the given item properly with the ESP8266 Download Tool 3.65. It blinks while doing so, but follow-up seral-monitoring onyl yields “lolin ts Jan 8 2013,rst cause:2, boot mode:(3,6)”.
So I ordered a from a german shop a new ESP8266. Looks like exactly the same model.
Will do some quicktest now with the blink-app (basic functionality and flashing works?). And then do a test with the ESP Download tool.
More later ..