< 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?
< 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
< 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)
< 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