The % dominance stats now update along with the manual hashrate.
The updating UI blocks were also moved so all the updating stats
are close to each other.
There's not much interesting data I could display that regular
Monero GUI or a block explorer can't do, so I'm scrapping the
[Monero] tab. Maybe it'll come back if I rewrite [Status] to include
graphs (never).
The [P2Pool] submenu is pretty much done, this changed the spacing
to make the logs larger and so all the elements fit correctly.
Instead of saving P2Pool payout logs as they are, they are now
(de)serialized in the same [Display] format, e.g:
<DATE> <TIME> | <12_DOT_FLOAT> XMR | Block <BLOCK>
2022-09-31 12:53:52.8683 | 0.166122683521 XMR | Block 2,713,512
The parsing functions were updated to be able to read both raw
log lines and the new above format.
Writing [a.lock().unwrap().b.lock().unwrap()] sucks, so these are
some macros that are for common situations. This commit also has
a [sed] replace on all previous code that _could_ have been a macro,
which they all are now.
Hopefully nothing breaks :D
Instead of a single "true" filename when walking dirs searching
for the newly downloaded (Gupax|P2Pool|XMRig), allow for multiple
valid names as long as they _seem_ correct AND are files, e.g:
GUPAX|Gupax|gupax (.exe)
P2POOL|P2Pool|P2pool|p2pool (.exe)
XMRIG|XMRig|Xmrig|xmrig (.exe)
If the packaging naming schemes change for any of these,
the update code will be able to actually handle it.
These couldn't be fit in before since there wasn't enough space.
They still can't all fit in, but the most important ones can be
after adjusting the font sizes and height spacing.
There was a deadlock happening between the [Helper]'s [gui_api_p2pool]
and the GUI's [gui_api_p2pool], since the locking order was different.
The watchdog loop locking order was fixed as well. This was a pain to
track down, better than a data race... I guess.
Oh and keyboard shortcuts were added in this commit too.
Comment from code:
// The ordering of these locks is _very_ important. They MUST be in sync
// with how the main GUI thread locks stuff or a deadlock will occur
// given enough time. They will eventually both want to lock the [Arc<Mutex>]
// the other thread is already locking. Yes, I figured this out the hard way,
// hence the vast amount of debug!() messages.
//
// Example of different order (BAD!):
//
// GUI Main -> locks [p2pool] first
// Helper -> locks [gui_api_p2pool] first
// GUI Status Tab -> trys to lock [gui_api_p2pool] -> CAN'T
// Helper -> trys to lock [p2pool] -> CAN'T
//
// These two threads are now in a deadlock because both
// are trying to access locks the other one already has.
//
// The locking order here must be in the same chronological
// order as the main GUI thread (top to bottom).
The entire codebase is now littered with [debug!()] messages.
Thankfully [log] has 0 cost if you aren't using them, so regular
users won't have a runtime penalty unless they specify RUST_LOG=debug.
