< Randolf>
booyah: Boost is a horrible library. Its updates sometimes break backward compatibility.
< Randolf>
booyah: I don't know what the specific reasons are for removing it from the Bitcoin project, but due to the various problems I've had with it conflicting with itself in the past, I'm glad it's on the way out.
< Randolf>
I had packages on NetBSD, for instance, that each required different versions of Boost. At first I thought "okay, no problem, I'll just use the most recent version." That, of course, failed. And I couldn't run multiple versions on the same system.
< Randolf>
Eventually I either had to find different versions of the library to use, or chroot/jail the few packages that needed different versions of Boost, or set them up on separate machines.
< Randolf>
Sorry, I meant to write this...
< Randolf>
Eventually I either had to find different (alternative) packages to use that don't rely on Boost, or chroot/jail the few packages that needed different versions of Boost, or set them up on separate machines.
< Randolf>
It really wasn't a fun problem at all.
< Randolf>
So, that's why I'm glad Boost is on its way out -- so that I won't have those problems with Bitcoin in the future.
< wumpus>
so I got word back from github "We're currently investigating similar reports regarding this issue, and I've added your report to our list." "If you need to merge that pull request soon, we recommend using git merge locally on the command line as a workaround. We apologize for any inconvenience, and thank you for your patience."
< fanquake>
wumpus annoying
< wumpus>
yes. it's disappointing. I'm not sure I want to merge it *because* I want to look at the discussion, that's why we use github in the first place.
< jonasschnelli>
"If you need to merge that pull request soon, we recommend using git merge locally [...]" ... :{
< wumpus>
jonasschnelli: right, as if that's the problem in the first place. I wonder if we have the messages as json from the API so we can at least look at the tread
< jonasschnelli>
wumpus: reminds me of a project I'd like to do since years. A custom webinterface that allows better interaction with github. Mark pulls, highlight comments that are relevant to you after some rules.
< jonasschnelli>
They should mirror the comment history
< wumpus>
so from what I understand, reading the comments in raw json format, is that 10267 should be ready for merge
< wumpus>
the comment history is in that bitcoin-gh-meta already - just need a better way to format it in the terminal than reading very long lines scrolling horizontally
< fanquake>
yea bitcoinacks has been improving quite a lot over the past week or two
< aj>
kallewoof: i guess your tweet implies i should see about making the other ~90 days of tx data i've got available somewhere
< jonasschnelli>
hmm.. my testnet seeder runs into 99% cpu usage due to the seeder (kswapd0 runs at 99% usage).
< kallewoof>
aj: I actually haven't finished the import feature for your data, but I definitely intend to, so that would be graet, yes.
< jonasschnelli>
A restart of the dnsseed seems to solve the issue...
< jonasschnelli>
leaks?
< jonasschnelli>
seems to only happens to my testnet seed (not mainnet)
< wumpus>
jonasschnelli: sounds like a memory leak, or just excessive memory use, if it's the swap that is hit
< wumpus>
might want to try to run valgrind/memcheck on it
< jonasschnelli>
wumpus: yes. I should probably do that...
< kallewoof>
aj: From what it looks, btw, your data will work perfectly well for replaying the mempool. I just have to time the block median times with your timestamps to get things approximately in order. (I guess I'll find out just how off median time is from reality soon enough).
< aj>
kallewoof: ? i've got the timestamps i received blocks in there too, that should make it easy shouldn't it?
< kallewoof>
aj: You do? I didn't realize that
< kallewoof>
aj: That definitely makes it easy, yes.
< aj>
kallewoof: hashtx, rawtx, and hashblock entries
< kallewoof>
ahh. I never saw the hashblock ones
< aj>
kallewoof: there aren't many of them by comparison :)
< aj>
kallewoof: okay, looks like it's not going to be much effort to upload it to google drive at least for the time being
< aj>
huh, shouldn't even take more than a night or so. may have to stop being snarky about my isp at this rate
< bitcoin-git>
[bitcoin] promag opened pull request #13189: Remove 2nd mapTx lookup in CTxMemPool::removeForBlock (master...2018-05-txmempool-removeforblock) https://github.com/bitcoin/bitcoin/pull/13189
< morcos>
promag: it took me a while to try to track it down, but actually the commit message explains it. we only track certain transactions for fee estimation (most obviously, only trancsactions with no unconfirmed parents). When we see a tx in a blcok we test whether it is in the fee estimators mapmempooltxs
< morcos>
If it is, its a transaction we were tracking and we should update the fee estimates.
< morcos>
However when txs are removed from the mempool, they are removed from fee estimators map as well, so that has to happen after we've used that information to determine whether the tx was a valid one for fee estimation
< promag>
morcos: ty. a
< promag>
afaiu CBlockPolicyEstimator doesn't use the mempool
< promag>
or it's because of CTxMemPoolEntry state is changed?
< promag>
morcos: anyhow please see if #13189 looks ok
< morcos>
no, the removeUnchecked in the mempool causes removeTx to get called
< bitcoin-git>
[bitcoin] sipa opened pull request #13191: Specialized double-SHA256 with 64 byte inputs with SSE4.1 and AVX2 (master...201709_dsha256_64) https://github.com/bitcoin/bitcoin/pull/13191
< wumpus>
jnewbery: can you view #10267? most of use are getting unicorns there :/
< gribble>
https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
< wumpus>
I reported it to github and they said multiple people had reported that and they were going to look at it, but I sitll have the problem
< sipa>
also a unicorn here
< wumpus>
I'll re-review locally
< promag>
another unicorn in #10267
< gribble>
https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
< promag>
kallewoof: should ArgsManager::ReadConfigStream warn about more -includeconf it's not the root conf?
< promag>
I mean, it's not recursive
< promag>
can be improved in a new PR though
< promag>
I suggest something like "warning: -includeconf cannot be used from included files; ignoring -includeconf=%s"
< bitcoin-git>
[bitcoin] lmanners opened pull request #13192: [tests] Fixed intermittent failure in p2p_sendheaders.py. (master...p2p_sendheaders) https://github.com/bitcoin/bitcoin/pull/13192
< bitcoin-git>
[bitcoin] promag opened pull request #13193: Avoid 2nd mapTx lookup in CTxMemPool::UpdateTransactionsFromBlock (master...2018-05-avoid-maptx-lookup) https://github.com/bitcoin/bitcoin/pull/13193