12017-06-16T00:01:02 *** abpa has quit IRC
22017-06-16T00:14:40 *** AaronvanW has quit IRC
32017-06-16T00:15:38 *** apll has quit IRC
42017-06-16T00:17:28 *** apll has joined #bitcoin-core-dev
52017-06-16T00:21:17 *** mol has quit IRC
62017-06-16T00:23:00 *** mol has joined #bitcoin-core-dev
72017-06-16T00:46:27 *** Chris_Stewart_5 has quit IRC
82017-06-16T00:47:22 <bitcoin-git> [bitcoin] gmaxwell opened pull request #10608: Add a comment explaining the use of MAX_BLOCK_BASE_SIZE. (master...size_comment) https://github.com/bitcoin/bitcoin/pull/10608
92017-06-16T00:56:53 *** dabura667 has joined #bitcoin-core-dev
102017-06-16T00:58:41 *** dabura667 has quit IRC
112017-06-16T00:59:50 *** dabura667 has joined #bitcoin-core-dev
122017-06-16T01:12:16 *** Ylbam has quit IRC
132017-06-16T01:27:47 <NicolasDorier> wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs achow101 : Sorry to ping you all, but since some dev are in Tokyo around end of july for some conferences, I thought it can be a good idea to have such occasion to have 1 or 2 days of pure bitcoin core
142017-06-16T01:27:47 <NicolasDorier> coding/review/idea sharing together. If you are interested, come in the channel ##tokyocore . My company Digital Garage can give us a nice place to go for coding. Note: I certaintly forgot some name, if you are contributor and wish to come, you are defintively welcome. The 25 June we freeze the list.
152017-06-16T01:31:37 <cfields> NicolasDorier: thanks for arranging!
162017-06-16T01:33:49 *** Dyaheon has quit IRC
172017-06-16T01:39:15 *** Dyaheon has joined #bitcoin-core-dev
182017-06-16T02:04:22 *** AaronvanW has joined #bitcoin-core-dev
192017-06-16T02:10:35 *** AaronvanW has quit IRC
202017-06-16T02:18:46 <cfields> gitian builders: 0.14.2 detached sigs are up
212017-06-16T02:21:59 *** ProfMac has quit IRC
222017-06-16T02:24:08 *** elkalamar has quit IRC
232017-06-16T03:28:23 *** ProfMac has joined #bitcoin-core-dev
242017-06-16T03:56:10 *** RubenSomsen has quit IRC
252017-06-16T04:06:29 *** Dyaheon has quit IRC
262017-06-16T04:08:25 *** Dyaheon has joined #bitcoin-core-dev
272017-06-16T04:33:40 <cfields> NicolasDorier: I just rsvpd as I was going to be there already. Thanks again.
282017-06-16T04:47:49 *** ProfMac has quit IRC
292017-06-16T04:57:13 <NicolasDorier> yay awesome
302017-06-16T05:01:14 *** harding has quit IRC
312017-06-16T05:37:43 *** [Author] has quit IRC
322017-06-16T05:41:05 *** [Author] has joined #bitcoin-core-dev
332017-06-16T05:42:22 *** RubenSomsen has joined #bitcoin-core-dev
342017-06-16T06:07:52 *** AaronvanW has joined #bitcoin-core-dev
352017-06-16T06:11:59 *** Ylbam has joined #bitcoin-core-dev
362017-06-16T06:12:38 *** AaronvanW has quit IRC
372017-06-16T06:29:32 *** ClockCat has joined #bitcoin-core-dev
382017-06-16T06:35:31 *** goatpig has quit IRC
392017-06-16T06:41:45 *** SopaXorzTaker has joined #bitcoin-core-dev
402017-06-16T06:44:08 *** Cory has quit IRC
412017-06-16T06:46:06 *** BashCo has quit IRC
422017-06-16T06:47:27 *** Giszmo has quit IRC
432017-06-16T06:48:39 *** ClockCat has quit IRC
442017-06-16T06:56:12 *** Pasha has joined #bitcoin-core-dev
452017-06-16T06:59:23 *** Pasha is now known as Cory
462017-06-16T07:05:02 *** Giszmo has joined #bitcoin-core-dev
472017-06-16T07:35:45 *** Guest___ has joined #bitcoin-core-dev
482017-06-16T07:43:12 *** paveljanik has quit IRC
492017-06-16T07:43:12 *** timothy has joined #bitcoin-core-dev
502017-06-16T07:53:40 *** Guest___ has quit IRC
512017-06-16T08:01:20 *** btcdrak has quit IRC
522017-06-16T08:08:34 *** AaronvanW has joined #bitcoin-core-dev
532017-06-16T08:12:53 *** AaronvanW has quit IRC
542017-06-16T08:14:26 *** btcdrak has joined #bitcoin-core-dev
552017-06-16T08:14:41 *** AaronvanW has joined #bitcoin-core-dev
562017-06-16T08:14:51 *** btcdrak is now known as Guest48187
572017-06-16T08:15:09 *** Guest48187 has joined #bitcoin-core-dev
582017-06-16T08:15:40 *** btcdrak_ has joined #bitcoin-core-dev
592017-06-16T08:16:14 *** btcdrak_ is now known as btcdrak
602017-06-16T08:16:29 *** btcdrak has joined #bitcoin-core-dev
612017-06-16T08:28:20 *** goatturneer has joined #bitcoin-core-dev
622017-06-16T08:29:24 *** Giszmo has quit IRC
632017-06-16T08:31:47 *** beatrootfarmer has quit IRC
642017-06-16T08:33:40 *** LeMiner has quit IRC
652017-06-16T08:34:36 *** RubenSomsen has quit IRC
662017-06-16T08:35:06 *** Guyver2 has joined #bitcoin-core-dev
672017-06-16T09:09:46 *** jouke has quit IRC
682017-06-16T09:11:53 *** jouke has joined #bitcoin-core-dev
692017-06-16T09:21:36 *** beatrootfarmer has joined #bitcoin-core-dev
702017-06-16T09:24:53 *** goatturneer has quit IRC
712017-06-16T09:38:18 *** RubenSomsen has joined #bitcoin-core-dev
722017-06-16T09:50:27 <luke-jr> you know you're up too late when you don't remember what the bug you were trying to fix was. ._.
732017-06-16T09:59:37 *** LeMiner has joined #bitcoin-core-dev
742017-06-16T10:01:51 <wumpus> cfields: thanks, pushed 0.14.2 signed sigs
752017-06-16T10:06:16 *** afk11 has quit IRC
762017-06-16T10:06:58 *** afk11 has joined #bitcoin-core-dev
772017-06-16T10:45:03 *** RubenSomsen has quit IRC
782017-06-16T10:48:51 *** laurentmt has joined #bitcoin-core-dev
792017-06-16T10:51:43 *** laurentmt has quit IRC
802017-06-16T10:58:46 *** RubenSomsen has joined #bitcoin-core-dev
812017-06-16T10:58:48 *** Guyver2_ has joined #bitcoin-core-dev
822017-06-16T11:00:48 *** Guyver2 has quit IRC
832017-06-16T11:00:52 *** Guyver2_ is now known as Guyver2
842017-06-16T11:05:52 *** cryptapus_afk has quit IRC
852017-06-16T11:08:23 *** RubenSomsen has quit IRC
862017-06-16T11:34:14 *** laurentmt has joined #bitcoin-core-dev
872017-06-16T11:35:23 *** annanay25 has quit IRC
882017-06-16T11:35:32 *** annanay25 has joined #bitcoin-core-dev
892017-06-16T11:51:05 <jonasschnelli> cfields: with be49a294a240ec81a901af1aaabbba2172d38dc1 I get only a single lock report... haven't looked at your code thourgh
902017-06-16T11:51:08 <jonasschnelli> *though
912017-06-16T11:56:27 *** BashCo has joined #bitcoin-core-dev
922017-06-16T11:57:27 *** JackH has quit IRC
932017-06-16T12:02:42 <jonasschnelli> wumpus: the pollBalanceThread is mainly responsible for UI freezes...
942017-06-16T12:02:54 <jonasschnelli> If I disable that poll thread,.. stuff runs much better
952017-06-16T12:05:26 *** arubi has quit IRC
962017-06-16T12:05:26 *** afk11 has quit IRC
972017-06-16T12:06:47 *** afk11 has joined #bitcoin-core-dev
982017-06-16T12:06:56 *** arubi has joined #bitcoin-core-dev
992017-06-16T12:18:06 *** apll has quit IRC
1002017-06-16T12:18:58 *** dabura667 has quit IRC
1012017-06-16T12:22:20 *** afk11 has quit IRC
1022017-06-16T12:22:33 *** afk11 has joined #bitcoin-core-dev
1032017-06-16T12:23:50 <jonasschnelli> ryanofsky: I'll give it a test (polling but keeping the cache)
1042017-06-16T12:24:01 *** cryptapus_afk has joined #bitcoin-core-dev
1052017-06-16T12:24:21 <jonasschnelli> ryanofsky: But what I don't understand is why we would/should do a TRY_LOCK on cs_main every 250ms
1062017-06-16T12:25:08 <jonasschnelli> cfields: nighly gitian build crashes on OSX (not tested on WIN/LINUX): https://0bin.net/paste/8-QKc7g9psBmYIGJ#msAwcpNd1CtU4KdEObG7tN4PK0XiIAbiELdwUtJLzui
1072017-06-16T12:25:33 *** Char0n has joined #bitcoin-core-dev
1082017-06-16T12:57:57 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1092017-06-16T13:04:32 *** Guyver2 has quit IRC
1102017-06-16T13:08:56 *** Guyver2 has joined #bitcoin-core-dev
1112017-06-16T13:14:32 *** johnpark_pj has joined #bitcoin-core-dev
1122017-06-16T13:17:47 *** goatturner has joined #bitcoin-core-dev
1132017-06-16T13:18:40 *** beatrootfarmer has quit IRC
1142017-06-16T13:29:46 <jonasschnelli> sipa: you said CCoinsViewDB::Upgrade() can be cancelled (and continued) any time. Is that correct?
1152017-06-16T13:30:12 <jonasschnelli> Adding a check for ShutdownRequested() and break the while (and write the possible batch) would make sense then?
1162017-06-16T13:32:46 *** laurentmt has quit IRC
1172017-06-16T13:33:22 <michagogo> Will have 0.14.2 signed up shortly
1182017-06-16T13:33:29 <michagogo> Doing a bit of VM maintenance
1192017-06-16T13:33:55 <michagogo> Speaking of which: does anyone know what the status is of Gitian in Xenial?
1202017-06-16T13:34:59 <michagogo> ISTR that for some reason we can't actually compile on Xenial and so the guest needs to remain Trusty, but can the Gitian (LXC) *host* be Xenial?
1212017-06-16T13:36:26 <jonasschnelli> michagogo: Xenial should work fine IMO
1222017-06-16T13:41:53 <sipa> jonasschnelli: i guess!
1232017-06-16T13:42:07 <jonasschnelli> sipa: Seems to work here...
1242017-06-16T13:42:29 <jonasschnelli> sipa: Can you tell me again how I can calculate the progress in that pcursor while loop?
1252017-06-16T13:43:48 <sipa> i'll make a commit later
1262017-06-16T13:43:52 <sipa> thanks for doing thid
1272017-06-16T13:44:30 *** BashCo has quit IRC
1282017-06-16T13:45:55 <jonasschnelli> okay. thanks
1292017-06-16T13:52:48 <wumpus> jonasschnelli: interesting! I hadn't expected that, it should only update the balance if the TRY_ succeeds not freeze on the lock update
1302017-06-16T13:53:21 <jonasschnelli> I don't know why currently but I know that its much faster with that PR
1312017-06-16T13:53:27 <jonasschnelli> At least on OSX
1322017-06-16T13:53:41 <jonasschnelli> Would be nice if someone could profile it on Linux / Win.
1332017-06-16T13:54:06 <wumpus> but the try_lock on cs_main should not *itself* cause freezes
1342017-06-16T13:54:43 <wumpus> if it runs the poll, and the lock is not available, the whole point would be that it doesn't spend time
1352017-06-16T13:54:56 <wumpus> if that's not how it works it seems the whole TRY_ concept is broken
1362017-06-16T13:55:22 <jonasschnelli> but what if the TRY_LOCK can acquire the lock every 250 ms and do the calculation...
1372017-06-16T13:55:45 <wumpus> it should only do the computation if the balance is dirty, right?
1382017-06-16T13:56:30 <wumpus> so in by far most cases if it gets the lock, it immediately is supposed to notice the balance is not dirty, so doesn't recompute it
1392017-06-16T13:56:35 <jonasschnelli> I tested three options, 1) master, 2) only atomic caches with polling, 3) like 2 but polling replaced with signal
1402017-06-16T13:56:39 <wumpus> if only needs to be recomputed if something changed
1412017-06-16T13:56:47 <jonasschnelli> wumpus: so, yes. It should only lock when the balances are dirty
1422017-06-16T13:57:08 <jonasschnelli> But in my test, I sent 20 txes, so the balance was always dirty afterwards
1432017-06-16T13:57:25 <jonasschnelli> I don't know why its much slower with the TRY_LOCK
1442017-06-16T13:57:28 <wumpus> right
1452017-06-16T13:57:53 <jonasschnelli> I guess it must be the QTimer / TryLock overhead?!
1462017-06-16T13:57:54 <wumpus> well yes if it gets a transaction every 250ms, sure
1472017-06-16T13:58:05 <ryanofsky> i'd think TRY_LOCK only when balances were dirty would give best of both worlds
1482017-06-16T13:58:09 <jonasschnelli> I manually sent the tx... ~every 0.5s
1492017-06-16T13:58:09 <wumpus> but GUI freezes happen anso to people that don't have anythign in their wallet
1502017-06-16T13:58:12 <wumpus> on the first sync
1512017-06-16T13:58:36 <jonasschnelli> ryanofsky: I though as well,.. but look at my profile results,.. they tell a different story
1522017-06-16T13:58:47 <wumpus> so it can't be just something with transactions, though there's clearly something with transactions too...
1532017-06-16T13:58:51 <ryanofsky> oh ok, i didn't see that listed as one your three tests
1542017-06-16T13:59:04 <jonasschnelli> Look here: https://github.com/bitcoin/bitcoin/pull/10251#issuecomment-309021160
1552017-06-16T13:59:40 <jonasschnelli> Master with only the atomic caches result in still 33% of the execution time in that poll function
1562017-06-16T13:59:49 <wumpus> ok
1572017-06-16T14:00:05 <jonasschnelli> While I can't find any call in my profiler running pure (all commits) of 10251
1582017-06-16T14:00:06 <wumpus> 33% of the time for something that gets called 4 times per second?
1592017-06-16T14:00:14 <wumpus> is that a very large wallet?
1602017-06-16T14:00:15 <jonasschnelli> *any call that related to the balance update
1612017-06-16T14:00:29 <jonasschnelli> wumpus: not really large,.. I only did generate 1100
1622017-06-16T14:00:39 <jonasschnelli> depends what "large" is
1632017-06-16T14:00:45 <wumpus> it's interesting that the balance computation is so slow
1642017-06-16T14:00:58 <wumpus> well if so, that's already large, it seems
1652017-06-16T14:00:59 <jonasschnelli> I guess we loop 6 times over the complete mapWallet
1662017-06-16T14:01:05 <wumpus> oh wow
1672017-06-16T14:01:16 <jonasschnelli> for all balance types...
1682017-06-16T14:02:55 <wumpus> ok, yes then I understand why things are so slow, though I still don't understand why it recomputes also the times the balance was not updated
1692017-06-16T14:03:13 <wumpus> it's as if the wallet is always dirty, even though only once in 0.5s a transaction arrives
1702017-06-16T14:03:40 <jonasschnelli> I'm not sure if it recomputes then...
1712017-06-16T14:03:45 <wumpus> because in principle, this should result in the same load: with the 0.25s poll, it should compute every time after a transaction comes it
1722017-06-16T14:03:59 <jonasschnelli> But when it does,.. it seems to take much longer.. don't know why. Maybe because of the QTimer internals
1732017-06-16T14:04:01 <wumpus> with the per-transaction notification, it also does
1742017-06-16T14:04:20 <wumpus> what if the transaction rate is higher though, e.g. with 10 transactions per second the polling shoudl be faster
1752017-06-16T14:04:33 <jonasschnelli> Yes. Indeed.
1762017-06-16T14:04:46 <jonasschnelli> The signal should filter that out... min 250ms delta or something
1772017-06-16T14:05:01 <wumpus> the fixed polling is also to reduce the maximum amount of work done
1782017-06-16T14:05:11 <jonasschnelli> yes.. indeed.
1792017-06-16T14:05:24 <wumpus> yes, it could, though if done not carefully it means the data is always one update behind
1802017-06-16T14:05:39 <wumpus> (e.g. if you would naively do "process this update only if the last was >250ms ago")
1812017-06-16T14:05:40 <jonasschnelli> Could it be the QTimer overhead?
1822017-06-16T14:05:45 <wumpus> no, I don't believe that
1832017-06-16T14:05:58 <wumpus> not at a 4Hz frequency
1842017-06-16T14:06:13 <wumpus> if you remove the code from the handler but keep the timer, it'd probably be the same
1852017-06-16T14:06:48 *** ProfMac has joined #bitcoin-core-dev
1862017-06-16T14:07:19 <jonasschnelli> I guess we should then try to continue to measure the atomic cache commit on top of master (with the TRY_LOCK polling).
1872017-06-16T14:07:40 <jonasschnelli> This is already much faster (I don't have numbers though)
1882017-06-16T14:07:45 <jonasschnelli> s/is/feels/
1892017-06-16T14:08:06 <wumpus> I'm really surprised by the result at least...
1902017-06-16T14:08:11 <jonasschnelli> What could be that we falsely always set fForceCheckBalanceChanged
1912017-06-16T14:08:24 <jonasschnelli> Could also be OSX only... who knows
1922017-06-16T14:08:32 <jonasschnelli> But since we also have a windows issue...
1932017-06-16T14:08:39 <jonasschnelli> I doubt it's OSX only
1942017-06-16T14:09:09 <wumpus> btw: what is the advantage of having a dirty flag per kind of balance - won't every update to the wallet invalidate *all* of them?
1952017-06-16T14:09:47 <wumpus> or are there changes that, say, only invalidate the immutable balance
1962017-06-16T14:10:24 * jonasschnelli looking at the code again
1972017-06-16T14:10:28 <ProfMac> I feel like this is the secret password to join a club: a60d7c8dde9b77e7ff547976ce37db1fe98c71833003465befe650d6bc102b6b bitcoin-0.14.1-aarch64-linux-gnu.tar.gz
1982017-06-16T14:10:36 <wumpus> ProfMac: congrats!
1992017-06-16T14:10:43 <wumpus> so you got it to work, awesome
2002017-06-16T14:11:03 <ProfMac> I said bad things & stomped my foot a time or two.
2012017-06-16T14:11:04 <jonasschnelli> ProfMac: nice one!
2022017-06-16T14:11:07 <ryanofsky> i think dirty flag doesn't really make sense for qt, but it does make sense for rpc
2032017-06-16T14:11:36 <wumpus> so the balance computations loop over all transactions?
2042017-06-16T14:11:44 <wumpus> which is always done 6 times
2052017-06-16T14:11:53 <jonasschnelli> wumpus: because each balance type has its own routine to calculate, we probably should have caches/dirty-flags per routine
2062017-06-16T14:12:03 <jonasschnelli> wumpus: that's the root source!
2072017-06-16T14:12:04 <wumpus> I wonder if it'd make sense to roll it into one routine, that computes all 6 balalnces in one pass
2082017-06-16T14:12:13 <jonasschnelli> wumpus: +100
2092017-06-16T14:12:25 <wumpus> it would be more cache friendly at least
2102017-06-16T14:12:33 <jonasschnelli> I guess that was a "organic growing" issue... we added one type after another over tim,e
2112017-06-16T14:12:55 <wumpus> the added overhead of, in that loop over every transaction, adding up one more number is probably neglible
2122017-06-16T14:13:13 <jonasschnelli> indeed
2132017-06-16T14:13:16 <wumpus> while LOCKing the wallet six times and iterating over its contents six times is probably bad
2142017-06-16T14:13:34 <wumpus> in any case it's good that your PR already brings improvements
2152017-06-16T14:13:39 <wumpus> then we should probably merge it
2162017-06-16T14:13:44 <jonasschnelli> But now it comes...
2172017-06-16T14:13:48 *** goatpig has joined #bitcoin-core-dev
2182017-06-16T14:13:54 <jonasschnelli> We call GetDepthInMainChain for each mapWallet tx
2192017-06-16T14:14:02 <jonasschnelli> Which does mapBlockIndex.find(hashBlock);
2202017-06-16T14:14:26 <jonasschnelli> I tried multiple times to cache the height... but seems to be relatively difficult to do it right
2212017-06-16T14:14:45 <wumpus> that would also be reduced with factor 6 if it were to be done in one go
2222017-06-16T14:14:55 <jonasschnelli> Yes.
2232017-06-16T14:15:40 <jonasschnelli> That would be related to 10251 but with a bigger ramification
2242017-06-16T14:15:52 <wumpus> I mean *ideally* the wallet would compute balance incremementally
2252017-06-16T14:15:56 <jonasschnelli> I think the pure atomic caches is a first step... even if we then can throw away all down to a sigle cache
2262017-06-16T14:16:03 <jonasschnelli> wumpus: Yes.
2272017-06-16T14:16:13 <jonasschnelli> It should keep basepoints at certain height/states
2282017-06-16T14:16:20 <wumpus> but if we had to do a pass over the entire wallet it's by far best to do it only once
2292017-06-16T14:16:41 <wumpus> right, it's extremely complex to get right, which is why it was never done
2302017-06-16T14:16:53 <jonasschnelli> Indeed, ... and we should probably do in â as most things â in a background thread (GUI wise)
2312017-06-16T14:17:18 <jonasschnelli> If the node coms where in a background thread, nobody would tackle this
2322017-06-16T14:17:21 <wumpus> e.g. there are so many small things that can change how a transaction is counted
2332017-06-16T14:17:40 <wumpus> right, if the computation was not in the GUI thread, it'd be much less bad
2342017-06-16T14:17:48 <wumpus> there would be some unnoticable lag
2352017-06-16T14:17:52 <ryanofsky> if you get rid of the dirty flag and compute balance with each transactions that effectively would move computation to a background thread. still might lock up gui because of holding cs_main though
2362017-06-16T14:17:54 <wumpus> instead of the thing hanging and complaining
2372017-06-16T14:18:23 <wumpus> ryanofsky: but that'd be crazy, it'd make receiving transactions quadratic
2382017-06-16T14:18:32 <wumpus> ryanofsky: if every transactions received causes a scan over the entire wallet
2392017-06-16T14:18:39 <wumpus> ryanofsky: that's why the dirty flag exists
2402017-06-16T14:19:07 <jonasschnelli> Balances should only be calculated if the user wants them
2412017-06-16T14:19:10 <ryanofsky> yes, what i meant above by dirty flag makes sense for rpc but not gui
2422017-06-16T14:19:18 *** regina909_ has joined #bitcoin-core-dev
2432017-06-16T14:19:19 <jonasschnelli> In the GUI, thats a bit different
2442017-06-16T14:19:29 <wumpus> ryanofsky: right now it makes sense for the GUI too, as it's only polled 4 times per second
2452017-06-16T14:19:33 <wumpus> ryanofsky: so it's naturally rate limited
2462017-06-16T14:19:56 <wumpus> ryanofsky: if you get 400 transactions per second, it still only computes 4 times per second
2472017-06-16T14:19:56 *** regina909_ has left #bitcoin-core-dev
2482017-06-16T14:19:58 <ryanofsky> for gui users who are creating more than 4 transactions per second i guess
2492017-06-16T14:20:06 <jonasschnelli> Modern GUI frameworks often poll/call updates when the according element is visible
2502017-06-16T14:20:12 <wumpus> or "receiving"
2512017-06-16T14:20:15 <wumpus> this happens during initial sync
2522017-06-16T14:20:18 <wumpus> if you have a full wallet
2532017-06-16T14:20:19 *** pandabull has joined #bitcoin-core-dev
2542017-06-16T14:20:35 <ryanofsky> oh, that's true. dirty flag makes sense there too
2552017-06-16T14:20:57 <wumpus> people always ignore initial sync for some reason, while that is the most common source of hangs, after initial sync the GUI is pretty ok
2562017-06-16T14:20:57 <ryanofsky> anyway to be clear i'm not suggesting getting rid of dirty flag
2572017-06-16T14:21:24 <wumpus> (initial sync or: more often, catching up after not running the node for a few days)
2582017-06-16T14:21:32 <ryanofsky> i'm just saying one way to move balance computation to "background thread" instead of gui thread is to compute it on tx notifications in cases where that makes sense
2592017-06-16T14:22:09 <wumpus> sure
2602017-06-16T14:31:20 *** BashCo has joined #bitcoin-core-dev
2612017-06-16T14:32:15 *** BashCo has left #bitcoin-core-dev
2622017-06-16T14:34:46 *** BashCo has joined #bitcoin-core-dev
2632017-06-16T14:50:26 <cfields> jonasschnelli: the lock report is printed when threads destruct. So, mostly at shutdown
2642017-06-16T14:50:37 *** Guyver2_ has joined #bitcoin-core-dev
2652017-06-16T14:50:37 <jonasschnelli> ah.. okay.. then my fault
2662017-06-16T14:50:51 <jonasschnelli> cfields: have you seen the crash on OSX in current master over gitian
2672017-06-16T14:51:22 <jonasschnelli> It must be one of the last 10 commits
2682017-06-16T14:51:40 <jonasschnelli> could it be: https://github.com/bitcoin/bitcoin/commit/cb24c8539d1098d1a61605b452ecfa11a693320d
2692017-06-16T14:51:49 <cfields> jonasschnelli: no, i haven't rebased my osx work in maybe ~1week, though
2702017-06-16T14:51:57 <cfields> I'll fire one up now
2712017-06-16T14:52:16 <jonasschnelli> The crash only happens when build via gitian
2722017-06-16T14:52:23 <jonasschnelli> local builds are fine...
2732017-06-16T14:52:23 <cfields> jonasschnelli: could also be the crc32 thing
2742017-06-16T14:52:33 <jonasschnelli> But nighly build from 15th works
2752017-06-16T14:52:37 <cfields> interesting
2762017-06-16T14:52:39 <jonasschnelli> Most be the last 10 commits
2772017-06-16T14:52:45 <cfields> jonasschnelli: you have binaries handy?
2782017-06-16T14:52:53 <jonasschnelli> yes...
2792017-06-16T14:52:57 <jonasschnelli> see: https://github.com/bitcoin/bitcoin/issues/10611
2802017-06-16T14:53:07 <jonasschnelli> use my builders build 176 vs 175
2812017-06-16T14:53:23 <cfields> perfect, thanks
2822017-06-16T14:53:33 *** Guyver2 has quit IRC
2832017-06-16T14:53:40 *** Guyver2_ is now known as Guyver2
2842017-06-16T14:53:58 <cfields> argh, i never added the osx debug symbols, did i?
2852017-06-16T14:54:06 *** BashCo has quit IRC
2862017-06-16T14:54:46 <jonasschnelli> I guess no...
2872017-06-16T14:55:38 <cfields> :(
2882017-06-16T14:55:42 * cfields adds it to the list
2892017-06-16T14:57:45 *** BashCo has joined #bitcoin-core-dev
2902017-06-16T14:59:58 *** pandabull has quit IRC
2912017-06-16T15:00:06 *** Dyaheon has quit IRC
2922017-06-16T15:00:36 *** pandabull has joined #bitcoin-core-dev
2932017-06-16T15:01:42 *** Dyaheon has joined #bitcoin-core-dev
2942017-06-16T15:02:19 *** svx has joined #bitcoin-core-dev
2952017-06-16T15:02:35 *** svx has left #bitcoin-core-dev
2962017-06-16T15:04:01 *** pandabul_ has joined #bitcoin-core-dev
2972017-06-16T15:05:05 *** pandabull has quit IRC
2982017-06-16T15:07:48 <cfields> jonasschnelli / sipa: https://0bin.net/paste/+O0wEWXmLDshuG97#oQTOyc4av4get3wvsrwRNwbKaTO7ODBrTotk5nbXcf3
2992017-06-16T15:08:41 *** pandabul_ has quit IRC
3002017-06-16T15:10:06 *** BashCo has quit IRC
3012017-06-16T15:12:41 *** BashCo has joined #bitcoin-core-dev
3022017-06-16T15:16:01 *** chjj has quit IRC
3032017-06-16T15:16:17 *** pandabull has joined #bitcoin-core-dev
3042017-06-16T15:21:49 *** BashCo has quit IRC
3052017-06-16T15:25:36 *** BashCo has joined #bitcoin-core-dev
3062017-06-16T15:26:11 *** laurentmt has joined #bitcoin-core-dev
3072017-06-16T15:29:24 *** chjj has joined #bitcoin-core-dev
3082017-06-16T15:39:44 *** BashCo has quit IRC
3092017-06-16T15:51:21 *** ovovo has joined #bitcoin-core-dev
3102017-06-16T15:51:43 *** RubenSomsen has joined #bitcoin-core-dev
3112017-06-16T15:52:27 *** abpa has joined #bitcoin-core-dev
3122017-06-16T15:54:36 *** owowo has quit IRC
3132017-06-16T15:54:56 *** BashCo has joined #bitcoin-core-dev
3142017-06-16T16:02:11 <bitcoin-git> [bitcoin] jnewbery opened pull request #10612: The young person's guide to the test_framework (master...templatefunctionaltest) https://github.com/bitcoin/bitcoin/pull/10612
3152017-06-16T16:04:43 <Victorsueca> anybody else having issues when cross-compiling 0.14.2 for windows in ubuntu 14?
3162017-06-16T16:06:06 <Victorsueca> I'm getting this thing on a machine that used to compile properly until now https://0bin.net/paste/q13F+WfsGqY4fkcW#4UXO33FPpzPvu7zb-Omj6zz8tHPGiAOH18/E5ti0xNO
3172017-06-16T16:06:08 <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
3182017-06-16T16:07:17 <sipa> Victorsueca: "issues" is pretty vague
3192017-06-16T16:07:42 <Victorsueca> sipa: yeah, more specifically with miniupnpc apparently
3202017-06-16T16:07:46 <Victorsueca> see the 0bin
3212017-06-16T16:07:55 <sipa> oh, sorry i missed the link
3222017-06-16T16:17:55 *** Guyver2 has quit IRC
3232017-06-16T16:21:35 *** chjj has quit IRC
3242017-06-16T16:30:34 *** spudowiar has joined #bitcoin-core-dev
3252017-06-16T16:30:38 <spudowiar> o/ jnewbery
3262017-06-16T16:35:24 *** chjj has joined #bitcoin-core-dev
3272017-06-16T16:48:18 *** jnewbery has quit IRC
3282017-06-16T16:48:31 *** jnewbery has joined #bitcoin-core-dev
3292017-06-16T16:52:48 *** Giszmo has joined #bitcoin-core-dev
3302017-06-16T17:02:09 *** cysm has quit IRC
3312017-06-16T17:02:34 <cfields> jonasschnelli: ok, i think i have the crash worked out. I've taken the opportunity to learn more about asm
3322017-06-16T17:02:47 *** _flow_ has quit IRC
3332017-06-16T17:05:57 *** _flow_ has joined #bitcoin-core-dev
3342017-06-16T17:06:17 *** cysm has joined #bitcoin-core-dev
3352017-06-16T17:08:50 *** Evel-Knievel has quit IRC
3362017-06-16T17:09:35 <sipa> cfields: my condolences
3372017-06-16T17:10:11 <cfields> sipa: heh. my mistake for not diving in decades ago
3382017-06-16T17:15:08 <cfields> sipa: clang is nice enough to use ebx for its stack canary, which cpuid clobbers. I'm trying to understand the PIC/ebx interaction fully before PRing something
3392017-06-16T17:16:14 <cfields> (context: rdrand detection)
3402017-06-16T17:16:52 <sipa> cfields: huh?
3412017-06-16T17:16:57 <sipa> my PR avoids clobbering ebx...
3422017-06-16T17:17:15 <cfields> more context: #10611
3432017-06-16T17:17:16 <gribble> https://github.com/bitcoin/bitcoin/issues/10611 | Gitian build (current master) crashes on OSX · Issue #10611 · bitcoin/bitcoin · GitHub
3442017-06-16T17:17:39 <cfields> sipa: my understanding is that the instruction still clobbers it, the compiler just isn't aware of that
3452017-06-16T17:17:48 <sipa> it does not clobber it
3462017-06-16T17:18:01 <sipa> the cpuid instruction clobbers it, but the whole asm block does not
3472017-06-16T17:18:10 <sipa> it moves the old value to a temp register first, and restores it
3482017-06-16T17:19:21 <cfields> grr, i was looking at my hacked up local source. I see that now, thanks.
3492017-06-16T17:19:45 <sipa> can you show me objdump -dC libbitcoin_util_a-random.o ?
3502017-06-16T17:20:24 <cfields> yea, sec, let me revert
3512017-06-16T17:20:50 <cfields> please don't tell the problem/solution though, I'd like to work it out
3522017-06-16T17:21:42 <sipa> i don't expect to learn anything interesting - just want to see if the clang compiler isn't doing something unexpected
3532017-06-16T17:22:42 <cfields> https://pastebin.com/raw/tS1TUPe0
3542017-06-16T17:24:54 <sipa> oooh!
3552017-06-16T17:25:00 * sipa sees it
3562017-06-16T17:26:14 <cfields> just tell me how deep i'm going to have to dive? :)
3572017-06-16T17:27:53 <sipa> hint: we'll need different asm code for 32bit and 64bit
3582017-06-16T17:28:43 *** chjj has quit IRC
3592017-06-16T17:28:55 *** pandabull has quit IRC
3602017-06-16T17:29:25 *** pandabull has joined #bitcoin-core-dev
3612017-06-16T17:33:12 <cfields> full canary address doesn't get restored via mov?
3622017-06-16T17:34:44 <sipa> indeed
3632017-06-16T17:35:09 <sipa> see why?
3642017-06-16T17:36:32 <cfields> vaguely. I'm so green I'm having trouble distinguishing values from addresses. Investigating.
3652017-06-16T17:38:48 *** griswaalt has joined #bitcoin-core-dev
3662017-06-16T17:39:39 <wumpus> oh, so the compiler isn't being told correctly what registers are being clobbered?
3672017-06-16T17:40:10 <sipa> wumpus: if you tell the compiler yoi clobber ebx, it will complain saying that it needs ebx for PIC
3682017-06-16T17:40:15 <sipa> and fail to compile
3692017-06-16T17:40:29 <sipa> so the code there manually saves and restores ebx
3702017-06-16T17:41:01 <sipa> i believe that is fixed in a later gcc
3712017-06-16T17:41:07 <cfields> gcc5
3722017-06-16T17:41:27 <cfields> i suppose it needs to be movq/rbx for 64bit instead?
3732017-06-16T17:41:32 <sipa> indeed
3742017-06-16T17:41:34 <wumpus> that seems kind of stupid, now you need to write the code in mind with the knowledge what every compiler might use for special things
3752017-06-16T17:41:42 <sipa> wumpus: indeed :(
3762017-06-16T17:41:56 <sipa> cfields: tmp needs to be a 64-bit int on 64-bit systems
3772017-06-16T17:42:23 <cfields> sipa: i've seen lots of rantings about gcc's x86 pic handling in the past, i'm beginning to understand the hatred now
3782017-06-16T17:42:32 <wumpus> (I suspect the cookie in ebx is not part of any official ABI convention, at least)
3792017-06-16T17:43:00 *** chjj has joined #bitcoin-core-dev
3802017-06-16T17:43:59 <cfields> well if you list ebx as a clobber, it sticks the cookie somewhere else. So my "fix" was totally accidental and wrong (and would ofc break on x86 pic).
3812017-06-16T17:44:17 <sipa> cfields: oh you're able to list ebx as a clobber?
3822017-06-16T17:44:20 <sipa> and it compiles?
3832017-06-16T17:44:26 <wumpus> in its defense, handling PIC on x86 32 bit is a nightmare
3842017-06-16T17:44:39 <sipa> in that case, we should probably do that on x86_64
3852017-06-16T17:44:50 <wumpus> modern architectures, and even less modern ones, have been designed with PIC in mind, but x86 never was
3862017-06-16T17:45:32 <cfields> sipa: yea
3872017-06-16T17:46:05 <sipa> you want to write a pr?
3882017-06-16T17:47:26 <cfields> sipa: sure, will be a while though. Still reading/experimenting/learning
3892017-06-16T17:48:06 *** Giszmo has quit IRC
3902017-06-16T17:50:40 <sipa> cfields: the issue is that the 32-bit ebx register and the 64-bit rbx register occupy the same space
3912017-06-16T17:50:47 *** timothy has quit IRC
3922017-06-16T17:51:01 <sipa> ebx is just a "view" of the lower 32 bits of rbx
3932017-06-16T17:52:18 <cfields> that makes sense
3942017-06-16T17:52:57 <sipa> and the "b" constraint can either mean ebx or rbx, depending on the size of the variable
3952017-06-16T17:53:26 <sipa> there are 8-bit and 16-bit views too
3962017-06-16T17:55:20 <cfields> so the compiler adapts the mov to the register size?
3972017-06-16T17:55:27 <sipa> yup
3982017-06-16T17:55:33 <sipa> the assembler, rather
3992017-06-16T17:55:49 <cfields> ok, got it
4002017-06-16T17:55:55 <cfields> thanks for the 101 :)
4012017-06-16T17:56:28 *** Gnof has joined #bitcoin-core-dev
4022017-06-16T18:07:31 <cfields> sipa: https://pastebin.com/raw/68f8cKHd ?
4032017-06-16T18:13:59 <cfields> mm, apparently that's broken since cpuid overwrites eax
4042017-06-16T18:15:48 <sipa> you can list eax as an input/outpit register
4052017-06-16T18:16:01 <sipa> but i think just listing all 4 as outputs is easier
4062017-06-16T18:16:28 <cfields> right, so:https://pastebin.com/BhBAHeFK
4072017-06-16T18:16:31 <cfields> ok
4082017-06-16T18:16:45 <cfields> will just do that. PRing. thanks again.
4092017-06-16T18:29:27 *** SopaXorzTaker has quit IRC
4102017-06-16T18:34:12 <Victorsueca> sipa: had to go for a while, any news on my issue? need extra debug info?
4112017-06-16T18:37:59 <sipa> Victorsueca: i have no clue
4122017-06-16T18:39:49 <achow101> Victorsueca: are you using WSL?
4132017-06-16T18:40:20 <Victorsueca> achow101: yes, it has been working until now
4142017-06-16T18:40:32 *** laurentmt has quit IRC
4152017-06-16T18:40:46 <achow101> IIRC it wasn't working for the past few months
4162017-06-16T18:40:54 <achow101> (at least not on my machines)
4172017-06-16T18:40:58 <ProfMac> I successfully did a gitian build on 0.14.1. It took days to grok the web pages, and about 7 hours to execute. I have placed some shell scripts at https://github.com/a-mcintosh/gitian-bitcoin-shell-scripts and these scripts capture the workflow mentioned at https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#create-a-new-virtualbox-vm
4182017-06-16T18:41:56 *** Evel-Knievel has joined #bitcoin-core-dev
4192017-06-16T18:41:59 <jonasschnelli> 7h?!
4202017-06-16T18:42:06 <jonasschnelli> DId you pass in -j2 or -j4?
4212017-06-16T18:43:02 <Victorsueca> the last version i've built succefully on my WSL was 0.14.1, now I'm on the same machine and it won't do the depends for 0.14.2
4222017-06-16T18:43:10 <achow101> Victorsueca: try https://github.com/bitcoin/bitcoin/issues/10269#issuecomment-307293086
4232017-06-16T18:43:14 <ProfMac> lol. At this point I'm so fatigued, I don't even know my own name. It does seem pretty slow. Have a look at the scripts and see if you spot any trouble.
4242017-06-16T18:43:15 *** SopaXorzTaker has joined #bitcoin-core-dev
4252017-06-16T18:43:33 <sipa> ProfMac: machine without hardware virtualization?
4262017-06-16T18:44:41 *** pandabul_ has joined #bitcoin-core-dev
4272017-06-16T18:44:57 <achow101> ProfMac: perhaps try using kvm instead of lxc? it will need to run on hardware and not in a vm though
4282017-06-16T18:46:22 <Victorsueca> achow101: that seems to work \o/
4292017-06-16T18:46:26 <Victorsueca> thanks
4302017-06-16T18:46:28 <ProfMac> Probably just not configured correctly. One of the scripts creates the virtualbox, so that can be corrected. 5.7 GiB RAM, Intel Core 2 Duo CPU E8400 @ 3.00 GHz x 2 Ubuntu 14.04 LTS 2.0 TB online.
4312017-06-16T18:47:20 <ProfMac> what kind of build times to others have? My impression was that it build the entire Trusty system from source during the process.
4322017-06-16T18:47:40 *** pandabull has quit IRC
4332017-06-16T18:48:27 <ProfMac> I don't know how to peek inside gitian-builder/target-trusty-amd64
4342017-06-16T18:50:12 <jonasschnelli> ProfMac: my build times are at bitcoin.jonasschnelli.ch
4352017-06-16T18:51:13 <ProfMac> Could I just make a new Trusty VM and do the build there? If I restore a "bare" snapshot before each build, what do I give up?
4362017-06-16T18:53:16 *** RubenSomsen has quit IRC
4372017-06-16T18:54:08 <ProfMac> jonasschnelli, thanks, but I get a 403 forbidden when I drop that into an address bar.
4382017-06-16T18:54:32 <jonasschnelli> https://bitcoin.jonasschnelli.ch
4392017-06-16T18:54:40 <jonasschnelli> Oh.. the SSL forwarder seems broken
4402017-06-16T18:55:35 <ProfMac> I'm at the page. Nice homage to Matrix, unless like me you still see pink after a night at the CRT.
4412017-06-16T18:56:00 *** Giszmo has joined #bitcoin-core-dev
4422017-06-16T18:59:11 <ProfMac> Oh my. 21 minutes vs 7 hours. LOL.
4432017-06-16T18:59:46 *** frabrunelle has quit IRC
4442017-06-16T18:59:56 *** draadpiraat[m] has quit IRC
4452017-06-16T18:59:56 *** herzmeister[m] has quit IRC
4462017-06-16T18:59:59 *** kewde[m] has quit IRC
4472017-06-16T19:02:02 <bitcoin-git> [bitcoin] theuni opened pull request #10614: random: fix crash on some 64bit platforms (master...fix-osx-crash) https://github.com/bitcoin/bitcoin/pull/10614
4482017-06-16T19:02:21 <cfields> jonasschnelli: ^^
4492017-06-16T19:09:06 *** chjj has quit IRC
4502017-06-16T19:09:07 <sipa> cfields: also, for reusable code (if we want to use hw sha instruction or something, you can use "xchg %1, %%ebx" instead of mov, and get the real ebx out
4512017-06-16T19:09:36 <cfields> sipa: heh, i meant to ask about that. that's what gcc does internally
4522017-06-16T19:09:54 <sipa> not suggesting to do that here, but it's hardly harder to write a generic "cpuid number -> give me a tuple of 4 uint32_t" function
4532017-06-16T19:13:25 <cfields> sipa: you mean just drop the special case and always stash b?
4542017-06-16T19:13:54 <sipa> cfields: i think your PR is fine
4552017-06-16T19:14:12 <sipa> but maybe later if we ever have multiple things to query cpuid for
4562017-06-16T19:14:25 <cfields> sipa: well i'm pretty sure I whined about it not being generic in your original PR :p
4572017-06-16T19:15:19 <jonasschnelli> cfields: nice. Just started a build: https://bitcoin.jonasschnelli.ch/build/181
4582017-06-16T19:15:37 <cfields> sipa: heh, yea: https://github.com/bitcoin/bitcoin/pull/10377#pullrequestreview-37172453
4592017-06-16T19:21:41 *** ovovo is now known as owowo
4602017-06-16T19:23:10 *** chjj has joined #bitcoin-core-dev
4612017-06-16T19:28:52 *** Giszmo has quit IRC
4622017-06-16T19:29:20 *** owowo has quit IRC
4632017-06-16T19:33:58 *** SopaXorzTaker has quit IRC
4642017-06-16T19:34:12 *** owowo has joined #bitcoin-core-dev
4652017-06-16T19:35:44 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c2ab38bdd57a...7a74f88a26cf
4662017-06-16T19:35:45 <bitcoin-git> bitcoin/master cc0ed26 Pavel JanÃk: Supress struct/class mismatch warnings introduced in #10284.
4672017-06-16T19:35:45 <bitcoin-git> bitcoin/master 7a74f88 Pieter Wuille: Merge #10598: Supress struct/class mismatch warnings introduced in #10284...
4682017-06-16T19:36:06 *** Dyaheon has quit IRC
4692017-06-16T19:36:24 <bitcoin-git> [bitcoin] sipa closed pull request #10598: Supress struct/class mismatch warnings introduced in #10284 (master...20170615_FeeCalculation_structclass) https://github.com/bitcoin/bitcoin/pull/10598
4702017-06-16T19:37:29 *** Dyaheon has joined #bitcoin-core-dev
4712017-06-16T19:47:59 *** hihi has joined #bitcoin-core-dev
4722017-06-16T19:50:59 <sipa> cfields: we're using gcc 4.8 for win and linux builds, which i think has a sufficiently mature LTO implementation; any opinion on using it in release builds?
4732017-06-16T19:51:15 <sipa> i don't know the status of LTO in clang
4742017-06-16T19:51:28 *** owowo has quit IRC
4752017-06-16T19:52:16 <cfields> sipa: my main concern is that we could see a discrepancy between release binaries and what devs run
4762017-06-16T19:52:40 <sipa> cfields: why?
4772017-06-16T19:52:41 <cfields> as even with gcc7, linking still takes a long time. I don't think we could enable it by default, it'd have to be in gitian
4782017-06-16T19:53:07 <sipa> it does take less memory too
4792017-06-16T19:53:34 *** laurentmt has joined #bitcoin-core-dev
4802017-06-16T19:53:36 <sipa> maybe a generic "optimized build" available from configure and one that isn't, and gitian uses optimized
4812017-06-16T19:53:42 *** laurentmt has quit IRC
4822017-06-16T19:53:45 <cfields> (not opposed, just considering the downsides)
4832017-06-16T19:53:58 <sipa> it's a good point to bring up
4842017-06-16T19:54:22 <sipa> i like that it categorically removes the concern about whether code needs to go in a header or not :)
4852017-06-16T19:54:23 <cfields> sipa: yea, that sounds reasonable
4862017-06-16T19:54:31 <cfields> heh
4872017-06-16T19:54:58 *** RubenSomsen has joined #bitcoin-core-dev
4882017-06-16T19:55:12 <cfields> speaking of which, i worked on pre-compiled headers a few days ago. Shaved roughly ~30% off of build time
4892017-06-16T19:55:48 <cfields> sipa: another one of the big benefits is that our deps can be lto'd as well. I suspect static lto'd qt would be a big win for filesize
4902017-06-16T19:55:55 <cfields> but again, that makes linking take forever
4912017-06-16T19:56:44 *** owowo has joined #bitcoin-core-dev
4922017-06-16T19:57:19 * cfields kicks off an lto'd qt build out of curiosity
4932017-06-16T19:59:36 <TD-Linux> cfields, https://git.xiph.org/?p=opus.git;a=blob;f=celt/x86/x86cpu.c;h=080eb25e413d9e6587a419933d85ea9a6243b46e;hb=HEAD#l61
4942017-06-16T20:00:41 <jonasschnelli> TD-Linux: hah. Always research first how other did it. ;)
4952017-06-16T20:02:10 <jonasschnelli> *others
4962017-06-16T20:02:33 *** spudowiar has quit IRC
4972017-06-16T20:03:13 <cfields> heh, yep
4982017-06-16T20:05:14 *** RubenSomsen has quit IRC
4992017-06-16T20:09:13 <luke-jr> has anyone benchmarked LTO vs normal?
5002017-06-16T20:14:41 *** pandabul_ has quit IRC
5012017-06-16T20:21:42 *** Gnof has quit IRC
5022017-06-16T20:22:04 *** pandabull has joined #bitcoin-core-dev
5032017-06-16T20:22:16 *** dermoth has quit IRC
5042017-06-16T20:23:07 *** pandabull has quit IRC
5052017-06-16T20:23:44 *** pandabull has joined #bitcoin-core-dev
5062017-06-16T20:24:32 <luke-jr> jonasschnelli: please add sources for companies you add to https://en.bitcoin.it/wiki/Segwit_support
5072017-06-16T20:29:26 *** arubi has quit IRC
5082017-06-16T20:29:32 *** dermoth has joined #bitcoin-core-dev
5092017-06-16T20:30:22 *** arubi has joined #bitcoin-core-dev
5102017-06-16T20:45:01 *** RubenSomsen has joined #bitcoin-core-dev
5112017-06-16T20:49:08 *** dermoth has quit IRC
5122017-06-16T20:53:04 <bitcoin-git> [bitcoin] luke-jr opened pull request #10615: RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet (master...multiwallet_rpc) https://github.com/bitcoin/bitcoin/pull/10615
5132017-06-16T21:18:40 *** chjj has quit IRC
5142017-06-16T21:27:50 *** laurentmt has joined #bitcoin-core-dev
5152017-06-16T21:28:12 *** laurentmt has quit IRC
5162017-06-16T21:29:07 *** pandabull has quit IRC
5172017-06-16T21:30:06 *** halo has joined #bitcoin-core-dev
5182017-06-16T21:30:22 *** herzmeister[m] has joined #bitcoin-core-dev
5192017-06-16T21:31:15 *** chjj has joined #bitcoin-core-dev
5202017-06-16T21:34:08 *** kewde[m] has joined #bitcoin-core-dev
5212017-06-16T21:34:09 *** frabrunelle has joined #bitcoin-core-dev
5222017-06-16T21:34:15 *** draadpiraat[m] has joined #bitcoin-core-dev
5232017-06-16T21:35:53 *** halo has quit IRC
5242017-06-16T21:41:42 *** Dyaheon has quit IRC
5252017-06-16T21:42:37 *** Dyaheon has joined #bitcoin-core-dev
5262017-06-16T21:50:08 *** RubenSomsen has quit IRC
5272017-06-16T21:53:57 *** RubenSomsen has joined #bitcoin-core-dev
5282017-06-16T22:03:33 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7a74f88a26cf...d76e84a21416
5292017-06-16T22:03:34 <bitcoin-git> bitcoin/master 131a8ce practicalswift: Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >)
5302017-06-16T22:03:34 <bitcoin-git> bitcoin/master d76e84a Pieter Wuille: Merge #10602: Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >)...
5312017-06-16T22:04:12 <bitcoin-git> [bitcoin] sipa closed pull request #10602: Make clang-format use C++11 features (e.g. A<A<int>> instead of A<A<int> >) (master...clang-format-cpp11) https://github.com/bitcoin/bitcoin/pull/10602
5322017-06-16T22:08:30 *** shesek has quit IRC
5332017-06-16T22:16:25 *** Aaronvan_ has joined #bitcoin-core-dev
5342017-06-16T22:17:48 *** AaronvanW has quit IRC
5352017-06-16T22:21:07 *** Giszmo has joined #bitcoin-core-dev
5362017-06-16T22:24:44 *** chjj has quit IRC
5372017-06-16T22:33:46 *** griswaalt has quit IRC
5382017-06-16T22:34:20 *** griswaalt has joined #bitcoin-core-dev
5392017-06-16T22:38:50 *** chjj has joined #bitcoin-core-dev
5402017-06-16T22:42:58 <midnightmagic> eek why is there only two of us signing the windows signed executables :-P
5412017-06-16T22:45:20 *** goatpig has quit IRC
5422017-06-16T23:04:47 <cfields> sipa: I'm confused about https://github.com/bitcoin-core/leveldb/commit/196962ff01c39b4705d8117df5c3f8c205349950
5432017-06-16T23:05:06 <cfields> how does that manage to link? there's no definition that returns zero
5442017-06-16T23:05:22 <sipa> cfields: the implementation is in posix_sse.c
5452017-06-16T23:05:30 <sipa> which apparently gets linked in
5462017-06-16T23:06:07 <cfields> sipa: ah, that's our problem then. leveldb's build doesn't link that in
5472017-06-16T23:06:16 <cfields> ...but that would mean windows is broken upstream
5482017-06-16T23:06:24 <sipa> windows does not _exist_ upstream
5492017-06-16T23:06:33 <cfields> oooooh :)
5502017-06-16T23:07:02 <cfields> hehe, got it. will fix.
5512017-06-16T23:08:28 <cfields> i see. so we patched up their build discovery stuff at one point, but stopped when we migrated it into our build
5522017-06-16T23:08:47 <sipa> right, and we don't run the tests for the windows build
5532017-06-16T23:09:58 <cfields> got it, thanks
5542017-06-16T23:18:48 *** sanada` has joined #bitcoin-core-dev
5552017-06-16T23:19:36 *** griswaal_ has joined #bitcoin-core-dev
5562017-06-16T23:21:12 *** ananteri1 has joined #bitcoin-core-dev
5572017-06-16T23:22:09 *** sdaftuar_ has joined #bitcoin-core-dev
5582017-06-16T23:22:12 *** PaulCapestany has quit IRC
5592017-06-16T23:24:44 *** ryanofsky_ has joined #bitcoin-core-dev
5602017-06-16T23:25:04 *** phantomcircuit_ has joined #bitcoin-core-dev
5612017-06-16T23:26:05 *** chjj has quit IRC
5622017-06-16T23:26:13 *** griswaalt has quit IRC
5632017-06-16T23:26:13 *** sanada has quit IRC
5642017-06-16T23:26:14 *** Soligor has quit IRC
5652017-06-16T23:26:14 *** [b__b] has quit IRC
5662017-06-16T23:26:14 *** phantomcircuit has quit IRC
5672017-06-16T23:26:14 *** ananteris has quit IRC
5682017-06-16T23:26:14 *** ryanofsky has quit IRC
5692017-06-16T23:26:14 *** AdrianG has quit IRC
5702017-06-16T23:26:14 *** sdaftuar has quit IRC
5712017-06-16T23:26:14 *** morcos has quit IRC
5722017-06-16T23:26:21 *** ananteri1 is now known as ananteris
5732017-06-16T23:26:24 *** [b__b] has joined #bitcoin-core-dev
5742017-06-16T23:26:25 *** ananteris has quit IRC
5752017-06-16T23:26:26 *** ananteris has joined #bitcoin-core-dev
5762017-06-16T23:27:28 *** Dyaheon has quit IRC
5772017-06-16T23:27:28 *** Soligor has joined #bitcoin-core-dev
5782017-06-16T23:30:45 *** Dyaheon has joined #bitcoin-core-dev
5792017-06-16T23:31:03 *** AdrianG has joined #bitcoin-core-dev
5802017-06-16T23:35:40 *** morcos has joined #bitcoin-core-dev
5812017-06-16T23:36:42 *** griswaal_ has quit IRC
5822017-06-16T23:37:08 <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d76e84a21416...de8db47b7ff3
5832017-06-16T23:37:08 <bitcoin-git> bitcoin/master f2fb132 practicalswift: Net: Fix resource leak in ReadBinaryFile(...)...
5842017-06-16T23:37:09 *** griswaalt has joined #bitcoin-core-dev
5852017-06-16T23:37:09 <bitcoin-git> bitcoin/master de8db47 Pieter Wuille: Merge #10587: Net: Fix resource leak in ReadBinaryFile(...)...
5862017-06-16T23:37:35 <bitcoin-git> [bitcoin] sipa closed pull request #10587: Net: Fix resource leak in ReadBinaryFile(...) (master...fopen-not-followed-by-fclose-in-all-states-of-the-universe) https://github.com/bitcoin/bitcoin/pull/10587
5872017-06-16T23:38:42 *** abpa has quit IRC
5882017-06-16T23:40:17 *** chjj has joined #bitcoin-core-dev