< bitcoin-git> [bitcoin] achow101 opened pull request #17458: Refactor OutputGroup effective value calculations and filtering to occur within the struct (master...cleanup-outputgroups) https://github.com/bitcoin/bitcoin/pull/17458
< bitcoin-git> [bitcoin] theStack opened pull request #17459: Remove redundant NDEBUG preprocessor checks (master...20191112-remove-redundant-ndebug-checks) https://github.com/bitcoin/bitcoin/pull/17459
< jeremyrubin> fyi if you have an opinion on OP_SECURETHEBAG naming convention please chime in on https://www.reddit.com/r/Bitcoin/comments/dviy6i/should_op_securethebag_be_renamed/ or the twitter poll. Trying to finalize a name (naming it is difficult as the boring but technically accurate name is OP_CHECKOUTPUTSANDSEQUENCESANDSCRIPTSIGSANDLOCKTIMEANDVERSIONANDNVINVERIFY is a bit too wordy). Hoping to resolve naming concerns so that focus
< jeremyrubin> can hone in on implementations...
< BlueMatt> jnewbery: note that "Add new peer state tracking class to reduce cs_main contention" only vaguely makes sense on its own - the vast majority of the contension is around cs_main for a reason...witout the rest of the patch to make ProcessNewBlock and the like not take cs_main it is a lot of code movement for not very much performance gain.
< bitcoin-git> [bitcoin] theStack opened pull request #17461: test: check custom descedant limit in mempool_packages.py (master...20191112-test-check_custom_descendant_limit_in_mempool-packages) https://github.com/bitcoin/bitcoin/pull/17461
< bitcoin-git> [bitcoin] RandyMcMillan opened pull request #17462: build: macOS fix Info.plist (master...info-plist) https://github.com/bitcoin/bitcoin/pull/17462
< bitcoin-git> [bitcoin] luke-jr opened pull request #17463: Bugfix: GUI: Restore SendConfirmationDialog button default to "Yes" (master...gui_custom_sendyes) https://github.com/bitcoin/bitcoin/pull/17463
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/8237889e8d0f...cd6cb9745e13
< bitcoin-git> bitcoin/master fab9850 MarcoFalke: scripted-diff: Avoid hardcoded libfaketime dir in gitian
< bitcoin-git> bitcoin/master 3333629 MarcoFalke: doc: Explain $LIB in LD_PRELOAD in gitian descriptors
< bitcoin-git> bitcoin/master cd6cb97 Wladimir J. van der Laan: Merge #17409: build: Avoid hardcoded libfaketime dir in gitian
< bitcoin-git> [bitcoin] laanwj merged pull request #17409: build: Avoid hardcoded libfaketime dir in gitian (master...1911-gitianArm64) https://github.com/bitcoin/bitcoin/pull/17409
< JeremyCrookshank> What does everyone use to develop on Bitcoin with? Visual studio code?
< meshcollider> JeremyCrookshank: notepad.exe
< jonatack> JeremyCrookshank: why not, fwiw i know several who use vim and also have seen emacs and atom used
< MarcoFalke> <JeremyCrookshank> What does everyone use to develop on Bitcoin with? Visual studio code?
< MarcoFalke> I use vanilla vim, sipa uses mcedit: https://twitter.com/pwuille/status/1192141975358541825, not sure about others
< sipa> real programmers use emacs: https://xkcd.com/378/
< jonatack> afaik achow101 uses atom, jnewbery, ariard, MarcoFalke, and (iirc) ryanofsky use vim (atm i use emacs)
< jonatack> clearly they can all do the job :)
< instagibbs> i see im too late for the minecraft joke
< luke-jr> JeremyCrookshank: I use Kate
< JeremyCrookshank> Not heard of that one
< elichai2> I use CLion and i'm not ashamed :P
< luke-jr> JeremyCrookshank: KDE's Advanced Text Editor
< JeremyCrookshank> Also not heard of clion
< JeremyCrookshank> I suppose nowadays most of these editors are the same :P
< sipa> nah, they're all very different in appearance ans features
< sipa> but it depends way more on your own way of working
< bitcoin-git> [bitcoin] dongcarl opened pull request #17466: depends: qt: Fix C{,XX} pickup (master...2019-11-qt-CC-CXX-pickup) https://github.com/bitcoin/bitcoin/pull/17466
< JeremyCrookshank> elichai2 clion looks decent what's the stigma?
< sipa> jonasschnelli: real_or_random and i jad some thoughts on simplifying future upgrades in the v2 protocol, ping me when you have some time
< elichai2> JeremyCrookshank: the stigma is that real devs use vim/emacs :)
< sipa> real devs use butterflies
< sipa> who cares
< midnight> µEmacs overlords
< luke-jr> elichai2: Kate does have a VI Mode
< MarcoFalke> clion has a vi mode, but it feels wrong to vanilla vim
< luke-jr> well, vim isn't vi :P
< jamesob> anyone ever apply lock annotations to a lambda? is possible?
< MarcoFalke> jamesob: no not possible
< jamesob> dammit
< MarcoFalke> You'd have to use AssertLockHeld
< MarcoFalke> jamesob: It is not possible because you can pass the lambda into a different translation unit
< MarcoFalke> I don't think clang can handle that
< JeremyCrookshank> why you want to
< MarcoFalke> JeremyCrookshank: Anywhere a lambda is used, you might want to add locking annotations
< jamesob> MarcoFalke: but AssertLockHeld won't make clang lock analysis happy, eh?
< MarcoFalke> For the same reason that you want to use locking annotations normally (in non lambdas)
< MarcoFalke> jamesob: I think it does
< MarcoFalke> jamesob: If not, you can use LockAssertion
< jamesob> ah right on, LockAssertion looks like it'll do it. thanks.
< sipa> according to this, it's possible: https://stackoverflow.com/a/40483407/8342274
< jamesob> argh, capturing a ::cs_main reference apparently isn't possible due to its storage duration
< jamesob> I'll just use a private method instead of a lambda
< luke-jr> MarcoFalke: but lock annotations are part of the type, no?
< jonasschnelli> sipa: Great. Happy to hear it.
< MarcoFalke> sipa: It is possible to put the annotation in, but I don't think the compiler can evaluate the annotation when the lambda is passes as a std::function into a different function in a different translation unit
< sipa> MarcoFalke: in that case, sure
< sipa> but usually lambdas are passed as a templated type
< sipa> which doesn't require collapsing to an std::function type
< MarcoFalke> There might be discussion about that in the commit in clang that added the possibility to annotate lambdas
< sipa> actually, perhaps clang supports having locking annotations on std::function types too; not sure
< MarcoFalke> sipa: Sure if it is templated then the Mutex is available in the translation unit, so it might be possible. However when it is a std::function, the header that defines the Mutex might not be included, so I dont' think clang can do its magic
< MarcoFalke> [14:13] <jamesob> argh, capturing a ::cs_main reference apparently isn't possible due to its storage duration
< MarcoFalke> hmm, are you sure? I think I did that recently
< MarcoFalke> maybe I didnt' compile with clang, though?
< jamesob> yeah, I got a clang warning
< jonasschnelli> <sipa>jonasschnelli: real_or_random and i jad some thoughts on simplifying future upgrades in the v2 protocol, ping me when you have some time
< jonasschnelli> Do you have time to explain it further?
< sipa> jonasschnelli: probably should do it when real_or_random is available too
< jonasschnelli> Okay. Let see if we find a overlapping timezone window. :)
< jamesob> MarcoFalke: hm weird, wonder what the difference was with my code. thanks.
< MarcoFalke> How did you capture?
< jamesob> tried capture and no capture - clang doesn't like the attempted capture-by-reference ("'cs_main' cannot be captured because it does not have automatic storage duration [clang-diagnostic-error]"). then when I write `LockAssertion(::cs_main)` I get "definition or redeclaration of 'cs_main' cannot name the global scope [clang-diagnostic-error]"
< MarcoFalke> jamesob: globals are already captured
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #17466: depends: qt: Fix C{,XX} pickup (master...2019-11-qt-CC-CXX-pickup) https://github.com/bitcoin/bitcoin/pull/17466
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #17466: depends: qt: Fix C{,XX} pickup (master...2019-11-qt-CC-CXX-pickup) https://github.com/bitcoin/bitcoin/pull/17466
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17469: test: Remove fragile assert_memory_usage_stable (master...1911-testFragileMem) https://github.com/bitcoin/bitcoin/pull/17469
< jamesob> MarcoFalke: yeah in the second case I'm not doing a capture
< JeremyCrookshank> @a5
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17470: ci: Use clang-8 for fuzzing to run on aarch64 ci systems (master...1911-ciFuzzClang8) https://github.com/bitcoin/bitcoin/pull/17470