< Silb> ..
< Silb> How active is the Bitcoin core irc channel?
< bitcoin-git> [bitcoin] gwillen opened pull request #14978: Factor out PSBT utilities from RPCs for use in GUI code; related refactoring. (master...feature-refactor-psbt-rpcs) https://github.com/bitcoin/bitcoin/pull/14978
< achow101> is travis broken?
< gwillen> achow101: no, I did something dumb
< gwillen> see my comment on the PR, I did something that clang likes but g++ does not, so I didn't catch it building on a mac
< sipa> gwillen: heh, those things are pretty rare
< gwillen> yeah, it is kind of odd, and my plan is to revert it back to how it was before to make it go away
< gwillen> rather than understand it
< gwillen> one of the types involved is "zero_after_free_allocator<char>"
< gwillen> which I assume is something core-specific but I've never encountered it before
< sipa> yes
< gwillen> the issue is: "no known conversion for argument 1 from ‘std::__cxx11::basic_string<char>::const_iterator {aka __gnu_cxx::__normal_iterator<const char*, std::__cxx11::basic_string<char> >}’ to ‘CDataStream::const_iterator {aka __gnu_cxx::__normal_iterator<const char*, std::vector<char, zero_after_free_allocator<char> > >}’"
< gwillen> oh, the allocator isn't the issue though, huh, I dunno what clang was doing to make this compile
< sipa> it may be that the std::vector<char> iterator in the clang stl can be converted (or is identical to?) the std::string iterator
< sipa> have you tried just CDataStream(tx_data, SER_NETWORK, PROTOCOL_VERSION); ?
< gwillen> you may be right, or it could be that the std::string iterator can be converted to char *? which is the other constructor.
< gwillen> I will try that
< sipa> yeah
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #14979: [Qt] Restore < Qt5.6 compatibility for addAction (master...2018/12/fix_addaction) https://github.com/bitcoin/bitcoin/pull/14979
< sipa> if you know that the string is not empty, &*str.begin() will work
< sipa> but that's illegal if the string is empty
< gwillen> no, it does not accept tx_data alone as being convertible to a vector
< sipa> (str.data(), str.data+str.size()) definitely works
< gwillen> anyway I will just try to put it back to being a vector like it was before I screwed with it
< gwillen> ok I lied, I'm using your trick, thanks
< promag> wumpus: what do you think of getrpcinfo added in #14958
< gribble> https://github.com/bitcoin/bitcoin/issues/14958 | qa: Remove race between conneting and shutdown on separate connections by promag · Pull Request #14958 · bitcoin/bitcoin · GitHub
< wumpus> I'm slightly confused who exposing all these internals is necessar
< wumpus> why*
< wumpus> all in all, the RPC tests are supposed to be mostly blackbox tests, the number of active RPC workers shouldn't really be relevant, only the behavior
< promag> In that case I need to wait for the other RPC
< promag> The other RPC will `waitfornewblock`
< promag> I want to `stop` the node only when the other RPC is already waiting
< wumpus> I'm not against 'getrpcinfo' in itself, to be clear
< wumpus> it's in line with other get*info; and maybe active_commands is useful for users as well
< promag> I agree with the above, but we need to have something to help test these concurrent/parallel cases
< wumpus> but I don't think it should be 'smuggled' in as part of a qa change for one test; can't you detect the command finishing some other way, on the functional test side?
< promag> nope, I tried to inspect http.Connection etc
< promag> nothing tells me the other connection is "waiting for new block"
< wumpus> true...
< promag> internally connection is accepted and then the worker picks it and executes the command in the table
< promag> the `stop` can be processed in between — which causes the test failure
< wumpus> yes
< wumpus> what about doing another RPC command in between?
< wumpus> if that finishes, you can be sure the previous one at least has been dispatched to a worker
< promag> I did, same problem — it doesn't guarantees the `waitfornewblock` is running
< wumpus> so this is not a matter of python's threading itself, is the command even sent to the server yet?
< promag> I can wait for that, but that's half of the fix
< wumpus> the HTTP server itself is single-threaded and asynchronous, and the workers handle commands in order
< wumpus> then again, maybe getrpcinfo is fine, but I'd suggest adding it as a PR in itself, so people can discuss that
< wumpus> as said, maybe 'number of running commands' is useful information to users as well...
< promag> fine, this is a rare race anyway
< wumpus> in which case it's great that this can be used to avoid this particular race as well
< promag> I believe this could be avoided if the server replied with chunks
< promag> for the wait* calls, the server could reply headers or something like that
< wumpus> yes
< promag> the client would receive that and know it's in waiting state
< promag> I'll proceed with the getrpcinfo PR
< wumpus> streaming/chunked output for HTTP could be useful for various things
< promag> true
< promag> I think I can work on that once the support for dynamic wallet UI is done
< wumpus> I had a lot of trouble with that in #7759 though
< gribble> https://github.com/bitcoin/bitcoin/issues/7759 | [WIP] rest: Stream entire utxo set by laanwj · Pull Request #7759 · bitcoin/bitcoin · GitHub
< wumpus> libevent's http server is strange
< promag> true, for #14670 I had to dig into it
< gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
< promag> regarding #14979
< gribble> https://github.com/bitcoin/bitcoin/issues/14979 | [Qt] Restore < Qt5.6 compatibility for addAction by jonasschnelli · Pull Request #14979 · bitcoin/bitcoin · GitHub
< promag> one goal of CI is to prevent breaking master right? should we build with minimums in one stage of travis?
< fanquake> install qt 5.2 on the travis-qt build ?
< fanquake> Or a new build with a combination of all minimums
< promag> it breaks more often because of Qt
< promag> fanquake: is 5.2 available on apt?
< fanquake> promag unsure, will have a look
< fanquake> I was trying to establish more minimum versions a few days ago.
< fanquake> From what I can tell we're meant to support libevent 2.0.21, (have workarounds in code for it), but can't actually compile with it?
< fanquake> *not meant to support 2.0.21, but have workarounds for it
< promag> I have that on my system
< promag> and builds fine, let me double check
< fanquake> promag maybe worth a PR then
< promag> after wall I'm already not using 2.0.21
< promag> *all
< promag> I have "rm -rf libevent-release-2.0.21-stable" on my history X)
< promag> fanquake: but it doesn't build with that libevent version? is there a report of that?
< fanquake> promag our minimum required is 2.0.22, so I wouldn't think so
< fanquake> promag my confusion came from some versioning in the http server that looked like workarounds for 2.0.21, but i'll have to double check
< wumpus> would be good to test building with minimum qt on travis, though I don't see how to concretely do this
< wumpus> we definitely don't want to build qt 5.2 as part of depends
< fanquake> we are essentially testing minimum Python for the tests now as well I think
< fanquake> wumpus think #14979 can go in
< gribble> https://github.com/bitcoin/bitcoin/issues/14979 | [Qt] Restore < Qt5.6 compatibility for addAction by jonasschnelli · Pull Request #14979 · bitcoin/bitcoin · GitHub
< wumpus> for python installing a different version is more widely supported, I don't think anyone does that for gui toolkits :)
< wumpus> fanquake: great
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/34241716852d...bfd7e5409720
< bitcoin-git> bitcoin/master 3e21b69 Jonas Schnelli: [Qt] Restore < Qt5.6 compatibility for addAction
< bitcoin-git> bitcoin/master bfd7e54 Wladimir J. van der Laan: Merge #14979: [Qt] Restore < Qt5.6 compatibility for addAction...
< bitcoin-git> [bitcoin] laanwj closed pull request #14979: [Qt] Restore < Qt5.6 compatibility for addAction (master...2018/12/fix_addaction) https://github.com/bitcoin/bitcoin/pull/14979
< lambolife> whats up guys
< lambolife> What's the latest update in Bitcoin's development so far. I'm gonna make a video about not to give Hopium but to present facts. So I;m here
< fanquake> lambolife Ask in #bitcoin instead, that'll be off-topic here.
< lambolife> got it
< bitcoin-git> [bitcoin] benthecarman opened pull request #14981: Clarifying RPC getrawtransaction's time help text (master...getrawtransaction_help_text_fix) https://github.com/bitcoin/bitcoin/pull/14981
< bitcoin-git> [bitcoin] promag opened pull request #14982: rpc: Add getrpcinfo command (master...2018-12-getrpcinfo) https://github.com/bitcoin/bitcoin/pull/14982
< promag> anyone can add "needs release notes" label to #14573?
< gribble> https://github.com/bitcoin/bitcoin/issues/14573 | qt: Add Window menu by promag · Pull Request #14573 · bitcoin/bitcoin · GitHub
< fanquake> promag done
< promag> ty
< provoostenator> fanquake: we're testing minimum python since #14884 though it's not bullet-proof.
< gribble> https://github.com/bitcoin/bitcoin/issues/14884 | Travis: enforce Python 3.4 support through linter by Sjors · Pull Request #14884 · bitcoin/bitcoin · GitHub
< provoostenator> As for minimum QT version on Travis, that seems like a good idea #14983 (and maybe we need to slightly bump the minimum even for that)
< gribble> https://github.com/bitcoin/bitcoin/issues/14983 | One Travis instance should run minimum supported QT version · Issue #14983 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfd7e5409720...b545a6e68965
< bitcoin-git> bitcoin/master faee591 MarcoFalke: test: Fix race in mempool_accept
< bitcoin-git> bitcoin/master b545a6e MarcoFalke: Merge #14964: test: Fix race in mempool_accept...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14964: test: Fix race in mempool_accept (master...Mf1812-testRaceMempoolAccept) https://github.com/bitcoin/bitcoin/pull/14964
< bitcoin-git> [bitcoin] promag opened pull request #14984: rpc: Speedup getrawmempool when verbose=true (master...2018-12-speedup-getrawmempool) https://github.com/bitcoin/bitcoin/pull/14984
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14985: test: Remove thread_local from test_bitcoin (master...Mf1812-testNoThreadLocal) https://github.com/bitcoin/bitcoin/pull/14985
< ken2812221> jonasschnelli: Your nightly gitian build website seems down.
< MarcoFalke> Yeah, the server that hosts the binaries seems down. The html itself is up?
< wumpus> hopefully I've solved the problem in #14968, seems that travis returns ENOENT when trying to bind IPv4 not EADDRNOTAVAIL as expected
< gribble> https://github.com/bitcoin/bitcoin/issues/14968 | http: Fail initialization when any bind fails by laanwj · Pull Request #14968 · bitcoin/bitcoin · GitHub
< wumpus> whoo passed
< bitcoin-git> [bitcoin] laanwj deleted 0.11 at 0bace83: https://github.com/bitcoin/bitcoin/commit/0bace83
< bitcoin-git> [bitcoin] laanwj deleted 0.12 at c1b7421: https://github.com/bitcoin/bitcoin/commit/c1b7421
< bitcoin-git> [bitcoin] laanwj deleted 0.13 at b654842: https://github.com/bitcoin/bitcoin/commit/b654842
< instagibbs> had the answer to my subtree q
< gwillen> whaaaaat
< gwillen> how fancy
< K222> HELOO
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14987: [rcp] RPCHelpMan: Require documentation of return value at compile time (master...Mf1812-rpcResultFlat) https://github.com/bitcoin/bitcoin/pull/14987
< bitcoin-git> [bitcoin] benthecarman opened pull request #14988: Number of confirmations added to transaction csv export (master...confirmations_in_csv_export) https://github.com/bitcoin/bitcoin/pull/14988