1 2016-11-15 00:46:00	0|sipa|achow101: i believe they never have been
  2 2016-11-15 00:49:06	0|achow101|well they're listed here: https://bitcoin.org/en/about-us#sponsorship
  3 2016-11-15 01:13:21	0|shinyg|so was there a specific reason why new releases stopped coming from bitcoin.org?
  4 2016-11-15 01:13:56	0|sipa|they're still published there
  5 2016-11-15 01:14:11	0|sipa|but bitcoin core has its own project website now
  6 2016-11-15 01:14:27	0|achow101|they're trying to separate bitcoin core from bitcoin.org as bitcoin.org is for bitcoin in general whilst bitcoin core is a specific project
  7 2016-11-15 01:15:09	0|shinyg|makes sense, how about is Bitcoin Core a Solution stack or software as some describe it/
  8 2016-11-15 01:17:11	0|shinyg|Maybe bitcoin is a software stack but Core is just software
  9 2016-11-15 01:28:17	0|Squidicuz|sipa, cool. I take it that site is bitcoincore.org, right?
 10 2016-11-15 01:28:40	0|achow101|Squidicuz: yes, bitcoincore.org is Bitcoin Core's site
 11 2016-11-15 01:29:10	0|Squidicuz|just double checking. ty
 12 2016-11-15 01:29:13	0|Squidicuz|:)
 13 2016-11-15 01:29:27	0|tulip|shinyg: with tools like gitian there's no real need for a canonical binary source.
 14 2016-11-15 01:31:17	0|Squidicuz|...I'm a little late
 15 2016-11-15 01:43:55	0|moli|sipa, hi, could you update your graph?
 16 2016-11-15 01:45:29	0|sipa|which?
 17 2016-11-15 01:45:38	0|achow101|bip9 bits graph
 18 2016-11-15 01:45:48	0|sipa|oh, will do
 19 2016-11-15 01:45:55	0|sipa|before the 18th
 20 2016-11-15 01:46:15	0|moli|ah still too early? ok, thanks, sipa :)
 21 2016-11-15 01:46:33	0|sipa|yes, first retarget after the 15th midnight utc
 22 2016-11-15 01:46:36	0|achow101|miners can signal now, right? just that it won't matter because the retarget period is almsot over
 23 2016-11-15 01:46:50	0|btcdrak|at this rate of acceleration it might just at the end of 17th...
 24 2016-11-15 01:46:53	0|sipa|them signalling right now will trigger the unknown softfork warning
 25 2016-11-15 01:47:25	0|achow101|oh, that's interesting
 26 2016-11-15 01:47:46	0|btcdrak|sipa: would those trigger while in the defined state?
 27 2016-11-15 01:48:10	0|btcdrak|oh nvm, ofc it will trigger, derp
 28 2016-11-15 01:48:37	0|achow101|why would it trigger?
 29 2016-11-15 01:50:48	0|achow101|oh, is it because it is still in the defined state, not started?
 30 2016-11-15 01:50:53	0|sipa|indeed
 31 2016-11-15 01:51:09	0|sipa|so it would be seen as signalling for an unrelated fork
 32 2016-11-15 01:52:04	0|sipa|which the current software does not know about
 33 2016-11-15 01:52:24	0|achow101|why are the two graphs on the segwit adoption page on opposite ends of the page? also, chrome is super not liking that sipa's website doesn't have https for those graphs
 34 2016-11-15 02:07:13	0|shinyg|thanks for the replies sipa and wiki contribs achow
 35 2016-11-15 02:52:43	0|achow101|wut
 36 2016-11-15 03:08:53	0|phantomcircuit|#8831
 37 2016-11-15 03:08:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/8831 | Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue by pstratem · Pull Request #8831 · bitcoin/bitcoin · GitHub
 38 2016-11-15 03:08:55	0|phantomcircuit|please
 39 2016-11-15 03:08:57	0|phantomcircuit|someone
 40 2016-11-15 03:08:59	0|phantomcircuit|review
 41 2016-11-15 03:09:02	0|phantomcircuit|please
 42 2016-11-15 06:20:07	0|gmaxwell|looks like some folks are signaling segwit prematurely.
 43 2016-11-15 06:59:33	0|midnightmagic|:-o
 44 2016-11-15 07:00:32	0|gmaxwell|Not harmful, but it's more evidence for my concern that version has been burned for consensus critical use.
 45 2016-11-15 07:00:53	0|gmaxwell|I blame Luke. :P
 46 2016-11-15 07:02:54	0|luke-jr|☹
 47 2016-11-15 07:05:07	0|gmaxwell|I think the big interface error is that mining exposes gnarly consensus internals to people who are not primarily interested in them but instead have simpler (though critical) goals like: Get mining working fast and reliably.
 48 2016-11-15 07:06:07	0|gmaxwell|E.g. it's not a good seperation of concerns. I don't have any doubt that any of the pool ops couldn't be great consensus plumbers if they wanted to be, but when they're hacking on pool software that isn't what they're trying to do.
 49 2016-11-15 07:06:14	0|luke-jr|yes, in hindsight it may have been better to do a more stratum-like getwork replacement in bitcoind (but that had its own share of problems)
 50 2016-11-15 07:06:39	0|luke-jr|by separation of this, we did gain a few things: miners can upgrade easier now than with 0.3+tons of patching
 51 2016-11-15 07:06:58	0|gmaxwell|We could be much worse off for sure.
 52 2016-11-15 07:07:38	0|luke-jr|I tried to make it simpler by having a GBT client library (libblkmaker), but it seems it isn't in any real use outside of BFGMiner
 53 2016-11-15 07:10:26	0|gmaxwell|One of the lessons (which I already knew from before) is that having a 'bad' interface, then a 'make it friendly' layer often doesn't work.  People will either never find the friendlyness layer, or not use it because your own test cases don't (which they look at to understand the interface), will encounter some limitation in it and go raw, or otherwise insist on doing their own for some better o
 54 2016-11-15 07:10:32	0|gmaxwell|r worse reason.
 55 2016-11-15 07:12:42	0|gmaxwell|I explirenced this with libvorbis, which had a vorbisfile API which was 100x easier to use right than the raw interface, included with the same library... and mostly used, but still bypassed often enough to cause frequent bogus support issues that would have been avoided by using vorbisfile. ...  and especially with liboggz which is a high level interface to many ogg embedded formats and ogg han
 56 2016-11-15 07:12:48	0|gmaxwell|dling which handles most of the gnarly stuff, ... and which virtually no one uses... instead implementing the same functionality themselves, usually incorrectly.
 57 2016-11-15 07:13:24	0|luke-jr|:/
 58 2016-11-15 07:14:10	0|jl2012|which block is signalling segwit?
 59 2016-11-15 07:14:24	0|gmaxwell|Then Opus (which has a much more carefully contstructed raw API) didn't ship with a opusfile (analog of the vorbisfile high level API), and relative usage of opusfile is probably 100x lower than vorbisfile.  Shipping it with it as a single package makes a big difference.
 60 2016-11-15 07:15:49	0|gmaxwell|jl2012: 438958 and 438914 I think.
 61 2016-11-15 07:16:30	0|jl2012|oh, slush
 62 2016-11-15 07:17:39	0|gmaxwell|luke-jr: in any case, the general advice I think we should follow is whe should always imagine the goals of the person using an API, and them assume that they will only correctly handle any non-trivial steps that were obvious from a statement of their goals.
 63 2016-11-15 07:19:36	0|gmaxwell|Like an API for signing should not ask the signer to provide a nonce that must obey some byzantine set of security requirements. Their goal was signing, not generating random numbers.  If it's easy to get it working without getting it right, it's a cointoss if they'll get it right or not.  (I don't mean this in a superior or condecending way-- it's human nature to get tunnel vision around your o
 64 2016-11-15 07:19:42	0|gmaxwell|wn goals).
 65 2016-11-15 07:21:03	0|gmaxwell|plus, expecting people to worry about details that aren't related to their goals is a failure to respect their time.
 66 2016-11-15 08:46:40	0|wumpus|it doesn't help that 'friendly' layers have a reputation to increase overhead and make things slower, deserved or not
 67 2016-11-15 08:48:51	0|wumpus|so this may be mainly an issue for cases where there are (perceived) performance concerns, like with media APIs and mining... people always clamoring for a more 'raw' interface instead of a 'friendly' one. Same for 3D rendering with the Vulkan instead of OpenGL interface. "closer to the hardware" etc
 68 2016-11-15 08:52:44	0|bitcoin-git|13bitcoin/06master 14ec34648 15Russell Yanofsky: [trivial] Fix hungarian variable name...
 69 2016-11-15 08:52:44	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b42291334651...770364b8eaf7
 70 2016-11-15 08:52:45	0|bitcoin-git|13bitcoin/06master 14770364b 15Wladimir J. van der Laan: Merge #9160: [trivial] Fix hungarian variable name...
 71 2016-11-15 08:52:59	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9160: [trivial] Fix hungarian variable name (06master...06hungarian) 02https://github.com/bitcoin/bitcoin/pull/9160
 72 2016-11-15 08:57:49	0|wumpus|also some attempts at friendly interfaces have actually made things harder by abstracting away details that matter, causing the API user to do brittle or nonsensical things when you see the whole picture. Or including scope/dependencies which are not necessary for a project (e.g. texture loaders for 33 image formats while the game only needs one). Good API/library design is hard and both
 73 2016-11-15 08:57:55	0|wumpus|commercial projects and open source projects have a lot of sins there
 74 2016-11-15 09:02:22	0|wumpus|the best way of 'imagining the goal of the person using the API' is probably to be a user of the API yourself, instead of just guessing to imagine what the goal of a user of the API could be. With mining we have some issues there because there are so few miners involved with development at any level :(
 75 2016-11-15 09:06:30	0|bitcoin-git|13bitcoin/06master 14f734505 15Jonas Schnelli: Make strWalletFile const
 76 2016-11-15 09:06:30	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/770364b8eaf7...f54e4605fc31
 77 2016-11-15 09:06:31	0|bitcoin-git|13bitcoin/06master 14f54e460 15Wladimir J. van der Laan: Merge #9132: Make strWalletFile const...
 78 2016-11-15 09:06:46	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9132: Make strWalletFile const (06master...062016/11/strWalletFile_const) 02https://github.com/bitcoin/bitcoin/pull/9132
 79 2016-11-15 09:12:54	0|jonasschnelli|wumpus: would a configuration option for a specific block-files path make sense?
 80 2016-11-15 09:14:11	0|jonasschnelli|paveljanik: what do you mean with ""Conditionalize" QR on QT?"?
 81 2016-11-15 09:14:26	0|wumpus|yes - however that needs more infrastructure than just adding an option. If bitcoind's state can be distributed over multiple places, those all need a 'datadir lock'
 82 2016-11-15 09:14:43	0|paveljanik|jonasschnelli, I qt = yes then echo $QR;
 83 2016-11-15 09:14:46	0|wumpus|the symbolic link hack is unsupported but works
 84 2016-11-15 09:14:56	0|paveljanik|ie if Qt is disabled, no need to print info on QR
 85 2016-11-15 09:15:22	0|wumpus|an official option + infrastructure for it would make it slightly harder to shoot yourself in the foot though, as people will try to share a blocks directory between instances and shit like that
 86 2016-11-15 09:15:26	0|jonasschnelli|wumpus: Yes. Dir locking would be required. You mean with a simple .lock file?
 87 2016-11-15 09:15:45	0|wumpus|jonasschnelli: exactly the same as we do for the data directory
 88 2016-11-15 09:16:05	0|jonasschnelli|wumpus: Okay. Thanks...
 89 2016-11-15 09:16:14	0|wumpus|however, there's a snag: locking doesn't work very well on remote filesystems
 90 2016-11-15 09:16:18	0|jonasschnelli|paveljanik: Yes. This makes sense.
 91 2016-11-15 09:16:30	0|jonasschnelli|Also, not sure how easy it would be to print out the Qt version...
 92 2016-11-15 09:16:44	0|wumpus|you don't need to print the qt version - just 4 or 6
 93 2016-11-15 09:16:47	0|wumpus|eh, 5
 94 2016-11-15 09:17:15	0|luke-jr|yeah, probably don't need the exact version
 95 2016-11-15 09:17:50	0|wumpus|printing the exact version is possible if pkgconfig was used, but it's not really what people care about usually
 96 2016-11-15 09:18:20	0|wumpus|+the minor versions can change if the distribution version is upgraded and shared libraries are used
 97 2016-11-15 09:18:28	0|wumpus|the major version is a compile-time decision
 98 2016-11-15 09:18:49	0|luke-jr|good point, for that reason it's actually preferable to only print major
 99 2016-11-15 09:19:03	0|jonasschnelli|Yes. But I guess getting the version number in configure.ac would require changes in the bitcoin-qt m4 macro.
100 2016-11-15 09:19:17	0|wumpus|jonasschnelli: yese, don't get stuck in that rabbit hole, just print the major version
101 2016-11-15 09:19:29	0|jonasschnelli|Will have a look
102 2016-11-15 09:20:22	0|wumpus|though possible that needs deeper autoconf changes too, as the macro needs to export the version, but maybe it alredy does as the major version is printed while configure is running
103 2016-11-15 09:24:14	0|jonasschnelli|Indeed. Will have a look.
104 2016-11-15 09:35:23	0|bitcoin-git|13bitcoin/06master 14b74ff5c 15Luke Dashjr: Bugfix: Correctly replace generated headers and fail cleanly...
105 2016-11-15 09:35:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f54e4605fc31...018a4eb120dc
106 2016-11-15 09:35:24	0|bitcoin-git|13bitcoin/06master 14018a4eb 15Wladimir J. van der Laan: Merge #9140: Bugfix: Correctly replace generated headers and fail cleanly...
107 2016-11-15 09:35:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9140: Bugfix: Correctly replace generated headers and fail cleanly (06master...06bugfix_genheaders) 02https://github.com/bitcoin/bitcoin/pull/9140
108 2016-11-15 10:18:15	0|phantomcircuit|sipa: thanks for the review
109 2016-11-15 10:18:16	0|phantomcircuit|but why
110 2016-11-15 11:02:37	0|thrasher`|hey all, just wondering how https://github.com/bitcoin/bitcoin/blob/master/src/qt/test/paymentrequestdata.h#L440 this request was generated?
111 2016-11-15 11:30:37	0|bitcoin-git|[13bitcoin] 15jonathan0405 opened pull request #9162: Ict block (06master...06ict) 02https://github.com/bitcoin/bitcoin/pull/9162
112 2016-11-15 11:33:18	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9162: Ict  (06master...06ict) 02https://github.com/bitcoin/bitcoin/pull/9162
113 2016-11-15 12:15:40	0|wumpus|thrasher`: no idea; there must be some code out there to generate payment requests, but I don't know any specific one
114 2016-11-15 14:20:16	0|bitcoin-git|[13bitcoin] 15instagibbs opened pull request #9164: [trivial] credit values are CAmount (06master...06intcredit) 02https://github.com/bitcoin/bitcoin/pull/9164
115 2016-11-15 14:38:43	0|sdaftuar|thrasher`: i don't know where that test case came from, but i do recall this github comment that may be of help: https://github.com/bitcoin/bitcoin/pull/5620#issuecomment-69351549
116 2016-11-15 15:30:41	0|jonasschnelli|This one is easy to review if someone has 2-3 minutes of boringness: https://github.com/bitcoin/bitcoin/pull/9142
117 2016-11-15 15:41:36	0|thermoman|hi there. just upgraded a 0.11.2 node to 0.13.1 and found out that RPC calls "listtransaction" doesn't work anymore
118 2016-11-15 15:41:44	0|thermoman|bitcoin-cli says can't parse reply
119 2016-11-15 15:42:01	0|thermoman|tcpdump reveals that the answer is sent to the client, looks like valid jason
120 2016-11-15 15:42:23	0|thermoman|EXCEPT: there are non-utf8 chars mixed in between in the comments associated with some TXs
121 2016-11-15 15:42:42	0|thermoman|like 0xFC for german umlaut ü (ue)
122 2016-11-15 15:42:58	0|thermoman|latin1 1byte instead of utf8 two bytes
123 2016-11-15 15:43:36	0|jonasschnelli|thermoman: I'm just trying to reproduce this
124 2016-11-15 15:43:41	0|thermoman|so now I'm stuck and luke-jr suggested starting a discussion here about how to handle non-utf8 wallets
125 2016-11-15 15:45:38	0|jonasschnelli|thermoman: Just did: sendtoaddress(getnewaddress(), 1, "Dr Schmöörenbröd, Bèrtälzç")
126 2016-11-15 15:45:51	0|jonasschnelli|listtransaction works (in Qt though):  "comment": "Dr Schmöörenbröd, Bèrtälzç",
127 2016-11-15 15:45:55	0|jonasschnelli|Now testing bitcoin-cli
128 2016-11-15 15:46:27	0|jonasschnelli|works as well
129 2016-11-15 15:46:31	0|thermoman|but what about comments entered in 0.11.2 or even before?
130 2016-11-15 15:46:48	0|jonasschnelli|hmm... yes.
131 2016-11-15 15:46:54	0|jonasschnelli|Give me your wallet.dat. :)
132 2016-11-15 15:47:07	0|jonasschnelli|Let me check the code
133 2016-11-15 15:47:10	0|thermoman|with the RPC calls there the client would send umlauts as latin1 instead of utf8
134 2016-11-15 15:47:48	0|jonasschnelli|thermoman: does it work for you when you create (temporary) a new wallet and send tx with a comment with umlaute?
135 2016-11-15 15:48:03	0|thermoman|didn't try this yet
136 2016-11-15 15:48:10	0|jonasschnelli|Maybe give it a try...
137 2016-11-15 15:49:19	0|luke-jr|jonasschnelli: most likely your sendtoaddress call used UTF-8? :p
138 2016-11-15 15:50:25	0|jonasschnelli|Yeah. I guess you can get stuck with a wtx holding an latin1 char. But why does that break JSON parsing?
139 2016-11-15 15:51:22	0|jonasschnelli|Hmm.. thinking of an easy solution.. i guess there is non.
140 2016-11-15 15:51:23	0|luke-jr|because we just send the wtx comment as-is, Univalue passes it through as-is, and valid JSON may only use UTF-8
141 2016-11-15 15:51:58	0|jonasschnelli|I guess best solution is to fiddle with the BDB file directly
142 2016-11-15 15:52:05	0|jonasschnelli|remove the char there...
143 2016-11-15 15:52:14	0|jonasschnelli|But I wouldn't do that with a hex editor.
144 2016-11-15 15:52:24	0|jonasschnelli|Maybe some berkley-db tool
145 2016-11-15 15:53:14	0|thermoman|there is db_dump
146 2016-11-15 15:53:33	0|thermoman|but i'm not sure I will see the text in plain there to be edited
147 2016-11-15 15:54:26	0|rafalcpp|maybe rebuild the bitcoind with a path that replaces the comment field with empty string when generating rpc reply?
148 2016-11-15 15:54:33	0|rafalcpp|*patch
149 2016-11-15 15:55:00	0|thermoman|If there was an official patch I would like to test that
150 2016-11-15 16:00:13	0|thermoman|do I need to open an issue on github or how will this be handled the best way?
151 2016-11-15 16:00:27	0|jonasschnelli|thermoman: Yes. Opening an issue would be good.
152 2016-11-15 16:00:42	0|jonasschnelli|I guess we should patch this, though not sure what priority this will have
153 2016-11-15 16:01:19	0|jonasschnelli|Comments are used rarely, and even more rarely with non-utf8 compatible chars.
154 2016-11-15 16:01:28	0|jonasschnelli|But feel free to fix it. :)
155 2016-11-15 17:44:33	0|bitcoin-git|13bitcoin/06master 1420c3215 15Gregory Sanders: credit values are CAmount
156 2016-11-15 17:44:33	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/018a4eb120dc...6eeac6e30d65
157 2016-11-15 17:44:34	0|bitcoin-git|13bitcoin/06master 146eeac6e 15Pieter Wuille: Merge #9164: [trivial] credit values are CAmount...
158 2016-11-15 17:44:49	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9164: [trivial] credit values are CAmount (06master...06intcredit) 02https://github.com/bitcoin/bitcoin/pull/9164
159 2016-11-15 18:01:39	0|bitcoin-git|[13bitcoin] 15instagibbs opened pull request #9165: [trivial] SendMoney: use already-calculated balance (06master...06triv-curbal) 02https://github.com/bitcoin/bitcoin/pull/9165
160 2016-11-15 18:12:46	0|thermoman|jonasschnelli, luke-jr: https://github.com/bitcoin/bitcoin/issues/9166
161 2016-11-15 18:14:47	0|timothy|[
162 2016-11-15 18:14:47	0|timothy|]
163 2016-11-15 18:14:47	0|timothy|drizzt@liara ~ %
164 2016-11-15 18:14:47	0|timothy|drizzt@liara ~ % bitcoin-cli listtransactions '*' 2
165 2016-11-15 18:14:55	0|sipa|sdaftuar: i have a branch sharedblock2 (which is rebased on top of #8589) that includes making the orphanmap and ATMT use shared_ptrs
166 2016-11-15 18:14:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
167 2016-11-15 18:15:31	0|sdaftuar|sipa: thanks, i found it yesterday and am working off it
168 2016-11-15 18:15:42	0|thermoman|timothy: empty wallet?
169 2016-11-15 20:30:34	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9167: IsAllFromMe (06master...06IsAllFromMe) 02https://github.com/bitcoin/bitcoin/pull/9167
170 2016-11-15 20:46:30	0|bitcoin-git|[13bitcoin] 15mrbandrews opened pull request #9168: [qa] add assert_raises_message to check specific error message (06master...06ba-assert-raises) 02https://github.com/bitcoin/bitcoin/pull/9168
171 2016-11-15 21:14:22	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9169: build: fix qt5.7 build under macOS (06master...06fix-objcxx-std) 02https://github.com/bitcoin/bitcoin/pull/9169
172 2016-11-15 21:15:30	0|cfields|morcos: ^^
173 2016-11-15 21:20:53	0|morcos|cfields: thanks.  i did a make clean and re-autogen/configure.  if that's sufficient to test it, it works
174 2016-11-15 21:22:23	0|cfields|morcos: assuming bitcoin-qt build succeeds after that, then yes, that's enough
175 2016-11-15 21:22:37	0|morcos|cfields: ha ha. yes.
176 2016-11-15 21:23:01	0|cfields|great, thanks for the quick test
177 2016-11-15 21:23:37	0|morcos|cfields: pretty please PR the prevector move commit too...
178 2016-11-15 21:24:13	0|cfields|morcos: uhm, sure. I never fully cleaned it up, but I suppose I can pr the bit that's already done
179 2016-11-15 21:24:26	0|cfields|morcos: though I should think it would matter much less after the shared_ptr merge?
180 2016-11-15 21:25:48	0|cfields|#9125, that is
181 2016-11-15 21:25:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
182 2016-11-15 21:25:57	0|morcos|i can try again, but it has consistently made a difference to me, not sure its just in txs that it matters
183 2016-11-15 21:31:21	0|cfields|morcos: ok, i'll PR a very simplified version
184 2016-11-15 22:06:56	0|cfields|morcos: top two commits here: https://github.com/theuni/bitcoin/commits/prevector-move
185 2016-11-15 22:07:38	0|cfields|morcos: mind seeing if you get the same speedup from those? I'd be much more comfortable PRing that than the set of much bigger changes
186 2016-11-15 22:08:37	0|morcos|cfields: no problem, but will have to wait til tomorrow now...
187 2016-11-15 22:09:06	0|cfields|morcos: np