New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metrics screen improvements #1735
Conversation
Assigning to 1.0.1 because several of the issues this closes are resulting in user confusion, which we should resolve sooner than later. |
@@ -287,6 +289,7 @@ class CRegTestParams : public CTestNetParams { | |||
public: | |||
CRegTestParams() { | |||
strNetworkID = "regtest"; | |||
strCurrencyUnits = "REG"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just picked this as a placeholder; it will probably never actually be used.
mature += subsidy; | ||
} | ||
} else { | ||
it = u->erase(it); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implicit assumption here is that if a block hash disappears either from mapBlockIndex
(should only happen on restart, so never relevant here) or chainActive
(happens on reorgs), it will never re-appear. I think this is a fair assumption for reorgs, inasmuch as it is far less likely that a second reorg would occur that re-includes a block after the local node has already observed one that orphans it. But if we want to remove that assumption, I can just build two parallel lists (one for tracked blocks, one for tracked orphans) and shuttle block hashes between them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Check whether iterator should be incremented before calling erase. http://stackoverflow.com/questions/596162/can-you-remove-elements-from-a-stdlist-while-iterating-through-it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the specification for std::list::erase
, this is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
http://en.cppreference.com/w/cpp/language/for
The iterator is incremented at end of the for loop, will that be an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes you're right. Switching to a while loop and manually iterating in the non-erasing branch will fix this.
Beautiful! |
boost::synchronized_value<std::list<std::string>> messageBox; | ||
boost::synchronized_value<std::string> initMessage; | ||
bool loaded = false; | ||
|
||
void TrackMinedBlock(uint256 hash) | ||
{ | ||
minedBlocks.increment(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make method synchronized for both of these operations.
@@ -121,8 +131,43 @@ int printMetrics(size_t cols, int64_t nStart, bool mining) | |||
|
|||
int mined = minedBlocks.get(); | |||
if (mined > 0) { | |||
LOCK(cs_main); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LOCK2...
Yep, that's an artifact of the way the UI is handled (plain console escape codes). I manually move the cursor up the right number of lines and only reprint the info that is refreshed, which means that spurious newlines cause changes like that. The fix would be to either print out the entire console view each time, or use a proper ncurses library. I'm leaning towards the latter, which should hopefully also improve cross-platform support. |
The counters could end up negative when they overflow.
How about using uint64_t ? |
|
Test failures are unrelated to this PR:
@bitcartel this feels like the weird gtest ordering bug again. |
Moved @zkbot r+ |
|
|
Fix the whitespace:
|
I really dislike the fact that whitespace issues in build scripts can break tests. I just built this and ran @zkbot r+ |
|
If you delete zcash-gtest and make it again, it will fail again (at least that is what I am seeing). After I moveed test_checkblock to the end of the list of tests did it stop crashing. |
|
The latent slave is still up, @str4d's recommendation was to wait for it. |
|
@zkbot retry |
|
Closes #1656, #1685, #1688 and #1716