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.
If the user fullscreens, restricting to the 4:3 aspect ratio
doesn't make sense, so change the test for only the default/min.
Max is 4k since... who owns 8k monitors :D
macOS moves "dangerous" applications into a read-only [/private]
filesystem. This messes up with the updater and default P2Pool and
XMRig paths.
If [/private] is detected, show a panic screen upon Gupax startup
telling the user to move it to [/Applications]. This _seems_ to
make macOS relax a little (after an arbitrary amount of time...)
Includes some small fixes:
- [localhost] will always be changed to [127.0.0.1] in the case
of XMRig (it doesn't understand localhost by itself)
- P2Pool/XMRig API path now checks for a [/] or [\]
and correctly applies the endpoint, e.g:
BASEPATH = "/home/hinto/p2pool"
ENDPOINT = "local/stats"
if BASEPATH doesn't end with '/' { BASEPATH.push('/') }
API_PATH = BASEPATH + ENDPOINT ("/home/hinto/p2pool/local/stats")
- P2Pool payout line got changed in: be18ad4177
The regex is now a more generic: [payout of [0-9].[0-9]+ XMR]
If user clicked the [X] or [ALT+F4] while on the [ask_before_quit]
screen, it'll actually exit now.
The [save_before_quit] option actually... saves before quitting now.
No cloning since we're exiting and no [ErrorState] setting on errors.
The console logs will show if a save error happens.
Keyboard shortcuts [Left] & [Right] were clobbering the
[TextEdit] left/right movement, so they are now [Z/X].
The shortcuts also look to make sure a TextEdit isn't
in focus so that [S/R/Z/X] can actually be typed.
P2Pool/XMRig now make sure the path ends with an [ACCEPTABLE_*]
value (e.g: P2pool, P2POOL) before enabling the [Start] UI.
In XMRig Advanced the color/checkmark code was being given [self.name]
instead of [self.rig] which caused them to be linked, e.g: you clear
"Name" and [Rig] goes red instead.
(Stupid) Problem (caused by me):
--------------------------------
Up to 56million bytes of P2Pool/XMRig output were being held in memory
so they could be parsed. P2Pool output is the only one that needs
parsing as well, so double bad.
(Obvious) Solution:
-------------------
For XMRig:
Just don't write to an extra [String] buffer.
For P2Pool:
Parse the output, then... toss it out? You don't need the output
anymore after you parsed the values out, e.g: `Payouts`, `XMR Mined`.
Once they are parsed, add them to the current values instead of
completely overwriting them and then toss out the log buffer.
Now Gupax doesn't use stupid amounts of memory holding what is
essentially dead logs we already parsed. The parsing will be a lot
cheaper too since we aren't parsing the entire thing over and over
again (it was already pretty fast though).
Fixes:
- Up/Down only work if UI is enabled
- Re-pushed [P2POOL_API_PATH] to popped relative path
but only after giving the popped path to P2Pool
1. [/tmp/gupax/p2pool/p2pool] -> [/tmp/gupax/p2pool]
2. Give that to P2Pool
3. [/tmp/gupax/p2pool] -> [/tmp/gupax/p2pool/local/stats]
4. Give that to the watchdog (so it can read it)
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.
