1 2017-02-02 06:40:29	0|bitcoin-git|[13bitcoin] 15sosochain opened pull request #9669: 0.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/9669
  2 2017-02-02 06:41:24	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9669: 0.13 (06master...060.13) 02https://github.com/bitcoin/bitcoin/pull/9669
  3 2017-02-02 08:55:04	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9658: Add clang_format.py to help automate code style analysis (06master...06PR-clang-format) 02https://github.com/bitcoin/bitcoin/pull/9658
  4 2017-02-02 09:00:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9632: Add clang_static_analysis.py to help automate static analysis runs (06master...06PR-clang-static) 02https://github.com/bitcoin/bitcoin/pull/9632
  5 2017-02-02 09:13:50	0|bitcoin-git|13bitcoin/06master 143eba88d 15Gregory Sanders: clarify listunspent amount description
  6 2017-02-02 09:13:50	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/77bd8c4cab67...e30d9287fd48
  7 2017-02-02 09:13:51	0|bitcoin-git|13bitcoin/06master 14e30d928 15Wladimir J. van der Laan: Merge #9663: [RPC] clarify listunspent amount description...
  8 2017-02-02 09:14:06	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9663: [RPC] clarify listunspent amount description (06master...06listoutput) 02https://github.com/bitcoin/bitcoin/pull/9663
  9 2017-02-02 09:19:45	0|bitcoin-git|13bitcoin/06master 14b9d95bd 15Douglas Roark: Fix various minor linearization script issues...
 10 2017-02-02 09:19:45	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e30d9287fd48...ae972a5e996a
 11 2017-02-02 09:19:46	0|bitcoin-git|13bitcoin/06master 14ae972a5 15Wladimir J. van der Laan: Merge #9580: Fix various minor linearization script issues...
 12 2017-02-02 09:19:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9580: Fix various minor linearization script issues (06master...06linearizefix) 02https://github.com/bitcoin/bitcoin/pull/9580
 13 2017-02-02 10:58:22	0|bitcoin-git|13bitcoin/06master 148fc6989 15practicalswift: Remove redundant semicolons
 14 2017-02-02 10:58:22	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ae972a5e996a...4e19efba0331
 15 2017-02-02 10:58:23	0|bitcoin-git|13bitcoin/06master 144e19efb 15Wladimir J. van der Laan: Merge #9556: Remove redundant semicolons...
 16 2017-02-02 10:58:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9556: Remove redundant semicolons (06master...06remove-redundant-braces) 02https://github.com/bitcoin/bitcoin/pull/9556
 17 2017-02-02 12:05:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4e19efba0331...7c93952feccb
 18 2017-02-02 12:05:16	0|bitcoin-git|13bitcoin/06master 143e900ac 15Matt Corallo: Require merge commits merge branches on top of other merge commits...
 19 2017-02-02 12:05:16	0|bitcoin-git|13bitcoin/06master 14ba94426 15Matt Corallo: Test that pushes to bitcoin/bitcoin are signed per verify-commits
 20 2017-02-02 12:05:17	0|bitcoin-git|13bitcoin/06master 147c93952 15Wladimir J. van der Laan: Merge #9656: Check verify-commits on pushes to master...
 21 2017-02-02 12:05:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9656: Check verify-commits on pushes to master (06master...062017-01-fix-verify-commits) 02https://github.com/bitcoin/bitcoin/pull/9656
 22 2017-02-02 12:14:47	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9670: contrib: github-merge improvements (06master...062017_01_ghmerge_update) 02https://github.com/bitcoin/bitcoin/pull/9670
 23 2017-02-02 12:26:27	0|bitcoin-git|13bitcoin/06master 14178454d 15Jorge Timón: Contrib: Add jtimon pgp keys for commit sigs and future gitian builds
 24 2017-02-02 12:26:27	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7c93952feccb...1c2edd9f6707
 25 2017-02-02 12:26:28	0|bitcoin-git|13bitcoin/06master 141c2edd9 15Wladimir J. van der Laan: Merge #9654: Add jtimon pgp keys for commit sigs and future gitian builds...
 26 2017-02-02 12:26:43	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9654: Add jtimon pgp keys for commit sigs and future gitian builds (06master...06jtimon-key-gpg) 02https://github.com/bitcoin/bitcoin/pull/9654
 27 2017-02-02 14:27:58	0|BlueMatt|<BlueMatt> #9650 (and, by extension, #9634) are probably 0.14
 28 2017-02-02 14:28:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/9650 | Better handle invalid parameters to signrawtransaction by TheBlueMatt · Pull Request #9650 · bitcoin/bitcoin · GitHub
 29 2017-02-02 14:28:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/9634 | Fail in DecodeHexTx if there is extra data at the end by jtimon · Pull Request #9634 · bitcoin/bitcoin · GitHub
 30 2017-02-02 14:28:05	0|BlueMatt|(ie need tag)
 31 2017-02-02 14:29:05	0|wumpus|tagged
 32 2017-02-02 14:29:09	0|BlueMatt|thanks
 33 2017-02-02 14:29:42	0|wumpus|9634 seems ready, it would be nice if it had a test though - this seems like something that could regress early if it's not caught by the tests
 34 2017-02-02 15:06:02	0|wumpus|it doesn't necessarily need to hold up the pull request, but there's not been a reply from the author yet
 35 2017-02-02 16:34:37	0|BlueMatt|wumpus: I'll take a look at doing that in a bit
 36 2017-02-02 16:35:52	0|BlueMatt|question, would anyone object to me trying to add something like https://github.com/TheBlueMatt/RelayNode/blob/next/c%2B%2B/preinclude.h to bitcoin? it makes atomics replaceable with either std::atomic or a custom thing which has valgrind annotations so that helgrind/drd actually work and dont spew spurious crap all the time
 37 2017-02-02 16:36:06	0|BlueMatt|means atomics get declared with DECLARE_ATOMIC instead of std::atomic x, though
 38 2017-02-02 16:36:31	0|BlueMatt|well, suppose they could be OUR_ATOMIC_OR_NOT, but either way
 39 2017-02-02 16:37:15	0|sipa|why use macros?
 40 2017-02-02 16:37:29	0|BlueMatt|because otherwise you override std::atomic?
 41 2017-02-02 16:37:41	0|BlueMatt|i mean you can say all atomics are now of type MACRO_ATOMIC_TYPE
 42 2017-02-02 16:38:32	0|sipa|no, if you're going to switch all places where atomocs are used to macros, why not switch them with a self defined class directly
 43 2017-02-02 16:38:53	0|sipa|and when you don't need the self defined type, have it be typedefed to be std::atomic
 44 2017-02-02 16:39:05	0|BlueMatt|yea, well same thing either way
 45 2017-02-02 16:42:04	0|BlueMatt|also, due to the presence of _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE, that file would need to be included everywhere prior to the inclusion of any std includes
 46 2017-02-02 16:42:11	0|BlueMatt|well, the atomics could be in a separate file
 47 2017-02-02 16:42:16	0|BlueMatt|but...
 48 2017-02-02 17:37:47	0|isle2983|please don't talk about coding style at the meeting
 49 2017-02-02 17:38:04	0|isle2983|I have some automation pieces coming togeher, but it might take a little while to get it done
 50 2017-02-02 17:38:23	0|wumpus|BlueMatt: wouldn't it be possible to do this with std::atomic? I like the move towards using standard primitives instead of self-defined ttpes
 51 2017-02-02 17:38:28	0|isle2983|I am working near-full-time on this in the short term
 52 2017-02-02 17:39:12	0|isle2983|a viable end objective might be a 'Nit Bot' that can analize the commits from a PR and detect a few categories of things
 53 2017-02-02 17:39:40	0|isle2983|it looks like you can load a github acct auth token into the TravisCI account as an env var
 54 2017-02-02 17:39:58	0|isle2983|so, securely the travisCI script can post content back to github
 55 2017-02-02 17:40:44	0|wumpus|are you sure that's worth spending so much work on? there are some much more pressing issues than code style
 56 2017-02-02 17:41:21	0|wumpus|we've considered using that but the TravisCI token stuff is easy to circumvent if it's used for testing pulls - the test script for the pull could just output the token or upload it somewhere
 57 2017-02-02 17:43:22	0|isle2983|I am not sure it is the ultimate thing, but there is a cost to the project - you spent 20 minutes talking about it last week
 58 2017-02-02 17:43:45	0|isle2983|and there is some annoyance at trivial pulls
 59 2017-02-02 17:43:48	0|wumpus|that's a rarity, usually it doesn't come up at all
 60 2017-02-02 17:44:10	0|isle2983|if it can be automated, it should be automated at some point
 61 2017-02-02 17:45:28	0|isle2983|I am also of the school that says code is written once, and read 100s of times afterwards, so make reading easy
 62 2017-02-02 17:45:48	0|isle2983|probably 100,000s of times afterwards for bitcoin
 63 2017-02-02 17:45:55	0|wumpus|BlueMatt: in general the more 'you need to use this special type' rules a project has, the harder it is to contribute to. Though making it easier to valgrind/helgrind is certainly a valuable goal.
 64 2017-02-02 17:49:16	0|wumpus|isle2983: all too true, but I don't think most of the (superficial) code style makes much difference to that. Having a sensible design and the logic and the reason for things documented/commented is what is important to understanding difficult code
 65 2017-02-02 17:54:31	0|isle2983|totally agreed, but I see that as all the more reason to filter out distractions so that attention can focus 100% on the important things
 66 2017-02-02 17:54:42	0|wumpus|focusing too much on moving around spaces and such takes away the focus from what really matters, and it's much easier so it easily crowds out deeper thinking
 67 2017-02-02 17:55:31	0|wumpus|well as I see it a 'style nit bot' would add distractions, not remove them
 68 2017-02-02 17:57:23	0|gmaxwell|talking about pointless stuff is good for community. :)
 69 2017-02-02 17:57:41	0|wumpus|unless it annoys people
 70 2017-02-02 17:58:51	0|isle2983|in the short term, perhaps. but in the long term it would train submitters to get the PR right offline. Using common tools and scripts also lets the coders just integrate it into their text editor so they don't have to think.
 71 2017-02-02 17:59:18	0|wumpus|there's two ways to go at this sanely: one is to use something like clang-format from the begining. For example in golang projects everyone uses the same formatter with the same style, preventing any disagreements about style. The other is to do best effort and just not worry too much about it. It's too late for the former.
 72 2017-02-02 17:59:32	0|wumpus|our goal is not to 'train submitters'
 73 2017-02-02 18:00:54	0|wumpus|it's just importing concerns that shouldn't be part of this, creating extra bureaucratic barriers
 74 2017-02-02 18:01:49	0|BlueMatt|wumpus: yea, I tend to agree, I'm not sure I really want to do it, but if valgrind doesnt get an update to actually support std::atomic I might have to do it
 75 2017-02-02 18:03:58	0|gmaxwell|wumpus: I wouldn't worry too much; thats what review is for.. and that is the kind of thing everyone will spot, no one should mind fixing up, especially since it would be visible in practice all over...  Obviously preferable to not.
 76 2017-02-02 18:05:23	0|wumpus|gmaxwell: I do worry about it. We've had this problem in the past with a certain person commenting on every pull about e.g. sorting include headers, whitespace, and so on, and it was incredibly annoying
 77 2017-02-02 18:07:11	0|gmaxwell|ah, I was commenting more on the macro for atomics.
 78 2017-02-02 18:07:24	0|gmaxwell|Yes. It certantly doesn't work if everyeone doesn't support it, especially if its merely cosmetic.
 79 2017-02-02 18:08:01	0|wumpus|right, I'm not worried about using a custom type for std::atomic, it shouldn't be used that much anyway. THough it seems to be something a tool should just handle.
 80 2017-02-02 18:08:10	0|gmaxwell|but "make valgrind usable to help us find data-races" is a substantial boon I hope we could all support. :)
 81 2017-02-02 18:09:53	0|wumpus|sure
 82 2017-02-02 18:10:29	0|wumpus|though it seems reasonably important to have it work for std::atomic so that the tool can analyse all projects using it, without needing special support at that side
 83 2017-02-02 18:18:31	0|cfields|wumpus: i wonder if that one, specifically, gets solved with newer versions of std libraries. For ex, iirc newer libc++ adds attributes to std::mutex/std::lock, etc, so that we won't need the wrappers in threadsafety.h
 84 2017-02-02 18:18:45	0|isle2983|I am happy to talk more about style automation on side channels - or also hear suggestions for what else I could be working on. I am in the learning phase and am open to anything that needs an extra brain and can help the project. Yielding now for important topics. Thanks.
 85 2017-02-02 18:22:34	0|wumpus|isle2983: to be clear I'm not trying to bash your work, just trying to set expectation how these kind of things are received, so you don't spend a lot of work automating something that won't be used
 86 2017-02-02 18:23:50	0|wumpus|cfields: indeed it could also be improved from the side of the library
 87 2017-02-02 18:24:15	0|cfields|yes, found it: https://reviews.llvm.org/D14731
 88 2017-02-02 18:24:40	0|cfields|i guess runtime tools wouldn't get access to those attributes, though
 89 2017-02-02 18:25:33	0|wumpus|they could if it would be exposed in debug metadata in some way
 90 2017-02-02 18:26:29	0|wumpus|isle2983: as for things to be working on, improving the tests is always very welcome :)
 91 2017-02-02 18:28:46	0|Chris_Stewart_5|isle2983: If you are interested, I'm working on a new testing paradigm in core in #8469
 92 2017-02-02 18:28:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
 93 2017-02-02 18:30:01	0|Chris_Stewart_5|I've found it to be a useful way to get familiar with the core codebase as well
 94 2017-02-02 18:30:18	0|Chris_Stewart_5|wrt to what wumpus said about improving/adding tests
 95 2017-02-02 18:30:37	0|isle2983|wumpus: hey no worries. I wouldn't want to work on a project that didn't have strong skepticism and pushback
 96 2017-02-02 18:31:05	0|isle2983|Chris_Stewart_5: cool, I will take a peek. Thanks.
 97 2017-02-02 18:34:18	0|sipa|BlueMatt: are relaxed reads from an atomic even recognizable from the binary?
 98 2017-02-02 18:34:40	0|BlueMatt|relaxed I dont know, but certainly most reads/writes show up in the st as load()/store()
 99 2017-02-02 18:35:51	0|BlueMatt|its unclear to me whether helgrind is just being overly conservative and reporting them anyway because they could still be logic-races, or whether helgrind also isnt taking into account the ordering there
