1 2018-02-27 00:35:21	0|bitcoin-git|[13bitcoin] 15denis2342 closed pull request #12541: streamlined the use of include_hex (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12541
  2 2018-02-27 00:43:19	0|eklitzke|31% of the time in ReadBlockFromDisk() is spent in prevector::resize
  3 2018-02-27 00:43:22	0|eklitzke|smh
  4 2018-02-27 00:44:22	0|eklitzke|actually that's just one of the code paths, altogether it's 37% if you count the other code paths
  5 2018-02-27 00:45:43	0|sipa|that's remarkable
  6 2018-02-27 00:45:51	0|sipa|oh, scriptSigs
  7 2018-02-27 00:46:31	0|sipa|(for scriptPubKeys, prevector should almost never need an allocation)
  8 2018-02-27 00:46:41	0|eklitzke|https://monad.io/readblockfromdisk.svg
  9 2018-02-27 00:48:04	0|sipa|\o/ flame diagram
 10 2018-02-27 00:50:05	0|sipa|and 44% in sse4_transform
 11 2018-02-27 00:50:40	0|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?
 12 2018-02-27 00:51:47	0|cfields|eklitzke: I assume it mallocs what's needed, then calls placement-new for each element
 13 2018-02-27 00:51:58	0|sipa|eklitzke: those are just placement news, they don't allocate
 14 2018-02-27 00:52:03	0|eklitzke|ah
 15 2018-02-27 00:52:15	0|cfields|if that's the case and where it's spending its time, we could short-circuit that for the unsigned char case.
 16 2018-02-27 00:52:26	0|sipa|eklitzke: it's filling the new space with objects (which should be trivial in the case the type is unsigned char)
 17 2018-02-27 00:52:37	0|sipa|cfields: ack
 18 2018-02-27 00:52:42	0|sipa|didn't you have a branch to do that?
 19 2018-02-27 00:53:24	0|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
 20 2018-02-27 00:54:39	0|cfields|eklitzke: grep for is_trivially_destructible. We could do the same for the ctor and is_trivially_default_constructible.
 21 2018-02-27 00:56:11	0|cfields|(though it should be possible to skip the runtime check entirely with SFINAE)
 22 2018-02-27 00:56:42	0|eklitzke|wait does this actually do the is_trivially_destructible check at runtime?
 23 2018-02-27 00:56:45	0|eklitzke|yeah
 24 2018-02-27 00:56:48	0|eklitzke|that's where i was going to go
 25 2018-02-27 00:57:05	0|sipa|eklitzke: a smart compiler will do it at compile time
 26 2018-02-27 00:57:11	0|cfields|eklitzke: hopefully the compiler optimizes it away
 27 2018-02-27 00:57:11	0|cfields|heh
 28 2018-02-27 00:57:19	0|eklitzke|right, looks strange to me though
 29 2018-02-27 00:57:25	0|sipa|it's possible to write the code in a way that forces it at compile time
 30 2018-02-27 00:57:34	0|eklitzke|yeah i'm used to doing this with std::enable_if
 31 2018-02-27 00:57:46	0|eklitzke|i'll try to make the prevector code a little faster
 32 2018-02-27 01:03:30	0|cfields|eklitzke: you may find it helpful to add resize() to the existing prevector benches
 33 2018-02-27 01:03:38	0|cfields|that'd make it trivial to demonstrate a speedup
 34 2018-02-27 01:03:59	0|eklitzke|good advice, i wouldn't have thought of that
 35 2018-02-27 01:05:28	0|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)
 36 2018-02-27 01:25:50	0|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.
 37 2018-02-27 01:25:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/12546 | [docs] Minor improvements to Compatibility notes by randolf · Pull Request #12546 · bitcoin/bitcoin · GitHub
 38 2018-02-27 01:27:22	0|esotericnonsense|Randolf: you pushed to randolf:master rather than randolf:patch-3
 39 2018-02-27 01:27:51	0|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?
 40 2018-02-27 01:31:26	0|Randolf|esotericnonsense:  Oh, okay.  I'll try to figure out what I've missed then.  Thank you.
 41 2018-02-27 01:31:44	0|Randolf|I did use this command prior to rebase:  git reset --hard origin/patch-3
 42 2018-02-27 01:31:51	0|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.
 43 2018-02-27 01:31:57	0|cfields|(from my reading of the code, anyway)
 44 2018-02-27 01:32:21	0|cfields|though I realize you're probably just looking at blocks atm
 45 2018-02-27 01:33:10	0|Randolf|Ah, yes, I see that "git push -f" is resulting in this:   + 393545d85...b787a7fc6 master -> master (forced update)
 46 2018-02-27 01:39:20	0|esotericnonsense|it sounds like you checked out master, reset it to origin/patch-3, then rebased and squashed, something like that.
 47 2018-02-27 01:41:43	0|Randolf|I'm going to try again with a "git checkout patch-3" command.  (I'm still new to git.)
 48 2018-02-27 01:43:28	0|Randolf|That was it -- I missed the checkout step.  It seems that I don't need to do the reset step then.
 49 2018-02-27 04:16:56	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #12549: Make prevector::resize() and other prevector operations much faster (06master...06prevector) 02https://github.com/bitcoin/bitcoin/pull/12549
 50 2018-02-27 04:25:07	0|sipa|eklitzke: nice!
 51 2018-02-27 04:28:02	0|bitcoin-git|[13bitcoin] 15bedri opened pull request #12550: Utils and libraries: Leveldb warning fixes (060.16...06leveldbWarningFixes) 02https://github.com/bitcoin/bitcoin/pull/12550
 52 2018-02-27 04:35:21	0|eklitzke|hmm, what version of gcc/libstdc++ does travis use?
 53 2018-02-27 04:35:39	0|sipa|gcc 4.8 i believe
 54 2018-02-27 04:38:38	0|bitcoin-git|[13bitcoin] 15bedri closed pull request #12550: Utils and libraries: Leveldb warning fixes (060.16...06leveldbWarningFixes) 02https://github.com/bitcoin/bitcoin/pull/12550
 55 2018-02-27 04:44:13	0|bitcoin-git|[13bitcoin] 15bedri opened pull request #12551: Leveldb warning fixes (06master...06leveldbWarningFixes) 02https://github.com/bitcoin/bitcoin/pull/12551
 56 2018-02-27 05:23:58	0|esotericnonsense|hm.
 57 2018-02-27 06:28:04	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12551: Utils and libraries: Leveldb warning fixes (06master...06leveldbWarningFixes) 02https://github.com/bitcoin/bitcoin/pull/12551
 58 2018-02-27 06:37:43	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #12553: Prefer wait_until over polling with time.sleep (06master...06wait-until) 02https://github.com/bitcoin/bitcoin/pull/12553
 59 2018-02-27 08:06:28	0|bitcoin-git|[13bitcoin] 15multibhw opened pull request #12555: Tweet  RUN TIME (06master...06TWEET) 02https://github.com/bitcoin/bitcoin/pull/12555
 60 2018-02-27 08:07:31	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12555: Tweet  RUN TIME (06master...06TWEET) 02https://github.com/bitcoin/bitcoin/pull/12555
 61 2018-02-27 08:29:32	0|hkjn0|eklitzke: cool flame graph! mind sharing how you produced it?
 62 2018-02-27 09:05:51	0|mistakenine|hi,Is there anyone interested in a parallel block chain？a complex data structure
 63 2018-02-27 09:49:54	0|bitcoin-git|13bitcoin/060.16 145d41110 15Wladimir J. van der Laan: doc: Clear out release notes post-0.16.0...
 64 2018-02-27 09:49:54	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.16: 02https://github.com/bitcoin/bitcoin/commit/5d41110c745c74e1eeb85f187f54777bf5e6407f
 65 2018-02-27 09:50:16	0|bitcoin-git|13bitcoin/060.16 1401f931b 15Wladimir J. van der Laan: test: Add missing signal.h header...
 66 2018-02-27 09:50:16	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.16: 02https://github.com/bitcoin/bitcoin/commit/01f931b928fbe0266b3a8d48d0fb2ecc728bd7f3
 67 2018-02-27 09:55:05	0|mistakenine|hi,Is there anyone interested in a parallel block chain？a complex data structure
 68 2018-02-27 09:56:01	0|mistakenine|to see all the parallel blockchain as a whole
 69 2018-02-27 09:56:35	0|wumpus|mistakenine: not here please
 70 2018-02-27 09:56:57	0|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.
 71 2018-02-27 09:57:44	0|wumpus|(a "parallel chain" is an interesting self-contradiction, anyway)
 72 2018-02-27 09:58:32	0|mistakenine|yes,but i find a way to give a solution
 73 2018-02-27 09:58:47	0|mistakenine|it's a very hard problem
 74 2018-02-27 09:59:41	0|CubicEarths|provoostenator: understood.
 75 2018-02-27 09:59:50	0|mistakenine|i give a math proof，but don't know how where to discuss that
 76 2018-02-27 10:00:06	0|wumpus|mistakenine: not here at least, it has nothing to do with bitcoin core development
 77 2018-02-27 10:47:35	0|bitcoin-git|[13bitcoin] 15tamasblummer opened pull request #12556: [Trivial] fix version typo in getpeerinfo RPC call help (06master...06fix_version_typo) 02https://github.com/bitcoin/bitcoin/pull/12556
 78 2018-02-27 11:33:23	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #12557: [WIP] [depends] openssl: add aarch64_darwin (06master...062018/02/depends-openssl-aarch64-apple-darwin1) 02https://github.com/bitcoin/bitcoin/pull/12557
 79 2018-02-27 12:37:27	0|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
 80 2018-02-27 12:48:18	0|michagogo|mlz: but I assume you don’t test on Vista
 81 2018-02-27 12:48:49	0|michagogo|rabidus: o_O
 82 2018-02-27 12:48:55	0|michagogo|I’ll check…
 83 2018-02-27 12:49:12	0|mlz|michagogo, oh.. no, I do have a Vista, it doesn't have enough space for bitcoin :D
 84 2018-02-27 12:49:44	0|michagogo|Seriously?
 85 2018-02-27 12:49:48	0|michagogo|Why?
 86 2018-02-27 12:50:31	0|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
 87 2018-02-27 12:55:08	0|ken2812221|https://github.com/bitcoin/bitcoin/blob/0.16/src/qt/locale/bitcoin_en_US.ts
 88 2018-02-27 12:55:42	0|rabidus|seems "ok" then :)
 89 2018-02-27 13:00:50	0|michagogo|ken2812221: …
 90 2018-02-27 13:00:53	0|michagogo|oops.
 91 2018-02-27 13:01:03	0|rabidus|at least I'm not running any chinese binaries .. probably
 92 2018-02-27 13:01:56	0|mlz|rabidus, that's very strange, i wouldn't use it, did you verify the binaries ?
 93 2018-02-27 13:02:01	0|ken2812221|Maybe someone can fix it on Transifex
 94 2018-02-27 13:02:21	0|michagogo|mlz: look at the link ken2812221 just posted
 95 2018-02-27 13:02:26	0|michagogo|It’s in the source code
 96 2018-02-27 13:02:27	0|rabidus|no, i didn't check any hashes, but as you can see from that translation url, it's "feature" :)
 97 2018-02-27 13:02:44	0|michagogo|No, it’s definitely a bug
 98 2018-02-27 13:02:49	0|rabidus|hehe, jk
 99 2018-02-27 13:04:26	0|mlz|i see, but not verifying download files on windows is a crime :P
