< cfields>
Luke-Jr: yea, just saw. testing locally
< Chris_Stewart_5>
What does OP_CODESEPARATOR do? The description is "All of the signature checking words will only match signatures to the data after the most recently-executed OP_CODESEPARATOR."
< Chris_Stewart_5>
so it is just the index of a signature?
< Chris_Stewart_5>
the actually code in core says pbegincodehash = pc;
< sipa>
Chris_Stewart_5: historic cruft
< jonasschnelli>
wumpus: do you know the reason why we multiple RPCTimerInterface?
< jonasschnelli>
Is it because the RPCRunLater() needs to be called from the GUI whenever one used the GUI console?
< jonasschnelli>
It does not make things more worse..
< wumpus>
hm but it makes an assumption of the order of interfaces in timerInterfaces
< wumpus>
I agree with your logic though
< wumpus>
but we should spell it out explicitly, 'if libevent is available use that otherwise fall back to qt'
< wumpus>
otherwise there are a tons of ways future "harmless refactors" can mess this up again
< jonasschnelli>
right.. so should I add a priority (int) in the timer interface and always use the one with highest prio?
< jonasschnelli>
Or other concepts?
< wumpus>
yea.. that sounds good to me
< wumpus>
or just have explicit logic in the GUI
< wumpus>
install a timer interface only when APpInit() hasn't installed one
< wumpus>
I think that's even more straightforward
< wumpus>
have a single timer interface instead of a list o them
< jonasschnelli>
ah... right... don't add the QTTimerInterface when there is already one.
< wumpus>
yes
< jonasschnelli>
okay.. i try to change it to only support one timer interface.
< wumpus>
that's what we effectively want, one timer interface, but I thought they were equivalent so 'picking one' was fine, apparantly not :(
< wumpus>
I hope it isn't a problem the other way around, using libevent timer mechanism when talking to qt
< wumpus>
in that case we really need an rpc 'context'
< jonasschnelli>
sorry, sorry, MarcoFalke just told me the fact that i did push branches to bitcoin/bitcoin, will delete them immediately! that git beast!
< jonasschnelli>
will keep three of them until the related PRs closed (to avoid close/reopen).
< wumpus>
oh I also did that by accident once, no problem, just remove them when they're done
< GitHub110>
[bitcoin] jonasschnelli opened pull request #7318: Backport: quickfix for RPC timer interface problem (0.12...2016/01/bp_rpctimerinterface) https://github.com/bitcoin/bitcoin/pull/7318
< GitHub85>
[bitcoin] jonasschnelli opened pull request #7319: [Backport 0.12][QT] Intro: Display required space (0.12...2016/01/bp_qtintrodatadirsize) https://github.com/bitcoin/bitcoin/pull/7319
< MarcoFalke>
Are any merges planned before the rc1 tag?
< MarcoFalke>
Any pulls need testers?
< btcdrak>
MarcoFalke: I dont think you can have an RC until the remaining 0.12 tagged PRs are merged.
< btcdrak>
MarcoFalke: else it cant be a release candidate by very definition (if stuff is pending), unless it's being specifically excluded for the next maintenance release.
< GitHub2>
bitcoin/0.12 4707797 Alex Morcos: Make sure conflicted wallet tx's update balances...
< Quent>
hey, when is the next release do we know?
< MarcoFalke>
Feb 1
< MarcoFalke>
rc1 is today or Monday, I think
< Quent>
thanks
< MarcoFalke>
morcos?
< MarcoFalke>
rpc tests look fine but there is a typo which makes travis fail
< GitHub174>
[bitcoin] theuni opened pull request #7322: c++11: add scoped enum fallbacks to CPPFLAGS rather than defining them locally (master...c++11-prep) https://github.com/bitcoin/bitcoin/pull/7322
< morcos>
MarcoFalke: thanks. fixed.
< cfields>
wumpus: I have a few questions in to Travis about how to proceed. There are several paths we could take, all missing one thing or another. I'm looking to find out what's most likely to be fixed first
< cfields>
worst case, i guess we can just leave c++11 disabled for win32 builds temporarily, as that's the most troublesome
< phantomcircuit>
sipa, in FRESH/DIRTY in coins.h "parent" means closer to disk, right?
< sipa>
phantomcircuit: yes
< phantomcircuit>
sipa, is it possible for FRESH to be set but not DIRTY ?
< phantomcircuit>
sipa, also, why does CCoinsViewCache::BatchWrite erase the entires from the batch?
< sipa>
phantomcircuit: to avoid a copy
< sipa>
phantomcircuit: otherwise you'd get a memory usage doubling whenever you're flushing
< phantomcircuit>
sipa, so the cacheCoins.clear(); in CCoinsViewCache::Flush never does anything?
< sipa>
phantomcircuit: deleting the map's storage?
< sipa>
unsure, not looking at code now
< phantomcircuit>
sipa, cacheCoins.size() == 0 always before it's called
< phantomcircuit>
oh ok nvm then :)
< morcos>
phantomcircuit: i had questions about that too, and i'd love it if you want to look at #6936 and figure out why the performance improvement isn't as good as you might expect
< cfields>
morcos: i just spent a ton of time in there, i'd be happy to talk it through if you'd like
< cfields>
morcos: haha, just looked at your PR. I was hacking on the same goal :)
< morcos>
cfields: great, thanks. maybe next week we can chat on it?
< cfields>
sure
< cfields>
morcos: fwiw, i was doing a test, and just hacked it up to always keep _all_ tx in the cache (to test the penalty of going to disk on osx) and the difference was very significant
< cfields>
so i'm surprised that you weren't happy with the improvement you saw
< cfields>
note that i primed the cache at startup, though, so it was always warm
< cfields>
(the cost of priming the cache turned out to be negligible compared to the gain of actually having it primed)