< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14552: wallet: throw an error if user load the wallet file by different ways (master...default-wallet-fix) https://github.com/bitcoin/bitcoin/pull/14552
< josephnicholas_>
Hello all
< bitcoin-git>
[bitcoin] merland opened pull request #14553: Fix wrong unit on hourly progress increase (master...progress-increase-per-h) https://github.com/bitcoin/bitcoin/pull/14553
< stevenroose>
Anyone here any experience with the Travis tests? We copied them for Elements and the one with NOWALLET=1 times out consistently. Could anyone tell what the NOWALLET=1 exactly involves?
< jamesob>
when's the last time someone proposed a "trace"-level logger that wouldn't ever be enabled for production, but might be useful during testing/debugging
< BlueMatt>
jamesob: isnt that kinda what -debug=1 means?
< BlueMatt>
I mean it prints all your inbound/outbound messages...
< jamesob>
yeah, suppose so - but we're missing a lot of logging around tx validation and peer treatment
< BlueMatt>
fair enough, probably worth adding? Could add another debug category if its too voluminous
< jamesob>
yup, sounds good
< phantomcircuit>
jamesob, there could certainly be many more log lines
< phantomcircuit>
but not that even when you're not logging things the LogPrint function takes some time
< sipa>
phantomcircuit: note that LogPrintf doesn't serialize its arguments when the debug category it's on is not enabled
< sipa>
but the argument are evaluated
< wumpus>
there's intentionally little/no debug logging around transaction validation, it would just be too spammy and confusing for users as it'd log for every transaction received from the network
< wumpus>
but yes I guess it'd work as a separate category…
< phantomcircuit>
sipa, yeah it's very fast, but putting it in a tight loop would be a mistake
< gmaxwell>
Anyone attempting that should be prepared to prove the change doesn't substantially lower performance when not in use.
< phantomcircuit>
i wonder if checking for the category TRACE and then exiting unless compile time option was set would allow optimization out completely
< sipa>
phantomcircuit: yeah certainly
< jamesob>
phantomcircuit: that's what I had in mind
< jamesob>
TraceLogPrintf as a macro that gets expanded or not based on configure options
< sipa>
jamesob: we kindof have that, due to the templated approach that forwards the arguments
< sipa>
though it would require inlining the function to guarantee the arguments aren't evaluated when needed
< luke-jr>
#define LogTrace(…) if (unlikely(g_trace)) { LogPrintf(__VA_ARGS__); }
< luke-jr>
maybe
< sipa>
that has the risk of removing statements with side effects, though
< sipa>
marking LogPrintf as __attribute__((always_inline)) where permitted is probably safer
< sipa>
(or whatever the syntax is)
< luke-jr>
sipa: hopefully nobody would use these new things with side-effect stuff.. especially if it's disabled by default
< luke-jr>
would always_inline actually avoid evaluating the arguments?
< sipa>
sometimes, sure
< sipa>
it'd enable the compiler to optimize it out when it provably has no side effectd
< luke-jr>
proving no side effects can be hard for C++
< luke-jr>
eg, a copy constructor might have side effects
< luke-jr>
but maybe the variadic argument situation is better, dunno
< sipa>
luke-jr: a c++ compiler is allowed to elide copy constructors even if they have side effects :)