1 2016-09-30 00:04:35	0|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
  2 2016-09-30 00:06:16	0|sipa|LOL https://git-man-page-generator.lokaltog.net/
  3 2016-09-30 00:06:19	0|sipa|</offtopic>
  4 2016-09-30 00:06:30	0|gmaxwell|well a 10ms sleep per 20 transactions would pretty much take care of it, I expect.
  5 2016-09-30 00:07:14	0|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
  6 2016-09-30 00:07:47	0|wumpus|sipa: hahaha
  7 2016-09-30 00:08:13	0|gmaxwell|thats old. :P
  8 2016-09-30 00:08:28	0|wumpus|I hadn't seen it yet
  9 2016-09-30 00:08:37	0|gmaxwell|damn repost supporters. :P
 10 2016-09-30 00:09:37	0|gmaxwell|okay, I'll permit it, since where I saw it was in a private msg from my SO,
 11 2016-09-30 00:09:41	0|gmaxwell|mindspillage.log:00:33 <mindspillage> hahah: http://git-man-page-generator.lokaltog.net/
 12 2016-09-30 00:10:52	0|sipa|i heartily endorse reposts. of things i hadn't seen.
 13 2016-09-30 00:10:58	0|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.
 14 2016-09-30 00:11:50	0|sipa|we'll need rainbow tables.
 15 2016-09-30 00:13:26	0|gmaxwell|https://en.wikipedia.org/wiki/LEDBAT
 16 2016-09-30 07:49:51	0|gmaxwell|Interesting factoid: MUSL libc's malloc uses floating point internally.
 17 2016-09-30 07:51:33	0|midnightmagic|that'd odd. what for?
 18 2016-09-30 07:51:58	0|gmaxwell|to enable darkness and hate in the world?
 19 2016-09-30 07:53:09	0|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.
 20 2016-09-30 07:53:46	0|midnightmagic|:-D
 21 2016-09-30 07:54:41	0|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.
 22 2016-09-30 07:55:04	0|midnightmagic|does smartheap still exist? I wonder if they do something similar.
 23 2016-09-30 07:57:12	0|midnightmagic|so.. threaded theora programs stomp on it?
 24 2016-09-30 07:57:34	0|gmaxwell|threaded is fine, OS saves the state betwen context switches.
 25 2016-09-30 07:58:07	0|luke-jr|wat return ((union { float v; uint32_t r; }){(int)x}.r>>21) - 496;
 26 2016-09-30 07:58:11	0|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.
 27 2016-09-30 07:58:11	0|midnightmagic|now I'm curious. Can you link a URL I can read?
 28 2016-09-30 07:58:29	0|gmaxwell|luke-jr: that looks like code for a a fast log.
 29 2016-09-30 07:58:29	0|luke-jr|gmaxwell: I just had to write http://codepad.org/XT8ifBBp to avoid losing my browser session when I switched to 64-bit.. :|
 30 2016-09-30 07:58:37	0|luke-jr|does not inspire confidence in browser developers
 31 2016-09-30 07:59:09	0|gmaxwell|luke-jr: assuming a particular floating point representation (implementation defined behavior hurrah).
 32 2016-09-30 07:59:20	0|luke-jr|gmaxwell: a fast log? it's adjusting alignment
 33 2016-09-30 07:59:24	0|luke-jr|oh, the MUSL code
 34 2016-09-30 07:59:29	0|gmaxwell|the MUSL code.
 35 2016-09-30 07:59:48	0|gmaxwell|it's extracting the exponent and pulling off the bias.
 36 2016-09-30 08:00:31	0|midnightmagic|ohh..  you mean libtheora is failing to do mmx fixup properly, not musl libc?
 37 2016-09-30 08:03:29	0|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.
 38 2016-09-30 08:05:01	0|gmaxwell|theora's bug ultimately, but libc non libm using floating point is a surpise.
 39 2016-09-30 08:09:37	0|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...
 40 2016-09-30 08:10:36	0|midnightmagic|gmaxwell: I love interesting bugs like that.
 41 2016-09-30 08:10:39	0|wumpus|"You have 3.14159... bytes free!"
 42 2016-09-30 08:10:40	0|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.)
 43 2016-09-30 08:13:15	0|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
 44 2016-09-30 08:14:56	0|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.
 45 2016-09-30 08:15:00	0|luke-jr|I think I read in GCC's manual sometime that it doesn't use older stuff when AVX is available
 46 2016-09-30 08:16:04	0|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
 47 2016-09-30 08:16:28	0|wumpus|yes, I'm by no means defending the use of floating point in resource allocation... :P
 48 2016-09-30 08:16:49	0|wumpus|especially in cross-platform code. Ouch.
 49 2016-09-30 08:17:28	0|wumpus|it's seems like of those bit flipping tricks that's very clever but a bad idea to use in production code
 50 2016-09-30 08:18:14	0|wumpus|maybe it's a few % faster on some CPUs but the pain for maintainers... :)
 51 2016-09-30 08:20:31	0|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. :)
 52 2016-09-30 08:21:03	0|gmaxwell|(and operating on floating point signals, not a random piece of floating point code in a sea of integer code)
 53 2016-09-30 08:22:34	0|wumpus|well that acts on float, as long as you can assume IEEE floating point formats I see nothing wrong with that
 54 2016-09-30 08:23:53	0|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 :)
 55 2016-09-30 08:27:48	0|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
 56 2016-09-30 08:27:49	0|luke-jr|wumpus: what if your platform has IEEE floats that conflict with the integer endian? :D
 57 2016-09-30 08:28:05	0|wumpus|luke-jr: hmm that's a valid point
 58 2016-09-30 08:28:18	0|luke-jr|wumpus: NEON's non-IEEE stuff differs only in behaviour, not format, I guess?
 59 2016-09-30 08:28:50	0|wumpus|yes, "non-IEEE" in modern usage refers to "sloppy" math behavior to impmlement some operations faster, not the format
 60 2016-09-30 08:31:43	0|wumpus|or even if lacking some minor things that hardly anyone uses anyhow like signaling NaNs
 61 2016-09-30 08:33:02	0|wumpus|but which are great fun in network protocols, especially because no one expect themn and they cause a trap
 62 2016-09-30 08:34:51	0|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.
 63 2016-09-30 08:37:34	0|luke-jr|btw, I think my Chromium problems were possibly caused by Wikipedia :p
 64 2016-09-30 08:37:53	0|luke-jr|it erroneously documented that 32-bit aligned 64-bit integers to 8 bytes same as 64-bit does
 65 2016-09-30 08:38:10	0|luke-jr|when in reality GCC aligns them to 4 bytes
 66 2016-09-30 08:38:58	0|wumpus|in structures? the normal gcc behavior is to algign to the type's size, on any arch
 67 2016-09-30 08:39:11	0|wumpus|though you can override it with a compiler flag
 68 2016-09-30 08:40:16	0|luke-jr|yes, in structures
 69 2016-09-30 08:40:40	0|luke-jr|x86-32 GCC aligns 64-bit integer types to only 4 bytes
 70 2016-09-30 08:40:52	0|luke-jr|even with the 64-bit compiler using -m32
 71 2016-09-30 08:43:14	0|wumpus|just tried it out and you're right
 72 2016-09-30 08:43:32	0|gmaxwell|freaky.
 73 2016-09-30 08:44:04	0|wumpus|on x86_32. On ARM32 it's 8 as expected.
 74 2016-09-30 08:44:38	0|wumpus|so please correct wikipedia :)
 75 2016-09-30 08:45:50	0|luke-jr|I did, this time
 76 2016-09-30 08:46:49	0|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
 77 2016-09-30 08:47:14	0|wumpus|but it would have tricked me too.
 78 2016-09-30 08:52:01	0|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
 79 2016-09-30 08:54:00	0|luke-jr|O.o
 80 2016-09-30 08:55:04	0|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 :)
 81 2016-09-30 08:57:49	0|wumpus|can we please move the serialization for float/double to serialize_unsafe.h?
 82 2016-09-30 08:58:36	0|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
 83 2016-09-30 09:01:17	0|luke-jr|can we make it so it *can't* be used for non-local stuff?
 84 2016-09-30 09:01:45	0|luke-jr|probably easier to just make it portable I guess
 85 2016-09-30 09:01:47	0|wumpus|moving it to a header with a very scary warning will at least be a first step
 86 2016-09-30 09:02:05	0|luke-jr|I see no reason not to move it unless someone plans to do something bette
 87 2016-09-30 09:02:07	0|luke-jr|r
 88 2016-09-30 09:02:17	0|wumpus|making it portable is one thing. Accepting arbitrary float/double bit fields over the internet without potential crashes is not.
 89 2016-09-30 09:03:09	0|wumpus|well it's easy if you know a platform, but it's platform specific
 90 2016-09-30 09:03:27	0|wumpus|in any case putting it in a separate header with a big warning would help
 91 2016-09-30 09:09:23	0|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%)
 92 2016-09-30 09:09:47	0|luke-jr|<1 day up and I'm already at 95% RAM use
 93 2016-09-30 09:10:07	0|wumpus|you could skip x86 64-bit and directly move ahead to the future, ARM64 :)
 94 2016-09-30 09:11:42	0|paveljanik|luke-jr, buffer, cache...
 95 2016-09-30 09:11:48	0|luke-jr|paveljanik: already excluding those
 96 2016-09-30 09:12:35	0|paveljanik|bitcoind with dbcache=16G? ;-)
 97 2016-09-30 09:16:52	0|luke-jr|I haven't even rebuild bitcoin-qt yet
 98 2016-09-30 09:16:52	0|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
 99 2016-09-30 09:17:14	0|wumpus|compilng C++ with paralellism 10?
