< cfields> sipa: did you use cppreference as a template for implementing span?
< cfields> trying to figure out some weirdness.
< sipa> cfields: yeah
< sipa> but just because it lists a copy constructor doesn't mean the implementation needs one explicitly of course
< cfields> sipa: sure, not concerned about that.
< cfields> sipa: I believe cppreference is using an outdated draft. Just wanted to see if that's what you were going by.
< cfields> will dig deeper tomorrow.
< sipa> cfields: at least it's up to date with using size_t as size type (it used to be ssize_t in an even older draft)
< cfields> sipa: aha, right. Thanks, that helps.
< cfields> sipa: specifically, ctor #7 is absent from the current draft: https://en.cppreference.com/w/cpp/container/span/span
< gribble> https://github.com/bitcoin/bitcoin/issues/7 | Block-header-only, faster startup client · Issue #7 · bitcoin/bitcoin · GitHub
< sipa> cfields: cppreference.cpp is a wiki ;)
< luke-jr> lol
< cfields> haha, fair enough.
< cfields> s/will dig deeper tomorrow/will perform surgery tomorrow/
< cfields> :)
< sipa> cfields: fwiw, https://godbolt.org/z/B5VHgu
< sipa> gcc trunk works; no clang version on godbolt seems to support span at all
< cfields> sipa: any chance there's a "g++ -stdlib=libc++" option ?
< sipa> g++: error: unrecognized command-line option '-stdlib=libc++'
< cfields> ok, thanks.
< cfields> well I'm about 10 kinds of confused. Going to call it a night.
< sipa> are you sure that's the right syntax?
< sipa> i see no -stdlib=... documented in gcc's manpage
< cfields> Oh, maybe gcc hasn't learned that? I could've sworn you could select it there too.
< cfields> sipa: huh, guess you're right.
< fanquake> Maybe coming in GCC 11
< cfields> sipa: that example compiles for me locally with clang and libc++. Another helpful data point, thanks.
< cfields> fanquake: ah, nice :)
< sipa> they don't have an explicit universal reference constructor, instead relying on temporaries binding with const lvalue reference
< sipa> that's a more elegant way of doing it actually
< bitcoin-git> [bitcoin] S3RK opened pull request #19384: test: speed up functional tests (master...test_speed_up) https://github.com/bitcoin/bitcoin/pull/19384
< bitcoin-git> [bitcoin] yancyribbens opened pull request #19385: test: Change default test logging directory (master...unit-log-location) https://github.com/bitcoin/bitcoin/pull/19385
< cfields> sipa: right, sorry, I didn't mean to imply that the construction was no longer possible. Only that it's no longer a universal reference.
< cfields> sipa: I'm regretting starting down this path now, I don't think it's really worth the effort. I'm mainly seeing it through now as a learning experience...
< cfields> That ensures that trivial copies are sent through the trivial constructor, and splits out the const reference case so that we can apply lifetimebound specifically to it.
< sipa> any reason why you wouldn't want the lifetimebound on both?
< sipa> ah, because temporaries just wouldn't bind against the mutable lvalue reference one?
< cfields> Right, no reason other than I don't see the need.
< sipa> but as i understand it, there is no harm in applying it to both
< cfields> sure, not opposed.
< sipa> in the second one, i think you need const V in the type checks?
< cfields> yup, nice catch.
< sipa> also, does that compile? it looks like the template argument to std::enable_if<... is not closed
< sipa> oh, it is
< sipa> nvm
< cfields> hehe. it's an arg enable_if now, not a template one.
< sipa> ah, is that preferable?
< sipa> i think it makes sense to more closely match the exact conditions used in an actual std lib
< cfields> that's why i switched it, I'm not sure if it's preferred though. Might be part of some overload matching rule that I'll never understand.
< sipa> i've had to fight with old compiler versions in travis a few times to make it work
< sipa> but i think this approach of splitting up const and nonconst is pretty elegant, and perhaps more likely to work
< sipa> *more likely to work on the first try
< cfields> oh, fun. guess I'll start that process.
< cfields> sipa: I'm guessing you didn't add the std::array overload because Extent isn't implemented?
< cfields> std::array constructor, sorry.
< sipa> yeah, it should be captured by the container constructor
< cfields> ack
< sipa> actually, the criterion to avoid arrays in your type expressions is superfluous too, i think
< sipa> as arrays don't have .data() and .size() member functions
< sipa> C++17 adds std::data and std::size, which generalize the data and size member functions to arrays
< cfields> Aha, right... they use the newer generic data(foo) rather than foo.data(), which must have an overload
< cfields> will remove
< hebasto> do we have a functional test for orphan tx eviction when a new block is connected? couldn't find it...
< sipa> hebasto: break it, and see if tests fail :)
< hebasto> yes!
< hebasto> thanks :)
< cfields> hehe
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #19386: rpc: Assert that RPCArg names are equal to CRPCCommand ones (server) (master...2006-rpcManServer) https://github.com/bitcoin/bitcoin/pull/19386
< hebasto> I've broke a half of `PeerLogicValidation::BlockConnected()` but functional test passed... It seems we need more tests :)
< bitcoin-git> [bitcoin] theuni closed pull request #19382: span: Add lifetimebound attribute to guard against temporary lifetime issues (master...lifetimebound) https://github.com/bitcoin/bitcoin/pull/19382
< bitcoin-git> [bitcoin] theuni opened pull request #19387: span: update constructors to match c++20 draft spec and add lifetimebound attribute (master...lifetimebound2) https://github.com/bitcoin/bitcoin/pull/19387
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f32f7e907a5e...3bbd8225b92d
< bitcoin-git> bitcoin/master 1087807 practicalswift: tests: Provide main(...) function in fuzzer
< bitcoin-git> bitcoin/master 3bbd822 MarcoFalke: Merge #19366: tests: Provide main(...) function in fuzzer. Allow building ...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19366: tests: Provide main(...) function in fuzzer. Allow building uninstrumented harnesses with --enable-fuzz. (master...provide-main-function-in-fuzzer) https://github.com/bitcoin/bitcoin/pull/19366
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3bbd8225b92d...49464004701e
< bitcoin-git> bitcoin/master d906aaa Hennadii Stepanov: qt: Fix regression in TransactionTableModel
< bitcoin-git> bitcoin/master 4946400 MarcoFalke: Merge bitcoin-core/gui#8: Fix regression in TransactionTableModel
< jamesob> do we have release signing pubkeys referenced anywhere in the repo?
< jamesob> (we do: https://github.com/bitcoin/bitcoin/tree/master/contrib/verifybinaries, though the key I retrieved differs from the one on bitcoin.org: https://bitcoin.org/laanwj-releases.asc)
< luke-jr> should encourage people to use the gitian sigs more anyway imo
< jamesob> did we ever figure out distribution for asmap? is the recommended method just to use sipa's python repo and build it yourself?
< sipa> jamesob: you're behind :p
< jamesob> too true
< sipa> the answer is no, but the encoder in https://github.com/bitcoin/bitcoin/pull/18573 is far better than my python scripts
< sipa> however, actually gathering the routing information... i don't really have a solution, except having some people build it independently and compare
< jamesob> would be nice to have a script in contrib that makes it easy to build one (with parameterized routing sources or something)
< sipa> and unless you have access to routing tables yourself like BlueMatt... you'll be relying on someone giving you a dump
< sipa> which necessarily puts trust in that entity
< sipa> (which only gathers/aggregates dumps, it doesn't encode)
< BlueMatt> right, given there's at least 3 public routing table dumps I'm aware of that can be found online, and likely many more possible, plus a few folks who have access to the routing table, I dont think its unreasonable to ship something presuming we have some ability to diff asmaps
< BlueMatt> ripe ris, oregon route views, caidia bgpstream are all good resources, plus anyone who is on a super small isp can probably just ask for a relevant routing table dump if you ping the noc.
< BlueMatt> you can probably find some other random route servers that have the ability to generate a dump left on
< sipa> BlueMatt: thanks for the reminder that i should add a asmap diff tool
< sipa> somewhefe
< BlueMatt> right, cerainly not practical to ship anything without a diff tool.
< * luke-jr> wonders if there's any way for random joes to monitor BGP or whatever directly
< BlueMatt> directly? ask your isp for a session. indirectly? see the list i just wrote above :)
< bitcoin-git> [bitcoin] luke-jr opened pull request #19390: doc/REST-interface: Remove stale info (master...restdoc_rm_stale) https://github.com/bitcoin/bitcoin/pull/19390
< bitcoin-git> [bitcoin] luke-jr opened pull request #19391: RPC/Mining: Clean out pre-Segwit miner compatibility code (master...gbt_rm_versionforce) https://github.com/bitcoin/bitcoin/pull/19391
< * luke-jr> peers at BSD CI failing on doc change O.o
< sipa> cfields: Span<const int> bad{MakeSpan(std::vector<int>{})} works fine :(
< sipa> without lifetimebound warning
< midnight> seeing an odd fdatasync() problem starting up a regtest instance to complete unit tests on a NetBSD vm, in the leveldb code.. :-/