If you have been writing C++ classes for mocking out your C or C++ dependencies, you know how tedious it is. I generally write small classes with just a handful of methods, so it's generally bearable, but when using third-party code I'm usually not that lucky. If the dependency is a C library this becomes especially tricky, both because they might be larger than what you can handle, and both because the lack of an object-oriented design might not offer you an easy solution to store the mock object data.
Before you get angry at me for this title, please let me state that I count myself in the number of the “idiots” and, secondly, that what I mean by “idiotism” here is not to be intended as an offence, but as some traits of mindset which are typical of very logical brains.
Lets say you want to debug a python process that is either already running or crashing in native code. Pythons PDB is of no help here and you will have to use low-level GDB debugger. Fortunately, it comes with support for debugging high level python scripts.
However, while the actual python-gdb commands are nicely described here, that page lacks important details on how to get python-gdb in the first place. We are merely told that a python-gdb.py is needed.
On Ubuntu/ Debian, this file is included in the python3-dbg package:
sudo apt install python3.10-dbgInstalling that is sufficient, if you use the matching python3 package. You can go ahead and connect to some running python process via:
gdb -p <PID>
# verify that the script is loaded
(gdb) info auto-load
# get a python backtrace
(gdb) py-bt
Traceback (most recent call first):
File "/usr/lib/python3.10/selectors.py", line 416, in select
fd_event_list = self._selector.poll(timeout)
File "/usr/lib/python3.10/socketserver.py", line 232, in serve_forever
...In case Ubuntu is merely a host and you use coda, you can still use the host python-gdb.py – even if the python versions dont match. You will have to load the script manually though like:
(gdb) source /usr/share/gdb/auto-load/usr/bin/python3.10-gdb.py
GNOME Open Desktop Ratings is the service that enables user ratings in various Linux app stores like the Snap-Store, Gnome Software and KDE Discover.
While it nowadays works for users by providing a mostly useful star rating, from a application developer perspective the story is very grim.
Basically one only gets the users view, which provides an average rating and some reviews in the current locale.
This means you might see something like “2 Stars from 80 Reviews” – but the 3 reviews in your current locale are all 4-5 Star.
To see something else you have to change the locale and restart the app store – which is inconvenient and confusing.
As a developer, seeing the negative reviews is crucial, as people often just post bug reports there and this is the only way to find out why the app did not work for them.
Therefore I quickly hacked together a web-based browser for the ODRS service, skillfully named
ODRS BrowserThis allows accessing the ODRS service from the web and shows the reviews from multiple locales at once. The idea here is that often people write reviews in english – regardless of their current locale. Currently, ODRS has no logic to detect that.
Also, if your app is packaged in different formats like snap and flatpack and deb, you can see the reviews of all variants in the overview.
Unfortunately, ODRS currently does not set the CORS header which prevents browsers from accessing it directly. The data that you see right now was scraped with python script. But once this issue is fixed, the ODRS Browser will be able to use live data.
In this post I want to take a look at the Logitech M720 mouse after having used it for 2.5 years.