< eklitzke>
i don't quite get it, so when you call resize() on a prevector, if it grows the vector it calls operator new in a loop for the full new capacity?
< cfields>
eklitzke: I assume it mallocs what's needed, then calls placement-new for each element
< sipa>
eklitzke: those are just placement news, they don't allocate
< eklitzke>
ah
< cfields>
if that's the case and where it's spending its time, we could short-circuit that for the unsigned char case.
< sipa>
eklitzke: it's filling the new space with objects (which should be trivial in the case the type is unsigned char)
< sipa>
cfields: ack
< sipa>
didn't you have a branch to do that?
< cfields>
sipa: i did at one point, but I believe the main slow-down was in the dtor, which was fixed. so I didn't go any further with it
< cfields>
eklitzke: grep for is_trivially_destructible. We could do the same for the ctor and is_trivially_default_constructible.
< cfields>
(though it should be possible to skip the runtime check entirely with SFINAE)
< eklitzke>
wait does this actually do the is_trivially_destructible check at runtime?
< eklitzke>
yeah
< eklitzke>
that's where i was going to go
< sipa>
eklitzke: a smart compiler will do it at compile time
< cfields>
eklitzke: hopefully the compiler optimizes it away
< cfields>
heh
< eklitzke>
right, looks strange to me though
< sipa>
it's possible to write the code in a way that forces it at compile time
< eklitzke>
yeah i'm used to doing this with std::enable_if
< eklitzke>
i'll try to make the prevector code a little faster
< cfields>
eklitzke: you may find it helpful to add resize() to the existing prevector benches
< cfields>
that'd make it trivial to demonstrate a speedup
< eklitzke>
good advice, i wouldn't have thought of that
< sipa>
also, given that the only instance of prevector today uses unsigned char, you could just unconditionally hack it in and remove that loop entirely (for the purpose of benchmarking it)
< Randolf>
I'm hoping someone can help me with this -- I tried to rebase PR #12546 down to a single commit, but it's just not showing up on GitHub, although "git log" shows me what I'm expecting to see. Is "git push -f" not synchronizing because the Travis CI build failed? Thanks in advance.
< esotericnonsense>
Randolf: you pushed to randolf:master rather than randolf:patch-3
< esotericnonsense>
Randolf: the PR is tracking patch-3, https://github.com/randolf/bitcoin looks to have the single commit on top of master I think?
< Randolf>
esotericnonsense: Oh, okay. I'll try to figure out what I've missed then. Thank you.
< Randolf>
I did use this command prior to rebase: git reset --hard origin/patch-3
< cfields>
eklitzke: something else you may be interested in benching, our utxo decompressor decompresses to a std::vector rather than a prevec, forcing an unnecessary copy into the resulting prevec.
< cfields>
(from my reading of the code, anyway)
< cfields>
though I realize you're probably just looking at blocks atm
< Randolf>
Ah, yes, I see that "git push -f" is resulting in this: + 393545d85...b787a7fc6 master -> master (forced update)
< esotericnonsense>
it sounds like you checked out master, reset it to origin/patch-3, then rebased and squashed, something like that.
< Randolf>
I'm going to try again with a "git checkout patch-3" command. (I'm still new to git.)
< Randolf>
That was it -- I missed the checkout step. It seems that I don't need to do the reset step then.
< bitcoin-git>
[bitcoin] eklitzke opened pull request #12549: Make prevector::resize() and other prevector operations much faster (master...prevector) https://github.com/bitcoin/bitcoin/pull/12549
< bitcoin-git>
bitcoin/0.16 01f931b Wladimir J. van der Laan: test: Add missing signal.h header...
< mistakenine>
hi,Is there anyone interested in a parallel block chain？a complex data structure
< mistakenine>
to see all the parallel blockchain as a whole
< wumpus>
mistakenine: not here please
< provoostenator>
CubicEarths: I know, I prefer the GUI myself. But technical people can use bitcoin.conf, so it's the less-technical users I'm trying to help here.
< wumpus>
(a "parallel chain" is an interesting self-contradiction, anyway)
< mistakenine>
yes,but i find a way to give a solution
< mistakenine>
it's a very hard problem
< CubicEarths>
provoostenator: understood.
< mistakenine>
i give a math proof，but don't know how where to discuss that
< wumpus>
mistakenine: not here at least, it has nothing to do with bitcoin core development
< bitcoin-git>
[bitcoin] tamasblummer opened pull request #12556: [Trivial] fix version typo in getpeerinfo RPC call help (master...fix_version_typo) https://github.com/bitcoin/bitcoin/pull/12556
< rabidus>
Am I the only one who gets their top-bar written in chinese when clicking "use previously used address" in 0.16.0 @ windows? Binaries was downloaded from bitcoin.org. AVG detected something and moved quarantine, but I granted permission. Screenshot: https://pasteboard.co/H9zSGvJ.png
< michagogo>
mlz: but I assume you don’t test on Vista
< michagogo>
rabidus: o_O
< michagogo>
I’ll check…
< mlz>
michagogo, oh.. no, I do have a Vista, it doesn't have enough space for bitcoin :D
< michagogo>
Seriously?
< michagogo>
Why?
< rabidus>
ok, AVG now says that the file is ok, so I assume that was because because of too fresh binaries :). Still that chinese top-bar is confusing
< bitcoin-git>
bitcoin/master d16bfaa Tamas Blummer: fix version typo
< bitcoin-git>
bitcoin/master 9e2ed25 Wladimir J. van der Laan: Merge #12556: [Trivial] fix version typo in getpeerinfo RPC call help...
< bitcoin-git>
[bitcoin] laanwj closed pull request #12556: [Trivial] fix version typo in getpeerinfo RPC call help (master...fix_version_typo) https://github.com/bitcoin/bitcoin/pull/12556
< wumpus>
michagogo: nah, IMO the only thing to warrant a 0.16.0.1 release is a crash bug
< luke-jr>
0.16.0 crashes if I overclock my CPU by 50%. hjelp! :p
< wumpus>
I get bit flips on one of my nodes even without overclocking, caused quite a panic this morning when it resulted in the node splitting from consensus
< provoostenator>
So I've been studying how the QT send screen composes a transaction. It all seems to revolve around WalletModelTransaction.
< wumpus>
yes, walletmodeltransaction is the GUI-side model for a transaction to be sent
< provoostenator>
The way it works now is that an initial WalletModelTransaction is created, but several aspects of the transaciton are "stored" in the UI itself. E.g. there's a UI element that holds the list of destinations. Only when you hit Send is all that information collected and added to the WalletModelTransaciton instance.
< wumpus>
yes, don't forget about the static coincontrol instance :(
< provoostenator>
So I'm thinking about seperating the model from the view a bit better, so that any time you add / change a destination the WalletModelTransaction instance is updated and that's the source of truth.
< provoostenator>
Which would be very nice for RBF: just give it a transaction hex, deserialize it and then render the UI.
< wumpus>
that was really a bad design choice, but it was never cleaned up after the initial coin control contribution
< provoostenator>
Yeah I've been digging through historical commits to see how this came to be :-)
< wumpus>
yes, that'd probably be better
< provoostenator>
But I wonder about the RPC. Wouldn't it benefit from some mechanism to build up a transaction in a modular way as well? So rather than needing to create a tranaction in one giant RPC command, you'd create a draft and manipulate that through smaller commands.
< provoostenator>
And if that's the case, maybe this should all be moved one level deeper (and not depend on QT).
< wumpus>
that's what the raw transactions API does
< wumpus>
createrawtransaction, fundrawtransaction, signrwatransactions are the RPC equivalent of building up a transaction step by step
< wumpus>
but intentionally entirely stateless
< wumpus>
please do keep that code in qt, the reason for having a UI-specific structure there is to make it easier to split off the GUI some day
< provoostenator>
Would it make sense to make CMutableTransaction more powerful though? Why wouldn't QT be able to include that?
< wumpus>
if things are only necessary for the UI, it's better to keep the code in the UI
< provoostenator>
Coin selection and replacing transaction seem useful to both RPC and UI to me.
< wumpus>
RPC has that, in other ways
< wumpus>
I think you're extending the scope of what you want to do too much
< provoostenator>
I don't know, I'm trying to figure out what's the best approach here. My own scope was to improve RBF in QT, prefereably without reinventing the wheel.
< provoostenator>
If that makes the RPC better that's nice, but not my goal.
< wumpus>
if you want to improve the UI, then improving th UI is what to do, if you start refactoring all over the place it's much harder to move forward
< provoostenator>
I agree that a huge refactor is a bad idea regardless.
< wumpus>
refactor of the UI would be ok, but combining it with changing CMutableTransaction etc is just too much
< provoostenator>
Actually I'm not sure if UI is my only concern here. I like the idea of keeping QT relatively simple and making it possible to build a UI on top of RPC (using whatever framework).
< provoostenator>
But I agree that changing both at this point would involve too many moving parts.
< wumpus>
I'm fairly sure it's possible to build this UI on top of listunspent and *rawtransaction API
< provoostenator>
The above is a fairly complicated way to achieve RBF, but has the advatage of letting UI users tweak the new transaction anyway they want.
< provoostenator>
A simpler approach would be improve the bumpfee RPC stuff and then create a UI where the user can merely change the fee, nothing else.
< provoostenator>
(by "the above" I mean moving some stuff from the view code into WalletModelTransaction, I don't mean changing CMutableTransaction)
< michagogo>
wumpus: I think I actually saw the commit that introduced the en_us translation
< michagogo>
It was 5109347, which added a whole lot of translations
< michagogo>
I remember I saw that and idly wondered what was going on there
< michagogo>
And forgot to follow up on that thought
< michagogo>
For example, I haven’t looked at the content, but I saw that it added a he_IL translation in addition to the existing he?
< michagogo>
As far as I know there isn’t really a Hebrew besides he_IL
< michagogo>
I also don’t really know how the translation stuff works
< wumpus>
well it synced the transifex translations with the ones in the repository
< michagogo>
That commit seems to introduce a bunch of new languages, but also a whole lot of new files with country codes where previously there was just the country-less language
< michagogo>
Can anyone on transifex just create a new language?
< wumpus>
well, if translations need to be deleted they need to be deleted from transifex first,t hen from the repository, that prevents them from coming back
< wumpus>
no, they have to be approved
< wumpus>
though the policy seems to be that everything is approved
< michagogo>
And within the release cycle all those new ones went in?
< wumpus>
it's hard to think of a valid reason to reject someone adding a translation for someone's language/country
< wumpus>
though adding en_US was stupid :)
< michagogo>
I suspect it might be a good idea to go over and do a sanity check of the languages that added a new single country code where previously there was just a bare language
< michagogo>
For example, adding he_IL when he exists seems vaguely suspicious to me
< michagogo>
Another example, de_DE was added when de exists, and no other de_XX versions
< michagogo>
I would expect that bare de would be German German
< michagogo>
If the new file were de_CH or something it would make sense, but…
< bitcoin-git>
[bitcoin] promag opened pull request #12559: Avoid locking cs_main in some wallet RPC (master...2018-02-avoid-cs_main-lock) https://github.com/bitcoin/bitcoin/pull/12559
< wumpus>
michagogo: I agree, but I don't have enough international lingual knowledge to make decisions about such things, if you find specific ones that make no sense, please report them
< wumpus>
this has happened in the past, that a transifex translator reported that a certain language/locale pair makes no sense and it was removed
< michagogo>
Yeah, I guess
< michagogo>
It’s things like this that make me really wish I had free time to do stuff like go and look at he vs he_IL
< wumpus>
but in the absence of specific information I tend to err on the side of allowing it
< michagogo>
I’m on my phone on the bus, so I didn’t look into the content, but I see the new he_IL is much, much shorter than the existing he
< michagogo>
Does Qt have a fallback thing, where if you’re set to xx_YY and a string is missing, it will use the translation for bare xx?
< michagogo>
Or is each translation completely independent?
< wumpus>
shortness doesn't matter, it will just override the general one for the messages that are specified
< michagogo>
Okay, good - at least there’s that
< wumpus>
e.g. fallback order would be he_IL -> he -> en/original
< michagogo>
Okay, that’s good at least
< luke-jr>
michagogo: wumpus: I did a sanity check a few months ago, and made a todo list
< luke-jr>
but it's probably not updated anymore
< luke-jr>
and I have no clue where I saved it :x
< michagogo>
But I still doubt there’s anything that belongs in he_IL that shouldn’t just be in he
< luke-jr>
someone should probably just do the obvious ones (eg, if there's no he, rename he_IL to it)
< luke-jr>
and then contact people in non-obvious cases
< wumpus>
wanted: localization maintainer
< michagogo>
There’s a Hebrew with >80% coverage, and a Hebrew (Israel) with <3%
< luke-jr>
that sounds about right?
< michagogo>
Well, that’s not really a division that makes sense AFAIK
< luke-jr>
the Israel one would presumably just have strings that differ from the "standard" Hebrew
< luke-jr>
oh
< wumpus>
right.
< luke-jr>
disclaimer: I know nothing about the Hebrew language or its variations :P
< michagogo>
Actually, the Windows 10 setup process asks you that at some point
< michagogo>
When you choose a keyboard layout
< michagogo>
I have no clue what the difference is…
< esotericnonsense>
i think I submitted a translation for en_GB vs en_US at some point
< esotericnonsense>
and then realised that someone who actually cares about the distinction should do it
< esotericnonsense>
what's the default en? !?!?!?!?! </trollface>
< wumpus>
US is the default
< wumpus>
that's why it was wrong for a separate en_US translation to exist
< wumpus>
en_UK would be a possible addition
< esotericnonsense>
there is an en_GB
< esotericnonsense>
or at least there was
< wumpus>
ehh yes, GB
< wumpus>
Great Britain instead of United Kingdom, I guess a distinction like Holland versus The Netherlands
< michagogo>
I don’t know about the latter
< michagogo>
But it’s the United Kingdom of Great Britain and Northern Ireland
< esotericnonsense>
in this context it doesn't make a difference because there's no 'locality' to the fact we spell a few words slightly differently other than 'generally on that island'
< wumpus>
strictly, Holland is a part of the Netherlands, Zuid and Noord Holland, but everyone uses them interchangably in practice
< michagogo>
So UK would make more sense than GB, but that’s not what the standards organizations decided
< esotericnonsense>
do norwegians learn 'color' or 'colour'? :D
< esotericnonsense>
i feel like i'm bikeshedding a thing that no-one actually cares about, but the idea of inheriting feels a bit odd to me
< michagogo>
Hm, why is en_US the default and not bare en?
< michagogo>
Oh, I guess if something isn’t defined in en then it’ll fall through to en_US
< wumpus>
esotericnonsense: it's simply how localization tends to work, so there's no use bikeshedding that here
< michagogo>
But why have bare en at all?
< esotericnonsense>
heh. some dialogs with 'colour' and some with 'color'. *shudders*
< wumpus>
bare en is the source language
< * esotericnonsense>
wanders off to do something useful
< wumpus>
it cannot be edited on transifex
< michagogo>
Uh
< michagogo>
Is source different from default
< michagogo>
?
< wumpus>
it's the language that the messages in the source code are in
< michagogo>
Right, makes sense
< michagogo>
But why have the default be en_US, and not just not use a translation by default?
< michagogo>
Oh, wait
< michagogo>
That’s what we do, since we deleted en_US
< michagogo>
Never mind.
< wumpus>
right, 'en' is not really a translation in our case, it only contains messages to be translated, no translations. There is no strict requirement that American English is the source language, it just happens to be the case for our project (and for many other projects).
< luke-jr>
wumpus: American English is? I thought standard English was, and that's why we have an en_US translation? :x
< wumpus>
no, we don't have an en_US translation, that was a mistake
< wumpus>
it was accidentally added for 0.16
< wumpus>
and removed again, now
< wumpus>
the messages in the source code are American English (minimize, synchronize, etc), and that's what defines the source language
< wumpus>
en_GB would be 'standard English'
< bitcoin-git>
[bitcoin] bedri opened pull request #12562: Utils and libraries: Leveldb compile warnings (master...leveldbCompileWarnings) https://github.com/bitcoin/bitcoin/pull/12562
< eklitzke>
i'm going to show my github ignorance here, but when a pull request gets merged, is the first comment on the PR (the one created by the PR author) what ends up in the git logs for the merge commit?
< achow101>
eklitzke: we have our own github merging script that does that
< eklitzke>
ok i think i understand, the right side of the merge has the original commits with their descriptions intact, and the merge commit itself is autogenerated with the pull request title, first comment description, and a signature
< sipa>
correct
< CubicEarths>
Why does the client seem to only download blocks a certain distance ahead of what the CPU has processed?
< sipa>
CubicEarths: to not interfere too much with pruning
< sipa>
(if the blocks are too much out of order on disk, you need to wait very long before a file which can contain a block of blocks from everywhere can be deleted)
< CubicEarths>
I don't understand... I can see reasons related to being a good citizen on the network, but you are saying it has to do with my own node's syncing performance?
< sipa>
if you enable pruning, you delete block files which only have old blocks in them
< sipa>
this is not possible if every block files contains blocks from all over the place
< CubicEarths>
ahh
< sipa>
by not letting downloading getting ahead too far of validation (1024 blocks ahead max), we guarantee that after 1024 blocks, you're always able to delete the old files with blocks before that point (plus some overhead blocks, i think 288, to not interfere with reorgs)
< sipa>
it doesn't really matter if you don't prune and don't plan to ever do so
< CubicEarths>
yeah
< sipa>
but it also doesn't hurt you much to restrict yourself to 1024 blocks ahead
< CubicEarths>
well, sometimes you are near great internet, and it would be nice to be able to download blocks as fast as possible, and allow the processing to happen later
< CubicEarths>
I am surprised that blocks are not put in blockfiles according to the block number
< CubicEarths>
But it sounds like the files are just filled up sequentially with blocks as the come in?
< aj>
CubicEarths: if you had blocks 1000-2000 in a single file, then had hundreds of reorgs in that range, that particular file could grow absurdly large; likewise if all those blocks were empty, you'd end up with unnecessarily small files