1 2017-03-27 01:15:26	0|phantomcircuit|is there an rpc that returns the distribution of fees in the mempool?
  2 2017-03-27 01:15:56	0|gmaxwell|phantomcircuit: "getblocktemplate" :P
  3 2017-03-27 01:16:44	0|phantomcircuit|gmaxwell, thanks -_-
  4 2017-03-27 05:35:23	0|bitcoin-git|[13bitcoin] 151Hyena opened pull request #10092: Update consensus.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10092
  5 2017-03-27 05:37:46	0|rabidus|:(
  6 2017-03-27 05:42:00	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10092: Update consensus.h (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/10092
  7 2017-03-27 07:14:50	0|wumpus|jonasschnelli: yes, I'd also say remove support for qt4. But apparently luke-jr and BlueMatt are still using that
  8 2017-03-27 07:15:19	0|jonasschnelli|wumpus: Yes. I just re-read the Qt4 EOL issue...
  9 2017-03-27 07:15:42	0|jonasschnelli|Maybe keep it for now... at least we should fix the compiling issue.
 10 2017-03-27 07:15:47	0|wumpus|it's kind of annoying, but that's what you get with 'big step' API changes, the old version will virtually stay around forever
 11 2017-03-27 07:15:50	0|wumpus|same with python2/3
 12 2017-03-27 07:15:55	0|jonasschnelli|Yeah.
 13 2017-03-27 07:16:07	0|wumpus|though qt4->qt5 is nowhere as much work as py2->3
 14 2017-03-27 07:16:13	0|jonasschnelli|Adding qt4 compilation over travis seems to be not worth it... I guess?
 15 2017-03-27 07:16:20	0|wumpus|I'd prefer not to
 16 2017-03-27 07:16:39	0|jonasschnelli|Okay. Lets fix then the compilation issue whenever someone reports them.
 17 2017-03-27 07:16:58	0|luke-jr|wumpus: and we don't need to support Py2 because Py3 is everywhere and works as well
 18 2017-03-27 07:17:13	0|wumpus|I'd prefer some timeframe for dropping qt4, but should be announced upfront
 19 2017-03-27 07:17:20	0|luke-jr|jonasschnelli: I already added Qt4 to Travis a while ago, and was under the impression we had a daily (not every PR) running it
 20 2017-03-27 07:18:00	0|luke-jr|it's funny how Qt5 is more compatible with GTK2 than it is with Qt4
 21 2017-03-27 07:18:13	0|wumpus|ironically qt3->qt4 was a bigger step, and people ported software over quicker
 22 2017-03-27 07:18:23	0|luke-jr|they did? O.o
 23 2017-03-27 07:18:29	0|luke-jr|IIRC KDE 4 took a looong time
 24 2017-03-27 07:18:54	0|luke-jr|and even today, KMail isn't up to par with the Qt3 version
 25 2017-03-27 07:18:56	0|wumpus|how I remember things they did, almost every project saw the need of supporting qt4 immediately, and it was very hard to support both 3 and 4 so 3 was pretty quickly dropped
 26 2017-03-27 07:19:22	0|wumpus|qt5 on the other hand, maybe because it's releatiively easy to suport both 4 and 5, takes longer
 27 2017-03-27 07:19:37	0|wumpus|but it's just anecdotal I don't have numbers to back it up
 28 2017-03-27 07:20:09	0|wumpus|qt5 does have some nice new features the thing is we don't really need them, at least not for the essential features
 29 2017-03-27 07:20:37	0|luke-jr|you mean dropping the old vs supporting the new, then?
 30 2017-03-27 07:20:53	0|wumpus|I gues
 31 2017-03-27 07:21:26	0|luke-jr|IMO old should only be dropped when it becomes a burden; so Qt4->Qt5 being minimal delays that because the burden is somewhat low
 32 2017-03-27 07:21:28	0|wumpus|yes I mean qt3 was dead sooner than qt4
 33 2017-03-27 07:21:53	0|wumpus|I'm fine with supporting qt4 as long as some of us compile with that and use it
 34 2017-03-27 07:22:15	0|wumpus|if not it means it goes largely untested
 35 2017-03-27 07:22:54	0|wumpus|in any case i'm not worried about a "doesn't compile with qt4" issue once in half a year which usually gets promptly fixed
 36 2017-03-27 07:23:07	0|wumpus|I'm much more worried about the wshadow diff noise
 37 2017-03-27 07:24:05	0|wumpus|that's more work to support than qt4
 38 2017-03-27 07:25:08	0|jonasschnelli|wumpus: wshadow: you mean because of your statement: "There's a large chance that one of the 'fixes' for WShadow, which seem to trail any larger change in the source code, introduce a bug."?
 39 2017-03-27 07:25:15	0|wumpus|jonasschnelli: yes
 40 2017-03-27 07:25:17	0|bitcoin-git|13bitcoin/06master 14dd5be2c 15NicolasDorier: [QA] Renaming rawTx into rawtx
 41 2017-03-27 07:25:17	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/111849345bb5...c044f03f99ba
 42 2017-03-27 07:25:18	0|bitcoin-git|13bitcoin/06master 14c044f03 15Wladimir J. van der Laan: Merge #10083: [QA] Renaming rawTx into rawtx...
 43 2017-03-27 07:25:36	0|wumpus|jonasschnelli: every single variable in the source code seems to be in progress of being renamed
 44 2017-03-27 07:25:38	0|jonasschnelli|Can we disable WShadow for the QT part?
 45 2017-03-27 07:25:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10083: [QA] Renaming rawTx into rawtx (06master...06fundrawtransactionfix) 02https://github.com/bitcoin/bitcoin/pull/10083
 46 2017-03-27 07:25:56	0|wumpus|I think we should disable wsshadow, full stop
 47 2017-03-27 07:26:05	0|wumpus|but I'm starting to sound like a broken record on that
 48 2017-03-27 07:26:30	0|jonasschnelli|heh... I have no strong opinion on that.
 49 2017-03-27 07:26:40	0|jonasschnelli|But the warnings are definitively annoying.
 50 2017-03-27 07:26:42	0|wumpus|it was just a mistake to enable it, and that's only been confirmed
 51 2017-03-27 07:26:53	0|jonasschnelli|Yes. It seems like.
 52 2017-03-27 07:27:07	0|jonasschnelli|What's the benefits of enabling it? IMO compilers handle it pretty well,... right?
 53 2017-03-27 07:27:08	0|wumpus|and yes, some of the annoyance may go away when disabling it for certain compilers, or parts of the code base
 54 2017-03-27 07:27:51	0|wumpus|compilers handle it fine, it's people that sometimes do not. We had one bug that was hidden by shadowing
 55 2017-03-27 07:28:03	0|wumpus|I don't think this whole operation has found any other
 56 2017-03-27 07:28:16	0|jonasschnelli|I see...
 57 2017-03-27 07:28:56	0|wumpus|#8102 is the bug that set it all in motion
 58 2017-03-27 07:28:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/8102 | Bugfix: use global ::fRelayTxes instead of CNode in version send by sipa · Pull Request #8102 · bitcoin/bitcoin · GitHub
 59 2017-03-27 07:35:25	0|bitcoin-git|13bitcoin/06master 14d5690f1 15Jameson Lopp: remove 'noconnect' option from documentation
 60 2017-03-27 07:35:25	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c044f03f99ba...db1ae5470bab
 61 2017-03-27 07:35:26	0|bitcoin-git|13bitcoin/06master 14db1ae54 15Wladimir J. van der Laan: Merge #10085: Docs: remove 'noconnect' option...
 62 2017-03-27 07:35:46	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10085: Docs: remove 'noconnect' option (06master...06noconnect) 02https://github.com/bitcoin/bitcoin/pull/10085
 63 2017-03-27 07:51:03	0|bitcoin-git|13bitcoin/06master 14717ad13 15John Newbery: Actually run assumevalid.py....
 64 2017-03-27 07:51:03	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/db1ae5470bab...b1a4f2757695
 65 2017-03-27 07:51:04	0|bitcoin-git|13bitcoin/06master 14b1a4f27 15Wladimir J. van der Laan: Merge #10073: Actually run assumevalid.py...
 66 2017-03-27 07:51:28	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10073: Actually run assumevalid.py (06master...06improveassumevalid) 02https://github.com/bitcoin/bitcoin/pull/10073
 67 2017-03-27 07:51:30	0|bambum|hi
 68 2017-03-27 07:54:20	0|bambum|last time I was told core dont want to decide about what people want to run, but some commits being closed and locked after 4 minutes about block site increase should be at least commented why they are closed and locked https://github.com/bitcoin/bitcoin/pull/10092
 69 2017-03-27 07:54:51	0|bambum|otherwise ppl talking about it all over the place: https://bitcointalk.org/index.php?topic=1842146.220
 70 2017-03-27 07:55:52	0|bambum|so someone awake might answer be that question, thanks
 71 2017-03-27 07:56:04	0|bitcoin-git|13bitcoin/06master 144df76e2 15Andrew Chow: Ensure an item exists on the rpcconsole stack before adding...
 72 2017-03-27 07:56:04	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b1a4f2757695...0ddea4430d62
 73 2017-03-27 07:56:05	0|bitcoin-git|13bitcoin/06master 140ddea44 15Jonas Schnelli: Merge #10060: [Qt] Ensure an item exists on the rpcconsole stack before adding...
 74 2017-03-27 07:56:29	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #10060: [Qt] Ensure an item exists on the rpcconsole stack before adding (06master...06fix-rpcconsole-empty-stack) 02https://github.com/bitcoin/bitcoin/pull/10060
 75 2017-03-27 07:59:21	0|gmaxwell|bambum: presumably because it was broken garbage-- would instantly break everything, didn't even pass the tests-- and submitted by someone who has made nasty comments in the past. No one is going to waste their time on trolling.
 76 2017-03-27 07:59:55	0|wumpus|bambum: because it is trolling
 77 2017-03-27 08:00:07	0|wumpus|he's not exactly the first to open a pull like that
 78 2017-03-27 08:00:39	0|wumpus|it's not funny, it's not constructive
 79 2017-03-27 08:00:56	0|wumpus|the only sensible reply is to block it and ignore it and continue on as normal
 80 2017-03-27 08:01:35	0|bambum|ok, but for better transparency it should be commented, just a copy past would be enough "trolling" is not specified. For someone like me it hard to know, I thought also it might not fit into some rules, but a clear comment why it is closed would be good
 81 2017-03-27 08:01:36	0|wumpus|also this is not about 'deciding about what people want to run' but concerns our project
 82 2017-03-27 08:02:12	0|wumpus|attacking our project with random PRs is only going to get you banned
 83 2017-03-27 08:02:31	0|wumpus|that's the end of this discussion. Please try to keep drama out of this channel.
 84 2017-03-27 08:02:58	0|bambum|there was nowhere drama in my questions, it was a fair question, you are over interpreting it
 85 2017-03-27 08:03:08	0|bambum|I wish more transparency
 86 2017-03-27 08:03:18	0|jonasschnelli|bambum: please...
 87 2017-03-27 08:04:03	0|wumpus|we are not obliged to give any motivation for closing issues, or giving you any extra information. Most of the people involved here are volunteers and their time they can spend on this project is very limited and better directed to useful purposes
 88 2017-03-27 08:04:05	0|jonasschnelli|You need to understand how tiresome such PRs are... it's like trowing a stones into gears.
 89 2017-03-27 08:04:29	0|jonasschnelli|s/a//
 90 2017-03-27 08:04:31	0|wumpus|jonasschnelli: yes, it's just tiring, drags on and on and on
 91 2017-03-27 08:04:37	0|wumpus|at some point you get annoyed and just close things
 92 2017-03-27 08:04:43	0|bambum|@jonasschnelli yes but how can I recognize it as someone not being involved in techs ?
 93 2017-03-27 08:04:47	0|gmaxwell|Any any comment left is just trolled against.
 94 2017-03-27 08:05:07	0|wumpus|bambum: again, this channel and github is for doing development
 95 2017-03-27 08:05:21	0|bambum|so you saying you can recognize its trolling just by seeing the code ?
 96 2017-03-27 08:05:37	0|bambum|@wumpus you dont understand the point
 97 2017-03-27 08:05:42	0|jonasschnelli|bambum: It's like changing the default port number from 80 to 13735 in apache... It's not serious.. everyone at bitcoin github level must understand this...
 98 2017-03-27 08:05:47	0|wumpus|bambum: maybe not, but you're starting to annoy me
 99 2017-03-27 08:05:51	0|bambum|I am talking about transparency, everyone should now what is happening
100 2017-03-27 08:05:55	0|gmaxwell|bambum: sure, like the fact that it didn't even pass the selftests. it wasn't an actual proposal for anything.
101 2017-03-27 08:06:20	0|bambum|know
102 2017-03-27 08:06:23	0|jonasschnelli|bambum: It's clear what happend. Somebody started to throw a stone. It got rejected. Fullstop.
103 2017-03-27 08:06:25	0|wumpus|bambum: this is the second time in a few days that you're monopolizing this channel with discussion about non-development things
104 2017-03-27 08:06:37	0|jonasschnelli|Yes. Let's stop this here.
105 2017-03-27 08:06:45	0|jonasschnelli|Move this on to #bitcoin if you like
106 2017-03-27 08:07:10	0|wumpus|please mind the topic of this channel "This is the channel for developing Bitcoin Core. Feel free to watch, but please take commentary and usage questions to #bitcoin"
107 2017-03-27 08:08:00	0|bambum|wumpus this was something what happend on the github website, last time i was here in the channel I was told that core dont want to influent peoples what do to, so I had a question about
108 2017-03-27 08:08:20	0|wumpus|we don't influence 'peoples what to do' but we do influence our own project
109 2017-03-27 08:08:21	0|bambum|I appreciate having the option to talk about it
110 2017-03-27 08:08:44	0|bambum|and the only think i am requesting is more transparency
111 2017-03-27 08:09:27	0|gmaxwell|bambum: request heard. now please stop repeating it.
112 2017-03-27 08:10:03	0|gmaxwell|(and while you're at it, go look at the post history of the person making that PR, you'll find it quite informative)
113 2017-03-27 08:10:04	0|bambum|jonasschnelli yes for me it was not so easy to understand it
114 2017-03-27 08:10:26	0|bambum|I just had the idea that his code don´t fits into some rules
115 2017-03-27 08:10:52	0|bambum|but needs to be commented imo, especially nowatimes
116 2017-03-27 08:11:05	0|gmaxwell|K.
117 2017-03-27 08:23:22	0|wumpus|jonasschnelli: at least github deleted the fake jonasschneli account
118 2017-03-27 08:23:48	0|jonasschnelli|wumpus: heh. Yes. I reported it and ~48h later they deleted it.
119 2017-03-27 08:23:55	0|jonasschnelli|Not superfast but still okay.
120 2017-03-27 08:26:00	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10093: [Qt] Don't add arguments of sensitive command to console window (06master...062017/03/qt_console) 02https://github.com/bitcoin/bitcoin/pull/10093
121 2017-03-27 08:29:09	0|jonasschnelli|wumpus: did you assigned yourself intentionally for this PR https://github.com/bitcoin/bitcoin/pull/8694
122 2017-03-27 08:29:42	0|wumpus|jonasschnelli: yes
123 2017-03-27 08:29:50	0|jonasschnelli|Okay. Good to know...
124 2017-03-27 08:34:40	0|bitcoin-git|13bitcoin/06master 145ba61f0 15Karl-Johan Alm: [zmq] Call va_end() on va_start()ed args.
125 2017-03-27 08:34:40	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0ddea4430d62...e6156a0aa329
126 2017-03-27 08:34:41	0|bitcoin-git|13bitcoin/06master 14e6156a0 15Wladimir J. van der Laan: Merge #10056: [zmq] Call va_end() on va_start()ed args....
127 2017-03-27 08:35:00	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10056: [zmq] Call va_end() on va_start()ed args. (06master...06fix-zmqpublishnotifier-va-end) 02https://github.com/bitcoin/bitcoin/pull/10056
128 2017-03-27 08:37:17	0|bitcoin-git|13bitcoin/06master 1481a3857 15Thomas Snider: Deduplicated sigaction() boilerplate
129 2017-03-27 08:37:17	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e6156a0aa329...5114f8113627
130 2017-03-27 08:37:18	0|bitcoin-git|13bitcoin/06master 145114f81 15Wladimir J. van der Laan: Merge #10057: [init] Deduplicated sigaction() boilerplate...
131 2017-03-27 08:37:37	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10057: [init] Deduplicated sigaction() boilerplate (06master...06tjps_dedupe_sigaction) 02https://github.com/bitcoin/bitcoin/pull/10057
132 2017-03-27 08:57:31	0|schnerchi|.
133 2017-03-27 09:05:41	0|bambum|@gmaxwell thanks for commenting the commit, imo it would be totally enough to list like "locked for -" or "banned for -" 1. Submitting broken code 2. Not passing self-tests 3. Breaking network .. next time. Even a bot can do this, if devs prefer to not comment themself the lock or the bann. Would save up some energy.
134 2017-03-27 09:12:55	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #10094: 0.14: Clear release notes (060.14...06Mf1703-014docClear) 02https://github.com/bitcoin/bitcoin/pull/10094
135 2017-03-27 09:54:17	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10094: 0.14: Clear release notes (060.14...06Mf1703-014docClear) 02https://github.com/bitcoin/bitcoin/pull/10094
136 2017-03-27 09:54:40	0|bitcoin-git|13bitcoin/060.14 14eeeeacd 15MarcoFalke: 0.14: Clear release notes
137 2017-03-27 09:54:40	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/ccb47bf83036...37bf0d5b381f
138 2017-03-27 09:54:41	0|bitcoin-git|13bitcoin/060.14 1437bf0d5 15Wladimir J. van der Laan: Merge #10094: 0.14: Clear release notes...
139 2017-03-27 11:50:11	0|jonasschnelli|wumpus: there is a travis issue with your #9902 (https://travis-ci.org/bitcoin/bitcoin/jobs/215449039#L2083)
140 2017-03-27 11:50:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/9902 | Lightweight abstraction of boost::filesystem by laanwj · Pull Request #9902 · bitcoin/bitcoin · GitHub
141 2017-03-27 11:52:55	0|wumpus|jonasschnelli: in the qt tests?! that's weird
142 2017-03-27 11:53:17	0|wumpus|undefined reference to `vtable for boost::unit_test::unit_test_log_t'
143 2017-03-27 11:53:21	0|wumpus|I don't get it
144 2017-03-27 11:53:30	0|jonasschnelli|Yes. Strage error indeed. Maybe rebase?
145 2017-03-27 11:53:42	0|wumpus|I just rebased it
146 2017-03-27 12:22:23	0|jonasschnelli|wumpus: https://github.com/bitcoin/bitcoin/pull/9902#issuecomment-289437353
147 2017-03-27 12:24:27	0|wumpus|jonasschnelli: thanks, makes sense
148 2017-03-27 12:25:01	0|wumpus|seems unrelated to that pull though, I don't get why it starts failing there
149 2017-03-27 12:25:05	0|wumpus|or why it works now
150 2017-03-27 12:25:14	0|jonasschnelli|Yes. I wonder why it works now...
151 2017-03-27 12:32:10	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10095: refactor: Move GetDifficulty out of `rpc/server.h` (06master...062017_03_getdifficulty_header) 02https://github.com/bitcoin/bitcoin/pull/10095
152 2017-03-27 12:33:40	0|wumpus|jonasschnelli: we didn't use to use boost test framework in the qt tests
153 2017-03-27 12:34:00	0|jonasschnelli|But your PR doesn't change that? Or does it?
154 2017-03-27 12:34:08	0|wumpus|no, it doesn't do anything with that
155 2017-03-27 12:34:59	0|wumpus|makes sense to PR that separately
156 2017-03-27 12:35:41	0|wumpus|uhm, we're still not using boost::test in the qt tests, I don't understand why we'd need that library
157 2017-03-27 12:35:58	0|jonasschnelli|Okay. I'll PR it.
158 2017-03-27 12:36:30	0|wumpus|well let's try to find out why it's needed first, I'm not sure anymore, I thought we had a good reason, but there's no reference to boost test in the qt tests
159 2017-03-27 12:37:33	0|wumpus|so that change should not be necessary :/
160 2017-03-27 12:38:16	0|jonasschnelli|It's seems to be for the logging....
161 2017-03-27 12:39:50	0|wumpus|the only three occurences of 'boost' or 'BOOST' in src/qt/test are: #include <boost/filesystem.hpp> boost::filesystem::remove_all  boost::signals2::scoped_connection
162 2017-03-27 12:40:12	0|wumpus|boost is not used for logging nor evaluating test cases
163 2017-03-27 12:43:54	0|wumpus|argh
164 2017-03-27 12:44:43	0|wumpus|wallettests.cpp includes test/test_bitcoin.h
165 2017-03-27 12:44:51	0|wumpus|maybe that indirectly imports some boost test stuff?
166 2017-03-27 12:46:58	0|wumpus|ideally the qt tests would test with a mocked wallet model instead of importing all the core stuff
167 2017-03-27 12:47:39	0|jonasschnelli|hmm. Yes. That probably the issue.
168 2017-03-27 12:48:54	0|wumpus|oh it even links against test_bitcoin.cpp
169 2017-03-27 12:49:00	0|jonasschnelli|wumpus: but even after I remove the #include "test/test_bitcoin.h" (and remove the test code), I still get the linker issue
170 2017-03-27 12:49:02	0|wumpus|that one certainly uses boost::test
171 2017-03-27 12:49:05	0|jonasschnelli|ah... thats it!
172 2017-03-27 12:49:34	0|jonasschnelli|I don't think this can be fix easily.
173 2017-03-27 12:49:39	0|wumpus|bleh, the test utils should not themselves rely on any test framework
174 2017-03-27 12:49:54	0|wumpus|e.g. testutil.cpp is fine
175 2017-03-27 12:50:27	0|wumpus|I don't think so either, I think it was mistake to make the qt and normal tests interdependent like this
176 2017-03-27 12:50:54	0|wumpus|anyhow no big deal to make qt tests depend on boost::unittest
177 2017-03-27 12:50:57	0|wumpus|at least we know why, now
178 2017-03-27 12:51:23	0|jonasschnelli|But why does this work in current master?!
179 2017-03-27 12:51:46	0|wumpus|maybe we should go all the way and make the qt tests a boost test runner as well... but fixing it for now is easy just add the lib
180 2017-03-27 12:51:48	0|wumpus|I don't know
181 2017-03-27 12:53:02	0|jonasschnelli|wumpus: Yes. Let's fix the missing lib add, then let's see if ryanofsky is up for a clean split
182 2017-03-27 12:54:10	0|wumpus|well it needs to be one of either: either the qt tests go fully boost::unit_test, or the shared code between the two test suites should be independent on the test framework
183 2017-03-27 12:54:57	0|wumpus|either is fine with me, but using a few functions from boost::unit_test through linking in test_bitcoin.cpp *without* using the framework is asking for trouble
184 2017-03-27 12:55:08	0|wumpus|e.g. what happens if you do BOOST_ASSERT while not in a boost unit test
185 2017-03-27 12:56:07	0|jonasschnelli|Indeed
186 2017-03-27 12:56:18	0|wumpus|hm! but seems he took that into account
187 2017-03-27 12:56:27	0|wumpus|I don't see references to boost_test in test_bitcoin.cpp
188 2017-03-27 12:56:49	0|wumpus|it's no longer the test main file
189 2017-03-27 12:58:30	0|wumpus|what, I don't get it, I remember I added some BOOST_REQUIRE to TestingSetup at some point
190 2017-03-27 12:59:09	0|wumpus|I'm really, raelly confused now
191 2017-03-27 12:59:32	0|wumpus|that wasn't #9902 at least
192 2017-03-27 12:59:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/9902 | Lightweight abstraction of boost::filesystem by laanwj · Pull Request #9902 · bitcoin/bitcoin · GitHub
193 2017-03-27 13:01:11	0|wumpus|oh 91e3035 removed those again
194 2017-03-27 13:01:21	0|wumpus|" Make test_bitcoin.cpp compatible with Qt Test framework"
195 2017-03-27 13:02:29	0|wumpus|then... what does 9902 change that re-introduces boost::unittest in either test_bitcoin.cpp or the qt tests?
196 2017-03-27 13:03:25	0|wumpus|OH I see! https://github.com/bitcoin/bitcoin/pull/9902/files#diff-d5ba361c5f8be78eb4cc0c787c1fc78eR28
197 2017-03-27 13:03:31	0|wumpus|accidentally re-adding the header
198 2017-03-27 13:03:47	0|jonasschnelli|ahh,...
199 2017-03-27 13:03:48	0|jonasschnelli|right.
200 2017-03-27 13:04:36	0|jonasschnelli|wumpus: so the non QT test_bitcoin is "boost/QT" free and can be included from both worlds.. right?
201 2017-03-27 13:04:43	0|wumpus|yep
202 2017-03-27 13:05:08	0|jonasschnelli|Okay. Got it... all good then. Then its just the accidentally added "include <boost/test/unit_test.hpp>".
203 2017-03-27 13:05:14	0|jonasschnelli|Great. At least we know now. :)
204 2017-03-27 13:06:02	0|wumpus|re-pushed with that line removed, let's see
205 2017-03-27 15:35:04	0|bitcoin-git|[13bitcoin] 15JeremyRubin closed pull request #9495: Fix CCheckQueue IsIdle (potential) race condition (06master...06checkqueue-control-lock) 02https://github.com/bitcoin/bitcoin/pull/9495
206 2017-03-27 15:40:53	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10096: Check that all test scripts in test/functional are being run (06master...06check_all_tests_run) 02https://github.com/bitcoin/bitcoin/pull/10096
207 2017-03-27 16:09:26	0|BlueMatt|jonasschnelli: as noteed in the issue qt4 -> qt5 introduces regressions
208 2017-03-27 16:09:32	0|BlueMatt|we need to fix those before we can turn it off
209 2017-03-27 16:10:04	0|BlueMatt|major regressions that break peoples' ability to use Bitcoin-Qt, that is
210 2017-03-27 16:15:25	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #10097: Move zmq test skipping logic into individual test case. (06master...06zmq_optional) 02https://github.com/bitcoin/bitcoin/pull/10097
211 2017-03-27 18:47:41	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10098: Make qt wallet test compatible with qt4 (06master...06pr/wqt4) 02https://github.com/bitcoin/bitcoin/pull/10098
212 2017-03-27 19:37:04	0|bitcoin-git|[13bitcoin] 15kallewoof closed pull request #10062: [net] Clean up the CNode class in net.h (06master...0620170322-cleanup-net) 02https://github.com/bitcoin/bitcoin/pull/10062
213 2017-03-27 19:44:35	0|bitcoin-git|[13bitcoin] 15JeremyRubin opened pull request #10099: Speedup & Slightly Improve Unit Tests for Checkqueue (06master...06speedup-checkqueue-tests) 02https://github.com/bitcoin/bitcoin/pull/10099
214 2017-03-27 20:24:49	0|BlueMatt|jonasschnelli: ping
215 2017-03-27 21:22:46	0|bitcoin-git|[13bitcoin] 15RHavar opened pull request #10100: Make ApproximateBestSubset optimize for amount of inputs (06master...06coinselection) 02https://github.com/bitcoin/bitcoin/pull/10100
216 2017-03-27 21:41:25	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #10101: [0.14] backports (060.14...06Mf1703-014backp) 02https://github.com/bitcoin/bitcoin/pull/10101
217 2017-03-27 21:48:41	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #10102: bitcoin-qt: spawn bitcoind and communicate over pipe (Experimental, WIP) (06master...06pr/ipc) 02https://github.com/bitcoin/bitcoin/pull/10102
218 2017-03-27 21:59:19	0|cfields|ryanofsky: cool!
219 2017-03-27 22:21:15	0|achow101|does anyone know if the way that Core 0.14 broadcasts messages has changed from the way the 0.13.2 did?
220 2017-03-27 22:22:06	0|sipa|can you be more specific?
221 2017-03-27 22:23:13	0|achow101|I guess more specific would be how network packets are being sent
222 2017-03-27 22:23:41	0|sipa|there have been significant changes to that, yes
223 2017-03-27 22:24:12	0|sipa|not sure whether those should be observable, though
224 2017-03-27 22:25:11	0|achow101|I think I mentioned this several months ago when I first started looking into this issue. On Armory, I have noticed that it was receiving and processing message headers separately from the message payloads
225 2017-03-27 22:25:43	0|achow101|it would appear that this behavior is caused by something in 0.14.0 since people have only been reporting the issue since 0.14.0's release
226 2017-03-27 22:26:00	0|achow101|I only noticed because I always run a build of the master branch.
227 2017-03-27 22:26:00	0|sipa|define 'separate' ?
228 2017-03-27 22:26:38	0|achow101|it would interpret the message header as a message, and then interpret the message payload as a completely new message
229 2017-03-27 22:26:45	0|sipa|TCP does not have messages
230 2017-03-27 22:26:51	0|sipa|it is a byte stream
231 2017-03-27 22:26:58	0|achow101|message being the bitcoin p2p messages
232 2017-03-27 22:27:16	0|cfields|achow101: yes, that's possible now
233 2017-03-27 22:27:18	0|sipa|that makes no sense... a p2p message is defined as a header + payload
234 2017-03-27 22:27:27	0|sipa|you're asking whether a message can consist of a message and a message
235 2017-03-27 22:27:37	0|sipa|cfields: it was always possible
236 2017-03-27 22:27:38	0|achow101|cfields: how so?
237 2017-03-27 22:27:47	0|cfields|sipa: tcp fast-send + split message sends
238 2017-03-27 22:27:50	0|phantomcircuit|sipa, im guessing they screwed up and are assuming the entire message will be received in a single recv()
239 2017-03-27 22:28:01	0|cfields|sec for some grepping so i can use better terms
240 2017-03-27 22:28:03	0|sipa|phantomcircuit: yes, that's my assumption too, but that would have always been a bug
241 2017-03-27 22:28:09	0|achow101|phantomcircuit: well we never saw this issue before 0.14.0
242 2017-03-27 22:28:24	0|phantomcircuit|sipa, yeah but wouldn't have been easily triggered until recently
243 2017-03-27 22:28:29	0|BlueMatt|phantomcircuit: in that case you'd also see it for big messages
244 2017-03-27 22:28:38	0|BlueMatt|(>~1k)
245 2017-03-27 22:28:39	0|sipa|achow101: yes, it's now done as separate send calls
246 2017-03-27 22:28:48	0|cfields|TCP_NODELAY + separate sends
247 2017-03-27 22:28:50	0|phantomcircuit|BlueMatt, not if they have a huge recv buffer and are on localhost always
248 2017-03-27 22:28:52	0|phantomcircuit|which they are
249 2017-03-27 22:28:53	0|achow101|we fixed the issue on our end, but I just wanted to figure out why that happened since it only appeared when people used 0.14.0
250 2017-03-27 22:28:58	0|cfields|make it likely that you'll receive the header in the first chunk
251 2017-03-27 22:29:04	0|BlueMatt|phantomcircuit: you still usually see it for things >>1k
252 2017-03-27 22:29:10	0|BlueMatt|eg 1MB you'd def see it
253 2017-03-27 22:29:15	0|phantomcircuit|uh
254 2017-03-27 22:29:18	0|phantomcircuit|hmm let me see
255 2017-03-27 22:29:21	0|phantomcircuit|i dont think that's right
256 2017-03-27 22:29:32	0|BlueMatt|localhost can be surprisingly slow somteimts
257 2017-03-27 22:29:35	0|BlueMatt|sometimes
258 2017-03-27 22:30:08	0|sipa|achow101: so, yes, there has been a change where header and payload are now sent through separate kernel calls, which makes it much more likely you'll see them in separate recv() calls
259 2017-03-27 22:30:22	0|achow101|ok. thanks
260 2017-03-27 22:30:45	0|achow101|we fixed the problem, I just wanted to know why it was a problem in the first place
261 2017-03-27 22:31:25	0|sipa|it should always have been possible to see this; TCP does not guarantee that message boundares are preserved
262 2017-03-27 22:31:30	0|gmaxwell|it's easy in tcp applications to write bugs where you assume your reads will always contain a complete message... when the remote end used a single write (or nagle merged them)... then something changes and the reads are short.
263 2017-03-27 22:31:33	0|sipa|but on localhost i guess it would be unlikely
264 2017-03-27 22:32:38	0|achow101|well I don't know how it was originally implemented in Armory nor how it was fixed. I just know that one day it magically started giving me errors for something that had never happened in a previous version of core
265 2017-03-27 22:32:53	0|achow101|anyways, thanks for the info
266 2017-03-27 22:33:03	0|cfields|well also if you're receiving a few messages in one read, it'd be very likely that a header would span 2 chunks
267 2017-03-27 22:33:11	0|cfields|so seems strange that that would've ever worked :)
268 2017-03-27 22:33:15	0|phantomcircuit|BlueMatt, why do i get two sendcmpt messages for every connection?
269 2017-03-27 22:33:29	0|BlueMatt|phantomcircuit: thats how the version negotiation works