100 2017-02-02 18:36:17	0|BlueMatt|its also unclear to me whether libc++ is doing the right thing with _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE set in their atomics and I just dont have that mapped to helgrind's equivalent
101 2017-02-02 18:36:25	0|BlueMatt|which may be an easy fix
102 2017-02-02 18:36:43	0|BlueMatt|(but that hadnt previously fixed it months ago when I was doing that for the relay network code)
103 2017-02-02 18:55:44	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9671: Fix super-unlikely race introduced in 236618061a445d2cb11e72 (06master...062017-02-fix-initnode-race) 02https://github.com/bitcoin/bitcoin/pull/9671
104 2017-02-02 18:55:47	0|BlueMatt|cfields: I blame you for ^, btw, you asked me to do it :p
105 2017-02-02 18:59:21	0|cfields|BlueMatt: In my defense I'm pretty sure i only said that it was ugly and that it should be cleaned up later, but I didn't complain when you went ahead and moved it either. So I'll take the blame :)
106 2017-02-02 18:59:54	0|BlueMatt|lol, yea, well /someone/ should have bothered to look at the implications :(
107 2017-02-02 19:00:04	0|lightningbot|Meeting started Thu Feb  2 19:00:02 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
108 2017-02-02 19:00:04	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
109 2017-02-02 19:00:04	0|wumpus|#startmeeting
110 2017-02-02 19:00:08	0|jonasschnelli|hi
111 2017-02-02 19:00:10	0|BlueMatt|oh thats today?
112 2017-02-02 19:00:19	0|gmaxwell|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
113 2017-02-02 19:00:31	0|sipa|yow.
114 2017-02-02 19:00:38	0|luke-jr|BlueMatt: no, it's fake news.
115 2017-02-02 19:00:39	0|wumpus|BlueMatt: it's thursday I hope?
116 2017-02-02 19:00:40	0|luke-jr|/s
117 2017-02-02 19:00:50	0|sipa|luke-jr: alternative news
118 2017-02-02 19:00:54	0|BlueMatt|wumpus: alternative facts
119 2017-02-02 19:00:55	0|BlueMatt|heh
120 2017-02-02 19:01:01	0|sipa|jinx
121 2017-02-02 19:01:29	0|sipa|i don't have topics
122 2017-02-02 19:01:33	0|wumpus|foremost topic would be what to still include in 0.14, as rc1 release is planned for monday
123 2017-02-02 19:02:10	0|gmaxwell|I propose not including any bugs.
124 2017-02-02 19:02:15	0|BlueMatt|I think the current list (+#9671) are going to be required for release, sooooo
125 2017-02-02 19:02:16	0|gribble|https://github.com/bitcoin/bitcoin/issues/9671 | Fix super-unlikely race introduced in 236618061a445d2cb11e72 by TheBlueMatt · Pull Request #9671 · bitcoin/bitcoin · GitHub
126 2017-02-02 19:02:27	0|jonasschnelli|These are the issues tagged for 0.14 : https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.14.0
127 2017-02-02 19:02:36	0|MarcoFalke|I think only remaining is the net stuff?
128 2017-02-02 19:03:04	0|cfields|rebasing 9609 now.
129 2017-02-02 19:03:15	0|instagibbs|hi
130 2017-02-02 19:03:26	0|BlueMatt|MarcoFalke: we added the signrawtransaction assertion too
131 2017-02-02 19:03:26	0|wumpus|do we have a fix for #9027 in the works yet?
132 2017-02-02 19:03:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub
133 2017-02-02 19:03:28	0|jonasschnelli|Imo the importmulti fixes can be done after 0.14
134 2017-02-02 19:03:29	0|BlueMatt|and importmulti
135 2017-02-02 19:03:31	0|cfields|probably a good time to call for release notes additions
136 2017-02-02 19:03:34	0|BlueMatt|wumpus: I vote we push that one
137 2017-02-02 19:03:37	0|BlueMatt|(to 0.15)
138 2017-02-02 19:03:49	0|wumpus|BlueMatt: ok, no problem with that
139 2017-02-02 19:03:56	0|BlueMatt|because not-regression, it turns out
140 2017-02-02 19:04:04	0|sipa|not regression?
141 2017-02-02 19:04:08	0|BlueMatt|slightly worse than it tused to be, but not so massively so that I think we definitely need to fix it asap
142 2017-02-02 19:04:10	0|gmaxwell|changing the API in the very next release would be unfortunate.
143 2017-02-02 19:04:25	0|achow101|are the three rpc things necessary for this release?
144 2017-02-02 19:04:26	0|BlueMatt|gmaxwell: context?
145 2017-02-02 19:04:31	0|BlueMatt|sipa: you're the one who decided it wasnt!
146 2017-02-02 19:04:31	0|jonasschnelli|gmaxwell: importmulti?
147 2017-02-02 19:04:34	0|sipa|gmaxwell: fixing 9027 does not need an api change afaik
148 2017-02-02 19:04:43	0|sipa|BlueMatt: oh!
149 2017-02-02 19:05:05	0|wumpus|we could disable importmulti if it isn't safe in time for the release
150 2017-02-02 19:05:32	0|sipa|or leave it undocumented?
151 2017-02-02 19:05:45	0|wumpus|depends on whether the issue of #9491 is serious enough
152 2017-02-02 19:05:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub
153 2017-02-02 19:06:00	0|gmaxwell|fixing the fact that it's very easy to fail to rescan anything, when you thought it was... does.
154 2017-02-02 19:06:23	0|wumpus|yes undocumented or could add a "warning: experimental, API will likely change next release" in any case too
155 2017-02-02 19:06:42	0|jonasschnelli|Or we just fix 9491... seems not very complex?
156 2017-02-02 19:06:53	0|jonasschnelli|Can fix in rc2 if it's to late for monday?
157 2017-02-02 19:07:27	0|wumpus|sure
158 2017-02-02 19:07:37	0|wumpus|but there's no guarantee there is a rc2
159 2017-02-02 19:07:42	0|gmaxwell|okay, lets see where that goes in the next couple days.
160 2017-02-02 19:07:48	0|wumpus|I don't know how hard it is? it seems to have caused quite a discussion but no fix
161 2017-02-02 19:07:51	0|luke-jr|importmulti seems akin to importprivkey which shouldn't be used by users anyway?
162 2017-02-02 19:07:59	0|gmaxwell|We can hide it right before cutting RC1 if nothing else.
163 2017-02-02 19:08:11	0|wumpus|yes
164 2017-02-02 19:08:21	0|gmaxwell|ashame, as it's a nice improvement.
165 2017-02-02 19:08:28	0|sipa|i think the fix would be easy?
166 2017-02-02 19:08:44	0|gmaxwell|sure, that is why I said lets see.
167 2017-02-02 19:08:54	0|achow101|can't you just change the default timestamp to be 0?
168 2017-02-02 19:08:54	0|BlueMatt|who is working on it?
169 2017-02-02 19:08:57	0|gmaxwell|but we have a fallback if it doesn't get fixed.
170 2017-02-02 19:09:00	0|BlueMatt|"lets see" only works if someone does it :p
171 2017-02-02 19:09:10	0|gmaxwell|achow101: then there is no easy way to express now.
172 2017-02-02 19:09:30	0|jonasschnelli|Would a fix where we set the importmulti timestamp to 0 instead of "now" do it for 0.14?
173 2017-02-02 19:09:39	0|luke-jr|gmaxwell: using time() from your OS?
174 2017-02-02 19:09:42	0|jonasschnelli|*default timestamp
175 2017-02-02 19:10:06	0|achow101|-1 for "now"
176 2017-02-02 19:10:06	0|wumpus|or have no default at all and require a time to be specified
177 2017-02-02 19:10:16	0|jonasschnelli|wumpus: +1
178 2017-02-02 19:10:21	0|luke-jr|wumpus: no default at all is nice since it allows a default to be chosen later
179 2017-02-02 19:10:32	0|jonasschnelli|0 as timestamp is very inefficient.
180 2017-02-02 19:10:35	0|gmaxwell|Lets not hash it out here, there is an issue.
181 2017-02-02 19:10:47	0|jonasschnelli|Okay. Lets comment there. Agree with gmaxwell
182 2017-02-02 19:10:59	0|gmaxwell|I agree with jonasschnelli in the sense there that we really have to stop assuming a full rescan is possible.
183 2017-02-02 19:11:30	0|wumpus|good point, yes
184 2017-02-02 19:11:35	0|jonasschnelli|Is also very inefficient if you have pruned or run hybrid SPV
185 2017-02-02 19:11:38	0|gmaxwell|It takes many hours on my normal development system, and is still quite slow even on the fastest hardware available.   But avoiding the rescan takes second seat to surprising the user. :)
186 2017-02-02 19:11:38	0|wumpus|it certainly shouldn't be the default
187 2017-02-02 19:11:42	0|wumpus|it's inefficient and lazy
188 2017-02-02 19:12:39	0|gmaxwell|in my view, except for certan recover operations that are infrequently done-- rescan effectively doesn't work anymore (takes more time than converting your entire usage to a third party api...)
189 2017-02-02 19:13:23	0|wumpus|users of the API should be encouraged to keep track of key birthdates
190 2017-02-02 19:14:06	0|gmaxwell|if we define a new private key format in the not so far future, we should make sure its string clearly integrates a birthdate. :P
191 2017-02-02 19:14:27	0|BlueMatt|ok, so discuss on the issue....next topic?
192 2017-02-02 19:14:27	0|wumpus|a full rescan is indeed only something that should be done for infrequent recovery reasons
193 2017-02-02 19:16:00	0|wumpus|no other topics?
194 2017-02-02 19:16:24	0|MarcoFalke|shortest meeting ever
195 2017-02-02 19:17:00	0|wumpus|I had expected heated debates on what to include last-minute in 0.14 and why to delay the rc, what a disappointment! </s>
196 2017-02-02 19:17:03	0|BlueMatt|great, lets get 0.14 done so I can get back to writing code :)
197 2017-02-02 19:17:11	0|jonasschnelli|Heh.
198 2017-02-02 19:17:15	0|sdaftuar|let's talk about code style again
199 2017-02-02 19:17:16	0|BlueMatt|wumpus: I vote we push it back a month so we can do all the things we wanted to a month ago :p
200 2017-02-02 19:17:26	0|wumpus|BlueMatt: lol!
201 2017-02-02 19:17:44	0|BlueMatt|hum
202 2017-02-02 19:17:44	0|BlueMatt|wait, i had something to talk about re: cde style
203 2017-02-02 19:17:55	0|gmaxwell|BlueMatt: die
204 2017-02-02 19:17:56	0|sdaftuar|i'll get the baseball bat
205 2017-02-02 19:17:57	0|BlueMatt|oh, auto
206 2017-02-02 19:18:04	0|jonasschnelli|Bumpfee: is there a reason why the logic is in the rpcwallet.cpp and not in wallet.cpp?
207 2017-02-02 19:18:15	0|jonasschnelli|Makes it really hard to use in the gui...
208 2017-02-02 19:18:25	0|BlueMatt|jonasschnelli: please move it, agreed
209 2017-02-02 19:18:26	0|luke-jr|jonasschnelli: it can be moved
210 2017-02-02 19:18:26	0|sdaftuar|jonasschnelli: i think we can refactor as needed
211 2017-02-02 19:18:30	0|luke-jr|in 0.15*
212 2017-02-02 19:18:35	0|wumpus|jonasschnelli: because it's only used in rpcwallet.cpp, if you need it in a more general place move it
213 2017-02-02 19:18:42	0|jonasschnelli|Okay.
214 2017-02-02 19:18:56	0|sipa|BlueMatt: i am strongly in favor of auto.
215 2017-02-02 19:19:02	0|wumpus|jonasschnelli: although moving everything to wallet.cpp isn't very nice either, we should refactor the wallet code some day
216 2017-02-02 19:19:05	0|luke-jr|I did suggest it earlier, but didn't seem like a blocker for merging
217 2017-02-02 19:19:08	0|wumpus|I'm also in favor of auto
218 2017-02-02 19:19:16	0|BlueMatt|sipa: it makes certain review much, much harder (I often grep for "everywhere X is used")
219 2017-02-02 19:19:17	0|luke-jr|wumpus: well, it's wallet code..
220 2017-02-02 19:19:24	0|BlueMatt|and have already missed things as a result
221 2017-02-02 19:19:25	0|wumpus|luke-jr: so? not all wallet code needs to be in one file
222 2017-02-02 19:19:36	0|wumpus|forbidding auto is just masochism
223 2017-02-02 19:19:42	0|jonasschnelli|wumpus: yes. Thats a good point.
224 2017-02-02 19:19:44	0|BlueMatt|wumpus: i wasnt voding forbidding it
225 2017-02-02 19:19:48	0|sipa|BlueMatt: introduce an incompatible change to the type, and recompile. tadaa, all places it is used
226 2017-02-02 19:19:51	0|BlueMatt|only carefully considering its use
227 2017-02-02 19:19:51	0|cfields|sipa: same. BlueMatt: maybe paste the thread in question?
228 2017-02-02 19:19:57	0|luke-jr|I like auto when the type is implied by some other type; eg, instead of xyz::value_type
229 2017-02-02 19:20:07	0|jtimon|yeah, but not forbidding it doesn't mean recommending it always either
230 2017-02-02 19:20:11	0|BlueMatt|https://github.com/bitcoin/bitcoin/pull/9609#discussion_r98335218
231 2017-02-02 19:20:17	0|wumpus|we have a whole src/wallet directory which could have tons of different implementation files for different facets of the wallet, instead of stashing it all into one file
232 2017-02-02 19:20:40	0|BlueMatt|(I believe gmaxwell's comment there was intedned for a different line)
233 2017-02-02 19:20:46	0|jonasschnelli|yes. Stuff like coin selection should be more modular
234 2017-02-02 19:21:05	0|wumpus|sure, as with any use of any c++ statement, use of auto should be measured
235 2017-02-02 19:21:09	0|MarcoFalke|Lets do it after priority removal
236 2017-02-02 19:21:19	0|MarcoFalke|Otherwise we step on each others toes
237 2017-02-02 19:21:25	0|wumpus|if you have some specific cases where it's bad to use auto, please document them
238 2017-02-02 19:21:28	0|BlueMatt|wumpus: mostly only things that are /actually/ a mile of text to type, imo
239 2017-02-02 19:21:58	0|sipa|BlueMatt: and not needing to change things all over the place when you turn a tuple into a struct
240 2017-02-02 19:22:09	0|BlueMatt|sipa: I have no problem reviewing sed-based changes
241 2017-02-02 19:22:09	0|sipa|or add a wrapper
242 2017-02-02 19:22:18	0|BlueMatt|in fact prefer that
243 2017-02-02 19:22:19	0|wumpus|BlueMatt: there's plenty of those - c++ is overly verbose, auto is a great advancement
244 2017-02-02 19:22:22	0|sipa|they're still annoying to fo
245 2017-02-02 19:22:29	0|BlueMatt|since I'm gonna go read every single place the change effected anyway
246 2017-02-02 19:22:30	0|BlueMatt|to review
247 2017-02-02 19:22:32	0|sipa|*to do
248 2017-02-02 19:22:52	0|sipa|and of course, let's consider on a case by case basis
249 2017-02-02 19:22:57	0|wumpus|right
250 2017-02-02 19:22:58	0|BlueMatt|wumpus: sure, iterators in iterators, np
251 2017-02-02 19:23:05	0|BlueMatt|yea, ok, whatever, I'll shut up
252 2017-02-02 19:23:06	0|sipa|but in my own preference, that is overwhelmingly the case
253 2017-02-02 19:24:02	0|cfields|well the specific case here is for loops. "for (auto& foo : bar)"
254 2017-02-02 19:24:03	0|MarcoFalke|Agree with BlueMatt, that auto should not be used unless necessary.
255 2017-02-02 19:24:06	0|cfields|any reason not to use auto there?
256 2017-02-02 19:24:06	0|jtimon|BlueMatt: the question is, do you have a general advice on when not to use auto?
257 2017-02-02 19:24:24	0|wumpus|it's never *necessary* auto is just nice
258 2017-02-02 19:24:26	0|BlueMatt|cfields: yes, so I can grep and review if the type's behavior changes in some way
259 2017-02-02 19:24:38	0|BlueMatt|jtimon: personally, if the type really, really doesnt matter
260 2017-02-02 19:24:41	0|luke-jr|cfields: if it's liable to produce bad results with bar changing under it
261 2017-02-02 19:24:51	0|BlueMatt|(which means very rarely use it)
262 2017-02-02 19:24:58	0|jtimon|BlueMatt: I'm afraid "doesn't matter" it's too vague here
263 2017-02-02 19:25:06	0|BlueMatt|eg if you're taking an iterator and passing it through to another function
264 2017-02-02 19:25:06	0|wumpus|I don't think this is going anywhere, too much isagreement
265 2017-02-02 19:25:10	0|wumpus|any other topics?
266 2017-02-02 19:25:24	0|wumpus|BlueMatt: function arguments can't use auto, right?
267 2017-02-02 19:25:30	0|sipa|indeed
268 2017-02-02 19:25:51	0|sipa|c++14 and later introduce some auto types in lambdas
269 2017-02-02 19:25:55	0|BlueMatt|wumpus: correct, but eg doing auto it = map.find(thing); if (it != ma.end()) DoThingWith(*it);
270 2017-02-02 19:25:58	0|BlueMatt|is like not a problem
271 2017-02-02 19:26:24	0|BlueMatt|auto it = map.find(thing); if (it != ma.end()) ILikePonies(it->second.rainbows); I do not like
272 2017-02-02 19:26:25	0|sipa|BlueMatt: how is that different from a for (const auto& x : container) {}
273 2017-02-02 19:27:09	0|BlueMatt|sipa: because in the specific case here the thing in the loop is not defined to take a specific type
274 2017-02-02 19:27:13	0|BlueMatt|it is templated
275 2017-02-02 19:27:16	0|jtimon|my question was, do you have a deductive method for finding the not ok cases instead of an inductive one for the "not a problem cases"?
276 2017-02-02 19:27:22	0|sipa|you can see that as an oblivious loop with iterators, and passing *it to a function that is tje body of the loop
277 2017-02-02 19:27:40	0|BlueMatt|jtimon: <BlueMatt> jtimon: personally, if the type really, really doesnt matter
278 2017-02-02 19:28:13	0|sipa|i see your point, but i don't think it weighs up against the benefitd
279 2017-02-02 19:28:16	0|sipa|*benefits
280 2017-02-02 19:28:21	0|wumpus|if you're iterating over some container, the type of container usually really doesn't matter, unless you make specific assumptions (but then you'd generally not be using a range for loop in the first place)
281 2017-02-02 19:28:43	0|BlueMatt|wumpus: imo if you are ever actually dereferencing the type you should not use auto
282 2017-02-02 19:28:57	0|sipa|BlueMatt: your own example dereferences...
283 2017-02-02 19:28:58	0|BlueMatt|if you're dereferencing the iterator to eg a pair or just taking the element and passing it to something else, ok
284 2017-02-02 19:29:10	0|BlueMatt|but if you're dereferencing it and accessing something inside it, no
285 2017-02-02 19:29:29	0|sipa|then we might as well not use it at all, i think
286 2017-02-02 19:29:47	0|jtimon|ok, I think I get what you mean by "doesn't matter" now
287 2017-02-02 19:29:54	0|BlueMatt|sipa: there are many places where you might do for (auto& thing: list) ActOn(thing);
288 2017-02-02 19:29:57	0|BlueMatt|thats reasonable
289 2017-02-02 19:30:09	0|sipa|requiring programmers to spell out redundant information just so you can grep for it seems extreme to me
290 2017-02-02 19:30:28	0|BlueMatt|yes, I didnt expect people to agree with me...I have extreme distaste for auto, personally
291 2017-02-02 19:30:28	0|gmaxwell|sipa: so functions shouldn't have prototypes? :)
292 2017-02-02 19:30:35	0|wumpus|yes, that' extreme, and not going tohhappen. Just use smarter tools.
293 2017-02-02 19:30:44	0|BlueMatt|wumpus: suggestions?
294 2017-02-02 19:31:31	0|wumpus|it should be fairly easy to implement using clang's parser, would be surprised if it doesn't exist
295 2017-02-02 19:31:51	0|gmaxwell|There is another side to it is that auto enables you to write code that acts on a type while having no idea of the type yourself. Which is safe 99% of the time and deadly the rest.
296 2017-02-02 19:32:22	0|gmaxwell|because in C++ not all operations which are catgorically unsafe on a type are actually stopped by typechecking. :(
297 2017-02-02 19:33:43	0|gmaxwell|I have an auto to a container... and then I extract an auto to an iterator on it and erase things. Is my code guilty of the sin of using an invalidated iterator? It depends on what container was in use, and that was hid by auto...
298 2017-02-02 19:34:09	0|gmaxwell|But... that sort of thing is an edge case, I'd love to see a realistic list of where auto is likely to cause problems, just to keep it in mind.
299 2017-02-02 19:34:30	0|wumpus|right - just keep it in mind while reviewing
300 2017-02-02 19:34:44	0|wumpus|and if there are well-defined cases where auto is dangerous, they should be documented in the developer notes
301 2017-02-02 19:34:58	0|BlueMatt|ehh, ok, well I go read all of wallet half the time reviewing wallet changes, i guess I'll just start doing that for net, too :p
302 2017-02-02 19:35:14	0|BlueMatt|(not a bad thing, that)
303 2017-02-02 19:35:30	0|gmaxwell|unfortunately, auto is most interesting when you have some horrible complex signature.  But those are the cases where it is also more of an issue.
304 2017-02-02 19:36:09	0|cfields|gmaxwell: for(auto& : foo) doesn't give you an iterator though, just a reference. So imo that should be highly preferred when possible to avoid your example.
305 2017-02-02 19:36:20	0|wumpus|well no, it's most interesting for bog-standard loops, 99% of the cases. If you're doing anything horribly complex, that's probably where you should be careful
306 2017-02-02 19:36:34	0|jtimon|BlueMatt: we can agree that auto is totally fine for unittests too, right? :p
307 2017-02-02 19:37:22	0|cfields|(preferred over auto foo = bar.begin(), that is)
308 2017-02-02 19:37:24	0|gmaxwell|wumpus: well my point is that stating the type explicitly is just as easy as auto when it's simple and obvious.
309 2017-02-02 19:37:30	0|sipa|gmaxwell: when you have some horrid complex type signature, best practice is to introduce a typedef for it... that also results in succint usage, and lacks the review concerns that BlueMatt has i think
310 2017-02-02 19:37:38	0|jtimon|I agree it removes clarity some times
311 2017-02-02 19:37:49	0|wumpus|gmaxwell: it's *easy* but the point is to avoid unnecessary verbosity/typing, not so you can forget the type
312 2017-02-02 19:37:55	0|BlueMatt|sipa: yes, agreed, also means dont use auto in place, which some people like to do
313 2017-02-02 19:38:11	0|jtimon|but I don't have a clear criterion on when to use it like matt
314 2017-02-02 19:38:15	0|BlueMatt|wumpus: I'm generally 100% in favor of extra verbosity
315 2017-02-02 19:38:26	0|gmaxwell|fking java programmers. :P
316 2017-02-02 19:38:26	0|wumpus|e.g. to avoid having to type std::vector<std::Strring> for the zillionth time
317 2017-02-02 19:38:29	0|wumpus|BlueMatt: go use java
318 2017-02-02 19:38:30	0|BlueMatt|extra verbosity generally means less magic, which makes review easier
319 2017-02-02 19:38:35	0|BlueMatt|lol, i expected that....
320 2017-02-02 19:38:38	0|gmaxwell|(though on type signatures, I usually also prefer being explicit more often)
321 2017-02-02 19:38:46	0|wumpus|BlueMatt: that's not categorically true, more verbosity also means more distraction
322 2017-02-02 19:38:53	0|sipa|agree
323 2017-02-02 19:39:00	0|BlueMatt|wumpus: well, ok, more verbosity as long as it actually provides information
324 2017-02-02 19:39:06	0|sipa|nobody actually looks at what large type definitions contain
325 2017-02-02 19:39:08	0|wumpus|having lot's of boilerplate does *not* equal easier review
326 2017-02-02 19:39:12	0|BlueMatt|public static void main(String[] args) {} probably doesnt provide more information
327 2017-02-02 19:39:27	0|wumpus|anyhow
328 2017-02-02 19:39:30	0|BlueMatt|sipa: I do!
329 2017-02-02 19:39:37	0|wumpus|any other topics? this is going the wrong way
330 2017-02-02 19:39:41	0|sipa|haha
331 2017-02-02 19:39:46	0|luke-jr|lol
332 2017-02-02 19:40:24	0|BlueMatt|soooo...endmeeting?
333 2017-02-02 19:40:27	0|wumpus|#endmeeting
334 2017-02-02 19:40:28	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.log.html
335 2017-02-02 19:40:28	0|lightningbot|Meeting ended Thu Feb  2 19:40:26 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
336 2017-02-02 19:40:28	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.html
337 2017-02-02 19:40:28	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.txt
338 2017-02-02 19:40:40	0|gmaxwell|wumpus: your request is a little explicit, you could have just said...  for auto meetingstep.
339 2017-02-02 19:41:02	0|BlueMatt|heh
340 2017-02-02 19:41:05	0|wumpus|gmaxwell: #endcurrentcontext
341 2017-02-02 19:42:23	0|jtimon|regarding https://github.com/bitcoin/bitcoin/pull/9609#issuecomment-276974228 I generally dislike habing the release branches differ from the master they branched from more than they need "artificially"
342 2017-02-02 19:43:26	0|jtimon|also for "we can fix that after the branch" types of things
343 2017-02-02 19:44:33	0|MarcoFalke|jtimon: master is for testing, release branches are for production
344 2017-02-02 19:44:44	0|jtimon|MarcoFalke: I know
345 2017-02-02 19:44:55	0|gmaxwell|The asserts don't leve enough record in any case, during development.
346 2017-02-02 19:45:27	0|MarcoFalke|jtimon: The thing is you may want asserts during testing, but you may not want them in production
347 2017-02-02 19:45:32	0|gmaxwell|I've had asserts fire and have had no idea which assert fired or why, only that my daemon went away.  So a crash was introduced but we didn't even learn from it.
348 2017-02-02 19:45:47	0|MarcoFalke|jtimon: We can not compile without asserts, so this is the only way?
349 2017-02-02 19:46:08	0|jtimon|MarcoFalke: perhaps something like if(debug) ?
350 2017-02-02 19:46:35	0|gmaxwell|(moreover, differences in behavior between testing and production exposes you to bugs that the testing code fixes)
351 2017-02-02 19:46:43	0|gmaxwell|e.g. when an asserts check has a side effect.
352 2017-02-02 19:47:34	0|gmaxwell|In any case, asserts around the net stuff are also special because the testing there is woefully inadequate right now.
353 2017-02-02 19:48:02	0|gmaxwell|As evidenced by the fact that the version assert was there for months and only triggered a couple times, but yet was still triggerable!
354 2017-02-02 19:48:37	0|jtimon|yeah, I'm talking more generally about the "we can fix that after the branch" or let's do A and master and B in 0.14 attitude
355 2017-02-02 19:48:45	0|luke-jr|#9619 has plenty of ACKs; shall I go add test cases, or merge this and PR test cases separate?
356 2017-02-02 19:48:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/9619 | Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates by luke-jr · Pull Request #9619 · bitcoin/bitcoin · GitHub
357 2017-02-02 19:49:26	0|BlueMatt|I do believe we need to start talking about making our assert infrastructure better - building test bins by default with DEBUG_LOCKORDER and many more asserts, with most of those asserts just printing warnings in production
358 2017-02-02 19:50:48	0|jtimon|yeah, and that doesn't require to have different code, maybe just change the value of a constant or something
359 2017-02-02 19:52:16	0|jtimon|or do all that stuff when -debug
360 2017-02-02 19:52:59	0|bitcoin-git|[13bitcoin] 15isle2983 closed pull request #9459: Improvements to copyright_header.py and some minor copyright header tweaks. (06master...06PR-copyright-script-improve) 02https://github.com/bitcoin/bitcoin/pull/9459
361 2017-02-02 19:53:27	0|bitcoin-git|[13bitcoin] 15isle2983 closed pull request #9603: Add basic_style.py to automate some style checking. (06master...06PR-basic-style) 02https://github.com/bitcoin/bitcoin/pull/9603
362 2017-02-02 20:14:05	0|jtimon|ugh, I missed the change in style... https://github.com/bitcoin/bitcoin/pull/9566#discussion_r98842239
363 2017-02-02 20:15:40	0|jtimon|if (checkwhatever)
364 2017-02-02 20:15:40	0|jtimon|return false/error(...)/state.DoS(...)
365 2017-02-02 20:15:40	0|jtimon|that's no suddenly against our style...
366 2017-02-02 20:15:40	0|jtimon|there's a lot of code of the form
367 2017-02-02 20:15:58	0|jtimon|s/that's no/that's now/
368 2017-02-02 20:16:29	0|sipa|jtimon: indeed. my preference is that anytime you're touching code (except simple move-onlys), you adapt the style of the code
369 2017-02-02 20:16:40	0|sipa|but no big refactors changing the style all over
370 2017-02-02 20:17:57	0|jtimon|right, my point is I would prefer that our rules for style was something that we're actually closer to achieve, even if that's something less strict
371 2017-02-02 20:19:11	0|jtimon|this is an invitation for someone to create a PR correcting some of those cases
372 2017-02-02 20:27:41	0|isle2983|it seems strange to me that the style is a moving target. is there some nuance that I am missing?
373 2017-02-02 20:28:20	0|isle2983|I would think that one of the off-the-shelf choices would be best.
374 2017-02-02 20:28:48	0|sipa|isle2983: the original satoshi code used a very arcane style, which many people dislike, and has in practice not been followed by contributors after satoshi left
375 2017-02-02 20:29:12	0|sipa|at some point we formalized the effective style people were using in the developer notes, but reviewers didn't actually enforce it
376 2017-02-02 20:29:35	0|sipa|plus, there was a strong "mimick the style around what you're editing" tendency, which doesn't really help converging
377 2017-02-02 20:29:51	0|sipa|i hope that going forward we start enforcing it
378 2017-02-02 20:29:56	0|sipa|in modified code, at least
379 2017-02-02 20:30:07	0|sipa|https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#developer-notes
380 2017-02-02 20:36:01	0|isle2983|yeah, that makes sense to me. but I am not going to poke the enforcement side too hard.
381 2017-02-02 20:36:42	0|jtimon|hmm, I'm also not sure https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format enforces the "always braces except if everything in one line" rule
382 2017-02-02 20:37:08	0|sipa|i'm not sure that it can
383 2017-02-02 20:37:43	0|isle2983|the clang-format script in #9658 generates a 'score' metric
384 2017-02-02 20:37:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9658 | Add clang_format.py to help automate code style analysis by isle2983 · Pull Request #9658 · bitcoin/bitcoin · GitHub
385 2017-02-02 20:38:05	0|isle2983|so at the very least, we can watch it converge rather than diverge over time
386 2017-02-02 20:39:41	0|jtimon|yeah, it seems some (all?) of your tools would fit  better in https://github.com/bitcoin-core/bitcoin-maintainer-tools from what other people said
387 2017-02-02 20:40:12	0|isle2983|yep
388 2017-02-02 20:40:26	0|isle2983|I am happy with that as a starting place
389 2017-02-02 20:41:12	0|jtimon|IMO, style rules aren't so useful until you start to enforce it with the help of automatic tools in the whole project, that's the only way you can really stop talking about style, which is the goal of having style rules in the first place, right?
390 2017-02-02 20:41:21	0|gmaxwell|sipa: clang-format (latest versions) can enforce that rule.
391 2017-02-02 20:41:47	0|gmaxwell|jtimon: I don't agree. Code style existed long before tools to do anything special with it.
392 2017-02-02 20:42:02	0|jtimon|gmaxwell: thanks for confirming, that's what I thought, including the exception for the single line ifs
393 2017-02-02 20:42:23	0|gmaxwell|I think automatic tools often handicap style discussions, because they enforce it stupidly to the point where they can irritate people and cause general opposition to standards.
394 2017-02-02 20:42:39	0|gmaxwell|jtimon: yes, including the exception, according to the docs. I have not tested it.
395 2017-02-02 20:42:51	0|jtimon|well, code style without automatic rules may save you some style discussions, but not all
396 2017-02-02 20:42:58	0|gmaxwell|(I don't have a current version of clang on my laptop -- another challenge with formating tools, they change.)
397 2017-02-02 20:43:12	0|jtimon|yep
398 2017-02-02 20:43:19	0|gmaxwell|jtimon: they give people a way to answer the question without first asking everyone else all the time. :)
399 2017-02-02 20:44:02	0|jtimon|absolutely
400 2017-02-02 20:44:47	0|gmaxwell|(I'm not opposed to tools, but they work MUcH better for single developers and single companies with rigidly enforced development workstation configs.. than they do for big projects)
401 2017-02-02 20:46:29	0|jtimon|true that, my very positive experience where with enforced development confgs per project, the project that had discussions about syle were those not enforcing the style automatically
402 2017-02-02 20:46:59	0|jtimon|s/experience where/experiences were
403 2017-02-02 20:47:33	0|isle2983|the trend does seem to be towards containerized environments for builds there the dependencies can be managed. That might be wrong for bitcoin, however.
404 2017-02-02 20:47:37	0|luke-jr|git-clang-format looks interesting
405 2017-02-02 20:47:51	0|isle2983|*where
406 2017-02-02 20:49:04	0|jtimon|luke-jr: https://github.com/llvm-mirror/clang/blob/master/tools/clang-format/git-clang-format ? seems the same concept as MarcoFalke's script we don't use, no?
407 2017-02-02 20:49:38	0|luke-jr|I haven't followed all the discussion, but an upstreamed tool seems better than one we maintain
408 2017-02-02 20:50:08	0|jtimon|ie this one https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/master/clang-format.py but yeah, this seems to be more interesting as it integrates with git
409 2017-02-02 20:52:11	0|luke-jr|step 1: provide a config file so we can just use git-clang-format manually for correct output ;)
410 2017-02-02 20:53:14	0|cfields|luke-jr: even better, i assume it can be a commit hook?
411 2017-02-02 20:53:52	0|luke-jr|cfields: I would think so, but I haven't tried it
412 2017-02-02 20:53:53	0|cfields|(that's a bit dangerous though i suppose, if the script breaks and you lose your commit)
413 2017-02-02 20:54:25	0|luke-jr|repo-wide commit hooks seem like a complex enough thing with git that I'd make that a full step 2 though ;)
414 2017-02-02 20:54:44	0|cfields|heh, yes
415 2017-02-02 21:21:40	0|MarcoFalke|luke-jr: It is a 1-1 copy of llvm
416 2017-02-02 21:30:07	0|luke-jr|>_<
417 2017-02-02 21:30:13	0|MarcoFalke|Eh, whatever. Misread the scorllback
418 2017-02-02 21:30:39	0|MarcoFalke|We could add the git-clang-format as well, so it is in our tree
419 2017-02-02 22:00:40	0|luke-jr|I don't see how this is possible https://github.com/bitcoin/bitcoin/pull/9619#issuecomment-277096336
420 2017-02-02 22:19:38	0|MarcoFalke|Is there a way to bisect only on (signed) merge commits?
421 2017-02-02 22:22:30	0|MarcoFalke|Otherwise merging this will probably upset a few: https://github.com/bitcoin/bitcoin/pull/9657#issuecomment-277094673
422 2017-02-02 22:23:58	0|luke-jr|it wouldn't be the first time we have an untestable tree merged in history
423 2017-02-02 22:24:11	0|luke-jr|it's a potential security issue to keep in mind though
424 2017-02-02 22:24:18	0|luke-jr|(bisecting unsigned commits)
425 2017-02-02 22:25:11	0|MarcoFalke|Well, I hope when people review, they check that the intermediate commits don't add random binary blobs
426 2017-02-02 22:26:46	0|gmaxwell|MarcoFalke: code that totally backdoors your machine could be a couple lines of shellscript.  And the concern there is just that you pull and some is slipped in and you run in bisect... it's worried me before, but didn't seem like there was anything to do over it.
427 2017-02-02 22:27:19	0|MarcoFalke|Still should be part of review to ensure this does not happen
428 2017-02-02 22:27:37	0|gmaxwell|it's not something review can control.
429 2017-02-02 22:27:41	0|kanzure|hi am i late
430 2017-02-02 22:27:55	0|gmaxwell|I do wish you could check in a .gitbisectuntestable which has a list of commits bisect should just skip over.
431 2017-02-02 22:28:21	0|MarcoFalke|Please explain why review can not control it
432 2017-02-02 22:28:54	0|sipa|gmaxwell, MarcoFalke: write a script that produces a list of all unsigned commits, and feed those to 'git bisect skip
433 2017-02-02 22:28:57	0|sipa|?
434 2017-02-02 22:30:24	0|jtimon|BlueMatt: at this point, should I just close #9634 as included in #9650 ?
435 2017-02-02 22:30:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/9634 | Fail in DecodeHexTx if there is extra data at the end by jtimon · Pull Request #9634 · bitcoin/bitcoin · GitHub
436 2017-02-02 22:30:28	0|gribble|https://github.com/bitcoin/bitcoin/issues/9650 | Better handle invalid parameters to signrawtransaction by TheBlueMatt · Pull Request #9650 · bitcoin/bitcoin · GitHub
437 2017-02-02 22:30:43	0|BlueMatt|jtimon: I suppose so
438 2017-02-02 22:30:50	0|gmaxwell|MarcoFalke: Because compromised code can hide things from reviewers. And there is no guarentee that things that hit the tree have been reviewed (particularly if a commiter is compromised). So if you get compromised you might merge bad commits. You can't see they're bad because the compromise hides them.  Other people don't see they're bad because they only review the ultimate commit if at all.
439 2017-02-02 22:30:56	0|gmaxwell|.. and becuase once they run something in a bad commit they become compromised and can't see it either.
440 2017-02-02 22:31:05	0|jtimon|BlueMatt: ok, thanks for the tests!
441 2017-02-02 22:32:12	0|luke-jr|all the more reason to sandbox dev
442 2017-02-02 22:32:16	0|gmaxwell|especially since we don't require that PR that we merge be based on the current tip (it would be unreasnable to do so), the intermediate commits will often not match exactly what anyone has reviewed.
443 2017-02-02 22:32:17	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9634: Fail in DecodeHexTx if there is extra data at the end (06master...06upstream-fail-decode-tx) 02https://github.com/bitcoin/bitcoin/pull/9634
444 2017-02-02 22:32:25	0|gmaxwell|Even where the final result does.
445 2017-02-02 22:32:48	0|BlueMatt|jtimon: thanks for catching that I forgot to upstream this!
446 2017-02-02 22:32:58	0|jtimon|np
447 2017-02-02 22:33:10	0|luke-jr|it'd probably be more practical to review if we used merge commits instead of rebasing
448 2017-02-02 22:33:25	0|MarcoFalke|Which is why I proposed we don't corrupt merge commits
449 2017-02-02 22:33:28	0|MarcoFalke|See  #8089
450 2017-02-02 22:33:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/8089 | verify-commits should also check for malicious code in merge commits · Issue #8089 · bitcoin/bitcoin · GitHub
451 2017-02-02 22:34:37	0|MarcoFalke|> Other people don't see they're bad because they only review the ultimate commit if at all.
452 2017-02-02 22:34:46	0|MarcoFalke|Review should always be done commit-by-commit
453 2017-02-02 22:34:54	0|gmaxwell|MarcoFalke: conflicts though is not the same as no difference at all.
454 2017-02-02 22:35:30	0|gmaxwell|Bascially if you require there be no difference then we must require every PR rebase and re-review every time another PR is merged that touches the same files (or at least functions).
455 2017-02-02 22:35:49	0|gmaxwell|Otherwise you can arrange the automatic resolution to add vulnerabilities.
456 2017-02-02 22:36:35	0|gmaxwell|and already people will review commits, but not review that what is ultimately merged were the same commits exactly (usually aren't, due to other changes)
457 2017-02-02 22:38:26	0|MarcoFalke|I don't understand how you end up with two different results when you merge the exact same commits.
458 2017-02-02 22:38:54	0|MarcoFalke|I mean you get a different commit hash when you don't adjust the time to time-of-merge and author to merge-commit-author etc
459 2017-02-02 22:39:20	0|MarcoFalke|but it should be possible to replay all merge commits and compare them to what peoples eyes reviewed
460 2017-02-02 22:40:01	0|jtimon|BlueMatt: you missed one garbate in 9650 :p
461 2017-02-02 22:40:15	0|BlueMatt|oh ffs, leave my spelling alone!
462 2017-02-02 22:40:15	0|BlueMatt|/s
463 2017-02-02 22:41:41	0|gmaxwell|MarcoFalke: If I review PR X  which is on head Y (or which I merged to Q)  that is not the same as reviewing PR X merged against Z.  (particularly in adversarial condictions)
464 2017-02-02 22:42:31	0|gmaxwell|I think this is getting too abstract, for this discussion I think it suffices to point out that people will pull code into their local branches before reviewing it, because pulling it into their branch is how they go about reviewing it.
465 2017-02-02 22:42:42	0|MarcoFalke|Reviewers don't commit to "PR X merged against Z", they commit to "PR X".
466 2017-02-02 22:43:18	0|MarcoFalke|They can only commit to the merge commit when the merge actually happened in the master branch
467 2017-02-02 22:45:09	0|MarcoFalke|I mean I can merge a commit_A locally for testing, but when I publish my review I don't refer to my local merge commit by to commit_A
468 2017-02-02 22:45:22	0|gmaxwell|You're saying the same thing as me--- I think. Reviewers review PR X and so cannot be counted on strongly to catch malicious behavior in X which is only exposed by its merge in Z.
469 2017-02-02 22:45:24	0|MarcoFalke|/by/but/
470 2017-02-02 22:45:54	0|gmaxwell|MarcoFalke: right, and so your review /may/ be ineffective, particularly if X was maliciously constructed.
471 2017-02-02 22:47:11	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9672: Opt-into-RBF for RPC & bitcoin-tx (06master...06rpc_rbf) 02https://github.com/bitcoin/bitcoin/pull/9672
472 2017-02-02 22:48:48	0|MarcoFalke|Oh I think we were talking about two completely unrelated things, I think. You were raising concerns about possible exploits that only arise after gits merge algorithm processed them. I was talking about maintainers appending commit/ ammending commits/ editing merge commits or reviewers skipping individual commits of pull request which happen to contain a +++ exploit.sh and ---exploit.sh
473 2017-02-02 22:50:35	0|gmaxwell|Right. and I am saying that I do not believe people review intermeadate commits in merges, because doing so cannot show issues that arose through the merge.  They look at PRs and at end results. If you slip in extra commits that do not change the end results, I believe it is unlikely to get noticed.
474 2017-02-02 22:50:41	0|gmaxwell|Perhaps I'm wrong.
475 2017-02-02 22:53:25	0|MarcoFalke|I don't think you are wrong, so we should work towards making it easy such that a uncompromised machine with a helper script and some verified keys can validate the current state of the bitcoin-git repo
476 2017-02-02 22:54:01	0|luke-jr|ideally, but I think we need to prioritise getting reviews done over making reviews more effort
477 2017-02-02 22:54:57	0|MarcoFalke|Yeah, that is the downside.
478 2017-02-02 23:31:40	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9673: Set correct metadata on bumpfee wallet transactions (06master...06pr/bumpfee-meta) 02https://github.com/bitcoin/bitcoin/pull/9673