12016-09-30T00:04:35 <wumpus> it's also not completely unprecedented, for example Transmission torrent client has a turtle icon, which can be clicked to slow down, indeed meant when using the computer for other things
22016-09-30T00:06:15 <sipa> LOL https://git-man-page-generator.lokaltog.net/
32016-09-30T00:06:19 <sipa> </offtopic>
42016-09-30T00:06:29 <gmaxwell> well a 10ms sleep per 20 transactions would pretty much take care of it, I expect.
52016-09-30T00:07:13 <wumpus> although as an idea for bitcoin it's new, I think. THere has been a patch to add a button to disable networking completely but that kind of misses the point. That means a full catch-up has to be done when re-enabling
62016-09-30T00:07:47 <wumpus> sipa: hahaha
72016-09-30T00:07:51 *** aureianimus_ has quit IRC
82016-09-30T00:07:59 *** aureianimus has joined #bitcoin-core-dev
92016-09-30T00:08:13 <gmaxwell> thats old. :P
102016-09-30T00:08:27 <wumpus> I hadn't seen it yet
112016-09-30T00:08:37 <gmaxwell> damn repost supporters. :P
122016-09-30T00:09:37 <gmaxwell> okay, I'll permit it, since where I saw it was in a private msg from my SO,
132016-09-30T00:09:40 <gmaxwell> mindspillage.log:00:33 <mindspillage> hahah: http://git-man-page-generator.lokaltog.net/
142016-09-30T00:10:52 <sipa> i heartily endorse reposts. of things i hadn't seen.
152016-09-30T00:10:57 <gmaxwell> wumpus: I suspect that in the long run to really address the resource usage we'll need something like bittorrent's utp to transfer blocks during catchup and ibd.
162016-09-30T00:11:50 <sipa> we'll need rainbow tables.
172016-09-30T00:13:26 <gmaxwell> https://en.wikipedia.org/wiki/LEDBAT
182016-09-30T00:14:49 *** Evel-Knievel has quit IRC
192016-09-30T00:15:10 *** Evel-Knievel has joined #bitcoin-core-dev
202016-09-30T00:15:39 *** davec has quit IRC
212016-09-30T00:16:06 *** davec has joined #bitcoin-core-dev
222016-09-30T00:27:00 *** Ylbam has quit IRC
232016-09-30T00:28:53 *** aureianimus_ has joined #bitcoin-core-dev
242016-09-30T00:28:54 *** aureianimus has quit IRC
252016-09-30T01:00:49 *** aalex has quit IRC
262016-09-30T01:03:54 *** aalex has joined #bitcoin-core-dev
272016-09-30T01:16:05 *** musalbas has quit IRC
282016-09-30T01:16:35 *** baldur has quit IRC
292016-09-30T01:19:49 *** aureianimus_ has quit IRC
302016-09-30T01:19:51 *** aureianimus has joined #bitcoin-core-dev
312016-09-30T01:22:06 *** Guest40115 has quit IRC
322016-09-30T01:22:43 *** stan has joined #bitcoin-core-dev
332016-09-30T01:23:08 *** stan is now known as Guest97182
342016-09-30T01:23:59 *** aalex has quit IRC
352016-09-30T01:27:30 *** Guest97182 has quit IRC
362016-09-30T01:28:49 *** aalex has joined #bitcoin-core-dev
372016-09-30T01:31:49 *** aureianimus has quit IRC
382016-09-30T01:32:00 *** aureianimus has joined #bitcoin-core-dev
392016-09-30T01:36:18 *** fengling has joined #bitcoin-core-dev
402016-09-30T01:46:55 *** aureianimus_ has joined #bitcoin-core-dev
412016-09-30T01:46:56 *** aureianimus has quit IRC
422016-09-30T02:17:38 *** aureianimus_ has quit IRC
432016-09-30T02:17:40 *** DigiByteDev has joined #bitcoin-core-dev
442016-09-30T02:17:50 *** aureianimus has joined #bitcoin-core-dev
452016-09-30T02:39:03 *** To7 has joined #bitcoin-core-dev
462016-09-30T02:54:43 *** aureianimus has quit IRC
472016-09-30T02:54:55 *** aureianimus has joined #bitcoin-core-dev
482016-09-30T03:06:01 *** aureianimus has quit IRC
492016-09-30T03:06:04 *** aureianimus_ has joined #bitcoin-core-dev
502016-09-30T03:07:17 *** Alopex has quit IRC
512016-09-30T03:08:22 *** Alopex has joined #bitcoin-core-dev
522016-09-30T03:13:06 *** aalex has quit IRC
532016-09-30T03:13:54 *** aalex has joined #bitcoin-core-dev
542016-09-30T03:20:44 *** luke-jr has joined #bitcoin-core-dev
552016-09-30T03:21:34 *** stan has joined #bitcoin-core-dev
562016-09-30T03:21:59 *** stan is now known as Guest9149
572016-09-30T03:23:24 *** aureianimus_ has quit IRC
582016-09-30T03:23:34 *** aureianimus has joined #bitcoin-core-dev
592016-09-30T03:26:21 *** Alopex has quit IRC
602016-09-30T03:27:26 *** Alopex has joined #bitcoin-core-dev
612016-09-30T03:47:07 *** Alopex has quit IRC
622016-09-30T03:48:06 *** aureianimus has quit IRC
632016-09-30T03:48:12 *** Alopex has joined #bitcoin-core-dev
642016-09-30T03:48:18 *** aureianimus has joined #bitcoin-core-dev
652016-09-30T03:52:24 *** fengling has quit IRC
662016-09-30T03:55:55 *** HellO has joined #bitcoin-core-dev
672016-09-30T04:01:28 *** cryptocrypt has joined #bitcoin-core-dev
682016-09-30T04:07:01 *** Alopex has quit IRC
692016-09-30T04:08:06 *** Alopex has joined #bitcoin-core-dev
702016-09-30T04:09:23 *** aureianimus_ has joined #bitcoin-core-dev
712016-09-30T04:09:23 *** aureianimus has quit IRC
722016-09-30T04:13:44 *** Giszmo has quit IRC
732016-09-30T04:14:12 *** HellO has quit IRC
742016-09-30T04:26:43 *** Guest9149 has quit IRC
752016-09-30T04:27:16 *** stan has joined #bitcoin-core-dev
762016-09-30T04:27:40 *** stan is now known as Guest50775
772016-09-30T04:30:25 *** aureianimus has joined #bitcoin-core-dev
782016-09-30T04:30:25 *** aureianimus_ has quit IRC
792016-09-30T04:31:31 *** Guest50775 has quit IRC
802016-09-30T04:33:21 *** justan0theruser has quit IRC
812016-09-30T04:39:28 *** justanotheruser has joined #bitcoin-core-dev
822016-09-30T04:47:26 *** cryptocrypt has quit IRC
832016-09-30T04:49:51 *** baldur has joined #bitcoin-core-dev
842016-09-30T04:51:10 *** aureianimus has quit IRC
852016-09-30T04:51:23 *** aureianimus has joined #bitcoin-core-dev
862016-09-30T05:02:13 *** aureianimus has quit IRC
872016-09-30T05:02:24 *** aureianimus has joined #bitcoin-core-dev
882016-09-30T05:05:53 *** e4xit_ has joined #bitcoin-core-dev
892016-09-30T05:07:41 *** e4xit has quit IRC
902016-09-30T05:07:41 *** e4xit_ is now known as e4xit
912016-09-30T05:32:28 *** aureianimus_ has joined #bitcoin-core-dev
922016-09-30T05:32:28 *** aureianimus has quit IRC
932016-09-30T05:38:14 *** mrkent has quit IRC
942016-09-30T05:40:49 *** DigiByteDev has quit IRC
952016-09-30T05:41:26 *** DigiByteDev has joined #bitcoin-core-dev
962016-09-30T05:49:42 *** jtimon has quit IRC
972016-09-30T05:53:03 *** gabridome has joined #bitcoin-core-dev
982016-09-30T05:57:17 *** gabridome has quit IRC
992016-09-30T06:03:44 *** aureianimus_ has quit IRC
1002016-09-30T06:03:56 *** aureianimus has joined #bitcoin-core-dev
1012016-09-30T06:08:03 *** gabridome has joined #bitcoin-core-dev
1022016-09-30T06:09:38 *** Ylbam has joined #bitcoin-core-dev
1032016-09-30T06:14:42 *** aureianimus has quit IRC
1042016-09-30T06:14:53 *** aureianimus has joined #bitcoin-core-dev
1052016-09-30T06:17:43 *** DigiByteDev has joined #bitcoin-core-dev
1062016-09-30T06:23:48 *** aureianimus has quit IRC
1072016-09-30T06:24:01 *** aureianimus has joined #bitcoin-core-dev
1082016-09-30T06:31:06 *** Alopex has quit IRC
1092016-09-30T06:32:11 *** Alopex has joined #bitcoin-core-dev
1102016-09-30T06:40:17 *** aalex has quit IRC
1112016-09-30T06:43:42 *** aalex has joined #bitcoin-core-dev
1122016-09-30T06:50:00 *** baldur has quit IRC
1132016-09-30T06:50:22 *** baldur has joined #bitcoin-core-dev
1142016-09-30T06:54:42 *** aureianimus has quit IRC
1152016-09-30T06:54:55 *** aureianimus has joined #bitcoin-core-dev
1162016-09-30T07:06:10 *** gabridome has quit IRC
1172016-09-30T07:10:56 *** gabridome has joined #bitcoin-core-dev
1182016-09-30T07:15:38 *** aureianimus has quit IRC
1192016-09-30T07:15:46 *** aureianimus has joined #bitcoin-core-dev
1202016-09-30T07:16:36 *** aureianimus has quit IRC
1212016-09-30T07:16:49 *** aureianimus has joined #bitcoin-core-dev
1222016-09-30T07:17:54 *** gabridome has quit IRC
1232016-09-30T07:31:51 *** luke-jr has quit IRC
1242016-09-30T07:37:20 *** luke-jr has joined #bitcoin-core-dev
1252016-09-30T07:39:30 *** aureianimus has quit IRC
1262016-09-30T07:39:44 *** aureianimus has joined #bitcoin-core-dev
1272016-09-30T07:49:51 <gmaxwell> Interesting factoid: MUSL libc's malloc uses floating point internally.
1282016-09-30T07:50:49 *** aureianimus has quit IRC
1292016-09-30T07:50:51 *** aureianimus_ has joined #bitcoin-core-dev
1302016-09-30T07:51:32 <midnightmagic> that'd odd. what for?
1312016-09-30T07:52:03 <gmaxwell> to enable darkness and hate in the world?
1322016-09-30T07:53:07 *** luke-jr has quit IRC
1332016-09-30T07:53:09 <gmaxwell> some internal algorithim, presumably on hardware with fast FPUs (e.g. nothing you're that likely to use MUSL on) I presume that it's faster than a fixed point version of the same algorithim. Also hate.
1342016-09-30T07:53:15 *** luke-jr has joined #bitcoin-core-dev
1352016-09-30T07:53:46 <midnightmagic> :-D
1362016-09-30T07:54:40 <gmaxwell> I found this out from friends chasing a bug report in libtheora... which uses mmx.. and mmx and fpu share registers... and you have to toggle between them, and the library very carefully fixes up the flag between entry and exit. ... but it didn't know that it had to do so across _libc_ calls, particularly malloc.
1372016-09-30T07:55:04 <midnightmagic> does smartheap still exist? I wonder if they do something similar.
1382016-09-30T07:57:12 <midnightmagic> so.. threaded theora programs stomp on it?
1392016-09-30T07:57:33 <gmaxwell> threaded is fine, OS saves the state betwen context switches.
1402016-09-30T07:58:07 <luke-jr> wat return ((union { float v; uint32_t r; }){(int)x}.r>>21) - 496;
1412016-09-30T07:58:11 <midnightmagic> now I'm curious. Can you link a URL I can read?
1422016-09-30T07:58:11 <gmaxwell> app calls libtheora, lib theora flips on mmx uses some MMX calls malloc does some more MMX flips off MMX OMG THE WORLD ENDS.
1432016-09-30T07:58:28 <luke-jr> gmaxwell: I just had to write http://codepad.org/XT8ifBBp to avoid losing my browser session when I switched to 64-bit.. :|
1442016-09-30T07:58:29 <gmaxwell> luke-jr: that looks like code for a a fast log.
1452016-09-30T07:58:37 <luke-jr> does not inspire confidence in browser developers
1462016-09-30T07:59:09 <gmaxwell> luke-jr: assuming a particular floating point representation (implementation defined behavior hurrah).
1472016-09-30T07:59:20 <luke-jr> gmaxwell: a fast log? it's adjusting alignment
1482016-09-30T07:59:24 <luke-jr> oh, the MUSL code
1492016-09-30T07:59:28 <gmaxwell> the MUSL code.
1502016-09-30T07:59:48 <gmaxwell> it's extracting the exponent and pulling off the bias.
1512016-09-30T08:00:31 <midnightmagic> ohh.. you mean libtheora is failing to do mmx fixup properly, not musl libc?
1522016-09-30T08:01:35 * luke-jr makes a long list of KDE 5 bugs
1532016-09-30T08:03:29 <gmaxwell> midnightmagic: it's fixing up before entry and exit, that libc is using the fpu is a surprise, -- and in C++ you'd be pretty screwed since it's easy for objects to malloc behaind your back in virtually any line of code.
1542016-09-30T08:05:01 <gmaxwell> theora's bug ultimately, but libc non libm using floating point is a surpise.
1552016-09-30T08:05:02 *** DigiByteDev has quit IRC
1562016-09-30T08:05:29 *** jannes has joined #bitcoin-core-dev
1572016-09-30T08:09:03 *** e4xit has quit IRC
1582016-09-30T08:09:37 <wumpus> a heap implementation using floating point is a surprise to me too. I think the advice should be extended from not using floating point for monetary values, to not using it for any kind of precise resource tracking...
1592016-09-30T08:10:36 <midnightmagic> gmaxwell: I love interesting bugs like that.
1602016-09-30T08:10:39 <wumpus> "You have 3.14159... bytes free!"
1612016-09-30T08:10:39 <gmaxwell> (though I still have no idea how you could possibly write MMX using code in C++ if you can't call malloc without restoring the fpu flags first.)
1622016-09-30T08:13:15 <wumpus> I don't think MMX is much-used these days, main reason because there are newer SIMD instruction sets but another reason is its weird re-purposing of registers, it not only makes it hard for developers to use it but let alone compilers... 3DNOW had a similar problem IIRC
1632016-09-30T08:14:56 <wumpus> at its height it was used for a few well-contained matrix multiplication functions in games, too much risk of interfering with the rest of the code otherwise. Newer sets such as SSE have their own registers so doesn't have that problem.
1642016-09-30T08:15:00 <luke-jr> I think I read in GCC's manual sometime that it doesn't use older stuff when AVX is available
1652016-09-30T08:16:03 <gmaxwell> Yes, SSE2 mostly mooted MMX. ... though mmx vs fpu aren't the only fpu flags that could cause you problems with malloc using the fpu.. in particular the flags to control rounding modes might have unexpected effects. :P
1662016-09-30T08:16:28 <wumpus> yes, I'm by no means defending the use of floating point in resource allocation... :P
1672016-09-30T08:16:49 <wumpus> especially in cross-platform code. Ouch.
1682016-09-30T08:17:27 <wumpus> it's seems like of those bit flipping tricks that's very clever but a bad idea to use in production code
1692016-09-30T08:18:14 <wumpus> maybe it's a few % faster on some CPUs but the pain for maintainers... :)
1702016-09-30T08:19:37 * wumpus wonders if gcc or clang has a flag to warn on floating point usage
1712016-09-30T08:20:30 <gmaxwell> can't say I haven't done it myself; https://git.xiph.org/?p=opus.git;a=blob;f=celt/mathops.h;h=1f8a20cb4540255ffc4ea0a5f6716a31798c6a6f;hb=HEAD#l130 but it's behind a flag, and behind a bunch of warnings about non-portability, on some devices its more than a couple percent speedups. :)
1722016-09-30T08:21:02 <gmaxwell> (and operating on floating point signals, not a random piece of floating point code in a sea of integer code)
1732016-09-30T08:22:33 <wumpus> well that acts on float, as long as you can assume IEEE floating point formats I see nothing wrong with that
1742016-09-30T08:23:53 <wumpus> and indeed it's operating on floating point signals, not integer numbers where off-by-one errors can cause a crash like memory allocation :)
1752016-09-30T08:27:47 <wumpus> I think non-IEEE floating point formats (well there can be some contention around NaN and Inf and such, but I mean the global layout) are rarer than not-1-byte-chars these days
1762016-09-30T08:28:02 <luke-jr> wumpus: what if your platform has IEEE floats that conflict with the integer endian? :D
1772016-09-30T08:28:02 *** DigiByteDev has joined #bitcoin-core-dev
1782016-09-30T08:28:04 <wumpus> luke-jr: hmm that's a valid point
1792016-09-30T08:28:18 <luke-jr> wumpus: NEON's non-IEEE stuff differs only in behaviour, not format, I guess?
1802016-09-30T08:28:49 <wumpus> yes, "non-IEEE" in modern usage refers to "sloppy" math behavior to impmlement some operations faster, not the format
1812016-09-30T08:31:43 <wumpus> or even if lacking some minor things that hardly anyone uses anyhow like signaling NaNs
1822016-09-30T08:31:53 *** aureianimus_ has quit IRC
1832016-09-30T08:31:58 *** aureianimus has joined #bitcoin-core-dev
1842016-09-30T08:33:02 <wumpus> but which are great fun in network protocols, especially because no one expect themn and they cause a trap
1852016-09-30T08:34:51 <wumpus> also the DoS-by-small-numbers of x86 denormalized floating point math has always surprised me. It's easy to think of floating point horror stories.
1862016-09-30T08:37:34 <luke-jr> btw, I think my Chromium problems were possibly caused by Wikipedia :p
1872016-09-30T08:37:52 <luke-jr> it erroneously documented that 32-bit aligned 64-bit integers to 8 bytes same as 64-bit does
1882016-09-30T08:38:10 <luke-jr> when in reality GCC aligns them to 4 bytes
1892016-09-30T08:38:46 * luke-jr wonders if this is actually GCC's bug, since SSSE3 also crashed quite a bit
1902016-09-30T08:38:58 <wumpus> in structures? the normal gcc behavior is to algign to the type's size, on any arch
1912016-09-30T08:39:11 <wumpus> though you can override it with a compiler flag
1922016-09-30T08:40:16 <luke-jr> yes, in structures
1932016-09-30T08:40:40 <luke-jr> x86-32 GCC aligns 64-bit integer types to only 4 bytes
1942016-09-30T08:40:52 <luke-jr> even with the 64-bit compiler using -m32
1952016-09-30T08:43:14 <wumpus> just tried it out and you're right
1962016-09-30T08:43:31 <gmaxwell> freaky.
1972016-09-30T08:43:45 *** aureianimus has quit IRC
1982016-09-30T08:44:01 *** aureianimus has joined #bitcoin-core-dev
1992016-09-30T08:44:04 <wumpus> on x86_32. On ARM32 it's 8 as expected.
2002016-09-30T08:44:18 *** aalex has quit IRC
2012016-09-30T08:44:38 <wumpus> so please correct wikipedia :)
2022016-09-30T08:45:49 <luke-jr> I did, this time
2032016-09-30T08:46:49 <wumpus> in principle it makes sense, 32-bit x86 has (originally) no 64-bit memory loads, 64-bit integers are treated as two 32-bit halves
2042016-09-30T08:47:14 <wumpus> but it would have tricked me too.
2052016-09-30T08:48:48 *** aalex has joined #bitcoin-core-dev
2062016-09-30T08:49:00 * luke-jr wonders why the lower half of his IPv6 address changed
2072016-09-30T08:52:01 <wumpus> yesterday I realized not even Amazon EC2 has IPv6 support yet. If there's anywhere you'd expect it to be used it'd be mass virtualized hosting
2082016-09-30T08:54:00 <luke-jr> O.o
2092016-09-30T08:54:14 * luke-jr wonders if that's what's holding Travis back
2102016-09-30T08:55:01 *** aureianimus has quit IRC
2112016-09-30T08:55:02 *** aureianimus_ has joined #bitcoin-core-dev
2122016-09-30T08:55:04 <wumpus> that could be the case, on the other hand, Travis was even lacking localhost IPv6 support, that is not the fault of the hoster :)
2132016-09-30T08:57:49 <wumpus> can we please move the serialization for float/double to serialize_unsafe.h?
2142016-09-30T08:58:36 <wumpus> I was kind of scared until I relaized it's only used for local files (such as the fee estimator), not for network protocols, not for consensus structures
2152016-09-30T09:01:17 <luke-jr> can we make it so it *can't* be used for non-local stuff?
2162016-09-30T09:01:45 <luke-jr> probably easier to just make it portable I guess
2172016-09-30T09:01:47 <wumpus> moving it to a header with a very scary warning will at least be a first step
2182016-09-30T09:02:05 <luke-jr> I see no reason not to move it unless someone plans to do something bette
2192016-09-30T09:02:07 <luke-jr> r
2202016-09-30T09:02:17 <wumpus> making it portable is one thing. Accepting arbitrary float/double bit fields over the internet without potential crashes is not.
2212016-09-30T09:03:09 <wumpus> well it's easy if you know a platform, but it's platform specific
2222016-09-30T09:03:26 <wumpus> in any case putting it in a separate header with a big warning would help
2232016-09-30T09:09:23 <luke-jr> OS: GNU/Linux 4.4.21-gentoo/x86_64 - CPU: 8 x Intel(R) Core⢠i7-4771 CPU @ 3.50GHz (3686.621 MHz) - Processes: 353 - Uptime: 09:09:19 up 1:35, 6 users, load average: 3.05, 2.33, 1.95 - Memory Usage: 15229MB/15950MB (95%)
2242016-09-30T09:09:29 * luke-jr wonders if he will regret moving back to 64-bit
2252016-09-30T09:09:47 <luke-jr> <1 day up and I'm already at 95% RAM use
2262016-09-30T09:10:07 <wumpus> you could skip x86 64-bit and directly move ahead to the future, ARM64 :)
2272016-09-30T09:10:40 * luke-jr was actually one of the earliest x86-64 adopters, but moved back to 32-bit in 2011 ;)
2282016-09-30T09:11:42 <paveljanik> luke-jr, buffer, cache...
2292016-09-30T09:11:47 <luke-jr> paveljanik: already excluding those
2302016-09-30T09:12:35 <paveljanik> bitcoind with dbcache=16G? ;-)
2312016-09-30T09:16:51 <wumpus> ok, just moving the serializers for float/double to a separate header file doesn't seem to be possible, it relies on a certain order of definitions
2322016-09-30T09:16:52 <luke-jr> I haven't even rebuild bitcoin-qt yet
2332016-09-30T09:17:13 <wumpus> compilng C++ with paralellism 10?
2342016-09-30T09:17:20 <luke-jr> nothing being compiled :P
2352016-09-30T09:17:34 <sipa> wumpus: make floating point serialization require nType == SER_DISK?
2362016-09-30T09:17:58 <wumpus> I wonder if jtimon has any ideas with regard to isolating a consensus-safe part of serialization
2372016-09-30T09:18:11 <wumpus> sipa: it'd work, I guess...
2382016-09-30T09:19:24 <wumpus> another option would be to use a special converter to/from binary for those few places that use it with float/double
2392016-09-30T09:19:55 <wumpus> something like FLATDATA, UNSAFE_SERIALIZE_DOUBLE
2402016-09-30T09:20:24 *** Guyver2 has joined #bitcoin-core-dev
2412016-09-30T09:20:52 <wumpus> anyhow I wasn't prepared to fight screenfuls of C++ compiler errors
2422016-09-30T09:21:35 <wumpus> another time
2432016-09-30T09:37:23 <sipa> haha
2442016-09-30T09:55:19 *** cdecker has joined #bitcoin-core-dev
2452016-09-30T10:07:25 *** DigiByteDev has quit IRC
2462016-09-30T10:22:43 *** e4xit has joined #bitcoin-core-dev
2472016-09-30T10:27:08 *** aureianimus_ has quit IRC
2482016-09-30T10:27:19 *** aureianimus has joined #bitcoin-core-dev
2492016-09-30T10:34:39 <GitHub114> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f560d9564f74...83998b52d07b
2502016-09-30T10:34:39 <GitHub114> bitcoin/master 46a4774 Johnson Lau: Fix nulldummy.py test
2512016-09-30T10:34:40 <GitHub114> bitcoin/master 83998b5 Wladimir J. van der Laan: Merge #8841: [qa] fix nulldummy test...
2522016-09-30T10:34:54 <GitHub138> [bitcoin] laanwj closed pull request #8841: [qa] fix nulldummy test (master...nulldummytest) https://github.com/bitcoin/bitcoin/pull/8841
2532016-09-30T10:35:02 <GitHub193> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83998b52d07b...929860106f5a
2542016-09-30T10:35:02 <GitHub193> bitcoin/master 30930e8 Wladimir J. van der Laan: test: Explicitly set encoding to utf8 when opening text files...
2552016-09-30T10:35:16 <GitHub193> bitcoin/master 9298601 Wladimir J. van der Laan: Merge #8840: test: Explicitly set encoding to utf8 when opening text files...
2562016-09-30T10:35:16 <GitHub152> [bitcoin] laanwj closed pull request #8840: test: Explicitly set encoding to utf8 when opening text files (master...2016_09_textfiles_locale) https://github.com/bitcoin/bitcoin/pull/8840
2572016-09-30T10:35:42 <GitHub40> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/929860106f5a...0572acd63bc8
2582016-09-30T10:35:42 <GitHub40> bitcoin/master 1d28faf Wladimir J. van der Laan: test: Avoid ConnectionResetErrors during RPC tests...
2592016-09-30T10:35:42 <GitHub40> bitcoin/master 0572acd Wladimir J. van der Laan: Merge #8839: test: Avoid ConnectionResetErrors during RPC tests...
2602016-09-30T10:35:51 <GitHub182> [bitcoin] laanwj closed pull request #8839: test: Avoid ConnectionResetErrors during RPC tests (master...2016_09_freebsd_rpctest_fix) https://github.com/bitcoin/bitcoin/pull/8839
2612016-09-30T10:35:56 <luke-jr> 10 seconds to view IRC tabs. I feel the pain. :x
2622016-09-30T10:36:03 <sipa> ?
2632016-09-30T10:36:15 <wumpus> what IRC client?
2642016-09-30T10:36:27 <GitHub160> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0572acd63bc8...90adfabd5daa
2652016-09-30T10:36:27 <GitHub160> bitcoin/master da94697 jnewbery: bitcoin-util-test.py should fail if the output file is empty
2662016-09-30T10:36:27 <GitHub160> bitcoin/master 90adfab Wladimir J. van der Laan: Merge #8836: bitcoin-util-test.py should fail if the output file is empty...
2672016-09-30T10:36:37 <GitHub19> [bitcoin] laanwj closed pull request #8836: bitcoin-util-test.py should fail if the output file is empty (master...bitcoin-tx-no-empty-outputs) https://github.com/bitcoin/bitcoin/pull/8836
2682016-09-30T10:36:38 <luke-jr> wumpus: Konversation; it's mostly due to swapping I think
2692016-09-30T10:37:01 <wumpus> ok, never used that one, though my experience with KDE apps is that they use lots of memory. This is very old experience though.
2702016-09-30T10:37:02 <luke-jr> OS: GNU/Linux 4.4.21-gentoo/x86_64 - CPU: 8 x Intel(R) Core⢠i7-4771 CPU @ 3.50GHz (3699.882 MHz) - Processes: 409 - Uptime: 10:36:55 up 3:02, 8 users, load average: 22.22, 20.22, 16.76 - Memory Usage: 20422MB/15950MB (128%)
2712016-09-30T10:37:44 <sipa> my irc client uses 21660 kB of RES
2722016-09-30T10:38:56 <luke-jr> gdb needs some way to report wtf is using so much memory
2732016-09-30T10:39:17 <sipa> gdb?
2742016-09-30T10:39:24 <sipa> how about top
2752016-09-30T10:39:29 <wumpus> mine is currently IRSSI, running on an amazon EC2 nano instance, 512 MB ram of which 250MB used, of which 117 by IRC
2762016-09-30T10:39:56 <sipa> irssi as well here
2772016-09-30T10:39:58 <wumpus> that's virtual size not RSS, RSS is something like 10MB
2782016-09-30T10:40:52 <sipa> 167 MB virtual here
2792016-09-30T10:41:32 * sipa remembers the joke "emacs == eight megabytes and constantly swapping"
2802016-09-30T10:41:48 <wumpus> luke-jr: there are some heap debugger tools, I found the one in gperftools reasonanly useful. But that's per-process, not system-wide
2812016-09-30T10:42:11 <wumpus> system-wide yes tools like gtop seem to do the job?
2822016-09-30T10:42:15 *** aureianimus has quit IRC
2832016-09-30T10:42:24 <wumpus> -g
2842016-09-30T10:42:24 *** aureianimus has joined #bitcoin-core-dev
2852016-09-30T10:42:44 <luke-jr> top just tells processes :p
2862016-09-30T10:42:45 <wumpus> there's no gtop, htop is nice tho :)
2872016-09-30T10:42:58 <luke-jr> RSS doesn't really work when swapping
2882016-09-30T10:44:31 <wumpus> I also like "dstat -cdnpmgs --top-bio --top-cpu" a lot, it also shows the most i/o using process
2892016-09-30T10:45:53 <luke-jr> 9 GB used by KDE for trivial crap
2902016-09-30T10:45:55 <luke-jr> fun
2912016-09-30T10:46:11 <wumpus> welcome to modern linux distros :(
2922016-09-30T10:46:19 <sipa> maybe try a different desktop environment?
2932016-09-30T10:46:34 <sipa> over time i've moved to more lightweight ones
2942016-09-30T10:46:40 <wumpus> so many background services and such for the GUI, it's almost like windows these days in that regard
2952016-09-30T10:46:46 <sipa> all i need is a terminal and a browser anyway
2962016-09-30T10:46:51 <luke-jr> wumpus: iotop works well
2972016-09-30T10:47:05 <wumpus> yes same here
2982016-09-30T10:47:26 <wumpus> even tend to use lynx as a browser sometimes, for viewing python docs and such
2992016-09-30T10:48:15 <luke-jr> sipa: I tried a few and couldn't find any I liked :/
3002016-09-30T10:48:19 <wumpus> to reduce mouse usage and such
3012016-09-30T10:48:51 <wumpus> luke-jr: lxqt must be something for you
3022016-09-30T10:49:16 * luke-jr kills all Chromium's tabs and gets it down to 13 GB (83%)
3032016-09-30T10:49:30 <luke-jr> wumpus: yeah, tried that. the main thing I need is a WM, and lxqt doesn't do that :|
3042016-09-30T10:50:29 <wumpus> GUI browsers use so much memory
3052016-09-30T10:50:29 <luke-jr> yes
3062016-09-30T10:50:38 <luke-jr> I wonder what it'd drop to if I quit it entirely
3072016-09-30T10:53:15 *** aureianimus has quit IRC
3082016-09-30T10:53:26 *** aureianimus has joined #bitcoin-core-dev
3092016-09-30T10:54:22 <wumpus> for the ultimate minimalism you could run Weston :) A minimal wayland compositor, doesn't do much more than showing windows and being able to switch between them, with a launcher bar with one button: to start a terminal... hehe
3102016-09-30T10:55:21 <luke-jr> 10 GB (60%) with Chromium entirely dead
3112016-09-30T10:56:22 <luke-jr> wumpus: but.. taskbar and systray and stuff :x
3122016-09-30T10:57:09 <wumpus> yes, it has none of that, even more limited than 90's desktop environment,it's really meant as a base for embedded systems not for desktop usage, but a few hardcore people do
3132016-09-30T10:57:31 *** laurentmt has joined #bitcoin-core-dev
3142016-09-30T10:57:50 *** To7 has quit IRC
3152016-09-30T10:59:34 *** laurentmt has quit IRC
3162016-09-30T10:59:48 <sipa> luke-jr: i haven't had a taskbar in almost 10 years
3172016-09-30T11:00:53 <sipa> wumpus: heh, i should try that
3182016-09-30T11:01:59 <sipa> xmonad isn't that much more
3192016-09-30T11:03:20 <luke-jr> Windows NT worked with 16 GB RAM :<
3202016-09-30T11:03:21 <luke-jr> MB*
3212016-09-30T11:03:29 <wumpus> yes xmonad looks like something I should take a look at some day
3222016-09-30T11:04:13 <wumpus> I guess you mean windows NT worked with 16 *MB* RAM?
3232016-09-30T11:04:26 *** aureianimus has quit IRC
3242016-09-30T11:04:28 <wumpus> though like emacs it was probably swapping all the time :)
3252016-09-30T11:04:34 *** aureianimus has joined #bitcoin-core-dev
3262016-09-30T11:05:07 <sipa> i think the first system on which i installed linux had 32 MB
3272016-09-30T11:05:24 *** davec has quit IRC
3282016-09-30T11:06:19 *** davec has joined #bitcoin-core-dev
3292016-09-30T11:06:39 <wumpus> I don't remember anymore how much memory my 486 had, but it was very few, I remember reverse-engineering the BIOS to find the registers to map 384kB extra
3302016-09-30T11:06:55 <wumpus> now we don't blink at that amount...
3312016-09-30T11:07:00 <luke-jr> lol
3322016-09-30T11:07:18 <sipa> i may misremember. it was a pentium 60MHz
3332016-09-30T11:08:20 <wumpus> I had an extremely crappy PC, for a long time, which was a big driver for me to look at things like Linux in the first place
3342016-09-30T11:09:27 * luke-jr figures out the trick to disable compositing
3352016-09-30T11:09:29 <wumpus> no, I think that works out
3362016-09-30T11:11:51 <luke-jr> not that it helped :<
3372016-09-30T11:12:03 <luke-jr> load average: 48.20, 34.62, 24.88 <-- I didn't know it could get that high
3382016-09-30T11:12:14 <wumpus> I'd expect disabling compositing to mainly free GPU memory
3392016-09-30T11:12:27 *** AaronvanW has quit IRC
3402016-09-30T11:13:40 <luke-jr> also killed the annoying shadow :D
3412016-09-30T11:13:58 <wumpus> don't people use KDE for the fancy effects? :)
3422016-09-30T11:14:08 <luke-jr> not I
3432016-09-30T11:14:19 <luke-jr> turn all that crap off
3442016-09-30T11:15:18 <wumpus> the first time I saw a wobbling window, or a workspace switch animation it seemed quite impressive, quickly after that it becomes a waste of time
3452016-09-30T11:15:33 <luke-jr> heh, and a bandwidth eater when accessing remotely
3462016-09-30T11:15:38 *** aureianimus has quit IRC
3472016-09-30T11:15:48 *** aureianimus has joined #bitcoin-core-dev
3482016-09-30T11:17:33 <sipa> wumpus: yeah, i used beryl and compiz and luminosity for a while
3492016-09-30T11:17:51 <wumpus> luke-jr: yes, even if 'remotely' is localhost different VM
3502016-09-30T11:18:15 <sipa> but it was mostly good for impressing windows users who made snarky comments about linux's UI :)
3512016-09-30T11:18:20 <luke-jr> wumpus: well, I have to disagree there. I had no problems doing 3D gaming over VNC to a VM some years ago.
3522016-09-30T11:18:33 <wumpus> sipa: hahah exactly!
3532016-09-30T11:18:38 <wumpus> sipa: 'it should look like in the movies'
3542016-09-30T11:19:14 <luke-jr> a VM within a VM even XD
3552016-09-30T11:19:28 <sipa> also, i used enlightenment 17 somewhere in 2005
3562016-09-30T11:19:35 <luke-jr> (KVM running PCSX2 with GPU and USB controller passthrough, viewed over VNC)
3572016-09-30T11:19:37 <sipa> a decade before it was released, i think
3582016-09-30T11:19:45 <wumpus> luke-jr: did that have a special protocol to route the 3D drawing commands?
3592016-09-30T11:19:51 <luke-jr> wumpus: no, just VNC
3602016-09-30T11:20:01 <luke-jr> Tight/JPEG encoding I guess
3612016-09-30T11:20:02 <wumpus> luke-jr: eh GPU passthrough is essentially the same
3622016-09-30T11:20:16 <luke-jr> wumpus: not really. that's just for the rendering :P
3632016-09-30T11:20:30 <luke-jr> I didn't view on that GPU
3642016-09-30T11:20:39 <wumpus> okay, right
3652016-09-30T11:21:50 <luke-jr> someday when I have free time (haha) maybe I'll finish .hack XD
3662016-09-30T11:26:19 <midnightmagic> dwm or fail :-P
3672016-09-30T11:26:33 *** aureianimus has quit IRC
3682016-09-30T11:26:34 <luke-jr> apparently I'm going to have to find *something*
3692016-09-30T11:26:47 *** aureianimus has joined #bitcoin-core-dev
3702016-09-30T11:27:43 <luke-jr> annoying, Qt5 has decided you need KDE to get any theming, so I'll end up losing that I guess
3712016-09-30T11:28:18 <sipa> my window manager uses 7.7 MB of RSS
3722016-09-30T11:29:21 <sipa> my terminal emulator 61 MB, Xord 112 MB, and firefox 987 MB
3732016-09-30T11:29:28 <sipa> *Xorg
3742016-09-30T11:30:58 <wumpus> luke-jr: you can also theme qt through gtk *ducks*
3752016-09-30T11:31:19 <luke-jr> >_<
3762016-09-30T11:31:38 <luke-jr> I think that needs GNOME running?
3772016-09-30T11:31:59 <wumpus> I don't think so, Ubuntu uses it too and Unity is not GNOME
3782016-09-30T11:32:22 <luke-jr> unfortunately, half the reason I want Qt is because GTK is terrible
3792016-09-30T11:32:29 <wumpus> I think it's just a qt plugin that themes-like-gtk
3802016-09-30T11:37:00 *** cryptapus_afk is now known as cryptapus
3812016-09-30T11:37:45 *** aureianimus has quit IRC
3822016-09-30T11:37:54 *** aureianimus has joined #bitcoin-core-dev
3832016-09-30T11:39:05 <wumpus> but it surpirses me to hear that Qt5 has no native theming ability anymore, that's kind of weird, I'm fairly sure qt5 is used a lot in embedded development and those companies all use their own theming.
3842016-09-30T11:39:39 <wumpus> which doesn't say that much, a lot just gets hacked on
3852016-09-30T11:42:21 <luke-jr> I think it has the ability, but it's not possible to configure it without a "platform module"
3862016-09-30T11:50:44 *** aureianimus has quit IRC
3872016-09-30T11:51:26 *** aureianimus has joined #bitcoin-core-dev
3882016-09-30T11:51:52 <sipa> if you use mmap with MAP_FIXED and specify nullptr as address, are you afterwards able to dereference nullptr?
3892016-09-30T11:52:17 <luke-jr> sipa: I think dosbox uses this?
3902016-09-30T11:52:22 <sipa> assuming you make the compiler sufficiently dumb to not optimize things away that it believes are impossible
3912016-09-30T11:52:42 <luke-jr> of course, C still considers it undefined behaviour
3922016-09-30T11:52:48 <luke-jr> I think recent Linux has an option to block it too
3932016-09-30T11:52:56 <luke-jr> since it's been used in exploits or something
3942016-09-30T11:56:54 *** MarcoFalke has joined #bitcoin-core-dev
3952016-09-30T12:12:10 *** aureianimus has quit IRC
3962016-09-30T12:12:21 *** aureianimus has joined #bitcoin-core-dev
3972016-09-30T12:20:02 *** jouke has quit IRC
3982016-09-30T12:25:33 *** aureianimus_ has joined #bitcoin-core-dev
3992016-09-30T12:25:41 *** aureianimus has quit IRC
4002016-09-30T12:43:08 <wumpus> sipa: yes, if the OS allows that that's a valid way to mmap the null page
4012016-09-30T12:43:44 <wumpus> I vaguely remember modern linux distros disallow it by default
4022016-09-30T12:43:56 <wumpus> because it could be used to trick the kernel in some cases
4032016-09-30T12:44:40 <wumpus> luke-jr: yes exactly
4042016-09-30T12:46:02 *** jnewbery has joined #bitcoin-core-dev
4052016-09-30T12:47:35 <wumpus> C compilers will still regard nullptr as an invalid pointer, no matter what is actually mapped there, this can cause surprises on MMU-less platforms that map I/O registers in that range
4062016-09-30T12:51:38 <sipa> sure, it's undefined behaviour to dereference a null pointer, i assume
4072016-09-30T12:52:46 <wumpus> indeed
4082016-09-30T12:53:07 <wumpus> so statements just disappear, sometimes at random,m depending on the mood of the compiler
4092016-09-30T12:53:47 <wumpus> recompile and they may be there again. C is a jungle with its undefined behavior...
4102016-09-30T12:54:03 <wumpus> (well recompile with a small change, maybe in a different function)
4112016-09-30T12:55:13 <wumpus> your best bet is to do it in assembly, then use a volatile asm() block which the comiler isnot allowed to optimize away
4122016-09-30T12:55:33 <wumpus> or even a function defined in an auxiliary .s file
4132016-09-30T12:56:28 *** aureianimus_ has quit IRC
4142016-09-30T12:56:29 *** aureianimus has joined #bitcoin-core-dev
4152016-09-30T13:06:31 <sipa> c++ has even more undefined behaviour :)
4162016-09-30T13:07:03 <wumpus> oh yes, I certainly didn't mean that C++ is any better in that regard
4172016-09-30T13:07:04 <sipa> taking a reference to a nullpointer, and taking a pointer to it will in any sane architecture give you a null pointer again, but it is undefined
4182016-09-30T13:07:18 *** aureianimus has quit IRC
4192016-09-30T13:07:28 *** aureianimus has joined #bitcoin-core-dev
4202016-09-30T13:12:19 *** cdecker has quit IRC
4212016-09-30T13:14:29 *** cdecker has joined #bitcoin-core-dev
4222016-09-30T13:19:06 *** aureianimus has quit IRC
4232016-09-30T13:19:20 *** aureianimus has joined #bitcoin-core-dev
4242016-09-30T13:28:10 *** aureianimus has quit IRC
4252016-09-30T13:28:33 *** aureianimus has joined #bitcoin-core-dev
4262016-09-30T13:29:05 *** To7 has joined #bitcoin-core-dev
4272016-09-30T13:32:33 *** jl2012_ is now known as jl2012
4282016-09-30T13:36:33 *** Giszmo has joined #bitcoin-core-dev
4292016-09-30T13:41:15 *** aureianimus has quit IRC
4302016-09-30T13:41:24 *** aureianimus has joined #bitcoin-core-dev
4312016-09-30T13:44:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4322016-09-30T13:46:49 *** stan has joined #bitcoin-core-dev
4332016-09-30T13:48:38 *** stan is now known as Guest17479
4342016-09-30T13:52:08 *** aureianimus has quit IRC
4352016-09-30T13:52:20 *** aureianimus has joined #bitcoin-core-dev
4362016-09-30T13:59:10 *** arowser has quit IRC
4372016-09-30T14:00:39 *** arowser has joined #bitcoin-core-dev
4382016-09-30T14:02:51 *** laurentmt has joined #bitcoin-core-dev
4392016-09-30T14:03:06 *** aureianimus has quit IRC
4402016-09-30T14:03:18 *** aureianimus has joined #bitcoin-core-dev
4412016-09-30T14:03:24 *** laurentmt has quit IRC
4422016-09-30T14:24:03 *** aureianimus has quit IRC
4432016-09-30T14:24:12 *** aureianimus has joined #bitcoin-core-dev
4442016-09-30T14:35:08 *** aureianimus has quit IRC
4452016-09-30T14:35:17 *** aureianimus has joined #bitcoin-core-dev
4462016-09-30T14:46:48 *** aureianimus has quit IRC
4472016-09-30T14:46:54 *** aureianimus has joined #bitcoin-core-dev
4482016-09-30T15:04:02 <GitHub8> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/90adfabd5daa...ef0801bd1381
4492016-09-30T15:04:02 <GitHub8> bitcoin/master b82f493 jnewbery: Add option to run bitcoin-util-test.py manually
4502016-09-30T15:04:02 <GitHub8> bitcoin/master ef0801b Wladimir J. van der Laan: Merge #8830: [test] Add option to run bitcoin-util-test.py manually...
4512016-09-30T15:04:12 <GitHub48> [bitcoin] laanwj closed pull request #8830: [test] Add option to run bitcoin-util-test.py manually (master...test-bitcoin-util-manually) https://github.com/bitcoin/bitcoin/pull/8830
4522016-09-30T15:09:24 *** jtimon has joined #bitcoin-core-dev
4532016-09-30T15:11:20 <GitHub121> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ef0801bd1381...9bc6a6bd7b0d
4542016-09-30T15:11:21 <GitHub121> bitcoin/master 41e58fa Wladimir J. van der Laan: net: Consistent checksum handling...
4552016-09-30T15:11:21 <GitHub121> bitcoin/master 305087b Wladimir J. van der Laan: net: Hardcode protocol sizes and use fixed-size types...
4562016-09-30T15:11:22 <GitHub121> bitcoin/master 9bc6a6b Wladimir J. van der Laan: Merge #8822: net: Consistent checksum handling...
4572016-09-30T15:11:24 <GitHub171> [bitcoin] jl2012 opened pull request #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h (master...consensusnulldummy) https://github.com/bitcoin/bitcoin/pull/8848
4582016-09-30T15:11:35 <GitHub165> [bitcoin] laanwj closed pull request #8822: net: Consistent checksum handling (master...2016_09_normalize_checksum_handling) https://github.com/bitcoin/bitcoin/pull/8822
4592016-09-30T15:13:14 <GitHub8> [bitcoin] czzarr opened pull request #8849: print P2WSH redeemScript in getrawtransaction if it s not a pubkey (master...print-p2wsh-redeemscript-in-getrawtransaction) https://github.com/bitcoin/bitcoin/pull/8849
4602016-09-30T15:17:38 *** aureianimus has quit IRC
4612016-09-30T15:17:53 *** aureianimus has joined #bitcoin-core-dev
4622016-09-30T15:28:44 <GitHub8> [bitcoin] laanwj opened pull request #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment (master...2016_09_beginptr_deprecation) https://github.com/bitcoin/bitcoin/pull/8850
4632016-09-30T15:33:30 *** Chris_Stewart_5 has quit IRC
4642016-09-30T15:35:48 *** MarcoFalke has quit IRC
4652016-09-30T15:36:17 *** MarcoFalke has joined #bitcoin-core-dev
4662016-09-30T15:58:39 *** aureianimus has quit IRC
4672016-09-30T15:58:52 *** aureianimus has joined #bitcoin-core-dev
4682016-09-30T16:01:01 *** laurentmt has joined #bitcoin-core-dev
4692016-09-30T16:01:01 *** laurentmt has quit IRC
4702016-09-30T16:11:31 *** mrkent has joined #bitcoin-core-dev
4712016-09-30T16:13:31 *** aureianimus has quit IRC
4722016-09-30T16:13:39 *** aureianimus has joined #bitcoin-core-dev
4732016-09-30T16:20:22 <GitHub54> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9bc6a6bd7b0d...fb24d7eeb47e
4742016-09-30T16:20:22 <GitHub54> bitcoin/master a92bf4a Matthew King: bitcoind: Daemonize using daemon(3)...
4752016-09-30T16:20:23 <GitHub54> bitcoin/master fb24d7e Wladimir J. van der Laan: Merge #8813: bitcoind: Daemonize using daemon(3)...
4762016-09-30T16:20:35 <GitHub61> [bitcoin] laanwj closed pull request #8813: bitcoind: Daemonize using daemon(3) (master...2016_09_daemonize) https://github.com/bitcoin/bitcoin/pull/8813
4772016-09-30T16:24:34 *** aureianimus_ has joined #bitcoin-core-dev
4782016-09-30T16:24:34 *** aureianimus has quit IRC
4792016-09-30T16:35:23 *** aureianimus_ has quit IRC
4802016-09-30T16:35:29 *** aureianimus has joined #bitcoin-core-dev
4812016-09-30T16:45:09 *** fengling has joined #bitcoin-core-dev
4822016-09-30T16:45:51 *** Cheeseo has joined #bitcoin-core-dev
4832016-09-30T16:45:51 *** Cheeseo has joined #bitcoin-core-dev
4842016-09-30T16:46:12 *** aureianimus has quit IRC
4852016-09-30T16:46:21 *** aureianimus has joined #bitcoin-core-dev
4862016-09-30T16:53:58 <wumpus> anything else ready for merge?
4872016-09-30T16:55:40 *** fengling has quit IRC
4882016-09-30T16:57:01 <MarcoFalke> probably not. The remaining 130 pulls are waiting for review :P
4892016-09-30T16:58:10 <wumpus> or rebase
4902016-09-30T16:58:55 <wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/8375
4912016-09-30T16:59:09 <gmaxwell> or to be put out of their misery. :P
4922016-09-30T16:59:13 <jtimon> in https://github.com/bitcoin/bitcoin/projects/5 please move #8526 to done
4932016-09-30T16:59:54 <wumpus> but it happens that a pull has tons of ACKs and I miss it, that's why I asked
4942016-09-30T16:59:58 <wumpus> heh :P
4952016-09-30T17:00:41 <wumpus> jtimon: thanks, done
4962016-09-30T17:00:52 <jtimon> thanks, np
4972016-09-30T17:01:28 <GitHub100> [bitcoin] MarcoFalke closed pull request #8633: Ugly hack to print out tests as they are run to mitigate travis timeouts (master...test-driver-hack) https://github.com/bitcoin/bitcoin/pull/8633
4982016-09-30T17:03:51 <jtimon> #8337 would make #8493 easier to read/replace but the acks were before the last rebase...re-review (or new review) welcomed...
4992016-09-30T17:04:26 *** jnewbery has quit IRC
5002016-09-30T17:08:32 *** droark has joined #bitcoin-core-dev
5012016-09-30T17:12:55 <GitHub192> [bitcoin] MarcoFalke opened pull request #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem) (master...Mf1610-walletDeriveNewChildPStratem) https://github.com/bitcoin/bitcoin/pull/8851
5022016-09-30T17:13:55 <wumpus> jtimon: will take a look
5032016-09-30T17:14:24 <wumpus> MarcoFalke: hah also looking at that pull
5042016-09-30T17:14:30 *** jnewbery has joined #bitcoin-core-dev
5052016-09-30T17:15:57 <MarcoFalke> I caused the merge conflict so I felt responsible :)
5062016-09-30T17:17:56 *** aureianimus has quit IRC
5072016-09-30T17:18:01 *** aureianimus_ has joined #bitcoin-core-dev
5082016-09-30T17:40:47 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5092016-09-30T17:44:39 *** aureianimus_ has quit IRC
5102016-09-30T17:44:41 <wumpus> re: #8828 apparently ud2 is an opcode to explicitly generate a SIGILL "Generates an invalid opcode. This instruction is provided for software testing to explicitly generate an invalid opcode. The opcode for this instruction is reserved for this purpose."
5112016-09-30T17:44:51 *** aureianimus has joined #bitcoin-core-dev
5122016-09-30T17:45:50 <wumpus> so that's deliberate, so much for accidental corruption of a function pointer, but why
5132016-09-30T17:46:22 *** BashCo has joined #bitcoin-core-dev
5142016-09-30T17:55:44 *** aureianimus has quit IRC
5152016-09-30T17:55:52 *** aureianimus has joined #bitcoin-core-dev
5162016-09-30T17:56:25 <GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fb24d7eeb47e...940748b4b087
5172016-09-30T17:56:25 <GitHub129> bitcoin/master e198c52 Patrick Strateman: Move key derivation logic from GenerateNewKey to DeriveNewChildKey
5182016-09-30T17:56:26 <GitHub129> bitcoin/master 940748b Wladimir J. van der Laan: Merge #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem)...
5192016-09-30T17:56:40 <GitHub187> [bitcoin] laanwj closed pull request #8375: [Wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (master...2016-07-19-cwallet-derivenewkey) https://github.com/bitcoin/bitcoin/pull/8375
5202016-09-30T17:56:43 <GitHub44> [bitcoin] laanwj closed pull request #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem) (master...Mf1610-walletDeriveNewChildPStratem) https://github.com/bitcoin/bitcoin/pull/8851
5212016-09-30T18:08:44 *** aureianimus has quit IRC
5222016-09-30T18:08:52 *** aureianimus has joined #bitcoin-core-dev
5232016-09-30T18:19:40 *** aureianimus has quit IRC
5242016-09-30T18:19:57 *** aureianimus has joined #bitcoin-core-dev
5252016-09-30T18:20:04 *** Soligor_ is now known as Soligor
5262016-09-30T18:20:13 *** achow101 has quit IRC
5272016-09-30T18:23:10 *** fengling has joined #bitcoin-core-dev
5282016-09-30T18:25:33 *** achow101 has joined #bitcoin-core-dev
5292016-09-30T18:25:42 *** Chris_Stewart_5 has quit IRC
5302016-09-30T18:25:49 *** bad_duck has quit IRC
5312016-09-30T18:25:56 *** bad_duck has joined #bitcoin-core-dev
5322016-09-30T18:27:00 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5332016-09-30T18:28:59 <wumpus> paveljanik: congrats on finding the problem
5342016-09-30T18:30:30 *** aureianimus has quit IRC
5352016-09-30T18:30:38 *** aureianimus has joined #bitcoin-core-dev
5362016-09-30T18:31:37 *** shesek has quit IRC
5372016-09-30T18:32:15 <paveljanik> wumpus, I was not able to parse the line mentally ;-)
5382016-09-30T18:32:30 <paveljanik> I had to diff the left side and right side...
5392016-09-30T18:32:47 *** Chris_Stewart_5 has quit IRC
5402016-09-30T18:33:05 <wumpus> paveljanik: I don't think anyone is, as it would involve a mental infinite loop
5412016-09-30T18:33:13 <wumpus> but I hadn't noticed it
5422016-09-30T18:34:12 <wumpus> anyhow the lesson is, if you do something as crazy as this and create a recursive reference, the compiler will generate an invalid instruction deliberately
5432016-09-30T18:35:01 <paveljanik> I think this is a bug in the compiler.
5442016-09-30T18:35:23 <wumpus> I don't know. How would you convert it to assembly if you were a compiler?
5452016-09-30T18:35:42 <paveljanik> I'd error.
5462016-09-30T18:35:50 <wumpus> it just makes no sense, garbage in, garbage out
5472016-09-30T18:35:52 <wumpus> yes okay
5482016-09-30T18:42:29 <GitHub16> [bitcoin] laanwj closed pull request #8795: [doc] Mention Gitian building script in documents. (master...master) https://github.com/bitcoin/bitcoin/pull/8795
5492016-09-30T18:48:33 *** MarcoFalke has left #bitcoin-core-dev
5502016-09-30T18:49:03 <cfields_> wumpus / MarcoFalke: before I forget: #8708 adds some sanity assertions that weren't there before. We were doing some things that didn't make sense. It immediately caused a few crashes for me, fixed in 89c5742. I suspect it will cause a few more assertion failures post-merge
5512016-09-30T18:49:10 <cfields_> blah, nice timing
5522016-09-30T18:50:10 <GitHub95> [bitcoin] laanwj opened pull request #8852: Mention Gitian building script in doc (master...2016_09_laudaa_master) https://github.com/bitcoin/bitcoin/pull/8852
5532016-09-30T18:50:25 <cfields_> wumpus: oh right, I meant to backport those 2 fixes for 0.13...
5542016-09-30T18:51:30 <GitHub151> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/940748b4b087...7b784cc2bbcd
5552016-09-30T18:51:30 <GitHub151> bitcoin/master 203e2dd Lauda: Mention Gitian building script in doc.
5562016-09-30T18:51:34 <GitHub151> bitcoin/master 7b784cc Wladimir J. van der Laan: Merge #8852: Mention Gitian building script in doc (Laudaa)...
5572016-09-30T18:51:40 <GitHub118> [bitcoin] laanwj closed pull request #8852: Mention Gitian building script in doc (Laudaa) (master...2016_09_laudaa_master) https://github.com/bitcoin/bitcoin/pull/8852
5582016-09-30T18:51:45 <wumpus> cfields_: makes sense
5592016-09-30T18:55:48 <wumpus> cfields_: there's still oppertunity for that, 0.13.1 isn't out yet! :)
5602016-09-30T18:56:49 <cfields_> wumpus: I figured you'd yell :). Doing now.
5612016-09-30T18:57:46 <wumpus> paveljanik: I think overall that's a good point though, C/C++ compilers tend to raise errors only if something is absolutely disallowed due to syntax errors or such, if code makes just no sense and the compiler has no clue what to do with it, is apparently not enough reason
5622016-09-30T18:58:36 <wumpus> cfields_: yes sorry, so many things to keep track of
5632016-09-30T18:59:24 <paveljanik> compilers are afraid of errors. because their users would point to them... But sometime the bug is between the keyboard and the computer :-)
5642016-09-30T18:59:25 <cfields_> wumpus: nono, I meant I figured you'd yell if I pr'd an addition to 0.13.1 at this point. I certainly wasn't expecting you to nag me about it.
5652016-09-30T18:59:29 <wumpus> paveljanik: same for undefined behavior. Compilers just remove statements and instructions when something is undefined. If they were less sadistic they could just raise errors...
5662016-09-30T18:59:42 <paveljanik> yes, definitely.
5672016-09-30T19:01:28 *** aureianimus has quit IRC
5682016-09-30T19:01:34 *** aureianimus has joined #bitcoin-core-dev
5692016-09-30T19:05:03 <wumpus> cfields_: I don't know, I was surprised that 0.13.1 didn't come forward as topic at all in this week's meeting. I think between the segwit fix-ups you can certainly still sneak in network fixes
5702016-09-30T19:14:18 *** aureianimus has quit IRC
5712016-09-30T19:14:30 *** aureianimus has joined #bitcoin-core-dev
5722016-09-30T19:14:31 *** dermoth has quit IRC
5732016-09-30T19:15:50 *** dermoth has joined #bitcoin-core-dev
5742016-09-30T19:21:23 *** dermoth_ has joined #bitcoin-core-dev
5752016-09-30T19:21:45 *** dermoth has quit IRC
5762016-09-30T19:21:51 *** dermoth_ is now known as dermoth
5772016-09-30T19:30:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5782016-09-30T19:32:34 <GitHub161> [bitcoin] czzarr opened pull request #8853: add p2sh and segwit options to bitcoin-tx outscript command (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8853
5792016-09-30T19:33:59 <GitHub180> [bitcoin] czzarr closed pull request #8853: add p2sh and segwit options to bitcoin-tx outscript command (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8853
5802016-09-30T19:34:18 <wumpus> huh
5812016-09-30T19:35:31 <wumpus> this is already the second segwit-related pull that user opens accidentally against our repo and closes immediately: the other was #8816 4 days ago
5822016-09-30T19:36:03 <BlueMatt> wumpus: same guy, meant to get private review before pr'ing to bitcoin core directly
5832016-09-30T19:36:24 <wumpus> BlueMatt: ok :)
5842016-09-30T19:37:52 <morcos> sipa: the optimistic write to pcoinsTip was a fantastic idea. thanks. i took a first pass at implementing it and it looks pretty good. i'm going to play with it some more.
5852016-09-30T20:05:54 *** jtimon has quit IRC
5862016-09-30T20:07:46 *** droark has quit IRC
5872016-09-30T20:07:47 *** cdecker has quit IRC
5882016-09-30T20:08:04 *** fengling has quit IRC
5892016-09-30T20:10:15 <gmaxwell> I think we all know whats needed for 0.13 mostly.
5902016-09-30T20:10:44 *** cdecker has joined #bitcoin-core-dev
5912016-09-30T20:15:03 <BlueMatt> what are the current thoughts on GetWitnessHash caching? (and before gmaxwell screams again, this isnt about 0.13.1)
5922016-09-30T20:18:25 <sdaftuar> BlueMatt: i think we should do it, right? (you mean caching it in the CTransaction object?)
5932016-09-30T20:18:33 *** Chris_Stewart_5 has quit IRC
5942016-09-30T20:18:34 <BlueMatt> sdaftuar: yes
5952016-09-30T20:19:38 <sdaftuar> i guess it wastes memory for non-segwit transactions, but it seems to me like we'll want it in the long run
5962016-09-30T20:19:42 <gmaxwell> Sipa has a PR that takes a good step towards making a flat const ctransaction object.
5972016-09-30T20:20:11 <gmaxwell> so perhaps the fixed hashes should be done as part of completing that work-- making the objects flat will significantly reduce their memory usage.
5982016-09-30T20:20:19 <wumpus> https://github.com/bitcoin/bitcoin/pull/8580
5992016-09-30T20:20:44 <BlueMatt> gmaxwell: heh, i was just looking at that...really hard to do efficiently since our serialization doesnt have length descriptors across the whole thing :(
6002016-09-30T20:20:58 <sdaftuar> gmaxwell: i had a moment of brief panic the other day when i noticed the CTransaction::operator== function
6012016-09-30T20:21:03 <sdaftuar> which just compares the stored hashes
6022016-09-30T20:21:19 <gmaxwell> Well the flat object wouldn't be our seralization.
6032016-09-30T20:21:45 <gmaxwell> e.g. you wouldn't want it to have varints in it. :)
6042016-09-30T20:21:53 <BlueMatt> diff --git a/src/primitives/transaction.cpp b/src/primitives/transaction.cpp
6052016-09-30T20:21:53 <BlueMatt> @@ -76,2 +76,4 @@ uint256 CTransaction::GetWitnessHash() const
6062016-09-30T20:21:53 <BlueMatt> {
6072016-09-30T20:21:53 <BlueMatt> + if (wit.IsNull())
6082016-09-30T20:21:53 <BlueMatt> + return GetHash();
6092016-09-30T20:22:28 <BlueMatt> gmaxwell: suresure, but it still sucks since you cant prealloc the right size object from the start
6102016-09-30T20:22:33 <gmaxwell> in any case, withash caching could just follow 8580 before going and flatting things. I expect flattening things will touch a lot of code.
6112016-09-30T20:22:46 <BlueMatt> def need that for FIBRE ^
6122016-09-30T20:22:53 <BlueMatt> ehh, that patch, that is
6132016-09-30T20:22:58 <gmaxwell> BlueMatt: yea, it would end up doing something like deseralize into a mutable transaction then convert that to flat.
6142016-09-30T20:23:21 <BlueMatt> gmaxwell: hmm, would that actually be faster?
6152016-09-30T20:24:01 <gmaxwell> an extra copy, but it would save a half dozen or more calls to the heap allocator, and likely later accesses will involve less pointer chasing-- and the data will be smaller and more contigious. I would be fairly surprised if it wasn't.
6162016-09-30T20:24:21 <BlueMatt> well the deserialization into a mutable transaction would do all the same heap allocations?
6172016-09-30T20:25:07 <gmaxwell> hm okay indeed it would in the way I described it. Guess more cleverness would be required.
6182016-09-30T20:25:23 <wumpus> q
6192016-09-30T20:25:46 <BlueMatt> gmaxwell: yea, this is why i wanted to just use our serialization and copy to memory, but you cant really do that :(
6202016-09-30T20:25:55 <BlueMatt> damn DRY serialization format :(
6212016-09-30T20:27:38 *** aureianimus has quit IRC
6222016-09-30T20:27:42 *** aureianimus_ has joined #bitcoin-core-dev
6232016-09-30T20:27:53 <gmaxwell> well, not the end of the world. just deseralize into a maximum size buffer kept around for that purpose, then copy into the correct one.
6242016-09-30T20:28:46 <gmaxwell> BlueMatt: if you want to see if you can fiddle with my compressed txn representation to make it easier to allocate for.. be my guest. Would be interesting if it could be done without losing too much packing efficiency.
6252016-09-30T20:29:30 <BlueMatt> i mean if you want that just add a length descriptor as the first element over the entire tx (or anything you want to pack)
6262016-09-30T20:29:42 <BlueMatt> it does ruin our nicely-DRY serialization, but it might be a valid tradeoff here
6272016-09-30T20:30:43 <gmaxwell> other alternative is to parse twice to extra the length first, but I expect that to be slower than a tidy copy.
6282016-09-30T20:31:27 <BlueMatt> quite possibly
6292016-09-30T20:31:27 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6302016-09-30T20:34:35 <BlueMatt> i mean if we do do a compressed txn format, we might consider this a feature, but I expect its hard to come up with something that can be trivially used for both without needing enough in-memory pointers and such that its no longer so useful
6312016-09-30T20:36:00 <gmaxwell> oh I don't thin we can have one format for the compressed format and the flat in memory transaction. But we could try to make the compressed format easier to deseralize. E.g. by reading a small amount of it you would know how much to allocate for the flat form.
6322016-09-30T20:36:05 <gmaxwell> s/thin/think/
6332016-09-30T20:36:30 *** Chris_Stewart_5 has quit IRC
6342016-09-30T20:37:12 <gmaxwell> e.g. a format that coded all the sizes in the first few bytes. I would have naturally done that in my sketch, except I was trying to avoid having any bitpacking.
6352016-09-30T20:37:35 *** btcdrak has quit IRC
6362016-09-30T20:38:27 <gmaxwell> but I think it could be reordered as is, so the it first gives all the type bytes and only after them does it seralize the payload.
6372016-09-30T20:39:09 <gmaxwell> so a sizing parse would only have to handle the first O(txin+txout) bytes or so.
6382016-09-30T20:48:37 <BlueMatt> yea, but if we have a nice in-memory blob format I can just make FIBRE use it :p
6392016-09-30T20:48:41 <BlueMatt> then FIBRE will be really fast
6402016-09-30T20:52:05 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6412016-09-30T20:58:48 *** jtimon has joined #bitcoin-core-dev
6422016-09-30T20:59:03 *** Guest17479 has quit IRC
6432016-09-30T21:00:05 *** stan has joined #bitcoin-core-dev
6442016-09-30T21:00:05 *** stan is now known as Guest70056
6452016-09-30T21:04:03 *** Guest70056 has quit IRC
6462016-09-30T21:08:27 *** aureianimus_ has quit IRC
6472016-09-30T21:08:39 *** aureianimus has joined #bitcoin-core-dev
6482016-09-30T21:25:45 *** aureianimus has quit IRC
6492016-09-30T21:25:54 *** aureianimus has joined #bitcoin-core-dev
6502016-09-30T21:33:25 *** fengling has joined #bitcoin-core-dev
6512016-09-30T21:36:47 *** btcdrak has joined #bitcoin-core-dev
6522016-09-30T21:38:10 *** aureianimus has quit IRC
6532016-09-30T21:38:22 *** aureianimus has joined #bitcoin-core-dev
6542016-09-30T21:43:59 *** BashCo has quit IRC
6552016-09-30T21:57:40 *** BashCo has joined #bitcoin-core-dev
6562016-09-30T22:04:19 *** Chris_Stewart_5 has quit IRC
6572016-09-30T22:09:10 *** aureianimus has quit IRC
6582016-09-30T22:09:18 *** aureianimus has joined #bitcoin-core-dev
6592016-09-30T22:10:47 *** fengling has quit IRC
6602016-09-30T22:20:45 *** aureianimus has quit IRC
6612016-09-30T22:20:57 *** aureianimus has joined #bitcoin-core-dev
6622016-09-30T22:31:42 *** aureianimus has quit IRC
6632016-09-30T22:31:53 *** aureianimus has joined #bitcoin-core-dev
6642016-09-30T22:32:38 *** aureianimus has quit IRC
6652016-09-30T22:32:46 *** aureianimus has joined #bitcoin-core-dev
6662016-09-30T22:40:26 *** jnewbery has quit IRC
6672016-09-30T22:42:51 *** shesek has joined #bitcoin-core-dev
6682016-09-30T22:53:30 *** aureianimus has quit IRC
6692016-09-30T22:53:42 *** aureianimus has joined #bitcoin-core-dev
6702016-09-30T22:56:53 *** cdecker has quit IRC
6712016-09-30T23:00:22 *** Guyver2 has quit IRC
6722016-09-30T23:04:32 *** aureianimus has quit IRC
6732016-09-30T23:04:38 *** aureianimus_ has joined #bitcoin-core-dev
6742016-09-30T23:06:05 *** cryptapus is now known as cryptapus_afk
6752016-09-30T23:10:15 *** fengling has joined #bitcoin-core-dev
6762016-09-30T23:25:26 *** aureianimus_ has quit IRC
6772016-09-30T23:25:31 *** aureianimus has joined #bitcoin-core-dev
6782016-09-30T23:36:17 *** AaronvanW has joined #bitcoin-core-dev
6792016-09-30T23:36:44 *** AaronvanW has quit IRC
6802016-09-30T23:36:44 *** AaronvanW has joined #bitcoin-core-dev
6812016-09-30T23:46:27 *** aureianimus_ has joined #bitcoin-core-dev
6822016-09-30T23:46:28 *** aureianimus has quit IRC
6832016-09-30T23:51:55 *** fengling has quit IRC