< fanquake>
Can someone add zeromq 4.2.2 & 4.2.3 to /depends-sources on bitcoincore.org
< spence>
I have a noob-ish question. How does the code determine the buffer size when reading the blocks, like in reindexing? I'm playing around with adding my own custom data structure to blocks, and I'm getting an ioerror "read attempted past buffer limit".
< sipa>
?
< spence>
sipa is that in response to me?
< meshcollider>
spence: I would imagine so :) adding custom data structure to blocks sounds like ##altcoin-dev rather than this channel I think?
< Varunram>
meshcollider: he quit :/
< meshcollider>
Heh oh well
< viru>
hi
< meshcollider>
viru: hi
< echeveria>
wish list: getmempoolinfo should show the size of the extra transactions pool.
< wumpus>
what is the 'extra transaction pool'?
< echeveria>
the compact blocks rejected transaction cache.
< wumpus>
oh that, yes was confused with the mempool relationship, but sure you could add the size of that structure on some RPC
< gmaxwell>
echeveria: patches welcome, that would be a oneline change.
< wumpus>
maybe three lines; would need to add a function to net_processing.cpp to query it from outside, too. But yeah definitely a good first PR.
< wumpus>
zelest: great to hear that the second try worked :)
< luke-jr>
will zelest become our new OpenBSD support dev? :P
< Lauda>
uh oh, that would be nice
< zelest>
Haha, if I only knew enough about coding :P
< zelest>
However, I'll do my best :) OpenBSD does have some nice malloc features.. which basically make it a rather unpleasant OS for poorly written software..
< zelest>
So it's nice to find bugs with :)
< bitcoin-git>
[bitcoin] laanwj opened pull request #11984: doc: Update OpenBSD build instructions for 6.2 (master...2017_12_openbsd_build_update) https://github.com/bitcoin/bitcoin/pull/11984
< jouke>
It's not that uncommom to wait for a block for more than an hour.
< provoostenator>
loucs_: #bitcoin is more appropriate for these questions.
< provoostenator>
I mean locus_
< wumpus>
Last block was 500527, on Fri Dec 22 11:41:18 2017
< wumpus>
well if it was bitcoin core he's running and it's stuck for 12 hours that might be a bug report, but he's already left
< meshcollider>
where should the actual code to register args for each module go do you think
< meshcollider>
the RPC stuff has a separate rpc/register.h header for the registration functions, and then the functions are spread over multiple files
< zelest>
When downloading and synking the full blockchain, is it the bandwidth that's the bottleneck or is it computationally heavy to validate it all?
< meshcollider>
but using a struct to hold the globals for the args for each module was suggested right? So where would be the best place for each struct and the corresponding registration code
< zelest>
syncing*
< meshcollider>
zelest: computationally heavy, verifying the signatures
< zelest>
Ah, gotcha :)
< wumpus>
meshcollider: in an init function per module, I guess
< wumpus>
meshcollider: same as how the RPC registration works
< meshcollider>
wumpus: I imagine all registration should happen during init and then call parseparameters, but how does that interact with -help, because -help should be checked before init proceeds further right?
< meshcollider>
so really -help needs to be checked before the registration of args and thus before parseparameters?
< wumpus>
meshcollider: I guess the registration needs to happen before -help handling
< meshcollider>
wumpus: alright, seemed a little unnatural to me to put arg registration for everything even before that, but I guess it makes sense
< wumpus>
meshcollider: that is kind of annoying, but no way around it, as -help is an argument itself *and* it needs access to all the registered other arguments
< wumpus>
yes it seems kind of unnatural, but the alternative would be to make -help handling special, in that it separately calls the registration functions, I don't think that's better
< meshcollider>
wumpus: no, I agree
< meshcollider>
wumpus: So when you refer to "modules", do you mean like bitcoind, wallet, bitcoin-cli, bitcoin-qt and bitcoin-tx?
< meshcollider>
wumpus: or more like wallet stuff, blockchain stuff, meta stuff like help/debug, etc.
< meshcollider>
in terms of dividing up the structs of globals
< wumpus>
meshcollider: I mean separate implementation units
< wumpus>
meshcollider: yes, the second
< wumpus>
the idea is keep the options as close to the code that uses them as possible
< wumpus>
this allows for localized changes, without generating merge hotspots
< meshcollider>
wumpus: does a new directory for arg files, which contains one for each "type" of args along with the function to register it all make sense?
< meshcollider>
a bit like the rpc/ dir with register.h header
< wumpus>
no, definitely not
< wumpus>
you don't want to group the args together
< wumpus>
you want to group the args with the code that uses them
< meshcollider>
ah I see, hmm
< wumpus>
creating a directory 'arg' would be like creating a directory 'types' which contains all types. It's not a useful semantic grouping :)
< meshcollider>
wumpus: true haha
< meshcollider>
I feel like this is going to be quite messy to decide where each arg goes though and what groupings make sense
< meshcollider>
especially if certain args are used in multiple places
< wumpus>
I agree it's a bit funny in the rpc case, why would rpcblockchain be under rpc and not under 'block chain functionality' but beh
< wumpus>
grouping things is hard
< wumpus>
meshcollider: yes...
< meshcollider>
wumpus: and also, I have not thought much yet about how to replace SoftSetArg and ForceSetArg, the former being difficult to tell if a value has been set or not using just a pointer to a variable
< meshcollider>
ForceSetArg should be ok I think
< wumpus>
yes, this is quite an annoying project in that regard, having handle so many concerns at the same time
< meshcollider>
mhm its a little overwhelming compared to what I have worked on up to this point :) good experience though
< ryanofsky>
meshcollider, there should be no need for arg registration init functions in typical case. just declaring an arg could add it to global list of args as in https://gflags.github.io/gflags/#define
< ryanofsky>
maybe you should describe what the proposed interface for registering and accessing args somewhere, before going to refactor all the code
< meshcollider>
I was thinking to have a function like gArgs.RegisterArg("-foo", {"-foo", "does something", ARG_BOOL, &foo, false});
< meshcollider>
Where second parameter is an enum with the info needed
< meshcollider>
Then ParseParameters is called as normal which populate all the variables, and then those variables can be used directly without needing gArgs anymore?
< ryanofsky>
meshcollider, that seems ok, but it is a little more verbose compared to gflags where you can just declare a global variable anywhere you want and don't need to write manual init code
< ryanofsky>
also unclear why "-foo" option name needs to be repeated twice and why ARG_BOOL couldn't be derived from the type of &foo