User Details
- User Since
- Sep 27 2017, 23:53 (376 w, 6 d)
May 20 2019
May 6 2019
May 5 2019
May 4 2019
Apr 25 2019
Apr 23 2019
Apr 16 2019
Sep 27 2018
May 1 2018
Apr 30 2018
- logging: Remove use of ARRAYLEN from utilstrencodings.
- logging: Change boost::mutex to std::mutex.
Rebased.
Apr 27 2018
Rebased onto master.
Apr 20 2018
Rebased onto master.
@jasonbcox @schancel I completely agree on not using Hungarian notation for new code, but changing these variable names would increase the diff size. If you want, I would prefer to rename all of the variables in a future diff that just does the renaming.
Remove unused <memory> include.
Apr 19 2018
Apr 18 2018
Apr 17 2018
Rebased.
Rebased.
Rebased.
Switched back to GetLogger function.
This does not enforce that if push_size is set that the next value is raw data. For example, the test case "PUSHDATA2 PUSHDATA1" would pass, I think.
Rebased.
Change g_logger to a *const instead of function with mutex.
Apr 16 2018
Apr 14 2018
Rebased.
Rebased.
Update member variable comment for fStartedNewLine.
Replaced std::unique_ptr to global logger with a thread-safe GetLogger method as discussed in chat.
Apr 13 2018
The thread safety is tricky.
Apr 12 2018
Adding logging.cpp to CMakeLists.txt.
Use global LogPrintf in util.h instead of Logger method.
Fix copyright notices and extraneous change to util.h.
Added braces around an if statement.
Yes, this diff does a lot at once, however each commit is fairly well scoped. It is much easier to review commit by commit, which I now realize is not that easy with Phabricator. The commits actually do take the approach you are describing of moving the same implementation behind a new interface, and only afterwards changing behavior. Is the recommended approach to break each commit into a separate diff?
Apr 11 2018
Apr 10 2018
I have a pull request open on Bitcoin Core that creates a precedent for parallel indexing: https://github.com/bitcoin/bitcoin/pull/11857. I would really like to see any new indexes created with a similar pattern, driven off of ValidationInterface instead of inline in the validation code.
CBlockIndex entries already have an nSequenceId, which may serve the same purpose. It not persisted, however, and set to 0 for all blocks on disk and incremented for each block received while the process is running.
Can you explain this further? Do you just renaming variables and methods with txid or txhash in the name?