< dongcarl>
Is there naming convention for function parameters? I'm seeing snake_case and CamelCase both
< sipa>
dongcarl: developer_notes.md
< sipa>
those are variables, so snake case
< dongcarl>
sipa: ah okay, didn't know if there was differentiation in terms of convention for parameters vs. other variables since I saw inconsistencies
< sipa>
ah, no
< sipa>
parameters are just local variables in the scope of the callee
< dongcarl>
right right
< dongcarl>
and it would be snake case even in the case of method declarations I would assume
< dongcarl>
Any way to have `test/lint/commit-script-check.sh` only run on one commit? Even when I specify the particular commit it seems to want to run through everything...
< bitcoin-git>
[bitcoin] murrayn opened pull request #14617: FreeBSD: Document Python 3 requirement for 'gmake check' (master...freebsd-test-doc) https://github.com/bitcoin/bitcoin/pull/14617
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14618: rpc: Make HTTP RPC debug logging more informative (master...limit-rpc-request-logging) https://github.com/bitcoin/bitcoin/pull/14618
< bitcoin-git>
[bitcoin] merland opened pull request #14619: tests: Fix value display name in test_runner help text (master...test-runner-fix) https://github.com/bitcoin/bitcoin/pull/14619
< wumpus>
dongcarl: right, if there is confusion about that, might want to add to the developr guide that the variable convention should be used for function arguments
< wumpus>
it's obvious in retrospect maybe but maaybe not to new developers
< wumpus>
dongcarl: as for commit-script-check.sh, yes, afaik you can pass it a commit id on the command line?
< esotericnonsense>
am I correct in thinking that the CRPCCommand arrays form the complete set of POST rpc commands?
< esotericnonsense>
(i'm writing a proxy for RPC, and I want to go through all of them and whitelist things I think are safe, basically)
< wumpus>
esotericnonsense: yes, I'm fairly sure that is the case, even meta-commands of the RPC server such as help should be in one
< esotericnonsense>
yep. I like "echo". :P
< esotericnonsense>
well, I have a working rust bitcoin-cli. it's not bitcoin-cli, bitcoin-cli has all sorts of edge cases i can't be bothered to emulate because there's ~0 chance of getting a rust binary in the repo anyway.
< wumpus>
indeed, it can be surprsingly useful
< esotericnonsense>
not really much to it I guess but i'm hoping to have a working Thing this/next week so will put it up as part of that, then.
< wumpus>
you're working on rust? why aren't you in #rust-bitcoin
< luke-jr>
do we have a way to test non-HD wallet code paths at this point? :/
< sipa>
i'm confused why github doesn
< sipa>
i'm confused why github doesn't mark #14477 as non-mergable now, since it also adds the "solvable" field
< sipa>
but i need to extend the tests and address some nits first
< instagibbs>
ok ping me when ready for additional review
< esotericnonsense>
ooh. `waitforblockheight` is cool.
< esotericnonsense>
is there a sort of 'overriding RPC timeout' anywhere or is it only limited by holding an rpc thread
< * esotericnonsense>
is going to get distracted by reading this list of RPCs and get nothing done. whee
< bitcoin-git>
[bitcoin] promag closed pull request #14303: rpc: Early call once CWallet::MarkDirty in import calls (master...2018-09-wallet-mark-dirty) https://github.com/bitcoin/bitcoin/pull/14303
< sipa>
i just went through all PRs that were touched in the last week, and found 10 that have a (presumably) spurious AppVeyor failure, and restarted those
< instagibbs>
looks like we ratcheted boost to 1.60 with boost::relative?
< dongcarl>
wumpus: even when I provide a commit-id to `test/lint/commit-script-check.sh` on the command line, it goes thru everything... Not sure what the expected behavior is? Is this correct or no?