< gwillen> achow101: can you explain the comment "Get all of the previous transactions" in rawtransaction.cpp (in finalizepsbt)?
< gwillen> it appears to be just using SignPSBTInput to check if inputs are signed -- is it also intentionally mutating the transaction in some way or something?
< gwillen> or is it safe to replace with "is PSBT input signed"?
< achow101> that's very likely to be the result of copy-paste from some other rpc
< * sipa> guesses: the comment was copied from rpcwallet.cpp
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d387507aeca6...8010ded6da56
< bitcoin-git> bitcoin/master 7e18673 Kristaps Kaupe: Fix typo
< bitcoin-git> bitcoin/master 8010ded Pieter Wuille: Merge #14524: Trivial: fix typo...
< bitcoin-git> [bitcoin] sipa closed pull request #14524: Trivial: fix typo (master...typos) https://github.com/bitcoin/bitcoin/pull/14524
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8010ded6da56...b14db5abab40
< bitcoin-git> bitcoin/master bc60c61 practicalswift: Avoid 1 << 31 (UB) in calculation of SEQUENCE_LOCKTIME_DISABLE_FLAG
< bitcoin-git> bitcoin/master b14db5a Pieter Wuille: Merge #14513: Avoid 1 << 31 (UB) in calculation of SEQUENCE_LOCKTIME_DISABLE_FLAG...
< bitcoin-git> [bitcoin] sipa closed pull request #14513: Avoid 1 << 31 (UB) in calculation of SEQUENCE_LOCKTIME_DISABLE_FLAG (master...1<<31-again) https://github.com/bitcoin/bitcoin/pull/14513
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b14db5abab40...b2863c0685a5
< bitcoin-git> bitcoin/master 369244f Chun Kuan Lee: utils: Fix broken Windows filelock
< bitcoin-git> bitcoin/master b2863c0 Pieter Wuille: Merge #14426: utils: Fix broken Windows filelock...
< bitcoin-git> [bitcoin] sipa closed pull request #14426: utils: Fix broken Windows filelock (master...filelock-test) https://github.com/bitcoin/bitcoin/pull/14426
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2863c0685a5...dc1e54206d76
< bitcoin-git> bitcoin/master 1f01fe0 Antoine Le Calvez: bitcoin-tx: Use constant for n pubkeys check...
< bitcoin-git> bitcoin/master dc1e542 Pieter Wuille: Merge #14474: bitcoin-tx: Use constant for n pubkeys check...
< bitcoin-git> [bitcoin] sipa closed pull request #14474: bitcoin-tx: Use constant for n pubkeys check (master...bitcoin_tx_use_constant) https://github.com/bitcoin/bitcoin/pull/14474
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to 0.17: https://github.com/bitcoin/bitcoin/compare/5b47b8efd48d...1b5af2c177ee
< bitcoin-git> bitcoin/0.17 f7dbcaa Sjors Provoost: [doc] getblocktemplate: use SegWit in example
< bitcoin-git> bitcoin/0.17 1b5af2c Pieter Wuille: Merge #14509: [0.17] doc: use SegWit in getblocktemplate example...
< fanquake> sipa It'd be great if you could also merged #14011
< gribble> https://github.com/bitcoin/bitcoin/issues/14011 | Disable wallet and address book Qt tests on macOS minimal platform by ryanofsky · Pull Request #14011 · bitcoin/bitcoin · GitHub
< sipa> fanquake: sgtm
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/dc1e54206d76...e754c6e33194
< bitcoin-git> bitcoin/master a3197c5 Russell Yanofsky: Disable wallet and address book Qt tests on macOS minimal platform...
< bitcoin-git> bitcoin/master e754c6e Pieter Wuille: Merge #14011: Disable wallet and address book Qt tests on macOS minimal platform...
< sipa> anything else?
< bitcoin-git> [bitcoin] sipa closed pull request #14011: Disable wallet and address book Qt tests on macOS minimal platform (master...pr/fuqtmac) https://github.com/bitcoin/bitcoin/pull/14011
< fanquake> sipa cheers. #14512 is also a trivial merge.
< gribble> https://github.com/bitcoin/bitcoin/issues/14512 | docs: Textual improvements in README.md by merland · Pull Request #14512 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e754c6e33194...91482e5bf22d
< bitcoin-git> bitcoin/master 29ed2d6 Hennadii Stepanov: Improve CAmount tests...
< bitcoin-git> bitcoin/master 91482e5 Pieter Wuille: Merge #14460: tests: Improve 'CAmount' tests...
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/91482e5bf22d...544f3234384b
< bitcoin-git> bitcoin/master b6b9915 Martin Erlandsson: Textual improvements
< bitcoin-git> bitcoin/master 544f323 Pieter Wuille: Merge #14512: docs: Textual improvements in README.md...
< bitcoin-git> [bitcoin] fanquake opened pull request #14526: docs: Document lint tests (master...revive-document-lint-tests) https://github.com/bitcoin/bitcoin/pull/14526
< bitcoin-git> [bitcoin] fanquake closed pull request #13708: docs: Document lint tests (master...document-lint-tests) https://github.com/bitcoin/bitcoin/pull/13708
< bitcoin-git> [bitcoin] fanquake closed pull request #13542: Adding Docker/docker-compose files (master...docker) https://github.com/bitcoin/bitcoin/pull/13542
< bitcoin-git> [bitcoin] fanquake closed pull request #14014: Scripts and tools: fix gitian-build.py --verify option (master...gitian-verify) https://github.com/bitcoin/bitcoin/pull/14014
< wumpus> midnightmagic: well... currently only run OpenBSD in VM; and yes, bitcoin builds fine on OpenBSD, there's special instructions for that, which fanquake updated for 6.4 and I'l like to test out but couldn't yet
< fanquake> wumpus I've looked at the BSD configure issue a bit more. Looks like a bug fix in 1.16 might have broken something we do, https://github.com/bitcoin/bitcoin/issues/14404#issuecomment-431542526
< fanquake> Still need to get an actual fix.
< fanquake> *automake 1.16
< midnightmagic> nice
< midnightmagic> if I could get netbsd into my talos somehow, I'd be testing in there.
< wumpus> fanquake: thanks for investigating; glad you could narrow it down to a specific automake change
< wumpus> midnightmagic: yeah would love to run *BSD on my SiFive board, but that's a pipe dream for now, even a linux kernel that works is hard to find :)
< midnightmagic> you mean the hifive unleashed?
< midnightmagic> did you get the expansion board too?
< wumpus> it's the first time I bothered with fedora as that seems to be the best supported distro for it
< wumpus> yes that one
< midnightmagic> i wonder if that page-fault-computing usenix method can be used on the sifive stuff
< wumpus> FWIW it runs a bitcoin + lightning node + tor fine :D
< midnightmagic> wow, nice.
< wumpus> yes it's kind of cool; I do use nbd for storage, though—no expansion board was too late for that
< midnightmagic> still unavailable, too, apparently.
< wumpus> I got one of the last unleashed boards, literally a week later the option to order them was closed :)
< midnightmagic> This kind of hardware, I don't mind learning new assembly for.
< sipa> that's risc-v?
< midnightmagic> yeah
< sipa> nice
< wumpus> midnightmagic: yeah it's not much work either, the instruction set is super straightforward
< midnightmagic> runs bitcoin okay? how long did it take to sync with nbd..?
< midnightmagic> (Also, why not nfs?)
< wumpus> midnightmagic: this lists all of them: https://github.com/michaeljclark/riscv-meta/blob/master/opcode-fullnames
< wumpus> (including extensions)
< midnightmagic> whoah, short.
< midnightmagic> did you ever see the power9 instruction set?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/544f3234384b...d433239a8d54
< bitcoin-git> bitcoin/master 94e21c1 James O'Beirne: test: forward timeouts properly in send_blocks_and_test
< bitcoin-git> bitcoin/master d433239 MarcoFalke: Merge #14456: test: forward timeouts properly in send_blocks_and_test...
< wumpus> the only thing I really had to get used to, is that loading longer immediates is split over multiple instructions instead of in-line (such as auipc and jlr for jump)
< wumpus> midnightmagic: I don't think so!
< midnightmagic> you have to do weird things like load in addresses in four pieces, carefully shifting them and arranging them..
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14456: test: forward timeouts properly in send_blocks_and_test (master...2018-10-test-forward-timeouts) https://github.com/bitcoin/bitcoin/pull/14456
< wumpus> at least I hope risc-v is the last assembly language I ever have to learn and it will take over everything xD
< wumpus> yes, bitcoin runs ok, syncing doesn't go super fast but it was a bit faster than most ARM boards from a few years ago I've tried on
< midnightmagic> wumpus: it's *huge*. The PowerISA reference manual is 1240 pages.
< wumpus> the SD card driver was kind of broken so that's why I'm using nbd, nbd in contrast to nfs is very easy to set up, no need to bother with username mappings, rpc servers, and horrible stuff like that
< midnightmagic> "Appendix F. Power ISA Instruction Set Sorted by Mnemonic" => 17 pages is tiny little writing.
< wumpus> that's kind of much for a *reduced* instruction set platform
< wumpus> though it's still less than Intel's multi-volume bibles
< midnightmagic> 56 opcodes per page.
< midnightmagic> What the hell does "Transaction Abort Doubleword Conditional Immediate & record" even mean lol and yet, after discovering the weird futureAlienTech IBM put into it. Dude.
< wumpus> heh those pages are either scribbled with occult markings or ▓███▒▓█-censored ... nah, sounds like some combinatorial complexity blowup
< wumpus> 'let's make 2^n variants of instruction and all document them separately, that's a way to fill a book'
< midnightmagic> If a pcie card tries to twiddle ram without a dma properly setup, the power chips intercept it and helpfully fire off an OS handler do you can decide what to do about it yourself. I guess on normal hardware it just lets it get away with it.
< wumpus> anyhow, risc-v is nice and clean, though if it really catches on with many vendors i'd expect ehere might be a cambrian explosion of (even proprietary) extensions at some point though
< midnightmagic> I have a supermicro sas card here that tried to munge main memory *on boot* and had to be disabled by the pre-OS checks. wtf.
< sipa> wumpus: i just learned from wikipedia that the r in risc does not refer to the size of the instruction set, but to how complex operations per instruction can be (in particular, how many memory accesses)
< midnightmagic> well I sure hope so.
< wumpus> sipa: oh! TIL too
< sipa> and there have been CISC platforms with just 8 instructions
< wumpus> midnightmagic: I agree, it'd be a form of open competition which is good
< ossifrage> I thought early RISC was along the lines of what can be done in an cycle (with most instructions being register to register)
< midnightmagic> still burns me atmel dropped avr for arm. wumpus: well if it does anything interesting with the bitcoin node, I know I at least would love to hear about it.
< ossifrage> I always found it cleaner to decouple memory to register instructions from register to alu to register instructions
< wumpus> ossifrage: apparently yes that's what it means
< wumpus> definitely, having, all the addressing modes for every instruction is a lot of complexity, and then you end up with things like 'MOV is turing-complete'
< ossifrage> If you don't have a pipeline writing a RISC CPU in verilog is surprisingly simple.
< wumpus> yes handling timing and pipelines is where it gets complex
< fanquake> MarcoFalke If you want to merge #14497 I think that's ready to go.
< gribble> https://github.com/bitcoin/bitcoin/issues/14497 | docs: Add doc/bitcoin-conf.md by hebasto · Pull Request #14497 · bitcoin/bitcoin · GitHub
< ossifrage> wumpus, the bugs in the chip I worked on where in the hazard logic and the pipeline bypass. Stuff that managed to get past verification
< ossifrage> I can't imagine how painful it is to verify a CISC processor
< wumpus> it can fit in the small FPGAs supported by the open source yosys toolchain
< wumpus> fanquake: will merge
< wumpus> but yes it's kind of sad i missed the expansion board, would have been neat to connect a GPU and keyboard and have an actual RISC-V PC
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d433239a8d54...6746a8951923
< bitcoin-git> bitcoin/master 1fb3c16 Hennadii Stepanov: Add `doc/bitcoin-conf.md`
< bitcoin-git> bitcoin/master 6746a89 Wladimir J. van der Laan: Merge #14497: docs: Add doc/bitcoin-conf.md...
< bitcoin-git> [bitcoin] laanwj closed pull request #14497: docs: Add doc/bitcoin-conf.md (master...20181016-bitcoin-conf-md) https://github.com/bitcoin/bitcoin/pull/14497
< wumpus> maybe they'll re-open production at some point! at least the unleashed board, despite the outrageous price, were popular enough for a new batch
< wumpus> midnightmagic: it's reassuring that the IOMMU on that board is consistent and doesn't make an exception for boot-time memory twiddling
< wumpus> midnightmagic: btw re: POWER cna you weigh in on #14066 please
< gribble> https://github.com/bitcoin/bitcoin/issues/14066 | gitian-linux: Build binaries for 64-bit POWER by luke-jr · Pull Request #14066 · bitcoin/bitcoin · GitHub
< fanquake> wumpus Would we be able to fork emil-e/rapidcheck to github.com/bitcoin-core/?
< midnightmagic> sure
< fanquake> Marco has a fork that we currently use for depends, however it'd be good to move to a newer version for some bug fixes and a potentially simpler build.
< fanquake> We need the fork so we can create our own archive, because emil-e/rapidcheck isn’t tagging releases yet.
< wumpus> fanquake: yep; do we need our own fork of that?
< wumpus> yes, sure
< fanquake> wumpus thanks. More context in my comment here: https://github.com/bitcoin/bitcoin/pull/14430#issuecomment-431555605
< wumpus> repo created, see https://github.com/bitcoin-core/rapidcheck, who needs commit access?
< wumpus> besides MarcoFalke
< fanquake> maybe Christewart, he seems to be spearheading most of this work
< wumpus> ok!
< wumpus> any idea if they're on IRC?
< wumpus> 09:25 -!- Christewart There was no such nickname at least not under that name
< gwillen> are you looking for Chris_Stewart_5 ? or someone else?
< fanquake> We spoke on IRC in tokyo
< fanquake> Yea I think that's it ^
< gwillen> he doesn't have a bouncer I guess, he seems to be on and off
< wumpus> of course!
< wumpus> (I vaguely remembered that but wasn't sure)
< wumpus> invited to bitcoin and bitcoin-core at least
< fanquake> wumpus cheers
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14527: Revert "Make qt wallet test compatible with qt4" (master...Mf1810-qtRemoveQT4file) https://github.com/bitcoin/bitcoin/pull/14527
< MarcoFalke> Sorry for the downtime of DrahtBot recently. It should be catching up in the next hour or so.
< fanquake> The flood of emails has begun :p
< promag> +1
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14528: travis: Compile once on xenial (master...Mf1810-travisXenial) https://github.com/bitcoin/bitcoin/pull/14528
< * luke-jr> wonders if we really need to ban regexs due to reviewer regex-illiteracy :x
< wumpus> banning regexps above a certain complexity would make sense, I think, also because it's usually symptomic of a deeper issue
< wumpus> e.g. *why* is the underlying data so complex, does it need a real lexer/parser (because it's a programming language or markup language), or is the data mangled in an earlier step (which might be avoided in the first place)
< wumpus> and yes long regexps are extremely hard to read, though most regexp engines provide means of splitting them into lines and commenting them, but still
< promag> MarcoFalke: should provide fs::relative implementation to our source? :/
< luke-jr> wumpus: I'm not seeing any non-forking-the-code way to use readelf as a library; the regex is fairly straightforward
< fanquake> Chris_Stewart_5 See the channel history, we've forked rapidcheck to bitcoin-core, could be a chance to use the new make install method etc. You should have gotten invite to /bitcoin and /bitcoin-core as well.
< luke-jr> [06:55:43] <fanquake> We need the fork so we can create our own archive, because emil-e/rapidcheck isn’t tagging releases yet. <-- uh, that's no reason for a fork - am I missing something?
< luke-jr> if you want an archive, just use the ones github generates..
< wumpus> luke-jr: there are some python modules that can do elf parsing, but agree it's suboptimal to introduce such a dependency; nm might be a good suggestion though depending
< wumpus> ... on whether its output is better
< luke-jr> its output seems far worse
< luke-jr> same column-based output, but with single letter stuff you need the manpage to understand
< wumpus> what information do you need?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6746a8951923...96c409c919b9
< bitcoin-git> bitcoin/master fadffae MarcoFalke: Revert "Make qt wallet test compatible with qt4"...
< bitcoin-git> bitcoin/master 96c409c Wladimir J. van der Laan: Merge #14527: qa: Revert "Make qt wallet test compatible with qt4"...
< luke-jr> wumpus: target architecture, imported symbol versions, and exported symbols
< bitcoin-git> [bitcoin] laanwj closed pull request #14527: qa: Revert "Make qt wallet test compatible with qt4" (master...Mf1810-qtRemoveQT4file) https://github.com/bitcoin/bitcoin/pull/14527
< wumpus> luke-jr: but as far as I'm aware we were already looking for those; how did this change for POWER, that necessitated the large regexp
< luke-jr> wumpus: the parser does not correctly handle readelf output
< luke-jr> simply splitting on spaces fails when the data contains spaces IIRC
< luke-jr> eg 3: 0000000000000000 0 FUNC GLOBAL DEFAULT [<localentry>: 8] UND mbrtowc@GLIBC_2.17 (2)
< luke-jr> this [<localentry>: 8] stuff
< wumpus> oh some new information in columns was introduced, interesting
< wumpus> it is apparently a powerPC ABI specific thing where a function can have two entry points
< luke-jr> hmm
< wumpus> we don't *need* that information but indeed it messes with the current parsing
< luke-jr> sorry, guess the motivation behind the change was missing >_<
< wumpus> indeed; so it seems fair enough
< wumpus> I still wonder if it could be done with a simpler regexp, but yes, documenting why you do something is important
< luke-jr> I don't really see how it can get any simpler :x
< luke-jr> wumpus: do you have a link for the PPC-specific details?
< luke-jr> ty
< wumpus> luke-jr: ok, I think it's not *that* complex understanding what it does
< wumpus> regarding fs::relative, is this a new API that did get introduced in a new c++ standard? does anyone know why doesn't it exist on xenial?
< wumpus> oh wait—it's a *boost* thing, fs is boost::fs
< promag> right, 1.58 doesn't have it
< wumpus> we need to support 1.47 according to dependencies.md
< wumpus> so using that is really out of the question
< wumpus> at least without fallback
< luke-jr> I thought we were trying to avoid boost anyway?
< promag> 1.47?
< promag> ah right, min version
< promag> err,
< promag> I'll submit a fix
< wumpus> luke-jr: really can't in this case until there's a replacement for boost::filesystem
< wumpus> (which would require a newer c++ than 11)
< wumpus> it's fairly straightforward to redefine the fs namespace then
< luke-jr> oh well
< wumpus> promag: thanks!
< wumpus> luke-jr: I know it gets tiring but moving away from boost is really a long-term project
< wumpus> it needs to be done without interfering with anything else and there's so many different concernt to juggle
< luke-jr> wumpus: well, if it serves a purpose, I'm fine with it :p
< luke-jr> better than re-inventing
< wumpus> yes, exactly,
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #14530: scripted-diff: Use RPCHelpMan on RPCs with no args (master...Mf1810-rpcHelpMan) https://github.com/bitcoin/bitcoin/pull/14530
< Sentineo> hm does anybody else have a different behavior with multiwallets in testnet vs mainnet?
< Sentineo> the testnet version ignores multiple wallets, even though they are specified with testnet.wallet directive. Loading a wallet from rpc works, then wallet.dat is marked as [default]. When I try to make "loadwalelt wallet.dat" again it crashes - core dumped. On mainnet bitcoind correctly tels me the wallet is already loaded + does not ignore the wallet directives in the config file.
< Sentineo> v0.17.0 btw
< promag> wumpus: MarcoFalke: #12842
< gribble> https://github.com/bitcoin/bitcoin/issues/12842 | Prevent concurrent savemempool by promag · Pull Request #12842 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] promag opened pull request #14531: Replace fs::relative call with custom GetRelativePath (master...2018-10-getrelativepath) https://github.com/bitcoin/bitcoin/pull/14531
< promag> wumpus: MarcoFalke ^
< bitcoin-git> [bitcoin] luke-jr opened pull request #14532: Never bind INADDR_ANY by default, and warn when doing so explicitly (master...rpcbind_explicit) https://github.com/bitcoin/bitcoin/pull/14532
< kakobrekla>
< karelb> MarcoFalke thx for feedback on the RPC stuff, will reply tomorrow after I sleep on it
< bitcoin-git> [bitcoin] practicalswift reopened pull request #13909: validation: Pass chainparams in AcceptToMemoryPoolWorker(...) (master...remove-chainparams-argument-to-AcceptToMemoryPoolWorker) https://github.com/bitcoin/bitcoin/pull/13909
< phantomcircuit> wumpus, they're unlikely to do another run of the same chips for sifive, im guessing that was recouping the cost of the smallest run they could get
< phantomcircuit> wumpus, but that also means the next one might be a more fully baked thing
< bitcoin-git> [bitcoin] mrwhythat opened pull request #14533: wallet: ensure wallet files are not reused across chains (master...wallet-file-reuse-prevention) https://github.com/bitcoin/bitcoin/pull/14533
< wumpus> phantomcircuit: on one hand I hope they do improve it, on the other, I hope it doesn't mean my board is no longer supported
< phantomcircuit> wumpus, i mean what does supported even mean for a dev board like that
< phantomcircuit> usually you're lucky to get insanely hacked together kernel source
< wumpus> welll fedora and debian distributions target it now because it's the only RISC-V board that supports Linux
< phantomcircuit> how about a 2.6.x branch with random bits from 4.x in it?
< phantomcircuit> which is no joke the norm for embeded type dev board things
< wumpus> kernel is just a matter of time, they're working on getting everything upstreamed
< phantomcircuit> yeah that's my point
< phantomcircuit> it seems documented enough to actually do that
< wumpus> they more or less did, got it to boot but had some problem with the network interface
< wumpus> (with mainline kernel I mean)
< wumpus> it's *certainly* not as bad as some ARM boards, as you say with ancient kernels
< phantomcircuit> wumpus, also it seems most of the poll() issues have to do with unconnected sockets and using it as a sleep
< wumpus> but you're right, it's not that big a concern in this case, I'm just too use to ARM SoCs where the next thing means the previous one is dropped
< phantomcircuit> which im avoiding completely now
< phantomcircuit> so im thinking we can use poll() on windows as long as it's not used on unconnected sockets
< wumpus> using unconnected sockets as a sleep wut?!?
< wumpus> well unconnected sockets shouldn't be emitting any events I guess
< wumpus> but it should be unnecessary to pass them to poll/select, you can use either function as a sleep by not passing anything...
< wumpus> as for using poll() on windows, be careful, I don't think that's very common, either because it's known as flaky or because it's only been introduced in more recent versions
< gmaxwell> It's also not terribly important on widows. Select uses a linked list there and doesn't have an FD range limit.
< wumpus> exactly...
< phantomcircuit> wumpus, no im saying the main select/poll loop doesn't have any sockets which haven't connected
< phantomcircuit> we have another thing that does that
< phantomcircuit> or maybe im misunderstanding the way this is all setup
< phantomcircuit> the windows bug is about sockets where you call connect non-blocking and then select it
< wumpus> but things like this is why I preferred using libevent, it chooses the best polling abstraction for the OS, and is pretty well tested because it's used by Tor
< wumpus> introducing this into our own code means having to handle all who-knows-what OS dependent edge cases ourselves
< phantomcircuit> wumpus, the first step to using libevent is to move to a callback style
< phantomcircuit> which we cna do while still using the loop
< phantomcircuit> (which is what libevent is doing internally)
< wumpus> yes, cfields was working on this at some point
< wumpus> to be clear I think it's fine to move to poll but I *expected* it to be much less of a hassle
< wumpus> I think it makes sense to focus on UNIXish OS and forget windows just leave that at select
< wumpus> it seems like you're trying to extend the scope of this too much
< phantomcircuit> wumpus, im just thinking about what to do next, need to cleanup the current pr a bunch before it's ready
< phantomcircuit> so i was thinking if i was going to do anything that would make that harder on accident
< bitcoin-git> [bitcoin] jbampton opened pull request #14534: Enable flake8 rule E225 which checks for missing whitespace around op… (master...flake8-fix-E225) https://github.com/bitcoin/bitcoin/pull/14534
< booyah> btw, why not asio, instead of all this problems with pool/libevent and all
< phantomcircuit> booyah, asio and libevent are both callback based
< phantomcircuit> while the current logic is polling based
< phantomcircuit> improving what's there is less error prone than switching the entire paradigm
< sipa> one step at a time
< wumpus> asio used to be used for the RPC server, that was pretty awful, also we don't really want to add any boost dependencies
< booyah> wumpus: what was afful there, in that rpc?