< 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/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
< 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 :)