100 2016-09-30 09:17:20	0|luke-jr|nothing being compiled :P
101 2016-09-30 09:17:34	0|sipa|wumpus: make floating point serialization require nType == SER_DISK?
102 2016-09-30 09:17:59	0|wumpus|I wonder if jtimon has any ideas with regard to isolating a consensus-safe part of serialization
103 2016-09-30 09:18:11	0|wumpus|sipa: it'd work, I guess...
104 2016-09-30 09:19:24	0|wumpus|another option would be to use a special converter to/from binary for those few places that use it with float/double
105 2016-09-30 09:19:55	0|wumpus|something like FLATDATA, UNSAFE_SERIALIZE_DOUBLE
106 2016-09-30 09:20:53	0|wumpus|anyhow I wasn't prepared to fight screenfuls of C++ compiler errors
107 2016-09-30 09:21:35	0|wumpus|another time
108 2016-09-30 09:37:24	0|sipa|haha
109 2016-09-30 10:34:40	0|GitHub114|13bitcoin/06master 1446a4774 15Johnson Lau: Fix nulldummy.py test
110 2016-09-30 10:34:40	0|GitHub114|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f560d9564f74...83998b52d07b
111 2016-09-30 10:34:41	0|GitHub114|13bitcoin/06master 1483998b5 15Wladimir J. van der Laan: Merge #8841: [qa] fix nulldummy test...
112 2016-09-30 10:34:55	0|GitHub138|[13bitcoin] 15laanwj closed pull request #8841: [qa] fix nulldummy test (06master...06nulldummytest) 02https://github.com/bitcoin/bitcoin/pull/8841
113 2016-09-30 10:35:02	0|GitHub193|13bitcoin/06master 1430930e8 15Wladimir J. van der Laan: test: Explicitly set encoding to utf8 when opening text files...
114 2016-09-30 10:35:02	0|GitHub193|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/83998b52d07b...929860106f5a
115 2016-09-30 10:35:03	0|GitHub193|13bitcoin/06master 149298601 15Wladimir J. van der Laan: Merge #8840: test: Explicitly set encoding to utf8 when opening text files...
116 2016-09-30 10:35:12	0|GitHub152|[13bitcoin] 15laanwj closed pull request #8840: test: Explicitly set encoding to utf8 when opening text files (06master...062016_09_textfiles_locale) 02https://github.com/bitcoin/bitcoin/pull/8840
117 2016-09-30 10:35:42	0|GitHub40|13bitcoin/06master 141d28faf 15Wladimir J. van der Laan: test: Avoid ConnectionResetErrors during RPC tests...
118 2016-09-30 10:35:42	0|GitHub40|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/929860106f5a...0572acd63bc8
119 2016-09-30 10:35:43	0|GitHub40|13bitcoin/06master 140572acd 15Wladimir J. van der Laan: Merge #8839: test: Avoid ConnectionResetErrors during RPC tests...
120 2016-09-30 10:35:52	0|GitHub182|[13bitcoin] 15laanwj closed pull request #8839: test: Avoid ConnectionResetErrors during RPC tests (06master...062016_09_freebsd_rpctest_fix) 02https://github.com/bitcoin/bitcoin/pull/8839
121 2016-09-30 10:35:57	0|luke-jr|10 seconds to view IRC tabs. I feel the pain. :x
122 2016-09-30 10:36:04	0|sipa|?
123 2016-09-30 10:36:16	0|wumpus|what IRC client?
124 2016-09-30 10:36:27	0|GitHub160|13bitcoin/06master 14da94697 15jnewbery: bitcoin-util-test.py should fail if the output file is empty
125 2016-09-30 10:36:27	0|GitHub160|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0572acd63bc8...90adfabd5daa
126 2016-09-30 10:36:28	0|GitHub160|13bitcoin/06master 1490adfab 15Wladimir J. van der Laan: Merge #8836: bitcoin-util-test.py should fail if the output file is empty...
127 2016-09-30 10:36:37	0|GitHub19|[13bitcoin] 15laanwj closed pull request #8836: bitcoin-util-test.py should fail if the output file is empty (06master...06bitcoin-tx-no-empty-outputs) 02https://github.com/bitcoin/bitcoin/pull/8836
128 2016-09-30 10:36:38	0|luke-jr|wumpus: Konversation; it's mostly due to swapping I think
129 2016-09-30 10:37:01	0|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.
130 2016-09-30 10:37:02	0|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%)
131 2016-09-30 10:37:44	0|sipa|my irc client uses 21660 kB of RES
132 2016-09-30 10:38:56	0|luke-jr|gdb needs some way to report wtf is using so much memory
133 2016-09-30 10:39:17	0|sipa|gdb?
134 2016-09-30 10:39:24	0|sipa|how about top
135 2016-09-30 10:39:30	0|wumpus|mine is currently IRSSI, running on an amazon EC2 nano instance, 512 MB ram of which 250MB used, of which 117 by IRC
136 2016-09-30 10:39:56	0|sipa|irssi as well here
137 2016-09-30 10:39:58	0|wumpus|that's virtual size not RSS, RSS is something like 10MB
138 2016-09-30 10:40:52	0|sipa|167 MB virtual here
139 2016-09-30 10:41:48	0|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
140 2016-09-30 10:42:11	0|wumpus|system-wide yes tools like gtop seem to do the job?
141 2016-09-30 10:42:24	0|wumpus|-g
142 2016-09-30 10:42:44	0|luke-jr|top just tells processes :p
143 2016-09-30 10:42:45	0|wumpus|there's no gtop, htop is nice tho :)
144 2016-09-30 10:42:59	0|luke-jr|RSS doesn't really work when swapping
145 2016-09-30 10:44:31	0|wumpus|I also like "dstat -cdnpmgs --top-bio --top-cpu" a lot, it also shows the most i/o using process
146 2016-09-30 10:45:53	0|luke-jr|9 GB used by KDE for trivial crap
147 2016-09-30 10:45:55	0|luke-jr|fun
148 2016-09-30 10:46:11	0|wumpus|welcome to modern linux distros :(
149 2016-09-30 10:46:20	0|sipa|maybe try a different desktop environment?
150 2016-09-30 10:46:34	0|sipa|over time i've moved to more lightweight ones
151 2016-09-30 10:46:40	0|wumpus|so many background services and such for the GUI, it's almost like windows these days in that regard
152 2016-09-30 10:46:46	0|sipa|all i need is a terminal and a browser anyway
153 2016-09-30 10:46:52	0|luke-jr|wumpus: iotop works well
154 2016-09-30 10:46:53	0|wumpus|yes same here
155 2016-09-30 10:47:26	0|wumpus|even tend to use lynx as a browser sometimes, for viewing python docs and such
156 2016-09-30 10:48:16	0|luke-jr|sipa: I tried a few and couldn't find any I liked :/
157 2016-09-30 10:48:19	0|wumpus|to reduce mouse usage and such
158 2016-09-30 10:48:51	0|wumpus|luke-jr: lxqt must be something for you
159 2016-09-30 10:49:30	0|luke-jr|wumpus: yeah, tried that. the main thing I need is a WM, and lxqt doesn't do that :|
160 2016-09-30 10:49:48	0|wumpus|GUI browsers use so much memory
161 2016-09-30 10:50:30	0|luke-jr|yes
162 2016-09-30 10:50:38	0|luke-jr|I wonder what it'd drop to if I quit it entirely
163 2016-09-30 10:54:23	0|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
164 2016-09-30 10:55:21	0|luke-jr|10 GB (60%) with Chromium entirely dead
165 2016-09-30 10:55:48	0|luke-jr|wumpus: but.. taskbar and systray and stuff :x
166 2016-09-30 10:57:10	0|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
167 2016-09-30 10:59:35	0|sipa|luke-jr: i haven't had a taskbar in almost 10 years
168 2016-09-30 11:00:54	0|sipa|wumpus: heh, i should try that
169 2016-09-30 11:01:59	0|sipa|xmonad isn't that much more
170 2016-09-30 11:03:20	0|luke-jr|Windows NT worked with 16 GB RAM :<
171 2016-09-30 11:03:22	0|luke-jr|MB*
172 2016-09-30 11:03:30	0|wumpus|yes xmonad looks like something I should take a look at some day
173 2016-09-30 11:04:13	0|wumpus|I guess you mean windows NT worked with 16 *MB* RAM?
174 2016-09-30 11:04:28	0|wumpus|though like emacs it was probably swapping all the time :)
175 2016-09-30 11:05:07	0|sipa|i think the first system on which i installed linux had 32 MB
176 2016-09-30 11:06:39	0|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
177 2016-09-30 11:06:55	0|wumpus|now we don't blink at that amount...
178 2016-09-30 11:07:00	0|luke-jr|lol
179 2016-09-30 11:07:19	0|sipa|i may misremember. it was a pentium 60MHz
180 2016-09-30 11:08:21	0|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
181 2016-09-30 11:09:29	0|wumpus|no, I think that works out
182 2016-09-30 11:11:52	0|luke-jr|not that it helped :<
183 2016-09-30 11:12:03	0|luke-jr|load average: 48.20, 34.62, 24.88 <-- I didn't know it could get that high
184 2016-09-30 11:12:14	0|wumpus|I'd expect disabling compositing to mainly free GPU memory
185 2016-09-30 11:13:40	0|luke-jr|also killed the annoying shadow :D
186 2016-09-30 11:13:58	0|wumpus|don't people use KDE for the fancy effects? :)
187 2016-09-30 11:14:09	0|luke-jr|not I
188 2016-09-30 11:14:19	0|luke-jr|turn all that crap off
189 2016-09-30 11:15:18	0|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
190 2016-09-30 11:15:33	0|luke-jr|heh, and a bandwidth eater when accessing remotely
191 2016-09-30 11:17:34	0|sipa|wumpus: yeah, i used beryl and compiz and luminosity for a while
192 2016-09-30 11:17:52	0|wumpus|luke-jr: yes, even if 'remotely' is localhost different VM
193 2016-09-30 11:18:16	0|sipa|but it was mostly good for impressing windows users who made snarky comments about linux's UI :)
194 2016-09-30 11:18:20	0|luke-jr|wumpus: well, I have to disagree there. I had no problems doing 3D gaming over VNC to a VM some years ago.
195 2016-09-30 11:18:33	0|wumpus|sipa: hahah exactly!
196 2016-09-30 11:18:39	0|wumpus|sipa: 'it should look like in the movies'
197 2016-09-30 11:19:15	0|luke-jr|a VM within a VM even XD
198 2016-09-30 11:19:28	0|sipa|also, i used enlightenment 17 somewhere in 2005
199 2016-09-30 11:19:36	0|luke-jr|(KVM running PCSX2 with GPU and USB controller passthrough, viewed over VNC)
200 2016-09-30 11:19:37	0|sipa|a decade before it was released, i think
201 2016-09-30 11:19:46	0|wumpus|luke-jr: did that have a special protocol to route the 3D drawing commands?
202 2016-09-30 11:19:51	0|luke-jr|wumpus: no, just VNC
203 2016-09-30 11:20:01	0|luke-jr|Tight/JPEG encoding I guess
204 2016-09-30 11:20:03	0|wumpus|luke-jr: eh GPU passthrough is essentially the same
205 2016-09-30 11:20:16	0|luke-jr|wumpus: not really. that's just for the rendering :P
206 2016-09-30 11:20:30	0|luke-jr|I didn't view on that GPU
207 2016-09-30 11:20:39	0|wumpus|okay, right
208 2016-09-30 11:21:51	0|luke-jr|someday when I have free time (haha) maybe I'll finish .hack XD
209 2016-09-30 11:26:20	0|midnightmagic|dwm or fail :-P
210 2016-09-30 11:26:35	0|luke-jr|apparently I'm going to have to find *something*
211 2016-09-30 11:27:44	0|luke-jr|annoying, Qt5 has decided you need KDE to get any theming, so I'll end up losing that I guess
212 2016-09-30 11:28:18	0|sipa|my window manager uses 7.7 MB of RSS
213 2016-09-30 11:29:22	0|sipa|my terminal emulator 61 MB, Xord 112 MB, and firefox 987 MB
214 2016-09-30 11:29:29	0|sipa|*Xorg
215 2016-09-30 11:30:58	0|wumpus|luke-jr: you can also theme qt through gtk *ducks*
216 2016-09-30 11:31:20	0|luke-jr|>_<
217 2016-09-30 11:31:38	0|luke-jr|I think that needs GNOME running?
218 2016-09-30 11:32:00	0|wumpus|I don't think so, Ubuntu uses it too and Unity is not GNOME
219 2016-09-30 11:32:23	0|luke-jr|unfortunately, half the reason I want Qt is because GTK is terrible
220 2016-09-30 11:32:29	0|wumpus|I think it's just a qt plugin that themes-like-gtk
221 2016-09-30 11:39:05	0|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.
222 2016-09-30 11:39:39	0|wumpus|which doesn't say that much, a lot just gets hacked on
223 2016-09-30 11:42:21	0|luke-jr|I think it has the ability, but it's not possible to configure it without a "platform module"
224 2016-09-30 11:51:52	0|sipa|if you use mmap with MAP_FIXED and specify nullptr as address, are you afterwards able to dereference nullptr?
225 2016-09-30 11:52:17	0|luke-jr|sipa: I think dosbox uses this?
226 2016-09-30 11:52:22	0|sipa|assuming you make the compiler sufficiently dumb to not optimize things away that it believes are impossible
227 2016-09-30 11:52:42	0|luke-jr|of course, C still considers it undefined behaviour
228 2016-09-30 11:52:48	0|luke-jr|I think recent Linux has an option to block it too
229 2016-09-30 11:52:56	0|luke-jr|since it's been used in exploits or something
230 2016-09-30 12:43:08	0|wumpus|sipa: yes, if the OS allows that that's a valid way to mmap the null page
231 2016-09-30 12:43:45	0|wumpus|I vaguely remember modern linux distros disallow it by default
232 2016-09-30 12:43:57	0|wumpus|because it could be used to trick the kernel in some cases
233 2016-09-30 12:44:40	0|wumpus|luke-jr: yes exactly
234 2016-09-30 12:47:35	0|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
235 2016-09-30 12:51:38	0|sipa|sure, it's undefined behaviour to dereference a null pointer, i assume
236 2016-09-30 12:52:46	0|wumpus|indeed
237 2016-09-30 12:53:07	0|wumpus|so statements just disappear, sometimes at random,m depending on the mood of the compiler
238 2016-09-30 12:53:48	0|wumpus|recompile and they may be there again. C is a jungle with its undefined behavior...
239 2016-09-30 12:54:03	0|wumpus|(well recompile with a small change, maybe in a different function)
240 2016-09-30 12:55:13	0|wumpus|your best bet is to do it in assembly, then use a volatile asm() block which the comiler isnot allowed to optimize away
241 2016-09-30 12:55:33	0|wumpus|or even a function defined in an auxiliary .s file
242 2016-09-30 13:06:32	0|sipa|c++ has even more undefined behaviour :)
243 2016-09-30 13:07:03	0|wumpus|oh yes, I certainly didn't mean that C++ is any better in that regard
244 2016-09-30 13:07:04	0|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
245 2016-09-30 15:04:02	0|GitHub8|13bitcoin/06master 14b82f493 15jnewbery: Add option to run bitcoin-util-test.py manually
246 2016-09-30 15:04:02	0|GitHub8|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/90adfabd5daa...ef0801bd1381
247 2016-09-30 15:04:03	0|GitHub8|13bitcoin/06master 14ef0801b 15Wladimir J. van der Laan: Merge #8830: [test] Add option to run bitcoin-util-test.py manually...
248 2016-09-30 15:04:12	0|GitHub48|[13bitcoin] 15laanwj closed pull request #8830: [test] Add option to run bitcoin-util-test.py manually (06master...06test-bitcoin-util-manually) 02https://github.com/bitcoin/bitcoin/pull/8830
249 2016-09-30 15:11:20	0|GitHub121|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ef0801bd1381...9bc6a6bd7b0d
250 2016-09-30 15:11:21	0|GitHub121|13bitcoin/06master 14305087b 15Wladimir J. van der Laan: net: Hardcode protocol sizes and use fixed-size types...
251 2016-09-30 15:11:21	0|GitHub121|13bitcoin/06master 1441e58fa 15Wladimir J. van der Laan: net: Consistent checksum handling...
252 2016-09-30 15:11:22	0|GitHub121|13bitcoin/06master 149bc6a6b 15Wladimir J. van der Laan: Merge #8822: net: Consistent checksum handling...
253 2016-09-30 15:11:25	0|GitHub171|[13bitcoin] 15jl2012 opened pull request #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h (06master...06consensusnulldummy) 02https://github.com/bitcoin/bitcoin/pull/8848
254 2016-09-30 15:11:35	0|GitHub165|[13bitcoin] 15laanwj closed pull request #8822: net: Consistent checksum handling (06master...062016_09_normalize_checksum_handling) 02https://github.com/bitcoin/bitcoin/pull/8822
255 2016-09-30 15:13:15	0|GitHub8|[13bitcoin] 15czzarr opened pull request #8849: print P2WSH redeemScript in getrawtransaction if it s not a pubkey (06master...06print-p2wsh-redeemscript-in-getrawtransaction) 02https://github.com/bitcoin/bitcoin/pull/8849
256 2016-09-30 15:28:45	0|GitHub8|[13bitcoin] 15laanwj opened pull request #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment (06master...062016_09_beginptr_deprecation) 02https://github.com/bitcoin/bitcoin/pull/8850
257 2016-09-30 16:20:22	0|GitHub54|13bitcoin/06master 14a92bf4a 15Matthew King: bitcoind: Daemonize using daemon(3)...
258 2016-09-30 16:20:22	0|GitHub54|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9bc6a6bd7b0d...fb24d7eeb47e
259 2016-09-30 16:20:23	0|GitHub54|13bitcoin/06master 14fb24d7e 15Wladimir J. van der Laan: Merge #8813: bitcoind: Daemonize using daemon(3)...
260 2016-09-30 16:20:35	0|GitHub61|[13bitcoin] 15laanwj closed pull request #8813: bitcoind: Daemonize using daemon(3) (06master...062016_09_daemonize) 02https://github.com/bitcoin/bitcoin/pull/8813
261 2016-09-30 16:53:59	0|wumpus|anything else ready for merge?
262 2016-09-30 16:57:02	0|MarcoFalke|probably not. The remaining 130 pulls are waiting for review :P
263 2016-09-30 16:58:10	0|wumpus|or rebase
264 2016-09-30 16:58:55	0|wumpus|e.g. https://github.com/bitcoin/bitcoin/pull/8375
265 2016-09-30 16:59:09	0|gmaxwell|or to be put out of their misery. :P
266 2016-09-30 16:59:13	0|jtimon|in https://github.com/bitcoin/bitcoin/projects/5 please move #8526  to done
267 2016-09-30 16:59:55	0|wumpus|but it happens that a pull has tons of ACKs and I miss it, that's why I asked
268 2016-09-30 16:59:58	0|wumpus|heh :P
269 2016-09-30 17:00:42	0|wumpus|jtimon: thanks, done
270 2016-09-30 17:00:52	0|jtimon|thanks, np
271 2016-09-30 17:01:28	0|GitHub100|[13bitcoin] 15MarcoFalke closed pull request #8633: Ugly hack to print out tests as they are run to mitigate travis timeouts (06master...06test-driver-hack) 02https://github.com/bitcoin/bitcoin/pull/8633
272 2016-09-30 17:03:51	0|jtimon|#8337 would make #8493 easier to read/replace but the acks were before the last rebase...re-review (or new review) welcomed...
273 2016-09-30 17:12:55	0|GitHub192|[13bitcoin] 15MarcoFalke opened pull request #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem) (06master...06Mf1610-walletDeriveNewChildPStratem) 02https://github.com/bitcoin/bitcoin/pull/8851
274 2016-09-30 17:13:56	0|wumpus|jtimon: will take a look
275 2016-09-30 17:14:25	0|wumpus|MarcoFalke: hah also looking at that pull
276 2016-09-30 17:15:57	0|MarcoFalke|I caused the merge conflict so I felt responsible :)
277 2016-09-30 17:44:41	0|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."
278 2016-09-30 17:45:50	0|wumpus|so that's deliberate, so much for accidental corruption of a function pointer, but why
279 2016-09-30 17:56:25	0|GitHub129|13bitcoin/06master 14e198c52 15Patrick Strateman: Move key derivation logic from GenerateNewKey to DeriveNewChildKey
280 2016-09-30 17:56:25	0|GitHub129|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fb24d7eeb47e...940748b4b087
281 2016-09-30 17:56:26	0|GitHub129|13bitcoin/06master 14940748b 15Wladimir J. van der Laan: Merge #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem)...
282 2016-09-30 17:56:40	0|GitHub187|[13bitcoin] 15laanwj closed pull request #8375: [Wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (06master...062016-07-19-cwallet-derivenewkey) 02https://github.com/bitcoin/bitcoin/pull/8375
283 2016-09-30 17:56:43	0|GitHub44|[13bitcoin] 15laanwj closed pull request #8851: [wallet] Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem) (06master...06Mf1610-walletDeriveNewChildPStratem) 02https://github.com/bitcoin/bitcoin/pull/8851
284 2016-09-30 18:28:59	0|wumpus|paveljanik: congrats on finding the problem
285 2016-09-30 18:32:15	0|paveljanik|wumpus, I was not able to parse the line mentally ;-)
286 2016-09-30 18:32:31	0|paveljanik|I had to diff the left side and right side...
287 2016-09-30 18:33:06	0|wumpus|paveljanik: I don't think anyone is, as it would involve a mental infinite loop
288 2016-09-30 18:33:13	0|wumpus|but I hadn't noticed it
289 2016-09-30 18:34:12	0|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
290 2016-09-30 18:35:01	0|paveljanik|I think this is a bug in the compiler.
291 2016-09-30 18:35:24	0|wumpus|I don't know. How would you convert it to assembly if you were a compiler?
292 2016-09-30 18:35:43	0|paveljanik|I'd error.
293 2016-09-30 18:35:50	0|wumpus|it just makes no sense, garbage in, garbage out
294 2016-09-30 18:35:53	0|wumpus|yes okay
295 2016-09-30 18:42:30	0|GitHub16|[13bitcoin] 15laanwj closed pull request #8795: [doc] Mention Gitian building script in documents. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/8795
296 2016-09-30 18:49:03	0|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
297 2016-09-30 18:49:11	0|cfields_|blah, nice timing
298 2016-09-30 18:50:10	0|GitHub95|[13bitcoin] 15laanwj opened pull request #8852: Mention Gitian building script in doc (06master...062016_09_laudaa_master) 02https://github.com/bitcoin/bitcoin/pull/8852
299 2016-09-30 18:50:26	0|cfields_|wumpus: oh right, I meant to backport those 2 fixes for 0.13...
300 2016-09-30 18:51:30	0|GitHub151|13bitcoin/06master 14203e2dd 15Lauda: Mention Gitian building script in doc.
301 2016-09-30 18:51:30	0|GitHub151|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/940748b4b087...7b784cc2bbcd
302 2016-09-30 18:51:31	0|GitHub151|13bitcoin/06master 147b784cc 15Wladimir J. van der Laan: Merge #8852: Mention Gitian building script in doc (Laudaa)...
303 2016-09-30 18:51:40	0|GitHub118|[13bitcoin] 15laanwj closed pull request #8852: Mention Gitian building script in doc (Laudaa) (06master...062016_09_laudaa_master) 02https://github.com/bitcoin/bitcoin/pull/8852
304 2016-09-30 18:51:46	0|wumpus|cfields_: makes sense
305 2016-09-30 18:55:48	0|wumpus|cfields_: there's still oppertunity for that, 0.13.1 isn't out yet! :)
306 2016-09-30 18:56:49	0|cfields_|wumpus: I figured you'd yell :). Doing now.
307 2016-09-30 18:57:46	0|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
308 2016-09-30 18:58:36	0|wumpus|cfields_: yes sorry, so many things to keep track of
309 2016-09-30 18:59:24	0|paveljanik|compilers are afraid of errors. because their users would point to them... But sometime the bug is between the keyboard and the computer :-)
310 2016-09-30 18:59:25	0|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.
311 2016-09-30 18:59:30	0|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...
312 2016-09-30 18:59:42	0|paveljanik|yes, definitely.
313 2016-09-30 19:05:03	0|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
314 2016-09-30 19:32:35	0|GitHub161|[13bitcoin] 15czzarr opened pull request #8853: add p2sh and segwit options to bitcoin-tx outscript command (06master...06add-p2sh-segwit-options-to-bitcoin-tx) 02https://github.com/bitcoin/bitcoin/pull/8853
315 2016-09-30 19:34:00	0|GitHub180|[13bitcoin] 15czzarr closed pull request #8853: add p2sh and segwit options to bitcoin-tx outscript command (06master...06add-p2sh-segwit-options-to-bitcoin-tx) 02https://github.com/bitcoin/bitcoin/pull/8853
316 2016-09-30 19:34:18	0|wumpus|huh
317 2016-09-30 19:35:31	0|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
318 2016-09-30 19:36:04	0|BlueMatt|wumpus: same guy, meant to get private review before pr'ing to bitcoin core directly
319 2016-09-30 19:36:25	0|wumpus|BlueMatt: ok :)
320 2016-09-30 19:37:53	0|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.
321 2016-09-30 20:10:15	0|gmaxwell|I think we all know whats needed for 0.13 mostly.
322 2016-09-30 20:15:03	0|BlueMatt|what are the current thoughts on GetWitnessHash caching? (and before gmaxwell screams again, this isnt about 0.13.1)
323 2016-09-30 20:18:26	0|sdaftuar|BlueMatt: i think we should do it, right?  (you mean caching it in the CTransaction object?)
324 2016-09-30 20:18:35	0|BlueMatt|sdaftuar: yes
325 2016-09-30 20:19:39	0|sdaftuar|i guess it wastes memory for non-segwit transactions, but it seems to me like we'll want it in the long run
326 2016-09-30 20:19:42	0|gmaxwell|Sipa has a PR that takes a good step towards making a flat const ctransaction object.
327 2016-09-30 20:20:12	0|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.
328 2016-09-30 20:20:19	0|wumpus|https://github.com/bitcoin/bitcoin/pull/8580
329 2016-09-30 20:20:44	0|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 :(
330 2016-09-30 20:20:58	0|sdaftuar|gmaxwell: i had a moment of brief panic the other day when i noticed the CTransaction::operator== function
331 2016-09-30 20:21:04	0|sdaftuar|which just compares the stored hashes
332 2016-09-30 20:21:20	0|gmaxwell|Well the flat object wouldn't be our seralization.
333 2016-09-30 20:21:45	0|gmaxwell|e.g. you wouldn't want it to have varints in it. :)
334 2016-09-30 20:21:53	0|BlueMatt|{
335 2016-09-30 20:21:53	0|BlueMatt|@@ -76,2 +76,4 @@ uint256 CTransaction::GetWitnessHash() const
336 2016-09-30 20:21:53	0|BlueMatt|diff --git a/src/primitives/transaction.cpp b/src/primitives/transaction.cpp
337 2016-09-30 20:21:54	0|BlueMatt|+    if (wit.IsNull())
338 2016-09-30 20:21:54	0|BlueMatt|+        return GetHash();
339 2016-09-30 20:22:28	0|BlueMatt|gmaxwell: suresure, but it still sucks since you cant prealloc the right size object from the start
340 2016-09-30 20:22:33	0|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.
341 2016-09-30 20:22:47	0|BlueMatt|def need that for FIBRE ^
342 2016-09-30 20:22:53	0|BlueMatt|ehh, that patch, that is
343 2016-09-30 20:22:58	0|gmaxwell|BlueMatt: yea, it would end up doing something like deseralize into a mutable transaction then convert that to flat.
344 2016-09-30 20:23:21	0|BlueMatt|gmaxwell: hmm, would that actually be faster?
345 2016-09-30 20:24:02	0|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.
346 2016-09-30 20:24:21	0|BlueMatt|well the deserialization into a mutable transaction would do all the same heap allocations?
347 2016-09-30 20:25:08	0|gmaxwell|hm okay indeed it would in the way I described it. Guess more cleverness would be required.
348 2016-09-30 20:25:24	0|wumpus|q
349 2016-09-30 20:25:47	0|BlueMatt|gmaxwell: yea, this is why i wanted to just use our serialization and copy to memory, but you cant really do that :(
350 2016-09-30 20:25:55	0|BlueMatt|damn DRY serialization format :(
351 2016-09-30 20:27:53	0|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.
352 2016-09-30 20:28:46	0|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.
353 2016-09-30 20:29:30	0|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)
354 2016-09-30 20:29:42	0|BlueMatt|it does ruin our nicely-DRY serialization, but it might be a valid tradeoff here
355 2016-09-30 20:30:43	0|gmaxwell|other alternative is to parse twice to extra the length first, but I expect that to be slower than a tidy copy.
356 2016-09-30 20:31:27	0|BlueMatt|quite possibly
357 2016-09-30 20:34:36	0|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
358 2016-09-30 20:36:00	0|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.
359 2016-09-30 20:36:06	0|gmaxwell|s/thin/think/
360 2016-09-30 20:37:12	0|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.
361 2016-09-30 20:38:28	0|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.
362 2016-09-30 20:39:09	0|gmaxwell|so a sizing parse would only have to handle the first O(txin+txout) bytes or so.
363 2016-09-30 20:48:38	0|BlueMatt|yea, but if we have a nice in-memory blob format I can just make FIBRE use it :p
364 2016-09-30 20:48:42	0|BlueMatt|then FIBRE will be really fast