The intention is, that if the user wishes the GUI version, they must download all 6 '.py' files (into the same, otherwise empty working folder). In that case, it's important Not to rename them in any way.

However, if only the console-window version is required, only the file 'double_hash_512.py' needs to be downloaded. Such a console is also referred to as a "Command Prompt" under Windows. If only this one file is needed, everything except the '.py' at the end may be renamed.

The way to download these files is, just to open them in the Web-browser, and then, to navigate the browser's command menu to 'File -> Save Page As (to disk)'.

Because these are all Python scripts, they can only be run on computers that have a Python 3 interpreter installed, and, the GUI version will require, that 'PyQt5' also be installed to Python (from elsewhere, by the user).

Execute permissions will need to be set for the Python files, on Linux systems with desktop managers, so that simply clicking on them will cause them to run.

The GUI version of the program is run, either as the file 'AppStart_mt.py' or as the file 'AppStart_mt2.py', which will recognize the other files in the folder by name. Why two launchers?

Both GUI launchers are multi-threaded, the main difference being, that 'AppStart_mt.py' uses the threading object built-in to Python, while 'AppStart_mt2.py' uses the 'QThread' object class, which is offered by PyQt5 specifically. 'AppStart_mt.py' will output warning messages to any command-console it may be run from. IMHO, those warning messages can safely be ignored. They arise because a worker thread is writing text, directly to the main, GUI thread's 'QLabel' widgets, which is technically not allowed. Yet I find, that the program works anyway.

OTOH, The fact that 'AppStart_mt2.py' uses the formal mechanism of communicating, between worker thread and main GUI thread, removes all messages that the program might dump to a terminal, warning or otherwise. The code that uses this formal mechanism is also more complex.


Also, the version 'AppStart_mt.py' will likely suffer from a minor resource leak. This is to be expected, because both versions need to establish one or more connections from signals in the worker thread, to slots in the GUI thread. In the version that uses Python threads and does not even run this thread from a different object, it's likely that the application framework also doesn't delete the signal-slot connection after the thread has exited. Thus, after many hash-codes have been computed, successively more RAM will be consumed.

In the version 'AppStart_mt2.py', the QThread exists as a separate object, and the application framework does everything Qt-related that should be done, including to delete the signal-slot connections, every time a QThread has exited.


Dirk Mittler