< fanquake>
aj unfortunately all of the /bitcoin subtrees are at /bitcoin-core
< aj>
ah good point
< fanquake>
aj did you end up getting the static analyzer working?
< aj>
fanquake: no, haven't tried the gist though (i didn't run autogen.sh through scan-build when i tried)
< fanquake>
aj ok. I'll be having a look at it again shortly.
< fanquake>
Thinking out load, not that we are seeing a lot more "Fix warning from analyzer X" type PRs. I think it'd be beneficial (maybe in a PR template?) to add some guidelines around opening those sort of PRs.
<@wumpus>
I agree
< fanquake>
At least including the compiler/version, the tool/version, which flags your passing to ./configure, which commit your building etc.
<@wumpus>
we're only interested in seeing such PRs *if* they fix issues that would be an issue without the static analyser as well, e.g. actual problems
< fanquake>
Otherwise, I look at a PR (for example) like #12882, and don't really have a quick way to just setup and atleast test the changes.
<@wumpus>
not 'work around bugs in my tool'
< gribble>
https://github.com/bitcoin/bitcoin/issues/12882 | tests: Make test_bitcoin pass under ThreadSanitzer (clang). Fix lock-order-inversion (potential deadlock). by practicalswift · Pull Request #12882 · bitcoin/bitcoin · GitHub
< fanquake>
wumpus yes. And being able to reproduce issues quickly and easier is key to that.
< fanquake>
I don't really want to waste time trying to recreate some obscure issue, and then findout they were using HEAD version of X tool, which may or may not produce correct results.
<@wumpus>
right
< fanquake>
Or using some *older* version of a tool that spews since-fixed warnings.
<@wumpus>
my point is also that the kind of changes we're interested in are usually easy to inspect, I mean, the static analyser finds a bug that normal review would also have found given enough eyes on the matter
< fanquake>
wumpus sure
<@wumpus>
if some obscure, hand-rolled analysis tool finds an important bug we'd be very thankful, but not if it comes with 20 screenfuls of false positives
< fanquake>
wumpus I agree, I'm not advocating "against" people hammering the codebase with whatever tools they want. Just want to make sure that when it appears in a PR it's something useful.
<@wumpus>
indeed
< fanquake>
I feel like if at some point we write enough bash scripts & linters, the repository will just about be able to maintain itself indefinitely
<@wumpus>
a kind of mutation engine for software evolution
< sipa>
i think we should be able to write scripted diffs into the blockchain and have them be applied automatically to the source code
< fanquake>
heh the *real* devcoin
< * sipa>
is reminded of BIP 2112
<@wumpus>
hehehe
< sipa>
is that really 6 years old already :o
< Kanna>
any idea about soft fork ? and how to do this ?
< fanquake>
Kanna in what conext?
< sipa>
consensus changes to bitcoin are generally discussed on the mailing list
< Kanna>
I want to do the bitcoin fork with some predefined block size for example 4mb [ Testing ]
< Kanna>
<fanquake> my fork should happen on this parameter Max Blocksize 8MB Block time 2 mins or 2.5 [ to test the bitcoin fork ]
< bitcoin-git>
[bitcoin] practicalswift opened pull request #12993: tests: Remove compatibility code not needed now when we're on Python 3 (master...remove-python-2-compatibility-code) https://github.com/bitcoin/bitcoin/pull/12993
< sipa>
Kanna: other currencies are off topic here
< fanquake>
Has anyone recreated #12990 ? I'm unable to on Ubuntu with GCC8.0.1 20180414
< Kanna>
How to reduce the latency of the transaction ? Do i need to consder block size on this ?
<@wumpus>
Kanna: off topic here, go to #bitcoin
< jonasschnelli>
I just tried to run the "bitcoin-0.16.99-arm-linux-gnueabihf-debug.tar.gz" debug binaries on my arm machine but get a "cannot execute binary file: Exec format error"
< jonasschnelli>
readelf -A bitcoin-tx.dbg tells me it should be executable
< jonasschnelli>
I probably doing something wrong...
< jonasschnelli>
Here is a typical connect block debug bench on the Odroid XU4 / SSD [USB3] (Cortex A15):
< jonasschnelli>
Odroid XU4 SSD via USB3 sync against random peers with 600MB dbcache maxmempool 50MB: 42 hours (2573 minutes)
< jonasschnelli>
(no assumevalid point given)
< jonasschnelli>
fricking github unicorn
<@wumpus>
github: everyone's favourite unicorn farming game
<@wumpus>
jonasschnelli: @I just tried to run the "bitcoin-0.16.99-arm-linux-gnueabihf-debug.tar.gz": that's expected, the debug files contain separate debug information for the main executables, they're not executable in themselves
< jonasschnelli>
wumpus: Then I guess I need to run the split-debug.sh script
< fanquake>
wumpus need to swap unicorns for black holes
<@wumpus>
fanquake: yess
<@wumpus>
jonasschnelli: if you wnt to debug something, gdb can cope with external debug symbols, but yes another option is to re-merge the debug information into the executable
< jonasschnelli>
wumpus: I want to time profile the binary... I cross compile armv7 with -O2 -g not via depends. But callgrind is extremly (too) slow
< jonasschnelli>
*cross compiled*
<@wumpus>
ok
< jonasschnelli>
any time profiling recommendation?
< jonasschnelli>
(currently trying to compile "perf")
<@wumpus>
perf! (@eklitzke)
<@wumpus>
IIRC perf is a sampling profiler instead of an instrumenting one so it has less effect on runtime speed
< jonasschnelli>
yes. that is what I want... it just don't come out-of-the box for Odroid XU4
<@wumpus>
what rootfs do you use?
< jonasschnelli>
I'm currently using the SD card they provide
< jonasschnelli>
some ubuntu derivate
<@wumpus>
ah right, perf is part of the kernel tools, at least on ubuntu it matches the kernel version (linux-tools-x.y.z)
< bitcoin-git>
bitcoin/master b95f9a6 practicalswift: tests: Remove compatibility code not needed now when we're on Python 3
< bitcoin-git>
bitcoin/master 0d69921 Wladimir J. van der Laan: Merge #12993: tests: Remove compatibility code not needed now when we're on Python 3...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12993: tests: Remove compatibility code not needed now when we're on Python 3 (master...remove-python-2-compatibility-code) https://github.com/bitcoin/bitcoin/pull/12993
< sdaftuar>
wumpus: #11739 could benefit from concentrated review, it's collected ACKs over several months but due to rebase and nit-fixes, there's only one ACK on the current commit. would this be a reasonable PR to tag "high priority for review"?
< jnewbery>
sdaftuar: +1. It'd be good to get that one merged. I also plan to rebase #12360 on it (they conflict so there's no point in rebasing mine until yours gets in)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #12997: [doc] build-windows: Switch to Artful, since Zesty is EOL (master...Mf1804-docBuildWinArtful) https://github.com/bitcoin/bitcoin/pull/12997
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #12998: Default to defining endian-conversion DECLs in compat w/o config (master...2018-04-default-decls) https://github.com/bitcoin/bitcoin/pull/12998
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #12999: qt: Show the Window when double clicking the taskbar icon (master...qt-fix) https://github.com/bitcoin/bitcoin/pull/12999
< jamesob>
the only reason ActivateBestChain is split up into steps is to reduce cs_main contention, right?