< bitcoin-git>
[bitcoin] lucash-dev closed pull request #13050: [tests] improvements to slow unit tests (master...slow-unit-tests-improvement) https://github.com/bitcoin/bitcoin/pull/13050
< promag>
MarcoFalke: #13230 needs rebase tag?
< gribble>
https://github.com/bitcoin/bitcoin/issues/13230 | Simplify include analysis by enforcing the developer guides include syntax by practicalswift · Pull Request #13230 · bitcoin/bitcoin · GitHub
< fanquake>
promag it looks ok to me?
< fanquake>
MarcoFalke is your bot on GH somewhere?
< bitcoin-git>
bitcoin/master 698cfd0 practicalswift: docs: Mention lint-locale-dependence.sh in developer-notes.md
< bitcoin-git>
bitcoin/master 5779dc4 Wladimir J. van der Laan: Merge #13041: build: Add linter checking for accidental introduction of locale dependence...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13041: build: Add linter checking for accidental introduction of locale dependence (master...lint-locale-dependence) https://github.com/bitcoin/bitcoin/pull/13041
< kallewoof>
cfields: are you able to debug using lldb on mac? even with ./configure --enable-debug and make clean I get 'optimized', which is because it puts in -O2. Despite --enable-debug.
< wumpus>
anyhow, going to tag rc2
< wumpus>
* [new tag] v0.16.1rc2 -> v0.16.1rc2
< sipa>
w00t
< fanquake>
wumpus If you're still here, #13369 can go in
< rafalcpp>
no one ported the github-merge.py script to support gitlab?
< wumpus>
not that I know
< wumpus>
i'd guess that they have similar APIs, and it's just a matter of tweaking some things
< wumpus>
huh, test_runner stopped printing progress dots here
< rafalcpp>
API differs, and they do not want to write compatiblity layer. But probably allows same needed functions
< wumpus>
oh it still prints ".", but it looks like it takes a lot longer to initially generate the cache
< wumpus>
(ok, can't bisect it either, must be something that changed locally in the environment here)
< wumpus>
rafalcpp: yes, I did not mean to imply it would be an exact mapping
< wumpus>
rafalcpp: looking at it, it does only use one call from the gh api, the one to get PR information
< rafalcpp>
wumpus: yeap, perhaps it will be written tomorrow
< wumpus>
and from that, it only uses the title, body and branch base ref
< bitcoin-git>
[bitcoin] marcoagner opened pull request #13410: Qt: removes html tags from tr calls (master...refactor_remove_tr_html_tags) https://github.com/bitcoin/bitcoin/pull/13410
< rafalcpp>
wumpus: any idea how "refs/heads/pull/1/merge" is created, because it seems to not exist on github.com repo for PR 1, and yet the script wants it
< bitcoin-git>
bitcoin/master ebebedc lucash.dev@gmail.com: speed up of tx_validationcache_tests by reusing of CTransaction....
< bitcoin-git>
bitcoin/master 3d3d8ae MarcoFalke: Merge #13404: [tests] speed up of tx_validationcache_tests by reusing of CTransaction....
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #13404: [tests] speed up of tx_validationcache_tests by reusing of CTransaction. (master...speedup-tx_validationcache_tests) https://github.com/bitcoin/bitcoin/pull/13404
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #13412: Make ReceivedBlockTransactions return void (master...Mf1806-refactorReturnCodeValidation) https://github.com/bitcoin/bitcoin/pull/13412
< bitcoin-git>
bitcoin/master 9b0ec1a Jim Posen: db: Remove obsolete methods from CBlockTreeDB.
< bitcoin-git>
bitcoin/master e5af5fc Jim Posen: db: Make reusable base class for index databases.
< bitcoin-git>
bitcoin/master 61a1226 Jim Posen: index: Extract logic from TxIndex into reusable base class.
< bitcoin-git>
[bitcoin] laanwj closed pull request #13243: Make reusable base class for auxiliary indices (master...index-abstraction) https://github.com/bitcoin/bitcoin/pull/13243
< jamesob>
nice change, congrats jimpo
< wumpus>
I think we should invite jimpo / Jim Posen to the organizations, he's certainly a frequent contributor
< sipa>
ack
< luke-jr>
is there some reason we went from single-value args + multi-value args to override-args + config-args? the former seems a lot better..
< rafalcpp>
wumpus: gitlab support is added probably. Though I see git submodules are not supported at all. Ok to add support for it? maybe just convert them to text of the sha1 commit?
< wumpus>
rafalcpp: in bitcoin we use subtrees, not submodules, that's why there's no support for them
< bitcoin-git>
[bitcoin] rfree-d opened pull request #13414: Support gitlab API in github-merge.py (master...githubmerge_support_gitlab) https://github.com/bitcoin/bitcoin/pull/13414
< skeees>
what would reaction / opinion be to defining a macro that allows a function to be static except in unit test builds
< skeees>
something like #ifdef TEST "" #else static
< sipa>
that would mean compiling the core objects separately for tests and for normal operation
< sipa>
which may have performance advantages, but also downsides w.r.t. testability (you're not testing the exact same code as the one that goes in production)
< cfields>
skeees: for what purpose?
< skeees>
basically, theres a bunch of stuff (e.g. in net_processing) that could become static (and a lot of which is only called from one place so probably even inlined at compile time) except that its unit tested somewhere. might have some perf benefits, and would also help readability because you can immediately assess that something is translation unit local
< skeees>
but i imagine the work to configure separate builds is substantial
< sipa>
the perf benefits we can get longer term through lto as well
< cfields>
skeees: sounds like you're looking for lto?
< skeees>
mostly actually, i'm trying to separate net_processing a bit more from validation, and its been somewhat of a manual exercise, but finding lots of these - so i would say primarily readability / modularization actually
< skeees>
probably better static analysis tools would accomplish the same
< cfields>
ah, I see
< gmaxwell>
If we just want a cosmetic note for arch reasons, there could be a STATICBUTFORTESTS that turns into STATIC for a specific test build (to verify that its used correctly) but otherwise isn't.
< wumpus>
skeees: there's some good reasons to be against including cpp files, but it's also useful for testing static functions :)
< skeees>
ahhh, well you could have that linter not run on anything in test/*
< gmaxwell>
In other projects I've had okay success with including .c files for unit tests. I can get arguments against it though.
< wumpus>
well it still has sipa's problem that "you're not testing the exact same code as the one that goes in production", it avoids the macro magic, but has including c/cpp files
< wumpus>
choosing between evils...
< wumpus>
the advantage of "my" method is that it also works for anonymous namespaces
< wumpus>
a macro to replace static, would just work for static
< gmaxwell>
Not testing the exact same code that goes into production is already pretty complicated. What the compiler is doing for inlinable functions already is inlining them where it can, potentially at every use in the file, and then the export is some other code. So the test may well already be testing code that is not used anywhere else.
< wumpus>
gmaxwell: indeed
< gmaxwell>
(obviously this doesn't matter if the code is all defined behavior and the compiler is bug free...)
< gmaxwell>
I like to think of the "not testing the exact same code" as more of just a fundimental limitation of unit tests.
< wumpus>
I mean it's a good point - internal/static functions are very likely inlined, so it's impossible to test exactly the same assembly code as used in production functions
< wumpus>
the point of the unit test would be to test the functionality of the code, not the compiler
< wumpus>
jcorgan: still 3 minutes to go according to my clock
< jcorgan>
ah, need to fix ntpd on my irc bouncer :)
< gmaxwell>
wumpus: yes, point of the unit test is testing functionality of the code not the compiler-- though if the code executes undefined behavior you can't fully decouple those things. In any case, my point is that static vs not static doesn't differ in the functionality of the code...
< sipa>
*GONG*
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Jun 7 19:00:08 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< wumpus>
PSA: v0.16.1rc2 has been tagged, please start your gitian builders if you haven't yet, hopefully this can be a short rc, the only change is translations
< sipa>
reasonable chance that rc2 will be final?
< sipa>
(sorry, i haven't followed 0.16.1 much)
< achow101>
yes
< wumpus>
well at least I haven't seen any other reports to it, except the Russian translation issue
< promag>
hi
< wumpus>
so yes I hope this can be final very quickly
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< luke-jr>
is there some reason we went from single-value args + multi-value args to override-args + config-args? the former seems a lot better..
< luke-jr>
(this is blocking me on 11082 rebasing)
< wumpus>
I'll take that as a topic suggestion
< sipa>
i'm not sure what you mean by that
< wumpus>
(for later)
< wumpus>
#12136 still has lots of active discussion
< gmaxwell>
I have cached skeptcisism mostly because compilers used to be VERY bad with register allocations for SIMD, resulting in a lot of code that is more complex than 'run this code 4x in parallel' not getting a speedup when hand asm hapily got a 3x speedup. I know they're much better now. So perhaps ignore me. :)
< luke-jr>
we used to have a map of arg name -> single value and arg name -> multiple values
< luke-jr>
it's been changed to arg name-> multiple values, but with two maps, one for config file, and one for command line options
< luke-jr>
it seems better to have config/commandline share maps
< wumpus>
gmaxwell: compilers seem to have become better with that, but I understand your skepticism
< wumpus>
gmaxwell: there's also the *optimizing for a specific CPU type* versus *optimizing it to be, on average, fast, for many families of CPUs* thing
< luke-jr>
this comes up because the change complicates how to implement rwconf
< achow101>
luke-jr: I think that change may be for qt settings interactions
< wumpus>
luke-jr: I'm not sure I know enough about this to understand the implications of this in practice
< wumpus>
whatever you do, please don't mess up the bitcoin-qt initialization order, the rest is fine with me :p
< sipa>
i think it would also be useful to make the arg information know whether a particular argument is single-value or multi-value
< sipa>
rather than have that information be at query time
< sipa>
but i also don't understand the interactions well enough
< sipa>
aj: you here?
< luke-jr>
sipa: yes, I was thinking about that too
< wumpus>
#13389 kind of scared me
< gribble>
https://github.com/bitcoin/bitcoin/issues/13389 | Utils and libraries: Fix #13371 - move umask operation earlier in AppInit() by n2yen · Pull Request #13389 · bitcoin/bitcoin · GitHub
< luke-jr>
the reason they're split one way or the other, is because the last command line option overrides the former ones, and the earlier config file overrides the later ones
< wumpus>
we don't have good tests for half of this stuff
< luke-jr>
so now when we do Get*Arg, the code is going for the end of the command line list, then the start of the config file list
< luke-jr>
(the altnerative being, to just parse into a single value at startup, and just access that map at runtime)
< sipa>
i feel like the right people aren't here to discuss that
< wumpus>
yes
< luke-jr>
maybe
< sipa>
it sounds reasonable what you're saying, but i don't know enough to really comment
< wumpus>
I agree
< jnewbery>
There's a lot of discussion and review in both #12878 and #11862. AJ also added really good code coverage in those PRs, so it should be pretty straightforward to follow
< wumpus>
other topics?
< gribble>
https://github.com/bitcoin/bitcoin/issues/12878 | [refactor] Config handling refactoring in preparation for network-specific sections by ajtowns · Pull Request #12878 · bitcoin/bitcoin · GitHub
< BlueMatt>
oh, quick comment: if you have had ideas about things you want to fork into the protocol in the future, *please* read https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki and make sure that your ideas can be added without protocol modifications so that miners dont need firmware updates
< BlueMatt>
and pools wouldnt need to change
< BlueMatt>
obviously basic things like additional commitments especially via the witness reserved value are clearly supported
< wumpus>
promag: if people open "competing PRs" for the same issue that makes things more difficult
< wumpus>
instead of just reviewing code, you suddenly need to be judge of what is the best approach
< promag>
what are the odds to open competing PRs at the "same time"?
< promag>
right
< wumpus>
promag: it luckily doesn't happen too much!
< promag>
imo one of the authors (the last?) should review the other
< promag>
and close his own
< wumpus>
I like your approach, get them to cooporate intead of compete
< * luke-jr>
goes through the PR list, rewrites them, and opens new PRs to compete. jk
< promag>
luke-jr: in this case they are very very similar
< wumpus>
luke-jr: I know it, I shouldn't have given away this obvious DoS strategy
< promag>
it's not a rewrite like you say
< luke-jr>
wumpus: actually, if someone does try to DoS with it, it may end up improving our flow quickly
< wumpus>
I'm... not going to say more about this, not giving people ideas :)
< promag>
wumpus: then feel free to review my PR
< wumpus>
promag: which one?
< promag>
all
< promag>
:|
< promag>
unloadwallet
< promag>
in travis its failing with -with-incompatible-bdb i think
< wumpus>
lets' first see why travis is failing on it
< promag>
I'll
< promag>
.. to reproduce locally
< wumpus>
multiwallet failing on x86_64 linux platforms
< wumpus>
promag_: /home/orion/projects/bitcoin/bitcoin/src/qt/bitcoingui.cpp:122:5: warning: field 'spinnerFrame' will be initialized after field 'm_wallet_selector_label' [-Wreorder]
< wumpus>
(I think that's due to your change, I haven't seen it before)
< wumpus>
promag_: I don't get the same crash locally
< promag>
regarding the warning, i'll fix
< promag>
strange
< promag>
mtt bug?
< wumpus>
mtt?
< promag>
multithread
< promag>
crash aside, a code review + concept ack would be nice
< bitcoin-git>
[bitcoin] skeees opened pull request #13417: [net] Tighten scope in net_processing (master...net_processing-disentangle) https://github.com/bitcoin/bitcoin/pull/13417