1 2016-09-14 06:32:59	0|GitHub186|13bitcoin/06master 141b6bcdd 15Jonas Schnelli: Remove maxuploadtargets recommended minimum
  2 2016-09-14 06:32:59	0|GitHub186|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fa7caf6d9116...57b34599b2de
  3 2016-09-14 06:33:00	0|GitHub186|13bitcoin/06master 1457b3459 15Jonas Schnelli: Merge #8712: Remove maxuploadtargets recommended minimum...
  4 2016-09-14 06:33:09	0|GitHub42|[13bitcoin] 15jonasschnelli closed pull request #8712: Remove maxuploadtargets recommended minimum (06master...062016/09/rem_maxupt_min) 02https://github.com/bitcoin/bitcoin/pull/8712
  5 2016-09-14 06:48:49	0|jonasschnelli|I guess the Travis master issue is due to a random flickering in walletbackup.py
  6 2016-09-14 06:50:43	0|jonasschnelli|Would be nice if anyone could review/ACK/NACK https://github.com/bitcoin/bitcoin/pull/7783 (nested RPC commands).
  7 2016-09-14 06:51:38	0|dcousens|jonasschnelli: how would you extend it to the RPC?
  8 2016-09-14 06:52:10	0|jonasschnelli|dcousens: there are no plans to extend it to the RPC layer... the PR once had support for RPC but we decided to keep it QT only for now.
  9 2016-09-14 06:52:40	0|jonasschnelli|Moving the function RPCExecuteCommandLine(std::string &strResult, const std::string &strCommand) to a core class would be trivial.
 10 2016-09-14 06:53:13	0|jonasschnelli|We could either have a special RPC command that result in parsing and executing multiple nested commands...but I don't think this would be clever.
 11 2016-09-14 06:53:26	0|jonasschnelli|The Qt version is "client-side".
 12 2016-09-14 06:53:41	0|jonasschnelli|A better approach for the RPC layer would be to add it into bitcoin-cli
 13 2016-09-14 06:53:41	0|sipa|i'd have liked that, but it seems i was alone with that :)
 14 2016-09-14 06:54:14	0|jonasschnelli|Having it server-side i just fear some uncontrollable resource usage.
 15 2016-09-14 06:54:32	0|jonasschnelli|I think its better to start with it client-side QT only, and if it turns to be useful, add it to bitcoin-cli.
 16 2016-09-14 06:54:34	0|sipa|rpc already has uncontrollable resource usage
 17 2016-09-14 06:54:41	0|dcousens|Personally I just always used bash,  but I never use the QT UI so *shrug*
 18 2016-09-14 06:54:43	0|sipa|fair enough :)
 19 2016-09-14 06:55:17	0|jonasschnelli|dcousens: Adding in in Qt has less of exposures... a better test-bed .:)
 20 2016-09-14 06:55:27	0|jonasschnelli|*it
 21 2016-09-14 06:55:46	0|dcousens|As for the RPC extension, I think a special RPC command, say a mechanism to chain calls - makes sense, would feel like the idea by wumpus, but won't break all our RPC implementations
 22 2016-09-14 06:56:18	0|dcousens|s/break/require changing
 23 2016-09-14 06:56:59	0|dcousens|as for resource usage, RPC is already meant to be a "safe space", haha
 24 2016-09-14 06:57:17	0|sipa|well if we turn it into an RPC thing, we'd arguably want more discussion about what the "query language" will look like
 25 2016-09-14 06:57:34	0|sipa|as it may be harder to make incompatible changes latee
 26 2016-09-14 06:58:01	0|dcousens|sipa: absolutely, the amount of time to get right may not be worth the extra line/rpc call for the few times this matters :P
 27 2016-09-14 06:58:53	0|jonasschnelli|The query language is pretty homebrew and non-standard..
 28 2016-09-14 06:59:11	0|jonasschnelli|Also,... once we have it in RPC, people are going to see it as part of the API...
 29 2016-09-14 06:59:18	0|jonasschnelli|changes at this point will probably more "difficult".
 30 2016-09-14 06:59:36	0|jonasschnelli|Lets find out through Qt how it could work in RPC. :)
 31 2016-09-14 06:59:37	0|dcousens|ultimately any bulk usage of the RPC ends up seeing the piped network latency being completely insignificant... and chaining the commands won't lower the JSON bulk
 32 2016-09-14 06:59:59	0|dcousens|unless their doing it over an open network I suppose
 33 2016-09-14 07:00:03	0|sipa|jonasschnelli: yes, agree there
 34 2016-09-14 07:00:15	0|wumpus|what did I break?
 35 2016-09-14 07:00:39	0|jonasschnelli|;-)
 36 2016-09-14 07:01:30	0|sipa|wumpus: ?
 37 2016-09-14 07:01:48	0|wumpus|oh that, yes that's a simple extension to JSON batching that would allow chaining of return values
 38 2016-09-14 07:03:13	0|wumpus|don't know whether to propose it or not, I'm fairly sure their reply will be 'if you need this level of sophistication don't use JSON-RPC you noob'
 39 2016-09-14 07:03:35	0|sipa|who is they?
 40 2016-09-14 07:04:00	0|wumpus|the people who made the JSON RPC standard
 41 2016-09-14 07:04:03	0|dcousens|I think if the RTT time is more significant than the encoding of the data itself, and you want to optimize RPC, its very likely you have control over the node anyway, just write a small HTTP wrapper that does that over localhost for you/
 42 2016-09-14 07:05:11	0|dcousens|or hell... write a RPC command that does what you want
 43 2016-09-14 07:05:29	0|sipa|hah, yes
 44 2016-09-14 07:05:34	0|sipa|that's my approach usually :)
 45 2016-09-14 07:05:42	0|dcousens|as is mine :S
 46 2016-09-14 07:05:59	0|wumpus|the point is that we don't want the API clogged full of 'chain A and B' commands
 47 2016-09-14 07:06:07	0|wumpus|but for a local patch sure
 48 2016-09-14 07:06:31	0|wumpus|in the end  I think no one really has any convincing use-cases for this
 49 2016-09-14 07:06:48	0|dcousens|yup, we're all just lazy cause it means 1 more line
 50 2016-09-14 07:07:05	0|jonasschnelli|I think the RPC layer is for app to app communication
 51 2016-09-14 07:07:16	0|wumpus|I've had approximately zero replies on me JSON-RPC extension proposal, though I think it makes a lot of sense *if* people are seriously considering this
 52 2016-09-14 07:07:18	0|jonasschnelli|The Qt console is supposed to be a human command line interface
 53 2016-09-14 07:07:55	0|wumpus|yes, the RPC layer is for app to app communication, it is an API
 54 2016-09-14 07:07:58	0|jonasschnelli|The convenience of nested commands are probably on the client side
 55 2016-09-14 07:08:02	0|dcousens|wumpus: I'm against the idea,  just wasn't sure if the Qt change (#7783) was relevant
 56 2016-09-14 07:08:16	0|wumpus|dcousens: huh?
 57 2016-09-14 07:08:28	0|wumpus|no, qt has nothing to do with it
 58 2016-09-14 07:08:40	0|wumpus|that' just a user convenience
 59 2016-09-14 07:08:48	0|dcousens|indeed, hence ACK :)
 60 2016-09-14 07:09:15	0|wumpus|I mean with bitcoin-cli you have full access to bash' scripting/variable munging/etc capabilities, in the Qt console you don't, so this adds a bit of shell power to it
 61 2016-09-14 07:09:22	0|sipa|wumpus: oh, i had no idea that that chaining value idea was your proposal
 62 2016-09-14 07:10:11	0|gmaxwell|or the rpc console could just link in a lua/python/js engine, all of which are embedable.
 63 2016-09-14 07:10:14	0|wumpus|this is  a completely orthogonal concern from being able to chain values at the server side to avoid latency
 64 2016-09-14 07:10:22	0|wumpus|gmaxwell: :-(
 65 2016-09-14 07:10:52	0|gmaxwell|heh
 66 2016-09-14 07:10:54	0|wumpus|no interpreters in bitcoin please
 67 2016-09-14 07:11:04	0|wumpus|(apart from the one we really need)
 68 2016-09-14 07:11:06	0|dcousens|no more*
 69 2016-09-14 07:11:32	0|wumpus|having a powerful interpreter in the target executable makes exploitation so much easier
 70 2016-09-14 07:12:03	0|dcousens|maybe the CLI could just have an interactive mode with a LUA shell or something?
 71 2016-09-14 07:12:05	0|gmaxwell|well it could be a seperate interface, e.g. fancy-console.
 72 2016-09-14 07:12:15	0|dcousens|that way its not in the core as such
 73 2016-09-14 07:12:19	0|wumpus|dcousens: yes, that has been proposed, we could jut have a python-based interactive CLI
 74 2016-09-14 07:12:24	0|gmaxwell|I've only heard of five or six instances where the Js enable ethereum wallet stuff was used to trick people into sending away all their funds. :P
 75 2016-09-14 07:12:26	0|dcousens|bitcoin-cli*, that is
 76 2016-09-14 07:12:47	0|wumpus|dcousens: it could be based on ncurses, ipython, etc, that idea is old as the hills, yet no one wrote one :)
 77 2016-09-14 07:12:55	0|gmaxwell|but yes, not having it in the main binary would be obvious. I dunno, I think the utility is all that great.
 78 2016-09-14 07:12:57	0|wumpus|I thnk the current tools are jut ok
 79 2016-09-14 07:12:58	0|dcousens|wumpus: but jonasschnelli wrote this :P
 80 2016-09-14 07:13:14	0|wumpus|gmaxwell: right, it just doesn't matter that much, people like talking about this but it's no itch to scratch
 81 2016-09-14 07:13:19	0|wumpus|dcousens: yes, he did, and it works
 82 2016-09-14 07:13:22	0|wumpus|it's awesome
 83 2016-09-14 07:13:25	0|dcousens|haha,indeed
 84 2016-09-14 07:13:42	0|wumpus|let's not try to shed-paint it to death
 85 2016-09-14 07:14:01	0|gmaxwell|the standard python bitcoin json library that people get linked to is not at all reliable (gets disconnected and then throws exceptions, and has to be wrapped to be usable) and I don't see anyone even complaining about it.
 86 2016-09-14 07:14:31	0|wumpus|s/json/json-rpc   and you're right
 87 2016-09-14 07:15:05	0|dcousens|I've found it much easier to just always use a well-tested rpc library than use something "bitcoin tailored"
 88 2016-09-14 07:15:23	0|wumpus|which one are you using for your projects?
 89 2016-09-14 07:15:25	0|gmaxwell|json-rpc, yes.
 90 2016-09-14 07:15:50	0|wumpus|are there any RPC mechanisms that don't suck?
 91 2016-09-14 07:16:35	0|dcousens|wumpus: myself? as most of my work is in JS, I ended up using my own (haha) simply because all the batch interfaces sucked with error handling for well tested ones
 92 2016-09-14 07:16:40	0|wumpus|this presentation talks about people using MQTT for bitcoin wallet control, among other things:  https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Lucas-Lundgren-Light-Weight%20Protocol-Critical-Implications.pdf   of course, without authentication or encryption and on the public internet :)
 93 2016-09-14 07:17:11	0|wumpus|tl.dr: don't do that
 94 2016-09-14 07:17:18	0|luke-jr|[06:53:12] <jonasschnelli> We could either have a special RPC command that result in parsing and executing multiple nested commands…but I don't think this would be clever. <-- this would be useful if the RPC client was over a netwrok, to avoid round-trips and such
 95 2016-09-14 07:17:30	0|dcousens|but, my point was, even my own implementation has nothing to do bitcoin as such, its just an RPC implementation
 96 2016-09-14 07:17:43	0|jonasschnelli|Luke-Jr: Yes. The server-side nesting could save bandwidth...
 97 2016-09-14 07:18:17	0|luke-jr|FWIW, I both dislike and like the idea at the same time. >_<
 98 2016-09-14 07:18:23	0|gmaxwell|wumpus: What did we do in the embeded python json-rpc used in the tests to make it reliable? (or did we not and the test just run fast enough that it isn't an issue?)
 99 2016-09-14 07:18:28	0|wumpus|server-side promise pipelining aves some bandwidth, but it mostly saves *latency*
100 2016-09-14 07:18:45	0|jonasschnelli|Example: with RPC nesting, you could get the first outputs value of the second transactions of the bestblock with just one command ---> bandwith: a couple of bytes:
101 2016-09-14 07:19:05	0|jonasschnelli|s/:/.
102 2016-09-14 07:19:16	0|luke-jr|it's easier to support server-side expressions when bitcoind is split from the consensus stuff someday
103 2016-09-14 07:19:22	0|wumpus|gmaxwell: which issue do you exactly mean?
104 2016-09-14 07:19:42	0|luke-jr|("support" in a human manner, not technical)
105 2016-09-14 07:20:35	0|wumpus|gmaxwell: we did add some code to AuthServiceProxy._request to handle connection loss
106 2016-09-14 07:21:16	0|luke-jr|I think there's some RPC mechanism which does expressions already BTW
107 2016-09-14 07:21:38	0|wumpus|luke-jr: yes, it's old as the hills, "promise pipelining" is usually what it's called
108 2016-09-14 07:21:47	0|wumpus|luke-jr: capnproto does it for example
109 2016-09-14 07:22:04	0|wumpus|I think even CORBA could do it in the 90's, but don't look for that, it'll turn you crazy
110 2016-09-14 07:22:36	0|wumpus|XCB (X11's RPC protocol) can do it too
111 2016-09-14 07:22:41	0|gmaxwell|wumpus: varrious forms of connection loss; bitcoind either times out the persistant connection then any other interaction with the proxy object throws an exception, or I believe any case where bitcoind returns an error. I don't have a detailed list because I've always just soloved it by creating a wrapper that catches the exception and reconnects.
112 2016-09-14 07:23:28	0|wumpus|gmaxwell: the high-level problem is that AuthServiceProxy uses python's http mechanism in an unconventional way: it opens a connection to a HTTP server, and instead of immediately queuing a bunch of requests, it keeps the connection open
113 2016-09-14 07:23:55	0|wumpus|gmaxwell: which in principle is fine, web browsers also do that, but it needs code to handle the case where the remote server hung up on you
114 2016-09-14 07:24:14	0|wumpus|gmaxwell: stock AuthServiceProxy has no code for that, our version (in the tests) does
115 2016-09-14 07:24:28	0|luke-jr|it used to :x
116 2016-09-14 07:25:29	0|wumpus|no, it assumes a unwordly friendly RPC server that never disconnects. Which used to be the case, approximately, before the switch to evhttpd, which introduced (like any other HTTP server in the world) connection timeouts
117 2016-09-14 07:25:53	0|wumpus|(but network problems can *also* result in the http connection being closed, you just can't make the assumption it will always be there in the real world)
118 2016-09-14 07:26:18	0|dcousens|wumpus: fwiw, I occassionally sync an address index from genesis just to see how fast it goes,  and its never the throughput/bandwidth that slows it up,  its the disk thrashing,  even in just a query-of txindex case
119 2016-09-14 07:26:42	0|dcousens|s/address index/script index
120 2016-09-14 07:27:02	0|gmaxwell|wumpus: yea, it was unreliable before-- just more obvious now.
121 2016-09-14 07:27:10	0|wumpus|dcousens: thanks for actually benchmarking to find bottlenecks instead of making assumptions :) ("it must be RPC overhead")
122 2016-09-14 07:27:46	0|luke-jr|oh, I see what it was: the older version that I thought worked simply never reused the connection :|
123 2016-09-14 07:28:08	0|wumpus|luke-jr: that's also a valid way to do it, if you don't have too many requests or theyr're sparse
124 2016-09-14 07:28:30	0|wumpus|it's how people usually use python's http: just open a connection per requests. The whole keep-alive thing is an optimization, not required
125 2016-09-14 07:28:43	0|wumpus|it brings a lot of state and complexity
126 2016-09-14 07:29:32	0|luke-jr|yet another unmaintained jgarzik project: https://github.com/jgarzik/python-bitcoinrpc/pull/49
127 2016-09-14 07:29:42	0|gmaxwell|though without it, I imagine performance is poor (well even with it, performance is poor)
128 2016-09-14 07:30:09	0|gmaxwell|it stinks mostly because everywhere recommends it, and it falls flat on its face... and I'm not sure what to recommend instead.
129 2016-09-14 07:30:55	0|wumpus|well "performance is poor" is relative. keep-alive only helps with repeated requests. In many cases of using RPC you don't really care about performance of repeated reuqests at all
130 2016-09-14 07:31:43	0|wumpus|many people just use the RPC through curl, or bitcoin-cli, which involves executing an external process per connection per command, and they don't complain either
131 2016-09-14 07:32:33	0|dcousens|wumpus: heh, I'm using 16 concurrent RPC connections w/ 300 batched in each
132 2016-09-14 07:32:38	0|wumpus|I think the problem is recommending using a broken-ish) library when the underlying mechanism is so trivial
133 2016-09-14 07:33:31	0|dcousens|needless to say I found where my custom RPC commands were missing LOCKs pretty quick
134 2016-09-14 07:33:38	0|gmaxwell|right, but "walk through the last N blocks to gather data" taking longer in python than it takes me to modify bitcoind and recompile feels a little silly.
135 2016-09-14 07:34:00	0|wumpus|yes, if you're one of the few people that needs to do really dense requesting, there are various optimizations that help
136 2016-09-14 07:34:07	0|wumpus|but that's not what JSON RPC was designed for in the first place
137 2016-09-14 07:34:31	0|wumpus|it's a high-overhead protocol that was designed to be simple to use, not for low-latency high-throughput application
138 2016-09-14 07:34:32	0|dcousens|wumpus: my point was, the RPC isn't whats slow, so no point changing it
139 2016-09-14 07:35:01	0|wumpus|something like capnproto is designed for the latter
140 2016-09-14 07:35:28	0|wumpus|howeer it's much harder to use, bind, and have basic setup, which is why companie generally offer JSON RPC or REST APIs
141 2016-09-14 07:35:44	0|dcousens|lest we forget SOAP
142 2016-09-14 07:35:50	0|wumpus|heh :)
143 2016-09-14 07:36:18	0|gmaxwell|author of capnproto didn't seem to regard sending uninitilized memory in struct padding to remote peers as a serious security problem when I spoke to him a year or two ago.
144 2016-09-14 07:37:00	0|wumpus|yes, security is another thing that is usually compromised on when latency is the most important thing
145 2016-09-14 07:37:19	0|gmaxwell|in any case, after seeing that the python stuff was slow I tested with curl and it didn't appear to be the bitcoind side that was slow.
146 2016-09-14 07:37:25	0|wumpus|it's a difficult choice, I think JSON-RPC was a fairly good choice as these things go
147 2016-09-14 07:37:42	0|gmaxwell|I agree.
148 2016-09-14 07:39:04	0|luke-jr|._.
149 2016-09-14 07:39:13	0|luke-jr|jonasschnelli: you forgot /s
150 2016-09-14 07:39:38	0|jonasschnelli|Ah... I forgot to migrate the Qt client to a chrome html/css extension. :)
151 2016-09-14 07:39:47	0|wumpus|the network and JSON processing on the bitcoind side is fast: the most common bottleneck would be the locking, which has nothing to do with the RPC mechanism. Or reading/deserializing blocks. Or...
152 2016-09-14 07:40:04	0|wumpus|jonasschnelli: hehe, maybe if bitcoin was designed 10 years earlier
153 2016-09-14 07:40:10	0|dcousens|jonasschnelli: I wonder when a ECDSA library will be written with pure CSS
154 2016-09-14 07:40:19	0|jonasschnelli|lol
155 2016-09-14 07:40:33	0|wumpus|dcousens: at least you can write a ECDSA library with just x86 mov instructions
156 2016-09-14 07:40:34	0|luke-jr|>_<
157 2016-09-14 07:40:47	0|luke-jr|https://github.com/xoreaxeaxeax/movfuscator
158 2016-09-14 07:40:57	0|wumpus|yea
159 2016-09-14 07:41:11	0|luke-jr|no need to write a new one, just build libsecp256k1..
160 2016-09-14 07:41:51	0|jonasschnelli|How large will it be?
161 2016-09-14 07:41:59	0|wumpus|moon-sized
162 2016-09-14 07:42:41	0|jonasschnelli|Would be fun open the moon-sized library in IDA-PRO
163 2016-09-14 07:42:41	0|luke-jr|dunno, never tried it
164 2016-09-14 07:43:40	0|wumpus|yes I think that's the only reason why anyone would do something like that, throw off people trying to analyze it 'this can't be real x86 code'
165 2016-09-14 07:44:23	0|luke-jr|s/people/software/
166 2016-09-14 07:44:28	0|luke-jr|eg virus scanners
167 2016-09-14 07:44:39	0|wumpus|well not just software, software is much easier to throw off
168 2016-09-14 07:45:00	0|luke-jr|is it? ☺
169 2016-09-14 07:45:13	0|dcousens|jonasschnelli: its possible to de-movuscate,isn't it? in which case eh?
170 2016-09-14 07:45:31	0|luke-jr|dcousens: IIRC this one intentionally makes it hard
171 2016-09-14 07:48:31	0|wumpus|then again if the virus is 1000MB it kind of inhibits its own spread
172 2016-09-14 08:16:48	0|GitHub179|13bitcoin/06master 1436fa01f 15Cory Fields: net: only delete CConnman if it's been created...
173 2016-09-14 08:16:48	0|GitHub179|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/57b34599b2de...881d7eaf29f7
174 2016-09-14 08:16:49	0|GitHub179|13bitcoin/06master 14881d7ea 15Wladimir J. van der Laan: Merge #8715: net: only delete CConnman if it's been created...
175 2016-09-14 08:17:03	0|GitHub0|[13bitcoin] 15laanwj closed pull request #8715: net: only delete CConnman if it's been created (06master...06fix-connman-shutdown) 02https://github.com/bitcoin/bitcoin/pull/8715
176 2016-09-14 09:02:43	0|jonasschnelli|Is there a reason why the last key in out HD scheme (and in BIP32) is non-hardened? Its m/0'/0'/0 for the first key and not m/0'/0'/0'
177 2016-09-14 09:02:58	0|jonasschnelli|Or does it just don't matter at the last level
178 2016-09-14 09:24:26	0|gmaxwell|because the wallet itself isn't intended to iterate at that level. The part below is subkeys.
179 2016-09-14 09:24:49	0|gmaxwell|So every key the wallet gives out is strong against unzipping, but it could support repeated payment arrangements without address reuse.
180 2016-09-14 09:24:53	0|gmaxwell|IIRC.
181 2016-09-14 09:56:03	0|MarcoFalke|wumpus: Can you elaborate? (random.random() *is* deterministic)
182 2016-09-14 09:56:14	0|MarcoFalke|I think the seed is the current time, so we may not know that
183 2016-09-14 09:56:22	0|MarcoFalke|But knowing the seed is not required.
184 2016-09-14 09:56:24	0|wumpus|MarcoFalke: I like test that simply test the same thing every time
185 2016-09-14 09:56:32	0|wumpus|there is no need to randomize here
186 2016-09-14 09:56:43	0|MarcoFalke|So just set it to usehd=0
187 2016-09-14 09:56:52	0|wumpus|just make every odd bitcoind a legacy wallet and every even one a HD one, or so
188 2016-09-14 09:57:55	0|wumpus|I just don't see the point of random() here, there's a fair chance that it ends up testing all-hd or all-non-hd
189 2016-09-14 10:01:36	0|MarcoFalke|Which is a legit case to test
190 2016-09-14 10:01:50	0|MarcoFalke|But I can remove it, so we don't need the import random
191 2016-09-14 10:01:53	0|wumpus|sure, but not randomly
192 2016-09-14 10:02:17	0|wumpus|I like deterministic tests, esp in travis
193 2016-09-14 10:02:32	0|MarcoFalke|But you want them to be constant?
194 2016-09-14 10:02:36	0|wumpus|yes
195 2016-09-14 10:03:02	0|MarcoFalke|Have you seen the print(extra_args) to make it reproducible in case of failure?
196 2016-09-14 10:03:06	0|wumpus|otherwise there's a larger chance it will fail due to reasons unrelated to the code changes
197 2016-09-14 10:03:12	0|wumpus|which confuses people
198 2016-09-14 10:04:03	0|wumpus|tests run in travis should preferably be constant and deterministic. I'm ok with a random fuzzing jackpot testing method for running locally, but the tests running for every pull should be the same tests every time
199 2016-09-14 10:07:04	0|wumpus|if you want to test with a combination of legacy and HD wallets in a test that's good, but just hardcode that
200 2016-09-14 10:09:20	0|MarcoFalke|fine
201 2016-09-14 10:09:45	0|MarcoFalke|Then we should write some new tests which do "parameter fuzzing" some time
202 2016-09-14 10:10:06	0|MarcoFalke|Sadly this depends somewhat on rewrinting the arg parser
203 2016-09-14 10:10:23	0|wumpus|sorry that I feel so strongly about htis, but I've seen too many random travis failures in the last months :)
204 2016-09-14 10:59:41	0|wumpus|cfields_: oh shit oh shit oh shit https://github.com/bitcoin/bitcoin/pull/8653#issuecomment-246973266
205 2016-09-14 11:00:22	0|wumpus|bitcoin core win64 cross-build is in a state of crap with ubuntu 16.04
206 2016-09-14 11:01:04	0|wumpus|I thought I did this before, and didn't have any of these issues, but I must hae imagined it
207 2016-09-14 11:06:12	0|GitHub17|[13bitcoin] 15andersoyvind opened pull request #8720: Minor change in section name (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8720
208 2016-09-14 13:12:28	0|GitHub88|[13bitcoin] 15laanwj opened pull request #8722: bitcoin-cli: More detailed error reporting (06master...062016_09_cli_http_error) 02https://github.com/bitcoin/bitcoin/pull/8722
209 2016-09-14 13:22:42	0|GitHub10|[13bitcoin] 15jonasschnelli opened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (06master...062016/09/hd_flex) 02https://github.com/bitcoin/bitcoin/pull/8723
210 2016-09-14 13:23:22	0|wumpus|jonasschnelli: whatevery you do don't look at #8653
211 2016-09-14 13:24:41	0|jonasschnelli|wumpus: hehe.. I did already and started disable --hardening wherever I can to avoid "possible startup problems". :P
212 2016-09-14 13:25:24	0|wumpus|my new favourite number is "zu"
213 2016-09-14 13:26:11	0|jonasschnelli|:-)
214 2016-09-14 13:26:18	0|wumpus|I think it's that posix mode of gcc that completely throws everything off track
215 2016-09-14 13:26:35	0|wumpus|(on windows)
216 2016-09-14 13:27:18	0|wumpus|I'm going to locally revert the usage of c++11 threads, compile with the -win32 compiler then see what happens, I think everything will be fine
217 2016-09-14 13:32:17	0|jonasschnelli|wumpus: Not sure if this helps.. but in another project I'm using mingw.thread.h (https://github.com/digitalbitbox/dbb-app/blob/master/src/mingw/mingw.thread.h)
218 2016-09-14 13:33:21	0|jonasschnelli|Then just include it with a #ifdef WIN32
219 2016-09-14 13:33:25	0|jonasschnelli|Probably a huge hack
220 2016-09-14 13:49:49	0|wumpus|jonasschnelli: that makes sense; but I don't get it, why isn't it part of mingw-w64 itself?
221 2016-09-14 13:50:36	0|wumpus|well it's less of a hack than fully fledged POSIX emulation mode on windows
222 2016-09-14 13:54:16	0|wumpus|it's supposed to just support it, and on trusty it doe
223 2016-09-14 13:54:29	0|wumpus|(it=std::mutex and friends)
224 2016-09-14 13:56:16	0|jonasschnelli|wumpus: Yes. I don't know why its not part of mingw itself... I just added them and it worked fine, though, I'm not using stuff like the --enable-hardening we do at Core
225 2016-09-14 13:56:53	0|wumpus|I doubt this has anything to do with hardening, I think with hardening it just detects the crazy memory corruption that happens sooner
226 2016-09-14 13:57:48	0|GitHub93|13bitcoin/06master 141111ddb 15MarcoFalke: gitignore: Remove unused lines
227 2016-09-14 13:57:48	0|GitHub93|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/881d7eaf29f7...a82e5d8220bb
228 2016-09-14 13:57:49	0|GitHub93|13bitcoin/06master 14a82e5d8 15MarcoFalke: Merge #8714: [qa] gitignore: Remove unused lines...
229 2016-09-14 13:58:03	0|GitHub7|[13bitcoin] 15MarcoFalke closed pull request #8714: [qa] gitignore: Remove unused lines (06master...06Mf1609-qaUnused) 02https://github.com/bitcoin/bitcoin/pull/8714
230 2016-09-14 13:58:43	0|wumpus|also there's a mutex header in ./lib/gcc/x86_64-w64-mingw32/5.3-win32/include/c++/mutex
231 2016-09-14 13:58:56	0|wumpus|maybe we need to #define something
232 2016-09-14 14:00:33	0|wumpus|well at least that's one more 'trivial' I've removed from a pull title
233 2016-09-14 14:02:44	0|jonasschnelli|heh.. yes. That happens quick..
234 2016-09-14 14:05:32	0|MarcoFalke|Hmm. Github allows us to write to branches that have a pull request open against bitcoin.
235 2016-09-14 14:05:35	0|MarcoFalke|c.f. https://github.com/bitcoin/bitcoin/pull/8720/commits
236 2016-09-14 14:05:49	0|MarcoFalke|Might come in handy but I'd prefer to disable it
237 2016-09-14 14:05:57	0|MarcoFalke|(if possible)
238 2016-09-14 14:09:12	0|jonasschnelli|MarcoFalke: so you did amend commit force push to 8720?
239 2016-09-14 14:09:25	0|MarcoFalke|Jup: https://github.com/blog/2247-improving-collaboration-with-forks
240 2016-09-14 14:09:35	0|MarcoFalke|Apparently not possible to disable
241 2016-09-14 14:09:40	0|jonasschnelli|Heh... that's handy but evil.
242 2016-09-14 14:20:41	0|wumpus|that can be really useful
243 2016-09-14 14:21:03	0|wumpus|was of course already possible to do that locally, but ok
244 2016-09-14 14:21:11	0|jonasschnelli|Yes. Thinking of all there cases where a nit holds back a PR
245 2016-09-14 14:21:53	0|jonasschnelli|I think its much better to have a more public way then locally alter during the merge
246 2016-09-14 14:22:10	0|wumpus|before the merge*
247 2016-09-14 14:24:17	0|wumpus|if you do a local merge you can simply add your own commits before doing it, that's pretty public
248 2016-09-14 14:24:43	0|jonasschnelli|It's public, but only in the commit list and not on the PR
249 2016-09-14 14:25:16	0|wumpus|right. Just wanted to be clear I didn't mean anything as sneaky as squashing it into the merge commit, or into the author's commits
250 2016-09-14 14:25:25	0|MarcoFalke|Also quite fiddly trying to emulate github-merge.py
251 2016-09-14 14:25:42	0|MarcoFalke|I think it is fine to use the new feature when we announce in in the pr that is affected
252 2016-09-14 14:25:44	0|wumpus|yes I've always intended to add a local mode to github-merge.py
253 2016-09-14 14:25:57	0|wumpus|(I have a local version of github-merge but it's really messy)
254 2016-09-14 14:33:01	0|GitHub197|[13bitcoin] 15MarcoFalke opened pull request #8724: [qa] walletbackup: Sync blocks inside the loop (06master...06Mf1609-qaWalletBackupFix) 02https://github.com/bitcoin/bitcoin/pull/8724
255 2016-09-14 14:55:07	0|jonasschnelli|windows_hell, nice branch name
256 2016-09-14 14:57:19	0|wumpus|well there seems to be a shitload of issues, for now the best recommendation would be to just use trusty. The "zu" issue doesn't exist with the gitian executables does it?
257 2016-09-14 14:58:44	0|wumpus|let's first try to figure out why the tests crash...
258 2016-09-14 15:01:38	0|jonasschnelli|Yes. We should probably flag certain distros not compatible with out cross compile process or so
259 2016-09-14 15:16:17	0|wumpus|it only seemed like bitcoin-qt was working: I had disabled wallet support, apparently it works then
260 2016-09-14 15:16:34	0|wumpus|windows is truly a mess on gcc 5.3
261 2016-09-14 15:16:58	0|wumpus|the test crash before it even get to the BasicTestingSetup constructor
262 2016-09-14 15:17:06	0|wumpus|at least I can reproduce it on wine....
263 2016-09-14 15:18:39	0|achow101|Is this windows problem the same thing as I was having a while back?
264 2016-09-14 15:41:29	0|wumpus|there are at least three seperate issues here
265 2016-09-14 15:42:18	0|achow101|the thing with mutex and not compiling
266 2016-09-14 15:42:22	0|wumpus|1) the std::mutex/thread c++11 compilation issue 2) something trange with libevent (the 'zu' issue) 3)  something with hardening
267 2016-09-14 15:43:07	0|wumpus|some of these may partially overlap in cause or effect
268 2016-09-14 15:43:12	0|wumpus|but it's a mess
269 2016-09-14 15:45:49	0|achow101|Yeah, it looks like the same problem, it happened on ubuntu 15.10 (wily)
270 2016-09-14 15:47:01	0|achow101|This is the discussion if it's of any help: https://botbot.me/freenode/bitcoin-core-dev/2016-08-08/?msg=70975840&page=1
271 2016-09-14 15:48:13	0|wumpus|right - it's still an issue on 16.04
272 2016-09-14 16:11:15	0|wumpus|ok, phew, at least verified that the libevent `zu` issue doesn't exist in the released 0.13.0 executables
273 2016-09-14 16:15:24	0|sipa|good
274 2016-09-14 16:16:02	0|wumpus|well travis RPC tests pass on windows, so it'd be surprising, but I don't understand why it suddenly starts happening with a certain gcc version
275 2016-09-14 16:16:51	0|wumpus|the libevent version didn't change since 0.13.0, neither did our use of it
276 2016-09-14 16:32:58	0|wumpus|achow101: which patches? I've also been testing w/ Ubuntu 16.04 and windows 10
277 2016-09-14 16:53:03	0|GitHub12|[13bitcoin] 15rebroad opened pull request #8725: Split debug for estimatefee into {estimatefee,2} (06master...06MoreGranularDebug2) 02https://github.com/bitcoin/bitcoin/pull/8725
278 2016-09-14 16:56:33	0|GitHub174|[13bitcoin] 15rebroad opened pull request #8726: Move a bunch of fairly verbose debug messages from mempool to mempool2 (06master...06MoreGranularDebug3) 02https://github.com/bitcoin/bitcoin/pull/8726
279 2016-09-14 17:01:45	0|GitHub66|[13bitcoin] 15rebroad opened pull request #8727: Move logic for TX INVs together (06master...06MoreGranularDebug4) 02https://github.com/bitcoin/bitcoin/pull/8727
280 2016-09-14 17:05:23	0|GitHub85|[13bitcoin] 15rebroad opened pull request #8728: More granular debug5 (06master...06MoreGranularDebug5) 02https://github.com/bitcoin/bitcoin/pull/8728
281 2016-09-14 17:18:44	0|GitHub29|[13bitcoin] 15rebroad opened pull request #8729: More granular debug6 (06master...06MoreGranularDebug6) 02https://github.com/bitcoin/bitcoin/pull/8729
282 2016-09-14 17:34:17	0|GitHub64|[13bitcoin] 15laanwj opened pull request #8730: depends: Add libevent compatibility patch for windows (06master...062016_09_libevent_windows_gcc_531) 02https://github.com/bitcoin/bitcoin/pull/8730
283 2016-09-14 17:35:39	0|wumpus|sheesh how many debug pulls do we need...
284 2016-09-14 17:36:53	0|paveljanik|8(
285 2016-09-14 17:37:11	0|paveljanik|6+1. The last one combines all prev 8)
286 2016-09-14 17:37:48	0|wumpus|we really should add a suggestion not to spam pull requests
287 2016-09-14 17:39:03	0|wumpus|especially if they're all related
288 2016-09-14 17:48:22	0|paveljanik|well, I know how he feels. Sometimes you know it is much easier to make it in steps. But doing steps separately and then all in one PR is nonsense...
289 2016-09-14 17:49:32	0|paveljanik|let's close the steps PR and comment only the final one.
290 2016-09-14 17:50:24	0|paveljanik|rebroad, is it ok for you?
291 2016-09-14 17:56:43	0|rebroad|paveljanik, hi
292 2016-09-14 17:57:37	0|rebroad|paveljanik, I find the whole process quite confusing... in my experience my smaller pull requests get merged but the larger ones don't... so this way I'm trying to hedge my bets and provide small ones and a larger one to work out which is preferred.
293 2016-09-14 17:58:03	0|rebroad|paveljanik, not sure what you mean by "the final one"
294 2016-09-14 17:58:24	0|paveljanik|the final one - the one containing all (almost) the previous
295 2016-09-14 17:58:28	0|rebroad|do you mean the one with all the commits in? and close the others?
296 2016-09-14 17:58:32	0|cfields_|wumpus: ok, diving into the win32 mess. I'd written it off as user error, but looks like I need to familiarize myself with what's going on now.
297 2016-09-14 17:58:55	0|paveljanik|8729
298 2016-09-14 17:58:56	0|rebroad|paveljanik, I'm happy to do this, but I'm not sure if this is would the other devs would prefer also
299 2016-09-14 17:59:33	0|paveljanik|well, some changes are wrong, yes, but they can tell you in one PR.
300 2016-09-14 17:59:54	0|rebroad|paveljanik, wrong?
301 2016-09-14 18:00:09	0|paveljanik|yes
302 2016-09-14 18:00:20	0|paveljanik|lets wait for comments
303 2016-09-14 18:00:41	0|paveljanik|I have already added approx. 5 comments.
304 2016-09-14 18:00:53	0|rebroad|paveljanik, ah, thank you
305 2016-09-14 18:01:00	0|GitHub154|[13bitcoin] 15rebroad opened pull request #8731: Debug headers received ("block" for new block announcement, "block2" … (06master...06DebugHeadersReceived) 02https://github.com/bitcoin/bitcoin/pull/8731
306 2016-09-14 18:01:33	0|rebroad|paveljanik, is there a way to easily go to my pull requests that have had comments left? i.e. is there an inbox for these comments somewhere on github?
307 2016-09-14 18:02:43	0|paveljanik|rebroad, yes, please read https://help.github.com/articles/about-discussions-in-issues-and-pull-requests/
308 2016-09-14 18:02:59	0|rebroad|thanks
309 2016-09-14 18:03:04	0|paveljanik|and especially "Further reading"
310 2016-09-14 18:04:33	0|rebroad|paveljanik, what did you mean by "why?" in #8728?
311 2016-09-14 18:07:04	0|paveljanik|expanded there...
312 2016-09-14 18:08:28	0|rebroad|paveljanik, #8727 you asked what other inv.type I can see.. not sure why you are asking this
313 2016-09-14 18:09:07	0|rebroad|I just moved the code that was doing the same thing as the code above into the same if statement.. which is needed to avoid messier code with the later commits also
314 2016-09-14 18:11:42	0|wumpus|this is starting to be annoying, please stop pushing debug pull requests
315 2016-09-14 18:11:54	0|rebroad|paveljanik, #8725 have added a description now... I guess the "why" is a reasonable question given it was absent.
316 2016-09-14 18:12:17	0|wumpus|most debugging information is only intersting for yourself during a debugging session, there is no reason to merge them upstream
317 2016-09-14 18:12:18	0|rebroad|wumpus, what is your issue with debug pull requests?
318 2016-09-14 18:12:39	0|paveljanik|there are many of them and useless - wumpus wrote it above...
319 2016-09-14 18:12:39	0|wumpus|a) there are way too many already b) it's mostly ego-commits, not intersting to other people
320 2016-09-14 18:13:29	0|rebroad|wumpus, from the pull requests I have seen I would say that various developers have found a number of my debug pull requests useful, and they facilitate better understanding of what is happening. It would be unreasonable to expect everyone to have to make their own changed to obtain useful debug information.
321 2016-09-14 18:13:49	0|wumpus|try to be focused when you submit pulls upsteam. Every one of us likely has tons of patches adding personal debugging information to solve specific problems, but it's not in general useful for others and you're wasting review time
322 2016-09-14 18:14:46	0|wumpus|it wouldn't be a problem if this was one or two pulls, but you keep pushing this on
323 2016-09-14 18:15:03	0|rebroad|wumpus, i just spend 3 days having to rebase all these debug commits due to changes that were made recently.. I am getting very very fed up with the amount of time wasted rebasing when I could be spending that time adding functionality to bitcoin. this is why this needs to get merged!
324 2016-09-14 18:15:09	0|wumpus|do you really expect people to review "more granular debug6"?
325 2016-09-14 18:15:21	0|rebroad|i have a life, which I'd like to spend living rather than rebasing
326 2016-09-14 18:15:40	0|wumpus|that's not a reason to merge it though, to merge it it needs to actually be considered useful, the project doesn't exist to save you work
327 2016-09-14 18:15:44	0|wumpus|we all have a life
328 2016-09-14 18:15:59	0|wumpus|it's kind of insulting to suggest you're the only one
329 2016-09-14 18:16:01	0|paveljanik|so why do you spend your time with useless stuff instead of The functionality?
330 2016-09-14 18:16:06	0|wumpus|and you can just burden us with your shit
331 2016-09-14 18:16:12	0|rebroad|wumpus, it's not just saving me work. I wouldn't write it if I thought it was only useful for me
332 2016-09-14 18:16:34	0|rebroad|i agree that some of the commits are trivial...
333 2016-09-14 18:16:42	0|rebroad|wumpus, what do you mean by "ego-commits"?
334 2016-09-14 18:16:43	0|wumpus|well some of them may be useful to others
335 2016-09-14 18:16:47	0|wumpus|but it's the sheer volume
336 2016-09-14 18:17:08	0|wumpus|everyone tries to make time to write and review patches that add functionality and fix bugs
337 2016-09-14 18:17:11	0|wumpus|not just debugging spam
338 2016-09-14 18:17:48	0|wumpus|<paveljanik> so why do you spend your time with useless stuff instead of The functionality? <- very good question
339 2016-09-14 18:18:08	0|wumpus|we have 402 issues and 140 pull requests open at this moment
340 2016-09-14 18:18:26	0|paveljanik|yup, pick one of the issues and try to solve it!
341 2016-09-14 18:18:40	0|wumpus|lots of actual problems that need to be solved, that are experienced by users
342 2016-09-14 18:18:56	0|rebroad|wumpus, you say sheer volume, but I'm not sure what you mean. do you mean pull reqs, or lines of code?
343 2016-09-14 18:19:00	0|wumpus|and yes, some of them may be bullshit, but let's try not to add too much more
344 2016-09-14 18:19:09	0|wumpus|rebroad: number of pull requests inthis case
345 2016-09-14 18:19:35	0|wumpus|(same could hold for lines of changed code, in some cases)
346 2016-09-14 18:20:26	0|rebroad|wumpus, ok, I will close the smaller ones as paveljanik suggests
347 2016-09-14 18:20:41	0|wumpus|yes just merge some together if they are related to the same concern
348 2016-09-14 18:20:56	0|wumpus|and at least make some effort to name/describe them
349 2016-09-14 18:21:02	0|wumpus|'more granular debug5' really sucks as name
350 2016-09-14 18:21:23	0|GitHub9|[13bitcoin] 15rebroad closed pull request #8484: More granular debug (06master...06MoreGranularDebug) 02https://github.com/bitcoin/bitcoin/pull/8484
351 2016-09-14 18:21:27	0|rebroad|wumpus, you don't mince your words, do you :)
352 2016-09-14 18:21:39	0|wumpus|rebroad: sorry this has been annoying me for a while
353 2016-09-14 18:22:02	0|rebroad|spending 3 days rebasing has been annoying me too ...
354 2016-09-14 18:22:07	0|wumpus|well then don
355 2016-09-14 18:22:08	0|wumpus|'t
356 2016-09-14 18:22:37	0|rebroad|if i need to understand the code and how it functions I do... unless these commits get merged
357 2016-09-14 18:22:57	0|rebroad|ok, I am oversimplifying a little
358 2016-09-14 18:23:06	0|rebroad|but it all helps, IMHO
359 2016-09-14 18:23:08	0|wumpus|you can understand code without logging everything, or by adding temporary logging
360 2016-09-14 18:23:17	0|wumpus|or by stepping through with a debugger
361 2016-09-14 18:23:27	0|wumpus|many ways taht don't involve adding logging statements to the upstream code
362 2016-09-14 18:23:41	0|rebroad|part of me needs to disagree with you as otherwise I've spent a lot of time for very little reason :-s
363 2016-09-14 18:24:17	0|wumpus|I'm not saying it's all useless
364 2016-09-14 18:24:44	0|rebroad|there are some more commits yet to come that might help to reveal the usefulness of the so far seemingly useless ones
365 2016-09-14 18:24:45	0|wumpus|just try to have some discipline, spend time explaining to others why something is useful, instead of just adding pulls with very little description
366 2016-09-14 18:26:25	0|rebroad|but yes, the mempool2 and estimatefee2 ones were a bit trivial... estimatefee2 more so... but still useful to an extent...  I'd still like to know what you mean by ego-commits... i do wonder how much ego is behind my struggle to get things merged.
367 2016-09-14 18:26:51	0|wumpus|and maybe explain the overall plan, people get lost if they only see details instead of where something is going
368 2016-09-14 18:26:58	0|rebroad|wumpus, you are right.. i do need to be less lazy when it comes to explaining
369 2016-09-14 18:27:36	0|rebroad|wumpus, thank you for your feedback and patience
370 2016-09-14 18:27:38	0|wumpus|an ego-commit is something that is useful to yourself, for example some feature that you need, or some piece of information that you specifically need, but without regard whether it's useful for other users
371 2016-09-14 18:28:13	0|rebroad|wumpus, I would find it hard to believe that some features are useful to only one person
372 2016-09-14 18:28:14	0|wumpus|and then to stop having to rebase it yourself you try to push it upstream
373 2016-09-14 18:29:05	0|wumpus|well it tends to happen if something is only a perceived need, someone is really held up about something
374 2016-09-14 18:29:22	0|rebroad|there seems to be a general attitude among many developers that "debug" commits are a waste of time.. I don't quite understand why that is the popular viewpoint
375 2016-09-14 18:29:35	0|wumpus|maybe it's useful to one other person :) but all code needs to be maintained, so there has to be some threashold
376 2016-09-14 18:29:49	0|wumpus|well debugging is something kind of personal to developers
377 2016-09-14 18:29:55	0|wumpus|what information do you need
378 2016-09-14 18:29:58	0|wumpus|for what you're doing
379 2016-09-14 18:30:11	0|wumpus|for the problem you're trying to find
380 2016-09-14 18:30:25	0|rebroad|a lot of people, non-developers especially often ask for more feedback on what their full-node is doing... they want to see what it is doing...
381 2016-09-14 18:30:38	0|rebroad|so in a sense, this debug info might benefit non-developers more than developers
382 2016-09-14 18:30:40	0|wumpus|e.g. to find a wine issue I"m now instrumenting some code to log every executed instruction
383 2016-09-14 18:30:52	0|wumpus|that's not something anyone would ever want upstream :-)
384 2016-09-14 18:31:04	0|rebroad|i could code something prettier like a matrix style green scrolly thing.. but that would move away from actual useful information then!
385 2016-09-14 18:31:30	0|wumpus|if I became really obsessed about this, and wanted this a default part of bitcoin, and became angry if other developers disagreed, that would be an ego commit
386 2016-09-14 18:32:14	0|wumpus|yes on a high level I agree with you, it'd be nice to have some more insight into what a node is doing
387 2016-09-14 18:32:28	0|wumpus|I kind of like statoshi's approach
388 2016-09-14 18:33:07	0|wumpus|but I'm not sure e.g. splitting up debug into a zillion categories, or adding lots of messages, is the way to go
389 2016-09-14 18:33:29	0|wumpus|haha if you'd add that to the GUI it may well be accepted
390 2016-09-14 18:33:42	0|rebroad|if it's granular enough, then no one should need to add adhoc debug message as you are suggesting... there'd be a debug message already there that they can activate just by editing bitcoin.conf
391 2016-09-14 18:33:44	0|wumpus|jonasschnelli did a screensaver-like thing once that showed statistics
392 2016-09-14 18:33:50	0|rebroad|and they'd not need to recompile etc
393 2016-09-14 18:33:57	0|rebroad|which wastes a lot of cpy, energy, etc...
394 2016-09-14 18:33:59	0|rebroad|cpu
395 2016-09-14 18:34:01	0|wumpus|but gave up on it unfortuantely
396 2016-09-14 18:34:12	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/5896
397 2016-09-14 18:34:28	0|jonasschnelli|I haven't gave it up... I just came with a more stable solution for a first start
398 2016-09-14 18:34:28	0|rebroad|:)
399 2016-09-14 18:34:30	0|jonasschnelli|The mempool stats
400 2016-09-14 18:34:40	0|rebroad|I love the mempool graphs..
401 2016-09-14 18:34:42	0|jonasschnelli|Once this will be merged, more can be added
402 2016-09-14 18:34:56	0|jonasschnelli|Nodes / Tx / Mempool just don't fit in one screem
403 2016-09-14 18:34:58	0|rebroad|although it would be great if I could point to the graph and it would tell me the X-Y co-ords of the point closest to the pointer
404 2016-09-14 18:35:00	0|kanzure|not clear to me if rebroad has used gdb and code stepping
405 2016-09-14 18:35:02	0|wumpus|well i think there's always someone that wants to add an ad-hoc debug messgae, I don't think it's possible to be complete in that regard
406 2016-09-14 18:35:44	0|kanzure|if there needs to be metrics for user display then probably a more general frmaewokr would be useful, rather than individual debugger additions
407 2016-09-14 18:35:47	0|rebroad|kanzure, i have used gdb.. but i think it's of limited use, in my experience and not as clear as some good debug messages, imho
408 2016-09-14 18:36:01	0|wumpus|the linux kernel has something called 'tracepoints' which allows inserting print or other hooks at certain points to print information on the fly
409 2016-09-14 18:36:06	0|wumpus|I think a similar thing exists for user space
410 2016-09-14 18:36:53	0|kanzure|wumpus: probably there's a very noisy compiler option for this...
411 2016-09-14 18:36:56	0|wumpus|most annoying about gdb is <value optimized out>
412 2016-09-14 18:37:45	0|GitHub167|[13bitcoin] 15rebroad closed pull request #8728: More granular debug5 (06master...06MoreGranularDebug5) 02https://github.com/bitcoin/bitcoin/pull/8728
413 2016-09-14 18:38:04	0|kanzure|-finstrument-functions
414 2016-09-14 18:38:06	0|kanzure|hehehe
415 2016-09-14 18:39:16	0|wumpus|another one is systemtap probe points
416 2016-09-14 18:39:54	0|GitHub28|[13bitcoin] 15rebroad closed pull request #8725: Split debug for estimatefee into {estimatefee,2} (06master...06MoreGranularDebug2) 02https://github.com/bitcoin/bitcoin/pull/8725
417 2016-09-14 18:40:09	0|GitHub62|[13bitcoin] 15rebroad closed pull request #8726: Move a bunch of fairly verbose debug messages from mempool to mempool2 (06master...06MoreGranularDebug3) 02https://github.com/bitcoin/bitcoin/pull/8726
418 2016-09-14 18:40:22	0|kanzure|cool.
419 2016-09-14 18:40:29	0|GitHub25|[13bitcoin] 15rebroad closed pull request #8727: Move logic for TX INVs together (06master...06MoreGranularDebug4) 02https://github.com/bitcoin/bitcoin/pull/8727
420 2016-09-14 18:41:02	0|wumpus|or gdb's "The dynamic printf command dprintf combines a breakpoint with formatted printing of your program's data to give you the effect of inserting printf calls into your program on-the-fly, without having to recompile it."
421 2016-09-14 18:41:26	0|rebroad|someone on github mentioned that everytime i change the pull title, or close/open that 1200 emails get sent... is this true?
422 2016-09-14 18:41:49	0|achow101|rebroad: yes.
423 2016-09-14 18:41:51	0|wumpus|well I think 1200 is kind of overstating it
424 2016-09-14 18:42:04	0|rebroad|if so.... this sounds a little verbose... i agree with paveljanik's comment that things can be concise to one person while verbose to another
425 2016-09-14 18:42:23	0|rebroad|which is why I felt more granular was the answer..
426 2016-09-14 18:42:27	0|kanzure|it's the same thing with mailing lists too. your email will be sent to many thousands of people.
427 2016-09-14 18:42:27	0|wumpus|but at least the maintainers and people that have posted to an issue get a notification
428 2016-09-14 18:42:44	0|achow101|wumpus: I don't think it is actually overstating it. Anyone who watches the repo will get an email and there are 1206 watchers
429 2016-09-14 18:42:47	0|kanzure|and if everyone is reading their email then a 5 minute email ~= economic catastrophe of time spent reading
430 2016-09-14 18:43:29	0|wumpus|achow101: I'm not sure watchers get a mail for everything that happens in a repostiory, but you could be right
431 2016-09-14 18:43:48	0|kanzure|wumpus: are you a watcher?
432 2016-09-14 18:44:01	0|achow101|I'm watching and I get mails for every comment and commit to every pr or issue
433 2016-09-14 18:44:20	0|kanzure|i sort of assumed all the regulars were using the watchers feature.
434 2016-09-14 18:44:42	0|kanzure|ah maybe it's something about org members on github. nevermind.
435 2016-09-14 18:44:46	0|wumpus|kanzure: I'm repo owner, so I get a lot of mail from github, but I didn't realize watchers get all that too
436 2016-09-14 18:44:52	0|rebroad|paveljanik, was it you who sent me a github article earlier on here? i am struggling to find the link you quoted earlier :-s
437 2016-09-14 18:45:12	0|paveljanik|rebroad, see topic, it contains a link to log of this channel...
438 2016-09-14 18:45:14	0|kanzure|you want https://help.github.com/articles/about-discussions-in-issues-and-pull-requests/
439 2016-09-14 18:45:19	0|wumpus|I don't amange to read most of it though
440 2016-09-14 18:45:59	0|wumpus|still looking for a way to filter when someone @'s me from the rest of the github spam
441 2016-09-14 18:46:50	0|kanzure|wumpus: i think github is supposed to do that on its homepage, but IIRC nobody ever views the github homepage :)
442 2016-09-14 18:46:56	0|achow101|Does anyone think that the pull request review feature on github might be useful?
443 2016-09-14 18:47:13	0|wumpus|really those should end up in my personal mailbox instead of with the bulk
444 2016-09-14 18:47:31	0|wumpus|achow101: haven't looked at it yet
445 2016-09-14 18:48:05	0|achow101|part of it looks like basically preventing PRs from merging without ACKs and ACKs are built in
446 2016-09-14 18:48:30	0|paveljanik|wumpus, github mails contain this weird CC: ... Comment <comment@noreply.github.com> or Mention or ...
447 2016-09-14 18:48:34	0|wumpus|ok that sounds fairly useful
448 2016-09-14 18:48:37	0|kanzure|achow101: are those ACKs tied to specific commit ids?
449 2016-09-14 18:48:58	0|achow101|Dunno, haven't fully checked it out yet. I just read over the help article they linked
450 2016-09-14 18:49:21	0|wumpus|paveljanik: that could be key
451 2016-09-14 18:55:08	0|wumpus|paveljanik: yes, searching for to:mention@noreply.github.com seems to do what I want
452 2016-09-14 19:00:11	0|GitHub131|[13bitcoin] 15rebroad opened pull request #8733: More granular debug [WIP] (06master...06MoreGranularDebug.wip) 02https://github.com/bitcoin/bitcoin/pull/8733
453 2016-09-14 19:00:44	0|rebroad|this is the version with 22 commit.... hopefuly if anyone can be bothered to look they can get a clearer idea of where it was all going..
454 2016-09-14 19:03:17	0|wumpus|much better
455 2016-09-14 19:13:10	0|GitHub147|[13bitcoin] 15MarcoFalke closed pull request #8731: Debug headers received ("block" for new block announcement, "block2" … (06master...06DebugHeadersReceived) 02https://github.com/bitcoin/bitcoin/pull/8731
456 2016-09-14 19:21:19	0|btcdrak|wow, what is this new "review" thing on Github
457 2016-09-14 19:22:17	0|BunBun|quit
458 2016-09-14 19:40:09	0|GitHub198|[13bitcoin] 15rebroad closed pull request #8596: [WIP] Feeler code and debugging. (06master...06FeelerFixes) 02https://github.com/bitcoin/bitcoin/pull/8596
459 2016-09-14 20:25:24	0|cfields_|wumpus: ok, i've finally had enough of the system package crap that we can't control. I'm adding native toolchains to depends, along with a BOOTSTRAP option, false by default. Bootstrapping can be done in gitian and uploaded, so that they're simply fetched 99% of the time.
460 2016-09-14 20:29:38	0|sipa|cfields_: so gcc being part of the build for all platforms?
461 2016-09-14 20:30:13	0|cfields_|sipa: that's what I'm considering, yes
462 2016-09-14 20:31:24	0|sipa|awesome.
463 2016-09-14 20:32:07	0|cfields_|I'm sure it'll spiral downward with arguments about where to stop, but gcc/binutils seems like a reasonable start.
464 2016-09-14 20:33:36	0|sipa|cfields_: do you know nixos?
465 2016-09-14 20:34:02	0|cfields_|sipa: not really
466 2016-09-14 20:34:49	0|cfields_|sipa: looks interesting. Is it intended to be deterministic across builders?
467 2016-09-14 20:35:24	0|sipa|it is not
468 2016-09-14 20:35:54	0|sipa|but it uses hashes of build instructions to identify packages
469 2016-09-14 20:36:20	0|cfields_|ah, nice. sounds familiar :)
470 2016-09-14 20:36:34	0|MarcoFalke|Isn't this what docker does?
471 2016-09-14 20:37:46	0|sipa|docker builds from source?
472 2016-09-14 20:40:32	0|cfields_|docker just does whatever you tell it to. but yes, i'd assume it uses the hash of the recipe for checkpointing
473 2016-09-14 20:50:39	0|luke-jr|btcdrak: paveljanik: where do you see the new review thing⁇
474 2016-09-14 20:50:57	0|btcdrak|luke-jr: look on the diff tab
475 2016-09-14 20:51:34	0|luke-jr|cfields_: we need to support building outside gitian anyway, so not sure I see the point
476 2016-09-14 20:51:36	0|btcdrak|luke-jr: "the files changed" tab.
477 2016-09-14 20:52:20	0|luke-jr|huh
478 2016-09-14 20:52:23	0|luke-jr|interesting
479 2016-09-14 20:58:17	0|MarcoFalke|luke-jr: I think the goal is to solve the cross compile issues with depends.
480 2016-09-14 21:00:41	0|MarcoFalke|So if you fetch the (gitian-built) toolchain, you can just build outside gitian like you do today