Rework debug logging #125
Rework debug logging #125
Conversation
compatibility - i.e. there is no immediate need to change all 'printf' statements.
|
My first reaction: this violates the KISS principle. |
|
I forgot to write my motivation for the patch. I wrote it because I got tired of having to sift through hundreds of "IRC got xxx" messages while I was trying to debug some other changes I was making. Plus I was concerned about the size of the debug.log file - after running for only 12 hours, the file was hundreds of megabytes. The file only gets truncated on startup, and then only if you specify the -debug flag - which increases the log activity. I haven't looked at boost::log, but how easy is it to incorporate into the existing code? One of the big advantages (IMO) of this patch is the fact that it fits into the existing code, which makes it less of a pain to migrate to the new logging system. |
|
This seems to match logging systems from other complex software projects. The sheer number of messages in a complex system begs for something like what jhyslop has submitted. BIND uses logging channels, giving you the ability to mask-in and mask-out certain types of messages. syslog has LOG_{ERR, WARNING, INFO, DEBUG}. Linux kernel network drivers have a facility (NETIF_MSG_xxx) which permits enabling or disabling of high volume per-packet messages, enabling or disabling of PHY-related messages ("link up!", "link down!"), enabling or disabling of driver probe detail messages, etc. I think it would be useful to selectively enable or disable (a) bitcoin's per-packet logging, (b) P2P logging in general, (c) RPC logging in general. |
…allowed This feature was intended to allow high priority txns to always propagate however there are issues with this as highlighted in issue bitcoin#125 1) This feature is a magic number which is not a good idea to begin with 2) txns that have been floating around without getting mined for long periods of time end up rising in priority and avoiding getting rate limited which the consequence that our mempools are filling up much faster with un-mineable txns. 3) This value can and does override the minlimitertxfee value at times which makes it confusing for users who see that the minlimitertxfee is not being honoured.
Staking various issues bitcoin#125 fix
Refactoring & test covering deterministic bitcoin commitments
…lator comments 8b77133 qt: Replace disambiguation strings with translator comments (Hennadii Stepanov) Pull request description: Since #21694 is merged, translator comments is the right way to pass context to translators. This PR fixes changes were made: - in #220 before #21694 - in #21694 on testing purpose - in #125 Closes #288. ACKs for top commit: jarolrod: ACK 8b77133 Tree-SHA512: 466ade35f4969a41fbf3196780b1ae9fa810bab5d2f09077f8631604636cc63b24a901c719f6b5797366d2aa307993d0aa419ce35200c8d0a741a3d81cad3e6b
CH3 - Typos and grammar
3 participants
Added new function, OutputLogMessageF, which contains most of the functionality of OutputDebugStringF.
OutputLogMessageF has two additional parameters over OutputDebugStringF: an enum indicating the context of the message, and an enum indicating the verbosity level.
The existing OutputDebugStringF forwards itself to OutputLogMessageF, passing enum values indicating a log context "Legacy", and verbosity "Debug".
Additional functions have been added to support the feature. These functions:
Several of the calls to OutputDebugStringF in main.cpp (which are hidden by the macro 'printf') have been changed to use OutputLogMessageF, to demonstrate how the new logging system works. I have not changed all occurrences (there are still 90 occurrences in main.cpp, and I haven't even touched most of the other files).
The change has been designed in such a way that migration to the OutputLogMessageF can take place as developers work on various sections of the code. The existing 'printf' calls still work, and can be viewed by using the command line options -loglevel=debug -logcontexts=legacy.