100 2018-02-27 13:06:03	0|Anduck|^
101 2018-02-27 13:06:11	0|michagogo|I mean, the installer _is_ signed
102 2018-02-27 13:06:16	0|rabidus|wouldn't change anything
103 2018-02-27 13:06:30	0|rabidus|top bar would still be in chinese
104 2018-02-27 13:06:32	0|rabidus|:)
105 2018-02-27 13:06:34	0|michagogo|Which shows up when it asks you to elevate
106 2018-02-27 13:08:51	0|michagogo|Oh, there’s already #12577
107 2018-02-27 13:08:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/12577 | HTTP Error 404: Not Found
108 2018-02-27 13:09:02	0|michagogo|I mean #12544
109 2018-02-27 13:09:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/12544 | Bitcoin Qt 0.16.0 displays a window title in Chinese instead of English · Issue #12544 · bitcoin/bitcoin · GitHub
110 2018-02-27 13:09:18	0|rabidus|oh, ok, nice
111 2018-02-27 13:10:18	0|bitcoin-git|[13bitcoin] 15drodil opened pull request #12558: Fix translations in en_US.ts (060.16...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/12558
112 2018-02-27 13:31:56	0|provoostenator|Somewhat related to the issue of translation review: #11875
113 2018-02-27 13:31:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/11875 | Snoei: a.k.a. how to translate technical jargon · Issue #11875 · bitcoin/bitcoin · GitHub
114 2018-02-27 13:34:00	0|TyrfingMjolnir|Anyone got 2 consequtive sample blocks?
115 2018-02-27 13:34:28	0|TyrfingMjolnir|with full schematics
116 2018-02-27 14:52:02	0|bitcoin-git|13bitcoin/060.16 14ea2e39f 15Wladimir J. van der Laan: qt: Remove faulty and unnecessary en_US translation...
117 2018-02-27 14:52:02	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.16: 02https://github.com/bitcoin/bitcoin/commit/ea2e39fd2004e83375c1703543e32a10e3b9d981
118 2018-02-27 14:52:03	0|eklitzke|hkjn0: i have a wrapper script around perf(1) here that i use to actually collect the profiling data (which requires that you have a build with debug symbols): https://github.com/eklitzke/bitcoin-tools/blob/master/perf.sh
119 2018-02-27 14:52:35	0|eklitzke|then the flame graph itself is generated using https://github.com/brendangregg/FlameGraph
120 2018-02-27 14:53:17	0|eklitzke|i have a wrapper script for invoking that as well here: https://github.com/eklitzke/bitcoin-tools/blob/master/gensvg.sh (although in practice i've found i often want to use grep to filter out more data before invoking flamegraph.pl)
121 2018-02-27 14:54:22	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12558: Fix translations in en_US.ts (060.16...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/12558
122 2018-02-27 14:57:00	0|bitcoin-git|13bitcoin/06master 14d16bfaa 15Tamas Blummer: fix version typo
123 2018-02-27 14:57:00	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/228b086b9a3d...9e2ed253f505
124 2018-02-27 14:57:01	0|bitcoin-git|13bitcoin/06master 149e2ed25 15Wladimir J. van der Laan: Merge #12556: [Trivial] fix version typo in getpeerinfo RPC call help...
125 2018-02-27 14:57:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12556: [Trivial] fix version typo in getpeerinfo RPC call help (06master...06fix_version_typo) 02https://github.com/bitcoin/bitcoin/pull/12556
126 2018-02-27 15:04:48	0|wumpus|michagogo: nah, IMO the only thing to warrant a 0.16.0.1 release is a crash bug
127 2018-02-27 15:05:52	0|luke-jr|0.16.0 crashes if I overclock my CPU by 50%. hjelp! :p
128 2018-02-27 15:15:29	0|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
129 2018-02-27 15:19:53	0|provoostenator|So I've been studying how the QT send screen composes a transaction. It all seems to revolve around WalletModelTransaction.
130 2018-02-27 15:21:29	0|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.
131 2018-02-27 15:21:29	0|wumpus|yes, walletmodeltransaction is the GUI-side model for a transaction to be sent
132 2018-02-27 15:21:53	0|wumpus|yes, don't forget about the static coincontrol instance :(
133 2018-02-27 15:22:07	0|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.
134 2018-02-27 15:22:38	0|provoostenator|Which would be very nice for RBF: just give it a transaction hex, deserialize it and then render the UI.
135 2018-02-27 15:22:41	0|wumpus|that was really a bad design choice, but it was never cleaned up after the initial coin control contribution
136 2018-02-27 15:22:59	0|provoostenator|Yeah I've been digging through historical commits to see how this came to be :-)
137 2018-02-27 15:23:02	0|wumpus|yes, that'd probably be better
138 2018-02-27 15:24:07	0|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.
139 2018-02-27 15:24:43	0|provoostenator|And if that's the case, maybe this should all be moved one level deeper (and not depend on QT).
140 2018-02-27 15:26:16	0|wumpus|that's what the raw transactions API does
141 2018-02-27 15:26:38	0|wumpus|createrawtransaction, fundrawtransaction, signrwatransactions are the RPC equivalent of building up a transaction step by step
142 2018-02-27 15:26:57	0|wumpus|but intentionally entirely stateless
143 2018-02-27 15:27:30	0|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
144 2018-02-27 15:28:23	0|provoostenator|Would it make sense to make CMutableTransaction more powerful though? Why wouldn't QT be able to include that?
145 2018-02-27 15:28:54	0|wumpus|if things are only necessary for the UI, it's better to keep the code in the UI
146 2018-02-27 15:29:22	0|provoostenator|Coin selection and replacing transaction seem useful to both RPC and UI to me.
147 2018-02-27 15:29:41	0|wumpus|RPC has that, in other ways
148 2018-02-27 15:29:48	0|wumpus|I think you're extending the scope of what you want to do too much
149 2018-02-27 15:30:29	0|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.
150 2018-02-27 15:30:43	0|provoostenator|If that makes the RPC better that's nice, but not my goal.
151 2018-02-27 15:30:44	0|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
152 2018-02-27 15:31:13	0|provoostenator|I agree that a huge refactor is a bad idea regardless.
153 2018-02-27 15:31:42	0|wumpus|refactor of the UI would be ok, but combining it with changing CMutableTransaction etc is just too much
154 2018-02-27 15:34:49	0|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).
155 2018-02-27 15:35:17	0|provoostenator|But I agree that changing both at this point would involve too many moving parts.
156 2018-02-27 15:40:06	0|wumpus|I'm fairly sure it's possible to build this UI on top of listunspent and *rawtransaction API
157 2018-02-27 15:40:38	0|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.
158 2018-02-27 15:41:02	0|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.
159 2018-02-27 15:44:18	0|provoostenator|(by "the above" I mean moving some stuff from the view code into WalletModelTransaction, I don't mean changing CMutableTransaction)
160 2018-02-27 16:16:59	0|michagogo|wumpus: I think I actually saw the commit that introduced the en_us translation
161 2018-02-27 16:17:20	0|michagogo|It was 5109347, which added a whole lot of translations
162 2018-02-27 16:17:35	0|michagogo|I remember I saw that and idly wondered what was going on there
163 2018-02-27 16:17:41	0|michagogo|And forgot to follow up on that thought
164 2018-02-27 16:18:13	0|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?
165 2018-02-27 16:18:29	0|michagogo|As far as I know there isn’t really a Hebrew besides he_IL
166 2018-02-27 16:18:46	0|michagogo|I also don’t really know how the translation stuff works
167 2018-02-27 16:19:41	0|wumpus|well it synced the transifex translations with the ones in the repository
168 2018-02-27 16:20:06	0|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
169 2018-02-27 16:20:41	0|michagogo|Can anyone on transifex just create a new language?
170 2018-02-27 16:20:43	0|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
171 2018-02-27 16:20:47	0|wumpus|no, they have to be approved
172 2018-02-27 16:20:57	0|wumpus|though the policy seems to be that everything is approved
173 2018-02-27 16:21:09	0|michagogo|And within the release cycle all those new ones went in?
174 2018-02-27 16:21:28	0|wumpus|it's hard to think of a valid reason to reject someone adding a translation for someone's language/country
175 2018-02-27 16:21:36	0|wumpus|though adding en_US was stupid :)
176 2018-02-27 16:21:59	0|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
177 2018-02-27 16:22:41	0|michagogo|For example, adding he_IL when he exists seems vaguely suspicious to me
178 2018-02-27 16:23:54	0|michagogo|Another example, de_DE was added when de exists, and no other de_XX versions
179 2018-02-27 16:24:10	0|michagogo|I would expect that bare de would be German German
180 2018-02-27 16:24:30	0|michagogo|If the new file were de_CH or something it would make sense, but…
181 2018-02-27 16:24:51	0|bitcoin-git|[13bitcoin] 15promag opened pull request #12559: Avoid locking cs_main in some wallet RPC (06master...062018-02-avoid-cs_main-lock) 02https://github.com/bitcoin/bitcoin/pull/12559
182 2018-02-27 16:32:08	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #12560: [wallet][RPC] Set or generate a new HD seed (06master...06sethdseed) 02https://github.com/bitcoin/bitcoin/pull/12560
183 2018-02-27 16:41:02	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #12561: Remove call to CheckBlock() in ConnectBlock() (06master...062018-02-improve-checkblock-failure) 02https://github.com/bitcoin/bitcoin/pull/12561
184 2018-02-27 16:43:15	0|TyrfingMjolnir|How can I create my own local block chain and generate 10 valid blocks at random for development purposes?
185 2018-02-27 16:44:01	0|Chris_Stewart_5|TyrfingMjolnir: $ bitcoind -regtest -daemon && bitcoin-cli -regtest generate 10
186 2018-02-27 16:45:13	0|TyrfingMjolnir|Perfect, thanks
187 2018-02-27 16:54:19	0|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
188 2018-02-27 16:54:50	0|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
189 2018-02-27 16:55:08	0|michagogo|Yeah, I guess
190 2018-02-27 16:55:58	0|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
191 2018-02-27 16:55:59	0|wumpus|but in the absence of specific information I tend to err on the side of allowing it
192 2018-02-27 16:58:26	0|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
193 2018-02-27 16:59:16	0|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?
194 2018-02-27 16:59:27	0|michagogo|Or is each translation completely independent?
195 2018-02-27 16:59:36	0|wumpus|shortness doesn't matter, it will just override the general one for the messages that are specified
196 2018-02-27 16:59:55	0|michagogo|Okay, good - at least there’s that
197 2018-02-27 17:00:06	0|wumpus|e.g. fallback order would be he_IL -> he -> en/original
198 2018-02-27 17:00:13	0|michagogo|Okay, that’s good at least
199 2018-02-27 17:00:20	0|luke-jr|michagogo: wumpus: I did a sanity check a few months ago, and made a todo list
200 2018-02-27 17:00:25	0|luke-jr|but it's probably not updated anymore
201 2018-02-27 17:00:51	0|luke-jr|and I have no clue where I saved it :x
202 2018-02-27 17:01:03	0|michagogo|But I still doubt there’s anything that belongs in he_IL that shouldn’t just be in he
203 2018-02-27 17:02:20	0|luke-jr|someone should probably just do the obvious ones (eg, if there's no he, rename he_IL to it)
204 2018-02-27 17:02:27	0|luke-jr|and then contact people in non-obvious cases
205 2018-02-27 17:05:43	0|wumpus|wanted: localization maintainer
206 2018-02-27 17:06:29	0|michagogo|There’s a Hebrew with >80% coverage, and a Hebrew (Israel) with <3%
207 2018-02-27 17:06:40	0|luke-jr|that sounds about right?
208 2018-02-27 17:06:56	0|michagogo|Well, that’s not really a division that makes sense AFAIK
209 2018-02-27 17:06:58	0|luke-jr|the Israel one would presumably just have strings that differ from the "standard" Hebrew
210 2018-02-27 17:07:03	0|luke-jr|oh
211 2018-02-27 17:07:04	0|wumpus|right.
212 2018-02-27 17:07:25	0|luke-jr|disclaimer: I know nothing about the Hebrew language or its variations :P
213 2018-02-27 17:07:38	0|michagogo|Actually, the Windows 10 setup process asks you that at some point
214 2018-02-27 17:07:49	0|michagogo|When you choose a keyboard layout
215 2018-02-27 17:07:58	0|michagogo|I have no clue what the difference is…
216 2018-02-27 17:09:24	0|esotericnonsense|i think I submitted a translation for en_GB vs en_US at some point
217 2018-02-27 17:09:50	0|esotericnonsense|and then realised that someone who actually cares about the distinction should do it
218 2018-02-27 17:10:04	0|esotericnonsense|what's the default en? !?!?!?!?! </trollface>
219 2018-02-27 17:10:55	0|wumpus|US is the default
220 2018-02-27 17:11:11	0|wumpus|that's why it was wrong for a separate en_US translation to exist
221 2018-02-27 17:12:34	0|wumpus|en_UK would be a possible addition
222 2018-02-27 17:12:45	0|esotericnonsense|there is an en_GB
223 2018-02-27 17:12:48	0|esotericnonsense|or at least there was
224 2018-02-27 17:13:38	0|wumpus|ehh yes, GB
225 2018-02-27 17:13:58	0|wumpus|Great Britain instead of United Kingdom, I guess a distinction like Holland versus The Netherlands
226 2018-02-27 17:14:12	0|michagogo|I don’t know about the latter
227 2018-02-27 17:14:26	0|michagogo|But it’s the United Kingdom of Great Britain and Northern Ireland
228 2018-02-27 17:14:47	0|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'
229 2018-02-27 17:14:58	0|wumpus|strictly, Holland is a part of the Netherlands, Zuid and Noord Holland, but everyone uses them interchangably in practice
230 2018-02-27 17:15:11	0|michagogo|So UK would make more sense than GB, but that’s not what the standards organizations decided
231 2018-02-27 17:15:14	0|esotericnonsense|do norwegians learn 'color' or 'colour'? :D
232 2018-02-27 17:16:18	0|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
233 2018-02-27 17:16:23	0|michagogo|Hm, why is en_US the default and not bare en?
234 2018-02-27 17:16:52	0|michagogo|Oh, I guess if something isn’t defined in en then it’ll fall through to en_US
235 2018-02-27 17:16:55	0|wumpus|esotericnonsense: it's simply how localization tends to work, so there's no use bikeshedding that here
236 2018-02-27 17:17:02	0|michagogo|But why have bare en at all?
237 2018-02-27 17:17:20	0|esotericnonsense|heh. some dialogs with 'colour' and some with 'color'. *shudders*
238 2018-02-27 17:17:23	0|wumpus|bare en is the source language
239 2018-02-27 17:17:36	0|wumpus|it cannot be edited on transifex
240 2018-02-27 17:17:42	0|michagogo|Uh
241 2018-02-27 17:17:47	0|michagogo|Is source different from default
242 2018-02-27 17:17:49	0|michagogo|?
243 2018-02-27 17:18:07	0|wumpus|it's the language that the messages in the source code are in
244 2018-02-27 17:18:13	0|michagogo|Right, makes sense
245 2018-02-27 17:18:40	0|michagogo|But why have the default be en_US, and not just not use a translation by default?
246 2018-02-27 17:18:52	0|michagogo|Oh, wait
247 2018-02-27 17:19:00	0|michagogo|That’s what we do, since we deleted en_US
248 2018-02-27 17:19:03	0|michagogo|Never mind.
249 2018-02-27 17:34:35	0|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).
250 2018-02-27 17:42:03	0|luke-jr|wumpus: American English is? I thought standard English was, and that's why we have an en_US translation? :x
251 2018-02-27 17:42:33	0|wumpus|no, we don't have an en_US translation, that was a mistake
252 2018-02-27 17:44:10	0|wumpus|it was accidentally added for 0.16
253 2018-02-27 17:44:18	0|wumpus|and removed again, now
254 2018-02-27 17:50:28	0|wumpus|the messages in the source code are American English (minimize, synchronize, etc), and that's what defines the source language
255 2018-02-27 17:50:54	0|wumpus|en_GB would be 'standard English'
256 2018-02-27 20:43:10	0|bitcoin-git|[13bitcoin] 15bedri opened pull request #12562: Utils and libraries: Leveldb compile warnings (06master...06leveldbCompileWarnings) 02https://github.com/bitcoin/bitcoin/pull/12562
257 2018-02-27 20:59:52	0|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?
258 2018-02-27 21:00:33	0|achow101|eklitzke: we have our own github merging script that does that
259 2018-02-27 21:00:59	0|achow101|https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/github-merge.py
260 2018-02-27 21:07:00	0|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
261 2018-02-27 21:11:01	0|sipa|correct
262 2018-02-27 23:41:20	0|CubicEarths|Why does the client seem to only download blocks a certain distance ahead of what the CPU has processed?
263 2018-02-27 23:44:44	0|sipa|CubicEarths: to not interfere too much with pruning
264 2018-02-27 23:46:56	0|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)
265 2018-02-27 23:51:40	0|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?
266 2018-02-27 23:52:31	0|sipa|if you enable pruning, you delete block files which only have old blocks in them
267 2018-02-27 23:52:49	0|sipa|this is not possible if every block files contains blocks from all over the place
268 2018-02-27 23:53:03	0|CubicEarths|ahh
269 2018-02-27 23:53:58	0|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)
270 2018-02-27 23:54:38	0|sipa|it doesn't really matter if you don't prune and don't plan to ever do so
271 2018-02-27 23:54:47	0|CubicEarths|yeah
272 2018-02-27 23:54:52	0|sipa|but it also doesn't hurt you much to restrict yourself to 1024 blocks ahead
273 2018-02-27 23:55:57	0|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
274 2018-02-27 23:56:54	0|CubicEarths|I am surprised that blocks are not put in blockfiles according to the block number
275 2018-02-27 23:57:28	0|CubicEarths|But it sounds like the files are just filled up sequentially with blocks as the come in?
276 2018-02-27 23:57:54	0|bitcoin-git|[13bitcoin] 15AkioNak closed pull request #11988: Reduce redundant code of prevector and speed it up (06master...06prevector) 02https://github.com/bitcoin/bitcoin/pull/11988
277 2018-02-27 23:58:54	0|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