< wumpus>
would consider it when C++ adopts an asynchronous i/o framework as standard
< promag_>
got it
< wumpus>
it's *nice* but we don't need fine-grained async communication with child processes for anything planned at this time, definitely not for 'launch a process and capture its stdout'
< promag_>
yeah sure
< promag_>
in 5677 dcousens mentioned it would be better, and some mentioned it would be easy to switch later - however I'm curious how since libuv has no http support
< wumpus>
i'm sure there's something comparable to libev or better for that, but yea that would be another dependency ... i just don't think this is a good conern to have now
< promag_>
just doing some tests before ack'ing boost::process
< promag_>
and as usual one thing leads to other..
< wumpus>
okay!
< rafalcpp>
wumpus: fyi, if anything then ASIO, might become std::asio. But probably in like 4+ years anyway
< rafalcpp>
I assume any performance issues with it would be mostly ironed out first
< wumpus>
rafalcpp: boost::asio was pretty meh at the time, lots of overhead and fragility, but who knows in four years
< wumpus>
right
< promag_>
achow101 ken2812221 ryanofsky please see #15575
< bitcoin-git>
bitcoin/master 890396c fanquake: cli: replace testnet with chain and return network name as per BIP70.
< bitcoin-git>
bitcoin/master 887f57e MarcoFalke: Merge #15566: cli: replace testnet with chain and return network name as p...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15566: cli: replace testnet with chain and return network name as per BIP70. (master...cli-testnet-to-network) https://github.com/bitcoin/bitcoin/pull/15566
< bitcoin-git>
[bitcoin] dongcarl opened pull request #15580: depends: native_protobuf: avoid system zlib (master...2019-03-depends-native_protobuf-no-zlib) https://github.com/bitcoin/bitcoin/pull/15580
< bitcoin-git>
[bitcoin] dongcarl opened pull request #15581: depends: Make less assumptions about build env (master...2019-03-true-neutral-depends) https://github.com/bitcoin/bitcoin/pull/15581
< gmaxwell>
jonasschnelli: aside observation, if you write a protocol description that sounds like it uses floating point, some people will implement it that way, and I will feel ever so slightly more like jumping off a bridge.
< jonasschnelli>
gmaxwell: do you mean because of floor(packet_sequence_number / 21)?
< gmaxwell>
yeah.
< jonasschnelli>
I see... unsure how to avoid that...
< gmaxwell>
if it's pseudocode, maybe consider python style // for truncating division? (or maybe I'm crazy, but floor() is explicitly a floating point function)
< gmaxwell>
or you can just write it witout having any large counters.
< jonasschnelli>
gmaxwell: I think its safe to just remove the floor
< jonasschnelli>
Since its just integer division (AFAIK should always result in floor)
< gmaxwell>
Probably writing the example without the big counters is better. e.g. keep a counter that goes from 0 to 21. and when it hits 21, increments packet_sequence_number and generates new data. and just start it at 22.
< gmaxwell>
that replaces the div and mod, and just converts one counter to a small cyclic counter.
< gmaxwell>
(which also avoids running into issues with position_in_keystream wrapping.)
< jonasschnelli>
sounds safe,... takes for the hint
< jonasschnelli>
will change
< bitcoin-git>
[bitcoin] sipa opened pull request #15582: Fix overflow bug in analyzepsbt fee: CAmount instead of int (master...201903_analyzepsbtoverflow) https://github.com/bitcoin/bitcoin/pull/15582
< bitcoin-git>
[bitcoin] promag opened pull request #15583: wallet: Ignore recursive_directory_iterator errors in ListWalletDir (master...2019-03-fix-listwalletdir) https://github.com/bitcoin/bitcoin/pull/15583