< GitHub73>
[bitcoin] sipa opened pull request #8123: Use std::atomic for fRequestShutdown and fReopenDebugLog (master...notsigbutatomic) https://github.com/bitcoin/bitcoin/pull/8123
< GitHub196>
bitcoin/master fa2637a Pieter Wuille: Always require OS randomness when generating secret keys
< GitHub196>
bitcoin/master 628cf14 Pieter Wuille: Don't use assert for catching randomness failures
< GitHub196>
bitcoin/master 950be19 Pieter Wuille: Merge #7891: Always require OS randomness when generating secret keys...
< GitHub132>
[bitcoin] sipa closed pull request #7891: Always require OS randomness when generating secret keys (master...betterrng) https://github.com/bitcoin/bitcoin/pull/7891
< gmaxwell>
\O/ (randomness)
< GitHub170>
[bitcoin] sipa opened pull request #8126: std::shared_ptr based CTransaction storage in mempool (master...sharedmempool) https://github.com/bitcoin/bitcoin/pull/8126
< gmaxwell>
\O/
< luke-jr>
O.o
< sipa>
^^
< sipa>
gmaxwell: it also conflicts with a few of your PRs, but it should simplify them
< gmaxwell>
I don't mind.
< btcdrak>
a rebase is a small price to pay for randomness
< btcdrak>
the new currency shall be called rebases.
< gmaxwell>
sipa: Is CTxMempool::CompareDepthAndScore dead code after the change that puts int in the Comparitor directly?
< luke-jr>
might be useful to have a typedef though?
< gmaxwell>
btcdrak: Sipa and I were commenting there about the shared_ptr change.
< luke-jr>
CTransactionRef or something?
< gmaxwell>
I kinda like knowing that its a shared_ptr, but... nevermind my taste.
< luke-jr>
I don't feel strongly about this, was mainly thinking if we ever had to go back to pre-C++11 for some reason
< luke-jr>
which seems unlikely
< sipa>
luke-jr: sounds fine... std::shared_ptr<const Ctransaction> is a bit awkward to type
< sipa>
on the aother hand... auto works well :)
< sipa>
gmaxwell: no, still used from the heapifier in message handling
< luke-jr>
'auto' certainly tells even less that it is a shared_ptr :P
< luke-jr>
so if the long type is going to encourage using auto everywhere, perhaps gmaxwell's goal is actually better suited by a typedef as well
< gmaxwell>
I think I'm going to have to give up on editing this code using an editor that can't go and read faraway prototypes. Auto for return types is pretty useful, but it currently results in me grepping to go find out what the type actually is.
< * sipa>
abandons his rewrite to increase usage of auto
< gmaxwell>
I hope not. Don't change what you're doing because of my very C-like preferences.
< sipa>
it's a valid argument
< gmaxwell>
I think it is best when the return type is obvious. E.g. functions that give you an iterator.
< sipa>
we could of course go back to strict hungarian notation :D
< * luke-jr>
understood that as abandoning "a PR intentionally doing nothing but changing stuff to 'auto' where possible"
< sipa>
luke-jr: oh, no, i mean improving my current shared_ptr PR
< luke-jr>
oh, ok
< gmaxwell>
sipa: is there something we can do at shutdown to tell if all the txn have been freed? even in just some debugging build?
< sipa>
gmaxwell: how could they not?
< luke-jr>
CTx constructor could increment a global, and destructor decrement it?
< sipa>
luke-jr: yup
< sipa>
an atomic global :)
< sipa>
and on every decrement, print to stderr
< gmaxwell>
in the current code, they couldn't AFAICT. But if we leaked some object with a shared ptr we'd leak the transaction. It's generally pretty hard to leak shared_ptr... but seems prudent to check for.
< gmaxwell>
Yea, that would work.
< sipa>
also: the glibc implementation of std::shared_ptr is not readable
< gmaxwell>
BlueMatt: thoughts on #8126 ? would you like to rebase compactblocks on that?
< sipa>
with --patience i get much more readable diffs often
< BlueMatt>
gmaxwell: I probably will after its merged, sure
< btcdrak>
BlueMatt: could you say so on the ticket so people arent waiting for it?
< BlueMatt>
btcdrak: who's waiting for what?
< sipa>
it shouldn't interfere with review of compact blocks otherwise
< sipa>
just the refcounting in the mempool can go away
< gmaxwell>
BlueMatt: you might want to review sipa's patch (or try the rebase) to make sure it won't get in your way.
< sipa>
i'll do the rebase for you, if it helps things forward
< gmaxwell>
sipa: might be a good review excercise even if matt doesn't want to use the result.
< gmaxwell>
Opinion piece against most uses of unit tests that I think makes some nice points: http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf (the biggest exceptions he makes are cases where there is a clear formal defintion of correctness that can be tested against for the function, and also when the tests are realistically able to completely test the function; otherwise he favors system
< gmaxwell>
tests and gives arguments from a number of angles).