The share of python3-uncompliant drivers has dropped to such a small
fraction that I've forgotten to enforce that new drivers be added to
the matrix.
So, at this point, it's time to flip the whitelist to a blacklist and
just mark the drivers that haven't been tested. This removes the
matrix and generation script, content from the makesupported target,
and instructions from the PR template. It replaces those with a simple
list of drivers in tests/py3-untested-drivers.txt
This is really kinda meh in terms of usefulness but getting these
squared away (or ignored) allows us to run the rest of mypy on the
drivers for the other benefits we might be able to actually see.
This adds a tool (more like a demonstration) that allows for running
the radio through the tuning process for an expert linear. It makes
the radio jump through the published band center frequencies in RTTY
mode and also supports automatic CW ID at the end of each step in
the cycle.
This makes us grab the "percent in common" stat for the new file being
added instead of just looking at the "percent changed" for the old one.
The latter ignores what may be a large amount of things considered to
be deleted, making the change amount look larger.
The style checker currently always applies new rules to files on the
argument list. This makes it use the same logic for those as "all
files" mode. Also fix some style issues in tools/ scripts.
bitdiff.py is from before we had GUI developer tools, and is not py3
compliant anyway.
img2thd72.py is no longer useful now that the thd72 driver can open
those files directly, and is not py3 compliant anyway.
elib_intl.py is something to do with internationalization on win32
(it seems). Not sure if/when we ever used that, but we don't anymore
and thus it is removed.
This makes cpep8 run flake8 on anything *not* in the manifest or
*not* in the blacklist. Thus, all new files will get flake8 run against
them by default. It adds a bunch of files to the blacklist that were
not in manifest and thus still aren't compliant. Those need to get
cleaned up, obviously.
No new files should be added to cpep8.manifest going forward so that
the stricter flake8 rules get applied by default. Ideally we'd also
remove files from cpep8.manifest as well so we can move to just one
set of rules for everything, but that will take a while.
Long ago, an anti-pattern was introduced by a driver whereby the prompt
string were marked for translation, but wrapped around a call to
dedent() for formatting. In order for gettext to pick up the strings
when building the catalog, the actual literals must be marked. Even
though the gettext call works at runtime, the static analysis does not
understand enough python to push through that call.
This is the first step of re-writing all those instances to avoid
using dedent() and instead use multiple string lines inside the gettext
call. This was done en masse, so it's possible that some of this is
not right, but it's a good start and much more reasonable than doing
it manually in so many places.
This also includes a dumb rule in check_commit.sh to help prevent
future introduction of this, although it won't catch all cases.
Related to #10434
The Q-MAC HF-90 radio was in production during the 1990's and 2000's.
In 2009, Q-MAC Electronics was acquired by Barrett Communications and
Barrett was acquired by Motorola Solutions in 2022.
Several models were produced: HF-90A (Australia), HF-90E (export),
HF-90H (frequency hopping) and HF-90M (military). The aim of this driver
is to support HF-90A and HF-90E as that's the hardware I have available.
Most likely this driver is also compatible with HF-90H.
There were numerous firmware changes over the years and some radios
can't be programmed with the latest PC software from Q-MAC. Here's the
warning from Qmac.exe v3.0.4 (from 2004):
This programming software is for use on radios with Export Version
firmware (HF-90E or HF-90H) and firmware version 301 or greater.
Earlier firmware versions will be corrupted if programmed using this
software and will render the HF-90 inoperable.
Consequently, this driver comes in two flavours: "v300 or earlier" which
imitates the older v2 dealer software for use with early firmware, and
"v301 or later" which imitates the more recent v3 dealer software and
is not for use with early firmware.
Perhaps technical documentation will come to light that would explain
the quirks of the various firmware revisions. If that should happen,
the v300/v301 scheme could be improved upon. For now, it's the best
I can do.
Fixes: #10428
