1 2013-01-28 00:03:48 <sipa> ha
2 2013-01-28 00:04:01 <gmaxwell> sipa: 'satoshi' varints could simply have specified that each size up subtracts the maximum of the prior size.
3 2013-01-28 00:04:39 <gmaxwell> Doing so doesn't make the code to read it really any more complex, and it makes it non-redundant and more compact.
4 2013-01-28 00:05:08 <sipa> yes, agree
5 2013-01-28 00:05:31 <sipa> so there is a variation possible that is guaranteed to be never less efficient
6 2013-01-28 00:07:05 <HM> it's kind of strange to try and save a few bits anyway when you're transmitting lengthy pseudorandom hashes and scripts
7 2013-01-28 00:07:28 <sipa> sure - it's more about guaranteeing a normalization
8 2013-01-28 00:08:00 <sipa> you could guarantee that otherwise too by saying "implementations must always use the shortest possible form", but that is very easy to forget to check
9 2013-01-28 00:10:22 <HM> many of my projects that have needed mini protocols have utilised protocol buffers. i can't be arsed twiddling with bits and hand writing such code.
10 2013-01-28 00:10:46 <sipa> protocol buffers' integer encoding is also redundant, actually
11 2013-01-28 00:10:53 <HM> it's base 128
12 2013-01-28 00:10:58 <sipa> yes
13 2013-01-28 00:11:01 <gmaxwell> HM: well, it's important that transactions be maximally small.. I agree that the space savings isn't paramount, though as sipa says??? the point wouldn't be to save space... thats just a bonus.
14 2013-01-28 00:11:14 <HM> indeed
15 2013-01-28 00:11:45 <sipa> HM: but you can manually construct a protocol buffer serialization that is not the smallest possible, and is accepted
16 2013-01-28 00:11:58 <gmaxwell> ugh.
17 2013-01-28 00:12:45 <sipa> non-redundant versions are much more cpu intensive, though
18 2013-01-28 00:13:32 <HM> yeah but pb is designed to be a flexible format, so you'd never be hashing it in that form anyway because normalising it isn't simple
19 2013-01-28 00:13:43 <gmaxwell> HM: haha
20 2013-01-28 00:14:11 <sipa> indeed, they lack normalisation in other ways too
21 2013-01-28 00:14:18 <HM> you can just send someone redundant fields with field id's that they don't recognise, fields can also be in any order
22 2013-01-28 00:14:34 <gmaxwell> sipa: not for anything we're doing at least??? I mean, you end up with a branch for difference sizes, just insert the subtraction in there. It should be free on any modern cpu.
23 2013-01-28 00:15:04 <HM> pfft
24 2013-01-28 00:15:10 <HM> future is gzipped json, didn't you hear?
25 2013-01-28 00:15:19 <sipa> in base64
26 2013-01-28 00:15:26 <HM> no no, base 58 :)
27 2013-01-28 00:15:43 <sipa> ACTION kills himself
28 2013-01-28 00:15:50 <gmaxwell> 58 isn't prime. Base59!
29 2013-01-28 00:16:24 <HM> but then you can't rot29 it
30 2013-01-28 00:16:39 <sipa> you mean triple-rot29, i hope
31 2013-01-28 00:16:48 <sipa> single rot29 is considered broken these days
32 2013-01-28 00:17:24 <HM> well there goes my wallet
33 2013-01-28 00:19:07 <sipa> HM: actually, i'd prefer base58-encoded zip files containing png's with QR codes that encode the data, itself encoded as JSON
34 2013-01-28 00:19:33 <gmaxwell> s/zip/rar/
35 2013-01-28 00:19:42 <HM> compressing a png isn't going to gain you much space
36 2013-01-28 00:19:48 <sipa> wait wait wait
37 2013-01-28 00:19:50 <kjj> delivered by avian carrier, I hope
38 2013-01-28 00:19:52 <HM> maybe an animated gif
39 2013-01-28 00:19:56 <sipa> are we trying to gain space? :o
40 2013-01-28 00:20:22 <gmaxwell> HM: thats why you mandate the png itself be uncompressed??? avoids mucking up the rar compression.
41 2013-01-28 00:20:23 <HM> the point wouldn't be to save space... thats just a bonus.
42 2013-01-28 00:20:41 <sipa> HM: you do know there's a parent on repeatedly compressing a file, to reach arbitrarily small sizes, right?
43 2013-01-28 00:20:45 <sipa> *patent
44 2013-01-28 00:20:52 <HM> yes, it's called rename
45 2013-01-28 00:21:01 <gmaxwell> they keep it right next to the perpetual motion machine patent.
46 2013-01-28 00:21:23 <HM> read byte from file, truncate file, append to filename :P
47 2013-01-28 00:21:28 <HM> zomg 0 byte file
48 2013-01-28 00:22:07 <sipa> http://gailly.net/05533051.html
49 2013-01-28 00:26:06 <gmaxwell> sipa: if it makes you feel better that patent was abandoned (applicant failed to pay maintance fees) and is no longer valid.
50 2013-01-28 00:26:46 <sipa> gmaxwell: thanks for saving my trust in the human kind
51 2013-01-28 00:26:59 <sipa> s/saving/restoring/
52 2013-01-28 00:29:15 <gmaxwell> Also, the patent was initially rejected by the examiner and the applicant fought the rejection.
53 2013-01-28 00:29:35 <sipa> wow!
54 2013-01-28 00:30:21 <gmaxwell> Because it was before 2002 I can't get the filewrapper online, so I dunno what the examiner says. (It would cost $200 to get the file??? too much for idle curiosity)
55 2013-01-28 00:30:54 <gmaxwell> I expect the examiner pointed out it was impossible and the applicant pointed to his weasel words and they allowed it.
56 2013-01-28 00:31:13 <gmaxwell> (they amended their claims too??? so they may have added the weasel words in response)
57 2013-01-28 00:32:22 <gmaxwell> Another interesting tidbit??? they failed to pay their maintenance fees back in 2004 and filed a petition for permission to pay them late. It was granted ... but then they never paid them and the patent lapsed in 2008.
58 2013-01-28 00:39:42 <andytoshi> but why pay for such a patent? nobody could ever infringe
59 2013-01-28 00:40:52 <gmaxwell> There are a number of reasons. In this case the inventor probably didn't know that and thought he had something, he may have been being exploited by an attorney he was paying to do the application.
60 2013-01-28 00:41:21 <gmaxwell> But a patent is fine resume padding, so it could be rational to get one which could never be enforced just to put it on your resume.
61 2013-01-28 00:41:30 <andytoshi> bizarre
62 2013-01-28 00:41:46 <CodeShark> lol
63 2013-01-28 00:42:13 <gmaxwell> Plenty of large companies get unenforcable patents just to pad their warchest... making sure you don't infringe it is still a cost. (rather: they don't care if its enforcable or not, and its generally easier to get non-enforcable patents)
64 2013-01-28 00:43:11 <CodeShark> getting a patent is cheap - it's the litigation that's expensive
65 2013-01-28 00:43:28 <gmaxwell> E.g. any patent claim longer than half a page is almost certantly non-enforcable. (~all of the text is limiting, so with enough of it nothing can infringe)
66 2013-01-28 00:43:45 <gmaxwell> But a long claim is almost certantly novel and distinct from the prior art!
67 2013-01-28 01:17:36 <HM> scary
68 2013-01-28 01:17:49 <HM> python doesn't care if you declare 2 classes of the same name in one file
69 2013-01-28 01:17:55 <HM> must merge them
70 2013-01-28 01:25:47 <Mad7Scientist> ;;getrating carryon
71 2013-01-28 01:25:48 <gribble> WARNING: Currently not authenticated. User carryon, rated since Fri Jan 25 21:29:00 2013. Cumulative rating 1, from 1 total ratings. Received ratings: 1 positive, 0 negative. Sent ratings: 1 positive, 0 negative. Details: http://bitcoin-otc.com/viewratingdetail.php?nick=carryon
72 2013-01-28 01:28:58 <jgarzik> Mad7Scientist: try /msg gribble please
73 2013-01-28 02:52:03 <CodeShark> are there any other distros of linux besides ubuntu, debian, and gentoo that should be supported by the bitcoind configure file?
74 2013-01-28 02:52:16 <kjj> slackware
75 2013-01-28 02:52:49 <CodeShark> any estimates on the bitcoind userbase using slackware? :)
76 2013-01-28 02:53:01 <kjj> >=1
77 2013-01-28 02:53:05 <CodeShark> lol
78 2013-01-28 02:53:10 <andytoshi> arch
79 2013-01-28 02:54:15 <andytoshi> CodeShark: by 'configure', do you mean you are setting up autotools?
80 2013-01-28 02:54:25 <gmaxwell> CodeShark: uh. if you're asking about supporting distros in the configure, you're failing at autotools.
81 2013-01-28 02:54:31 <CodeShark> no, I'm handwriting the script
82 2013-01-28 02:54:31 <Luke-Jr> CodeShark: HP-UX, SunOS
83 2013-01-28 02:54:39 <Luke-Jr> gmaxwell: he's not using autotools :P
84 2013-01-28 02:54:55 <CodeShark> autotools is a huge bloated monster :)
85 2013-01-28 02:55:10 <Luke-Jr> CodeShark: but it works well
86 2013-01-28 02:55:12 <gmaxwell> ugh.
87 2013-01-28 02:55:21 <Luke-Jr> CodeShark: also, don't forget to make sure cross-compiling works! :P
88 2013-01-28 02:55:22 <andytoshi> it does work well, unfortunately
89 2013-01-28 02:56:02 <gmaxwell> Luke-Jr: as soon as you stipulate cross-compiling people end up reinventing autotools poorly in order to comply.
90 2013-01-28 02:59:16 <CodeShark> no cross-compiling for now...this is not intended for production builds - it's intended for users who want to compile it themselves...and very few windows users will
91 2013-01-28 02:59:25 <Luke-Jr> gmaxwell: yeah, when I first saw his work, I decided I'd better just keep my mouth shut as long as I wasn't planning to do a proper autotools myself <.<
92 2013-01-28 03:01:51 <Luke-Jr> CodeShark: btw, did you get my point about MACHINE? uname -m is NEVER useful for configure scripts. ever.
93 2013-01-28 03:02:26 <CodeShark> i386 vs x86_64?
94 2013-01-28 03:02:55 <CodeShark> I could imagine that being useful in some instances
95 2013-01-28 03:03:04 <Luke-Jr> CodeShark: but it doesn't tell you which one the OS is
96 2013-01-28 03:03:06 <Luke-Jr> just the kernel
97 2013-01-28 03:03:18 <Luke-Jr> for example, I run 32-bit, but my kernel is 64-bit, so uname -m will tell you x86_64
98 2013-01-28 03:03:24 <Luke-Jr> if you compile for x86_64 somehow, it won't run
99 2013-01-28 03:03:53 <Luke-Jr> and x32 systems always have x86_64 kernels
100 2013-01-28 03:04:03 <CodeShark> wait...huh?
101 2013-01-28 03:04:47 <Luke-Jr> CodeShark: x86_64 kernels can run more than just x86_64 OS ;)
102 2013-01-28 03:05:04 <Luke-Jr> they can also run regular i386 OS, or x32 OS
103 2013-01-28 03:05:38 <CodeShark> isn't the kernel like the main part of the OS?
104 2013-01-28 03:05:52 <etotheipi_> does bitcoin-qt finally register itself for URI-handling on all OS, now?
105 2013-01-28 03:05:55 <jgarzik> ACTION ditto's luke-jr
106 2013-01-28 03:05:55 <Luke-Jr> no, it's just the hardware go-between more or less
107 2013-01-28 03:06:07 <jgarzik> I prefer autotools, and used it in picocoin, cpuminer, ...
108 2013-01-28 03:06:30 <jgarzik> ACTION noticed the pull requests's "configure" was hand-rolled... but not prepared to do the work myself to get autotools working for bitcoin
109 2013-01-28 03:06:39 <jgarzik> so I kept my mouth shut
110 2013-01-28 03:06:43 <CodeShark> lol
111 2013-01-28 03:06:43 <Luke-Jr> CodeShark: gcc -dumpmachine <-- useful
112 2013-01-28 03:06:50 <Diablo-D3> jgarzik: lol
113 2013-01-28 03:08:08 <CodeShark> so everyone knows how to do it with autotools but nobody wants to...
114 2013-01-28 03:08:42 <Luke-Jr> CodeShark: don't let us discourage you though, your hand-script is certainly better than nothing at all
115 2013-01-28 03:09:06 <andytoshi> CodeShark: i don't know how :)
116 2013-01-28 03:09:36 <CodeShark> I still don't follow the 32 bit OS on 64-bit kernel thing. I understand 32-bit applications on a 64-bit OS...but 32-bit OS on a 64-bit kernel?
117 2013-01-28 03:09:54 <andytoshi> CodeShark: you can have all your libraries be 32-bit
118 2013-01-28 03:10:02 <andytoshi> including libc, which is pretty-much your OS
119 2013-01-28 03:10:20 <Luke-Jr> CodeShark: 32-bit applications don't *actually* run on a 64-bit OS - what you're thinking is really a hybrid 32/64 OS :p
120 2013-01-28 03:10:21 <CodeShark> libraries yes - but the kernel is still 64-bits
121 2013-01-28 03:10:35 <Luke-Jr> CodeShark: the kernel doesn't matter to applications
122 2013-01-28 03:11:50 <CodeShark> I agree that it is more important what the libraries are than the kernel as far as building software...but if the kernel is only 32-bits, you will not get anything from trying to install and link to a 64-bit library
123 2013-01-28 03:12:10 <CodeShark> as far as performance, etc..
124 2013-01-28 03:12:15 <Luke-Jr> CodeShark: of course, an i386 kernel can only run an i386 OS
125 2013-01-28 03:12:37 <Luke-Jr> it's the x86_64 kernel that can run 3 flavours of OS architectures
126 2013-01-28 03:16:30 <CodeShark> an i386 could still run 64-bit libraries using emulation
127 2013-01-28 03:18:24 <CodeShark> anyhow, I'm not sure I've heard of OS architecture and kernel architecture being treated as two separate things - I've always thought of the kernel as the most important part of the OS...and libraries are libraries.
128 2013-01-28 03:18:28 <Luke-Jr> or MIPS, PPC, or ARM even, but that's not really as relevant I think :P
129 2013-01-28 03:18:42 <CodeShark> so to me, the kernel and the OS are inseparable
130 2013-01-28 03:19:05 <CodeShark> the libraries, the shell, etc...they can also be considered part of the OS - but without the kernel you cannot have an OS at all
131 2013-01-28 03:19:11 <Luke-Jr> CodeShark: well, thankfully that mistake plagues only very few programs anymore ???
132 2013-01-28 03:19:22 <Luke-Jr> CodeShark: the kernel is the easiest part of the OS to replace
133 2013-01-28 03:20:10 <Luke-Jr> you could replace Linux with FreeBSD's kernel and (assuming it supports all your hardware) never know the difference
134 2013-01-28 03:20:30 <Luke-Jr> (Debian in fact supports this)
135 2013-01-28 03:21:51 <andytoshi> to be fair, systemd would stop working and /proc and /sys would look different
136 2013-01-28 03:22:25 <Luke-Jr> andytoshi: please, keep systemd away from my systems regardless of kernel
137 2013-01-28 03:22:29 <Luke-Jr> init works fine
138 2013-01-28 03:22:48 <Luke-Jr> anyhow, I meant from the perspective of an end user, not a low-level hacker ;)
139 2013-01-28 03:23:18 <gmaxwell> Systemd seems pretty nice actually. I liked it more than I expected, and I didn't even expect to dislike it.
140 2013-01-28 03:23:40 <andytoshi> ACTION goes back to LWN, where there's none of this awful systemd arguing..
141 2013-01-28 03:24:16 <Luke-Jr> gmaxwell: besides init working great and I'd miss it and have to relearn everything??? systemd's assimilation of udev recently screwed me out of a whole day
142 2013-01-28 03:25:08 <gmaxwell> andytoshi: systemd's non-portablity is arguably a bug, though its own its developers defend... in either case that doesn't really invalidate Luke's point. From 20 layers down the stack the kernel is mostly only relevent when its buggy or broken. :P
143 2013-01-28 03:25:36 <andytoshi> i really wish systemd was portable, because it's actually a killer app for linux for me
144 2013-01-28 03:25:52 <andytoshi> but it's not BSD-licensed, so i can't see how any of the BSD's could use it, even if they were able to
145 2013-01-28 03:26:12 <Luke-Jr> andytoshi: how is it a killer app when it doesn't do anything new?
146 2013-01-28 03:26:42 <Luke-Jr> ACTION wonders what he did to get on stamit's PM list
147 2013-01-28 03:26:46 <andytoshi> it does things much more simply, and does all the awful PID juggling for me
148 2013-01-28 03:27:09 <andytoshi> so i can write .service files without any trouble, and not worry that i'll be rewriting them every time i switch distro
149 2013-01-28 03:27:31 <Luke-Jr> ??? assuming every distro uses systemd <.<
150 2013-01-28 03:27:43 <andytoshi> well, sure
151 2013-01-28 03:28:01 <CodeShark> what about upstart?
152 2013-01-28 03:28:09 <andytoshi> i've never used upstart tbh
153 2013-01-28 03:28:22 <Luke-Jr> CodeShark: same thing as systemd more or less
154 2013-01-28 03:28:35 <Luke-Jr> unnecessary reinventing the wheel
155 2013-01-28 03:28:42 <andytoshi> there are some pretty big technical differences
156 2013-01-28 03:29:03 <andytoshi> systemd uses cgroups, so it can track processes and see when they die, consistently
157 2013-01-28 03:29:05 <jgarzik> systemd breaks everything, but the end result seems quite fast
158 2013-01-28 03:29:13 <gmaxwell> I think upstart takes most of the compatiblity costs (though it pretends to be a bit more backwards compatible) without most of the benefits, I was not a big fan of it.
159 2013-01-28 03:29:43 <Luke-Jr> a well-configured init is pretty fast
160 2013-01-28 03:29:48 <Luke-Jr> especially if you enable parallel boot
161 2013-01-28 03:29:51 <andytoshi> jgarzik, Luke-Jr, lennart just posted a "30 myths about systemd" post which talks about a bit of this
162 2013-01-28 03:30:07 <Luke-Jr> andytoshi: I find the myths are about init.
163 2013-01-28 03:30:23 <Luke-Jr> andytoshi: upstart and systemd seem to pretend init doesn't do 90% of what it can
164 2013-01-28 03:30:47 <andytoshi> http://0pointer.de/blog/projects/the-biggest-myths
165 2013-01-28 03:31:19 <gmaxwell> Another more subtle argument is that change is a fact of life??? and some parts of the linux ecosystem are changing in ugly ways (e.g. I've been generally unimpressed by everything within 10 meters of gconf). Systemd at least clearly understands the positive values of the things it is replacing, and so competent change ought to be rewarded by embracing it so that people who try to push incompent change can't argue that I'm rejecting all ...
166 2013-01-28 03:31:25 <gmaxwell> ... change.
167 2013-01-28 03:32:28 <Luke-Jr> A package involving 69 individual binaries can hardly be called monolithic. <-- this person is arguing semantics; if those 69 binaries only work with each other, it's still monolithic
168 2013-01-28 03:33:11 <CodeShark> no, if they can work independently I disagree
169 2013-01-28 03:33:22 <CodeShark> they are monolithic if they cease to function if you remove any of them
170 2013-01-28 03:33:47 <andytoshi> gmaxwell, i bet i can remove gconf from my system with no ill effect
171 2013-01-28 03:34:12 <andytoshi> whn yum is done stalling i'll let you know
172 2013-01-28 03:34:53 <andytoshi> wth, emacs depends on it
173 2013-01-28 03:35:19 <gmaxwell> HAHAH
174 2013-01-28 03:35:24 <gmaxwell> Exactly
175 2013-01-28 03:35:55 <gmaxwell> Seriously, forget I mentioned it. The rage gconf will induce as you peel back the layers will shorten your life. It's not worth it.
176 2013-01-28 03:36:37 <Luke-Jr> I don't have gconf installed.
177 2013-01-28 03:36:39 <gmaxwell> (also generally, anything touching d-bus, ??? which I suppose includes systemd, oh well..)
178 2013-01-28 03:36:51 <Luke-Jr> haven't made any particular effort to avoid it (specifically) either
179 2013-01-28 03:36:58 <Diablo-D3> FUCKING SYSTEMD
180 2013-01-28 03:37:01 <Diablo-D3> WHY WONT IT DIE
181 2013-01-28 03:37:08 <gmaxwell> Luke-Jr: Yea, you're not on a distro so afflicted by the particular desktop stupidity that fedora is...
182 2013-01-28 03:37:12 <Diablo-D3> ITS SO GODDAMNED HORRIBLE
183 2013-01-28 03:37:15 <Diablo-D3> JUST KILL IT ALREADY
184 2013-01-28 03:37:32 <Diablo-D3> SYSVINIT IS PARALLEL AND BOOTS FASTER AND HAS LESS DEPENDENCIES
185 2013-01-28 03:37:34 <CodeShark> lol - well, one thing's for certain - everyone seems to have a very strong opinion on this subject
186 2013-01-28 03:37:36 <andytoshi> ah, phonon depends on gconf, and everything depends on phonon
187 2013-01-28 03:37:47 <Diablo-D3> andytoshi: if you're on kde, yes
188 2013-01-28 03:37:51 <Diablo-D3> but who the fuck uses that pile of shit
189 2013-01-28 03:38:00 <CodeShark> lol
190 2013-01-28 03:38:03 <gmaxwell> Diablo-D3: do you yell like this in person?
191 2013-01-28 03:38:16 <andytoshi> Diablo-D3: i don't even have a DE
192 2013-01-28 03:38:16 <Diablo-D3> gmaxwell: its not yelling as much as channeling lewis black
193 2013-01-28 03:38:18 <andytoshi> this is ludicrous
194 2013-01-28 03:38:45 <gmaxwell> andytoshi: I apologize for pointing out the rot behind the walls. :P
195 2013-01-28 03:39:00 <Diablo-D3> I should make my own fucking linux distro
196 2013-01-28 03:39:00 <Luke-Jr> andytoshi: I have phonon, but not gconf..
197 2013-01-28 03:39:10 <gmaxwell> RantOS
198 2013-01-28 03:39:14 <Luke-Jr> lol
199 2013-01-28 03:39:19 <Diablo-D3> it'll boot instantly
200 2013-01-28 03:39:33 <andytoshi> gmaxwell: my gf constantly badgers me about using fedora
201 2013-01-28 03:39:38 <andytoshi> because she uses arch
202 2013-01-28 03:39:43 <Diablo-D3> andytoshi: use debian
203 2013-01-28 03:39:55 <CodeShark> lol - the religious hour has started
204 2013-01-28 03:40:09 <Diablo-D3> I think even an arch hipster would agree debian > fedora
205 2013-01-28 03:40:29 <andytoshi> haha, hipster
206 2013-01-28 03:40:56 <andytoshi> yeah, i should really switch to debian
207 2013-01-28 03:41:00 <andytoshi> as long as i can run systemd ;)
208 2013-01-28 03:41:03 <Diablo-D3> I COMPILE MY OWN DISTRO BECAUSE ITS IRONIC
209 2013-01-28 03:41:03 <Luke-Jr> ACTION wonders if *anyone* would disagree about Debian > Fedora???
210 2013-01-28 03:41:13 <weex> nah...nobody.
211 2013-01-28 03:41:25 <Diablo-D3> Luke-Jr: there are people who work for redhat who use debian as their primary distro of choice
212 2013-01-28 03:41:26 <andytoshi> Diablo-D3: well, given how much effort it takes to tear down a big distro to a usable level
213 2013-01-28 03:41:28 <Luke-Jr> andytoshi: Debian doesn't support systemd because of its lack of portability.
214 2013-01-28 03:41:55 <CodeShark> that's pretty ironic :)
215 2013-01-28 03:45:34 <gmaxwell> andytoshi: Everyone I know that has switched to arch eventually stoped using free software and switched to OSX. I suggest you run now, lawyer up, hit the gym, etc.
216 2013-01-28 03:45:51 <Diablo-D3> >hit the gym
217 2013-01-28 03:45:55 <andytoshi> haha
218 2013-01-28 03:46:01 <Diablo-D3> PSSSH, DO YOU EVEN LIFT?!
219 2013-01-28 03:46:16 <Luke-Jr> LOL
220 2013-01-28 03:46:34 <gmaxwell> Luke-Jr: I am not a fan of debian at all. Debian perpetually ships out of date software in stable and makes my life sad. In testing they are frequently broken. The overall system is very very slow to pull in major infrastructure changes (e.g. multiarch)
221 2013-01-28 03:46:42 <Diablo-D3> gmaxwell: no no no no
222 2013-01-28 03:46:43 <Diablo-D3> you fail
223 2013-01-28 03:46:48 <Diablo-D3> stable means unmoving
224 2013-01-28 03:46:50 <Diablo-D3> use sid.
225 2013-01-28 03:46:54 <Diablo-D3> not testing. sid.
226 2013-01-28 03:46:59 <Diablo-D3> dont argue with this wisdom
227 2013-01-28 03:47:28 <Diablo-D3> testing is not meant for end users, its meant for those following internal debian development
228 2013-01-28 03:47:31 <Luke-Jr> gmaxwell: I strongly dislike multiarch. I also often find Debian stable has newer stuff than Gentoo stable.
229 2013-01-28 03:47:32 <gmaxwell> Diablo-D3: Other people use stable on servers. Then they report bugs I fixed twenty years ago. I would do something about this, but apparently it is unlawful to kill all the users.
230 2013-01-28 03:47:42 <Diablo-D3> gmaxwell: because they're retarded
231 2013-01-28 03:47:45 <Diablo-D3> use sid
232 2013-01-28 03:47:53 <Diablo-D3> even on production servers, use sid
233 2013-01-28 03:48:05 <gmaxwell> Luke-Jr: multiarch in fedora is a pleasure??? and in a default system there is no i386 binaries ... but when you want to cross compile its a cinch.
234 2013-01-28 03:48:08 <Luke-Jr> I am happy with Debian stable (soon to be oldstable) on my remote servers.
235 2013-01-28 03:48:10 <Diablo-D3> if they cant read the fucking debian users guide on the fucking debian.org website
236 2013-01-28 03:48:15 <Diablo-D3> theyc an go fuck themselves
237 2013-01-28 03:48:33 <Diablo-D3> stable is for people who work for companies that have criminally broken internal policies
238 2013-01-28 03:48:39 <Diablo-D3> sid is for anyone who actually wants to get work done
239 2013-01-28 03:48:40 <Luke-Jr> gmaxwell: I don't see a point to having more than one arch.
240 2013-01-28 03:48:54 <gmaxwell> Diablo-D3: And yet its very very widely used...
241 2013-01-28 03:48:56 <Diablo-D3> Ive used sid since before it was sid and was potato unstable
242 2013-01-28 03:49:09 <Diablo-D3> gmaxwell: quite a few companies have broken policies
243 2013-01-28 03:49:24 <Diablo-D3> this is why "websites" keep getting "hacked" or whatever the buzzwords this week are
244 2013-01-28 03:49:54 <Diablo-D3> Luke-Jr: multiarch is typically used for ia32 binaries on x86-64
245 2013-01-28 03:50:10 <Luke-Jr> gmaxwell: I used x86_64 exclusively from almost the day it was available until 2011, and never saw a need for any i386 binaries. Now that I'm back on i386 because I value memory more than CPU time, I don't see a need for x86_64 binaries.
246 2013-01-28 03:50:13 <gmaxwell> In any case, I don't care to argue it. Luke asked if anyone disagreed, I do.
247 2013-01-28 03:50:17 <Diablo-D3> LOL
248 2013-01-28 03:50:22 <Diablo-D3> luke thinks ia32 uses less memory
249 2013-01-28 03:50:39 <gmaxwell> Diablo-D3: it does for some things, esp if you happen to have a major service written in python.
250 2013-01-28 03:50:44 <Diablo-D3> too bad in the average program, pointers take up about 1-2% of the memory used
251 2013-01-28 03:51:21 <gmaxwell> Diablo-D3: And when has anyone said that Luke was average?
252 2013-01-28 03:51:23 <gmaxwell> :P
253 2013-01-28 03:51:25 <Diablo-D3> and you're losing about 35% performance on your average program by running it wrong
254 2013-01-28 03:51:28 <CodeShark> why would you write a major service in python?!
255 2013-01-28 03:51:34 <Diablo-D3> gmaxwell: well, who knows what his bible app does
256 2013-01-28 03:51:39 <Diablo-D3> CodeShark: drugs.
257 2013-01-28 03:51:39 <Luke-Jr> Diablo-D3 must not use C++ or any higher-level languages???
258 2013-01-28 03:51:40 <gmaxwell> CodeShark: you missed that argument by 24 hours.
259 2013-01-28 03:51:56 <Diablo-D3> Luke-Jr: this is why no one will ever take you seriously as a programmer
260 2013-01-28 03:52:01 <Diablo-D3> you dont know this shit already
261 2013-01-28 03:52:09 <andytoshi> i got gconf down to 26 dependent packages, so i'm happy
262 2013-01-28 03:52:12 <gmaxwell> Diablo-D3: Please cut the hostility.
263 2013-01-28 03:52:17 <andytoshi> and most of it is kde stuff drawn in by kmplot
264 2013-01-28 03:52:28 <Luke-Jr> Diablo-D3: if I run x86_64, I'm constantly swapping even with 16 GB RAM
265 2013-01-28 03:52:31 <gmaxwell> What is kmplot?
266 2013-01-28 03:52:39 <Luke-Jr> at least i386 keeps me off the swap
267 2013-01-28 03:52:48 <Diablo-D3> Luke-Jr: _lol_
268 2013-01-28 03:52:53 <andytoshi> gmaxwell: it's a simple point-and-click graphing calculator
269 2013-01-28 03:52:57 <Diablo-D3> you think linux doesnt preemptively swap, how cute
270 2013-01-28 03:53:04 <gmaxwell> andytoshi: ah.
271 2013-01-28 03:53:05 <Luke-Jr> that's not the point
272 2013-01-28 03:53:06 <andytoshi> Diablo-D3: i don't even have swap
273 2013-01-28 03:53:16 <Luke-Jr> andytoshi: that's kinda silly
274 2013-01-28 03:53:17 <gmaxwell> Diablo-D3: _constantly_ swapping != preemptive swapping.
275 2013-01-28 03:53:30 <Diablo-D3> gmaxwell: and I doubt hes constantly swapping
276 2013-01-28 03:53:36 <Diablo-D3> either that, or hes running one hell of a leaky program
277 2013-01-28 03:53:39 <andytoshi> it's a bit silly, yeah, but i've only got a 64-gig hdd
278 2013-01-28 03:53:39 <gmaxwell> andytoshi: yea, swap is good. The kernel is competent.
279 2013-01-28 03:53:48 <Diablo-D3> the kernel isnt competent
280 2013-01-28 03:53:51 <Diablo-D3> it really isnt
281 2013-01-28 03:54:02 <gmaxwell> hm.
282 2013-01-28 03:54:06 <gmaxwell> ACTION tests a hypothesis.
283 2013-01-28 03:54:14 <gmaxwell> Diablo-D3: Diablo-D3 is really smart.
284 2013-01-28 03:54:16 <Luke-Jr> Diablo-D3: KDE's Plasma is pretty leaky.
285 2013-01-28 03:54:29 <Diablo-D3> using low values for swappiness is recommended (but not 0, that breaks shit)
286 2013-01-28 03:54:44 <Luke-Jr> but I also keep about 100 browser windows open with like 5 tabs each on average
287 2013-01-28 03:54:47 <Diablo-D3> gmaxwell: that isnt it, you're saying shit thats already been generally proven wrong
288 2013-01-28 03:54:50 <Luke-Jr> and numerous Kate instances, etc
289 2013-01-28 03:55:02 <Diablo-D3> Luke-Jr: I usually have about 200 tabs open across a dozen windows in firefox
290 2013-01-28 03:55:09 <Diablo-D3> never goes above 2gb usage
291 2013-01-28 03:55:09 <Luke-Jr> [04:54:28] <gmaxwell> Diablo-D3: Diablo-D3 is really smart. <-- already been generally proven wrong
292 2013-01-28 03:55:14 <gmaxwell> Hm. Theory validated. Diablo-D3 actually does disagree with everything.
293 2013-01-28 03:55:27 <Diablo-D3> gmaxwell: I didnt disagree with everything
294 2013-01-28 03:55:31 <gmaxwell> lol
295 2013-01-28 03:55:33 <Diablo-D3> there are things that I do agree with
296 2013-01-28 03:55:33 <Luke-Jr> lol
297 2013-01-28 03:55:52 <Diablo-D3> its just that, atm, you and luke both are saying some pretty stupid shit
298 2013-01-28 03:56:48 <Luke-Jr> Diablo-D3: I suppose everyone behind x32 and merging it (like Linus, the GCC/glibc folks, etc) are idiots too?
299 2013-01-28 03:57:57 <gmaxwell> x32 makes me sad.
300 2013-01-28 03:58:15 <gmaxwell> I'd prefer to just encourage things to fix their insane pointer bloat. :-/
301 2013-01-28 03:58:40 <andytoshi> i like to think all the pointers are making the code cleaner
302 2013-01-28 03:58:41 <Luke-Jr> gmaxwell: I'd rewrite my entire OS given the spare time, but there's only so much people can do :P
303 2013-01-28 03:58:43 <gmaxwell> 4gb address space limits stink, and the resulting scalablity limits stink. ... and having systems with two sets of all libraries stinks.
304 2013-01-28 03:58:45 <andytoshi> maybe it's all in lisp or something
305 2013-01-28 03:59:08 <Luke-Jr> gmaxwell: one set of x32 libraries should be fine; maybe some new PAE-like hacks for VM-type software
306 2013-01-28 03:59:44 <gmaxwell> As soon as you need even one x86_64 binary for scalablity reasons the duplicate libraries in ram eat most of the memory savings of x32... I'd say it makes sense on phones, except phones are going to start bumping into 4gb address space limits in a few more years (even arm is going 64 bit now).
307 2013-01-28 04:00:36 <gmaxwell> Luke-Jr: I frequently run single tasks that actually need more than 4gb ram. I know my workloads are not common desktop ones, but they're not that crazy.
308 2013-01-28 04:00:54 <Luke-Jr> gmaxwell: O.o
309 2013-01-28 04:14:16 <etotheipi_> maybe we should've been more proactive and skipped 64-bit CPU.... jumped right to 256-bit CPU or something
310 2013-01-28 04:14:48 <etotheipi_> we're just delaying another annoying architecture mess
311 2013-01-28 04:14:58 <Luke-Jr> etotheipi_: meh, the CPUs are really like 48-bit anyway
312 2013-01-28 04:15:04 <etotheipi_> and at least then we could do some crypto in "int" types in C++
313 2013-01-28 04:15:15 <mappum> meanwhile, my gpu is 192-bit
314 2013-01-28 04:15:48 <Luke-Jr> etotheipi_: I agree wider registers and ops might be nice, but no reason to increase pointers.
315 2013-01-28 04:17:13 <andytoshi> indeed, 48 bits can refer to 28Tb
316 2013-01-28 04:17:26 <andytoshi> but having 256 bits in general-purpose registers would be wonderful
317 2013-01-28 04:19:00 <CodeShark> no increasing pointers? how else will I address my zettabyte RAM?
318 2013-01-28 04:21:08 <gmaxwell> I'd much rather have things like hardware tagging. (e.g. having zero perfomance hit valgrind on everything, did someone mention lisp machines?)
319 2013-01-28 04:21:50 <Luke-Jr> CodeShark: take MMUs to the next step
320 2013-01-28 04:22:41 <Luke-Jr> ACTION wonders how much performance hit all the PIC stuff has, and why we can't just have compilers output code using non-overlapping memory regions <.<
321 2013-01-28 04:23:15 <gmaxwell> etotheipi_: you don't need 256 bit registers to have a 256 bit int type in C like languages.
322 2013-01-28 04:23:36 <CodeShark> primitive types?
323 2013-01-28 04:23:46 <Luke-Jr> GCC probably has a SSE 256-bit int type hidden somewhere
324 2013-01-28 04:23:49 <gmaxwell> (an, in fact, GCC has a reasonable 128 bit int type)
325 2013-01-28 04:23:56 <gmaxwell> s/an/and/
326 2013-01-28 04:24:11 <gmaxwell> CodeShark: primitive types doesn't mean it has to fit in a single register.
327 2013-01-28 04:25:15 <gmaxwell> And on x86_64 doing arithemetic on 128 bit values is pretty much no different than 64 bit ones (you use the carry flags and do half-word math)... same way nominally 16 bit arches do 32 bit 'long'.
328 2013-01-28 04:25:43 <CodeShark> takes a few more CPU cycles
329 2013-01-28 04:26:21 <gmaxwell> it takes more instructions and has higher latency, doesn't usually harm throughput much.
330 2013-01-28 04:26:41 <gmaxwell> (and certantly if it were common the implementation could make it free)
331 2013-01-28 04:28:04 <Luke-Jr> looks like native int256 would need AVX
332 2013-01-28 04:28:21 <Luke-Jr> ACTION ponders how well an AVX miner would perform
333 2013-01-28 04:29:49 <Luke-Jr> looks like Ufasoft found it infeasable for some reason, oh well
334 2013-01-28 04:31:52 <gmaxwell> Luke-Jr: the first generation of AVX is basically float only.
335 2013-01-28 04:32:08 <gmaxwell> The integer stuff gets added in the next rev which isn't shipping in anything yet, I think.
336 2013-01-28 04:32:37 <gmaxwell> Yea, AVX2 is Haswell.
337 2013-01-28 04:32:43 <Luke-Jr> and float probably lacks bitshift ops I guess
338 2013-01-28 04:36:01 <kjj> does it really have enough width internally?
339 2013-01-28 04:38:37 <gmaxwell> kjj: does what really have enough width?
340 2013-01-28 04:43:42 <kjj> does the CPU have enough capacity to do 4096 bits at once, or is the instruction set just a handy wrapper around a multi-cycle series of 64 bit operations?
341 2013-01-28 04:45:22 <gmaxwell> AVX is not 16*256.
342 2013-01-28 04:45:39 <gmaxwell> It's 256 bits wide, with instructions that partition it up in different ways.
343 2013-01-28 04:46:02 <gmaxwell> (well the whole avx register file is 16*256 ??? actually because of shadowing it's probably substantially larger than that in reality)
344 2013-01-28 04:48:03 <kjj> it isn't so much the storage that I was wondering about, as the ALU
345 2013-01-28 04:50:37 <gmaxwell> sandy bridge can actually execute a 256bit (e.g. 8 x single precision) multiply in a single cycle (and IIRC, can also do an non-dependant 8xsingle precision add, and an unrelated load/store at the same time)
346 2013-01-28 05:03:56 <CodeShark> I'm still using penryn microarchitecture CPUs
347 2013-01-28 05:05:32 <CodeShark> I'll probably wait for Haswell before upgrading everything
348 2013-01-28 05:42:40 <wumpus> <gmaxwell> (an, in fact, GCC has a reasonable 128 bit int type) <- it does (__int128_t), but it only works on 64-bit platforms
349 2013-01-28 05:46:28 <gmaxwell> wumpus: yea, it continues the C tradition of having some kind of long / long long that is one step larger than the largest native type, implemented using the carry flags (so its still fast).
350 2013-01-28 05:47:06 <CodeShark> I really wish C would have made the width explicit in their types from the beginning and would have made unsigned ints the default :)
351 2013-01-28 05:47:20 <CodeShark> you should have to use a signed keyword for signed
352 2013-01-28 05:47:43 <gmaxwell> CodeShark: unsigned is not magically superior. In particular you often get worse performing loops when you use unsigned as an iterator.
353 2013-01-28 05:47:55 <CodeShark> worse performing loops?
354 2013-01-28 05:47:59 <gmaxwell> (though the promotion rules in C kinda suck)
355 2013-01-28 05:48:14 <CodeShark> why would they perform worse as iterators?
356 2013-01-28 05:48:53 <gmaxwell> CodeShark: yea, it's really really common for the compiler to be able to prove that a loop runs??? say??? 4 times _exactly_ or infinity. Overflow of a signed integer is undefined in C, so the compiler can exclude the infinity case and vectorize or unroll the loop.
357 2013-01-28 05:49:25 <gmaxwell> but if the loop counter is unsigned, no joy. The loop might run until it overflows.
358 2013-01-28 05:50:28 <andytoshi> i wish char had been unsigned by default
359 2013-01-28 05:50:34 <andytoshi> instead of implementation-defined..
360 2013-01-28 05:50:54 <andytoshi> there's no need for a 1-byte counter unless you're deliberately doing overflow tricks
361 2013-01-28 05:52:07 <CodeShark> gmaxwell: give me an example where the compiler could prove that a loop runs either 4 times exactly or infinity
362 2013-01-28 05:53:17 <andytoshi> CodeShark: anytime the iterator might start above 4
363 2013-01-28 05:53:25 <andytoshi> for (i; i < 4; ++i)
364 2013-01-28 05:53:29 <andytoshi> ;)
365 2013-01-28 05:53:38 <CodeShark> oh... :)
366 2013-01-28 05:53:59 <CodeShark> well, if the i is not modified inside the loop, the compiler could prove it always runs 4 times exactly
367 2013-01-28 05:54:03 <CodeShark> never infinity
368 2013-01-28 05:54:19 <andytoshi> if i is not modified, it will definitely run infinity times:P
369 2013-01-28 05:54:33 <CodeShark> it gets modified by the ++i only
370 2013-01-28 05:54:49 <CodeShark> oh, you're saying if it's not even initialized
371 2013-01-28 05:55:08 <andytoshi> for (i = 15; i < 4; ++i) printf ("Running for the %dth time\\n", i);
372 2013-01-28 05:55:27 <kjj> C looks like portable assembly, but it isn't. modern CPUs would be worthless without compilers being aggressive with "undefined" behavior
373 2013-01-28 05:55:56 <andytoshi> yeah, that's why C still acts the way it does in 2013
374 2013-01-28 05:56:19 <andytoshi> it's certainly -possible- to do bounds checking and trap on overflow and watch for NULLs
375 2013-01-28 05:56:46 <gmaxwell> CodeShark: or initilized elsewhere, or based off a nonstatic values.. for(i=x;i<x+4;i++)
376 2013-01-28 05:57:17 <CodeShark> who the hell writes for loops that loop around the maximum unsigned value anyhow? lol
377 2013-01-28 05:57:56 <andytoshi> well, suppose you wanted to run 256 times, but you wanted the starting value of something to be variable..
378 2013-01-28 05:57:57 <gmaxwell> CodeShark: I've actually seen code that needed that, don't ask??? but regardless, it _must_ not break in that case. unsigned overflow is well defined.
379 2013-01-28 05:58:02 <andytoshi> say, for some sorta duff's device..
380 2013-01-28 06:02:04 <andytoshi> and say, your starting value came from setjmp, and represented a recursion depth
381 2013-01-28 06:02:17 <andytoshi> so that you could do different things depending how fine you'd split a problem up
382 2013-01-28 06:02:25 <andytoshi> i believe that is called "dynamic programming"
383 2013-01-28 06:03:49 <gmaxwell> andytoshi: I ... wouldn't normally describe that as dynamic programming??? though I suppose some DP algorithims coule be implemented that way.
384 2013-01-28 06:03:58 <andytoshi> hahaha
385 2013-01-28 06:05:08 <CodeShark> well, compiler optimization aside, it seems unsigned ints are used far more in typical programs than signed ints
386 2013-01-28 06:05:37 <CodeShark> at least ints that are never set to negative values (even if it's a signed type)
387 2013-01-28 06:05:39 <andytoshi> CodeShark: i don't think so
388 2013-01-28 06:05:47 <andytoshi> yeah, that's probably true
389 2013-01-28 06:05:52 <CodeShark> array indices? counters?
390 2013-01-28 06:06:23 <gmaxwell> what, you don't use negative indexes? pshaw.
391 2013-01-28 06:06:24 <andytoshi> but most ints also don't use more than the signed range
392 2013-01-28 06:06:25 <andytoshi> so it's a wash
393 2013-01-28 06:06:48 <CodeShark> but it's an issue when comparing ints
394 2013-01-28 06:06:55 <andytoshi> sometimes i use negative indexes to implement a fixed-size stack, when i'm writing throwaway code
395 2013-01-28 06:07:10 <gmaxwell> and the underflow behavior makes signed values produce more tractable errors too.
396 2013-01-28 06:07:11 <andytoshi> CodeShark: yeah, that's frustrating
397 2013-01-28 06:07:38 <gmaxwell> CodeShark: yea, the promotion rules are annoying??? but you can solve them by _never_ using unsigned, as a rule.. and lots of people use that rule.
398 2013-01-28 06:07:44 <andytoshi> i kinda wish you could set ranges like in ada
399 2013-01-28 06:07:52 <andytoshi> even if the compiler wouldn't enforce it for you
400 2013-01-28 06:08:16 <gmaxwell> andytoshi: ACSL (http://frama-c.com/acsl.html)
401 2013-01-28 06:08:46 <andytoshi> ooh, exciting!
402 2013-01-28 06:11:37 <CodeShark> as for simple counting loops, it would have been nice for there to be a foreach in range type deal from the beginning :)
403 2013-01-28 06:12:09 <CodeShark> but I guess C took a fairly minimalist approach to language constructs
404 2013-01-28 06:12:57 <andytoshi> gmaxwell, this is so cool
405 2013-01-28 06:13:12 <CodeShark> yeah, it is pretty neat
406 2013-01-28 06:13:14 <andytoshi> i generally use dozens of asserts() everywhere
407 2013-01-28 06:16:00 <gmaxwell> andytoshi: the prover stuff in frama .. well. it's not as smart as I'd hope. hopefully it gets better... but when I've used it I'd quickly run into cases where no matter how many hard assertions I added I couldn't get it to prove an operation didn't overflow.
408 2013-01-28 06:17:21 <andytoshi> well, the next time i've got some academic C code to write, i'll try it out
409 2013-01-28 06:22:29 <gmaxwell> petertodd: you should join #bitcoin
410 2013-01-28 06:53:44 <gmaxwell> petertodd: so I think it's possible (given blockchain rule modifications) to make it so that your blinded bank can't block withdraws back into bitcoin.
411 2013-01-28 06:53:59 <SomeoneWeird> can you get the version of bitcoind running with tcp ?
412 2013-01-28 06:54:16 <SomeoneWeird> like echo "version" | nc host port o something ?
413 2013-01-28 06:54:31 <gmaxwell> SomeoneWeird: not that simply.
414 2013-01-28 06:54:55 <SomeoneWeird> handshake or something ?
415 2013-01-28 06:55:08 <gmaxwell> SomeoneWeird: yes.
416 2013-01-28 06:55:18 <SomeoneWeird> mm
417 2013-01-28 06:55:30 <gmaxwell> petertodd: I have a 1BTC token from your bank. I want to withdraw it. You have issued 1000 1BTC tokens, their bitcoin is all assigned at txout AAAA with some special flags and scriptpubkey.
418 2013-01-28 06:55:42 <SomeoneWeird> and i suppose that isn't simple enough todo via cli ?
419 2013-01-28 06:56:31 <gmaxwell> petertodd: I ask you to exchange my 1 BTC token for a new blinded one. But unknown to you, the new blinded one says inside "can be redeemd from the blockchain". If I later try to get you to swap that after unblinding it, you'll tell me to buzz off.
420 2013-01-28 06:56:58 <gmaxwell> petertodd: Instead I present that unblinded token to the blockchain and it lets me spend 1btc out of the 1000 to an address of my choosing.
421 2013-01-28 06:58:20 <gmaxwell> petertodd: what I'd really like is a secure way to redeem the tokens if the bank goes out of business, but I haven't come up with one of those yet... but at least I got "bank can't block you from getting your coins out of it", which I think sounds like a useful property.
422 2013-01-28 06:59:06 <CodeShark> SomeoneWeird, you can do it via curl -d '{"method":"getinfo","params":[],"id":0}' http://user:pwd@host:port :)
423 2013-01-28 06:59:20 <SomeoneWeird> ah, neat thanks
424 2013-01-28 06:59:30 <gmaxwell> I'd assumed that SomeoneWeird wanted the p2p port.
425 2013-01-28 06:59:47 <SomeoneWeird> well in this case both are open, so it doesn't matter
426 2013-01-28 06:59:58 <gmaxwell> SomeoneWeird: someone has an open RPC port on the internets?
427 2013-01-28 07:00:05 <SomeoneWeird> mhm
428 2013-01-28 07:00:18 <gmaxwell> ACTION facepalm
429 2013-01-28 07:01:36 <Cryo> this sync is taking forever.. 7000 more blocks to go zzzzzzzzz
430 2013-01-28 07:02:46 <CodeShark> via p2p port, I have a utility that can do that but haven't published it
431 2013-01-28 07:03:10 <gmaxwell> just addnode it and use getpeerinfo. :P
432 2013-01-28 07:04:01 <CodeShark> no, I mean a utility that can do that even if the local host doesn't have bitcoind
433 2013-01-28 07:06:12 <SomeoneWeird> nice
434 2013-01-28 07:09:14 <andytoshi> gmaxwell: will the addnode stuff be pulled?
435 2013-01-28 07:09:49 <andytoshi> i'm suprised that nobody looked at it today..i guess its sunday
436 2013-01-28 07:10:25 <CodeShark> dynamic addnode would be nice to have
437 2013-01-28 07:11:02 <gmaxwell> CodeShark: we have a now tested pull request for it.
438 2013-01-28 07:12:44 <CodeShark> 1549?
439 2013-01-28 07:13:05 <andytoshi> yeah
440 2013-01-28 07:14:25 <gmaxwell> CodeShark: feel free to do your own testing and provide feedback.
441 2013-01-28 07:16:24 <leotreasure> hello, does anyone know how to connect to mt gox api using the python script?
442 2013-01-28 07:45:18 <gmaxwell> petertodd: so the best I've got for the shutdown case is orderly-but-effortless-shutdown. As the bank operates it maintains??? potentially in public??? a merkelized STXO (spent transaction) tree for each issuance containing all the redeemed tokens. (you'd want to do that anyways if the bank is in secure hardware, as it would let you have the expensive storage outside of the stored hardware.
443 2013-01-28 07:46:05 <gmaxwell> petertodd: if the bank needs to shut down fast, it makes sure the final STXO state is published, and it makes a final bitcoin transaction to transfer all the funds to a recievership script.
444 2013-01-28 07:46:36 <gmaxwell> petertodd: then any token can be redeemed by putting it in a transaction along with the tree fragments that prove the token is not in the final STXO set.
445 2013-01-28 07:46:45 <gmaxwell> the problem is that the transactions would be really big. :(
446 2013-01-28 08:12:10 <sipa> jgarzik: what would be needed to convince you to write an autotools based config for bitcoin...?
447 2013-01-28 08:14:06 <CodeShark> I'll do it if that's what everyone wants
448 2013-01-28 08:14:51 <sipa> actually, what i want is anything that is maintained
449 2013-01-28 08:15:16 <sipa> so pushing someone to write a config which is then neglected seems like a vad idea
450 2013-01-28 08:15:52 <sipa> and i have no problem personally with a hand-rolled script, if it allows more platforms than we do now
451 2013-01-28 08:16:39 <sipa> though it should also be used for production builds, otherwise it will too easily lag behind
452 2013-01-28 08:36:05 <njbartlett> Hi, I'm having trouble with the Bitcoin-Qt client synchronizing the blockchain. It's been stuck at block no 210348 for over 24 hours now. Previously it was downloading okay (though slow!). Any ideas what might be wrong?
453 2013-01-28 08:37:04 <sipa> njbartlett: likely database corruption
454 2013-01-28 08:37:41 <njbartlett> sipa: Damn. What does that mean, I have to start downloading the chain all over again?
455 2013-01-28 08:37:55 <sipa> basically, yes
456 2013-01-28 08:38:19 <sipa> if it's any help: 0.8 should be a lot faster and less prone to corruption
457 2013-01-28 08:40:14 <njbartlett> sipa: Thanks. I don't see 0.8 available for download yet... would I need to build from source?
458 2013-01-28 08:41:18 <kinlo> njbartlett: it's not released yet
459 2013-01-28 11:22:12 <Luke-Jr> TD[gone]`: it's quite trivial in theory to monopolize on miner policy differences to double-spend
460 2013-01-28 11:24:25 <porquilho> hello
461 2013-01-28 11:27:35 <Mikej0h> hi
462 2013-01-28 12:26:12 <debiantoruser> Greetings!
463 2013-01-28 12:27:00 <debiantoruser> Is there easy way to discuss with bitcoind developers bitcoind options ?
464 2013-01-28 12:28:36 <sipa> debiantoruser: just ask your question, people may or may not answer
465 2013-01-28 12:30:42 <debiantoruser> bitcoind getaccountaddress "myaccount"
466 2013-01-28 12:30:53 <debiantoruser> this way, i get New address
467 2013-01-28 12:31:34 <debiantoruser> Like bitcoind getnewaddress "named"
468 2013-01-28 12:31:55 <debiantoruser> But i looking for this options # bitcoind getaddressesbyaccount "named"
469 2013-01-28 12:32:10 <debiantoruser> for listing all of addresses in account
470 2013-01-28 12:32:50 <debiantoruser> There is one option # bitcoind listaccounts
471 2013-01-28 12:33:12 <debiantoruser> It show me all of my accounts, but it doesn't show addresses
472 2013-01-28 12:33:42 <debiantoruser> It would be cool to have one easy, pretty json printed options to see all of accounts with addresses in each
473 2013-01-28 12:34:23 <debiantoruser> And another one cool option - to delete (remove) address from wallet
474 2013-01-28 12:34:37 <debiantoruser> Do you copy?
475 2013-01-28 12:34:55 <sipa> deleting addresses is intentionally not possible - it's way too easy to burn yourself that way
476 2013-01-28 12:35:18 <sipa> as it means losing any transactions that were sent to that address before, which may screw up your balance
477 2013-01-28 12:35:39 <sipa> hiding an address is something else, which may be useful but isn't implemented
478 2013-01-28 12:35:54 <debiantoruser> rm -fr / - to one of such ways, but it is accessible by user (:
479 2013-01-28 12:37:48 <debiantoruser> I set new account and import address by private key, when i use option: bitcoind getaccountaddress "this my new account"
480 2013-01-28 12:37:54 <debiantoruser> I get another one address
481 2013-01-28 12:38:05 <debiantoruser> so my wallet with 10 accounts looks like junkyard
482 2013-01-28 12:38:37 <debiantoruser> and i am no so addictive
483 2013-01-28 12:38:48 <sipa> when importing an address, and giving it a label, i don't think it is made the default address of that account
484 2013-01-28 12:39:00 <sipa> so you don't get that address when requesting getaccountaddress
485 2013-01-28 12:39:27 <debiantoruser> why?
486 2013-01-28 12:39:48 <debiantoruser> Am i need to submit ticket?
487 2013-01-28 12:40:03 <sipa> in general, the accounts feature is not very useful
488 2013-01-28 12:40:17 <sipa> and it badly interacts with a lot of other things
489 2013-01-28 12:40:36 <sipa> imho, multi-wallet support (probably coming in 0.9) is much closer to what people exptect accounts to be
490 2013-01-28 12:41:42 <debiantoruser> how far it from nowadayz?
491 2013-01-28 12:42:08 <sipa> we don't even have a 0.8 release candidate, so not very soon
492 2013-01-28 12:43:07 <debiantoruser> what a main task for dev command today?
493 2013-01-28 12:43:18 <sipa> ?
494 2013-01-28 12:43:43 <debiantoruser> what do you do?
495 2013-01-28 12:46:09 <sipa> eh, several things :)
496 2013-01-28 12:46:21 <sipa> i'm a core developer, but i haven't worked on wallet-related things for a while
497 2013-01-28 12:47:04 <debiantoruser> Could you please divide fee by ten?
498 2013-01-28 12:47:15 <HM> lol
499 2013-01-28 12:47:52 <sipa> haha
500 2013-01-28 12:48:45 <SomeoneWeird> lols
501 2013-01-28 12:51:34 <sipa> debiantoruser: you choose the fee yourself; there is a safety minimal fee if you try large(bytes)/young/spammy transactions, as the network won't relay those without a fee
502 2013-01-28 12:52:07 <sipa> the fee policy is certainly going to change, but it first needs changes in the network
503 2013-01-28 13:12:58 <HM> sipa: going to change?
504 2013-01-28 13:13:03 <HM> you mean go up? ;)
505 2013-01-28 13:36:34 <TD> BlueMatt: poke
506 2013-01-28 13:36:37 <TD> are you there?
507 2013-01-28 13:37:54 <jgarzik> sipa: it would be easy to maintain, once written
508 2013-01-28 13:38:11 <jgarzik> sipa: autotools configure just annoying to get going the first time
509 2013-01-28 13:38:13 <jgarzik> *is just
510 2013-01-28 13:39:05 <CodeShark> I could use the experience so I volunteer
511 2013-01-28 13:55:29 <epscy> what is the motivation for changing the fee structure
512 2013-01-28 13:58:26 <BlueMatt> TD: pong
513 2013-01-28 14:01:51 <TD> in FilteredBlockAndMerkelTreeTests the filtered block is still being sent after the transactions, not before
514 2013-01-28 14:01:55 <TD> is that intentional?
515 2013-01-28 14:04:19 <BlueMatt> shouldnt be
516 2013-01-28 14:04:30 <BlueMatt> I know I changed that test like yesterday
517 2013-01-28 14:04:31 <BlueMatt> did I not push?
518 2013-01-28 14:05:32 <TD> http://code.google.com/r/bluemattme-bitcoinj/source/list?name=bloomfilter
519 2013-01-28 14:06:04 <TD> not sure ???. i guess not
520 2013-01-28 14:06:23 <TD> i'm merging it in, perhaps i've merged a 2/3 day old version?
521 2013-01-28 14:06:30 <TD> but i think i started yesterday
522 2013-01-28 14:06:52 <BlueMatt> the version on git bloomfilter is right, though the change may have ended up in the wrong commit?
523 2013-01-28 14:07:33 <BlueMatt> seems to be right in 3906aa62d902, where it was added
524 2013-01-28 14:07:47 <BlueMatt> first filteredBlock, then tx0-3 then Pong
525 2013-01-28 14:07:48 <TD> hmm
526 2013-01-28 14:07:53 <TD> ok
527 2013-01-28 14:08:01 <TD> i wish i could see the history of pushes
528 2013-01-28 14:08:26 <BlueMatt> yea...push -f gets kinda messy
529 2013-01-28 14:08:50 <BlueMatt> Im pretty sure the last change I made was just before the bitcoinj ml post asking for reviews
530 2013-01-28 14:09:42 <TD> i probably messed up git
531 2013-01-28 14:09:54 <TD> this tool is still one of the sharpest and most dangerous knives i've seen for a while
532 2013-01-28 14:10:03 <BlueMatt> yes
533 2013-01-28 14:10:03 <TD> how do I force my local branch to be identical to your remote branch?
534 2013-01-28 14:10:12 <TD> "git reset --hard bluematt/bloomfilter" didn't do the trick
535 2013-01-28 14:10:30 <BlueMatt> git fetch and git checkout should do it
536 2013-01-28 14:10:38 <BlueMatt> (unless you have local changes, then checkout should complain)
537 2013-01-28 14:10:53 <BlueMatt> hmm...reset should too
538 2013-01-28 14:10:55 <TD> i have an existing branch that i want to make a duplicate of yours
539 2013-01-28 14:11:04 <BlueMatt> yea, that should do it
540 2013-01-28 14:11:21 <BlueMatt> Im not sure, does git log bluematt/bloomfilter show cea95b809d9935406c057905f415731b3e81cdb3 as head?
541 2013-01-28 14:11:46 <TD> Author: Matt Corallo <git@bluematt.me>
542 2013-01-28 14:11:46 <TD> commit 6440237d0037a9e27ac65bdb3fc85ad4ba60fbab
543 2013-01-28 14:11:46 <TD> Date: Mon Dec 24 17:28:12 2012 -0500
544 2013-01-28 14:11:46 <TD> $ git log bluematt/bloomfilter|head
545 2013-01-28 14:11:47 <TD> Add test cases for PMT/FilteredBlock including network download.
546 2013-01-28 14:11:49 <TD> nope
547 2013-01-28 14:11:53 <TD> guess that's the issue
548 2013-01-28 14:12:00 <BlueMatt> umm...yea, so fetch didnt get it right
549 2013-01-28 14:12:26 <BlueMatt> wow, that is really old, that is before the refresh bloom filter every 25k blocks stuff
550 2013-01-28 14:12:31 <BlueMatt> or nFlags
551 2013-01-28 14:13:35 <TD> it must be when i first fetched the branch
552 2013-01-28 14:13:40 <TD> grr.
553 2013-01-28 14:13:42 <BlueMatt> bluematt is the right remote, right?
554 2013-01-28 14:14:19 <BlueMatt> cat .git/config
555 2013-01-28 14:14:33 <TD> hearn-macbookpro:bitcoinj hearn$ git remote show bluematt
556 2013-01-28 14:14:34 <TD> Fetch URL: https://code.google.com/r/bluemattme-bitcoinj/
557 2013-01-28 14:14:34 <TD> Push URL: https://code.google.com/r/bluemattme-bitcoinj/
558 2013-01-28 14:14:34 <TD> * remote bluematt
559 2013-01-28 14:14:55 <TD> [remote "bluematt"]
560 2013-01-28 14:14:55 <TD> \tfetch = +refs/heads/*:refs/remotes/bluematt/*
561 2013-01-28 14:14:55 <TD> \turl = https://code.google.com/r/bluemattme-bitcoinj/
562 2013-01-28 14:14:59 <BlueMatt> yea, thats right...
563 2013-01-28 14:14:59 <TD> i guess so
564 2013-01-28 14:15:06 <BlueMatt> wtf google code?
565 2013-01-28 14:15:21 <BlueMatt> wait can you even git show cea95b809d9935406c057905f415731b3e81cdb3?
566 2013-01-28 14:16:17 <TD> yes. i get "refresh filter every 25k blocks"
567 2013-01-28 14:16:26 <BlueMatt> ok, so just reset your branch to that and go from there
568 2013-01-28 14:17:28 <TD> ok
569 2013-01-28 14:18:20 <BlueMatt> you can probably skip the "fix #292" commit until I throw in the second part (the inputIndex+1 fix)
570 2013-01-28 14:18:29 <BlueMatt> unless you want to get murexcon... to sign the cla
571 2013-01-28 14:19:03 <TD> if you could do it, that'd be convenient for me
572 2013-01-28 14:19:05 <TD> or i'll do it
573 2013-01-28 14:19:07 <TD> it seemed easy
574 2013-01-28 14:19:18 <TD> actually i can just do it
575 2013-01-28 14:19:20 <BlueMatt> yea, I just wanted to read through the code and make sure its all wrong before I add the +1
576 2013-01-28 14:19:20 <TD> that seems fastest
577 2013-01-28 14:19:32 <TD> ok if you want to do extra stuff, no problem
578 2013-01-28 14:19:38 <BlueMatt> but feel free, Im sure Ill read through it before 0.7 gets released
579 2013-01-28 14:19:57 <BlueMatt> I just want to read through bitcoind side-by-side to make sure its +1 in all cases
580 2013-01-28 14:22:16 <TD> ok. it might be easier to understand the if the SigType mangling is done a bit differently, like with an accessor that maps the byte value to the right enum value
581 2013-01-28 14:23:04 <BlueMatt> well I figured it would work fine the way it was done, as you have to use the original byte value when doing the checkSig whether you map it to an enum or not
582 2013-01-28 14:23:37 <TD> why? because of round-trip serialization?
583 2013-01-28 14:24:15 <jgarzik> CodeShark: I'd be happy to supply any and all info you need for an autotools task
584 2013-01-28 14:24:29 <jgarzik> CodeShark: I'm an expert at this point (note: that's not something to brag about :))
585 2013-01-28 14:24:35 <CodeShark> thank you, much appreciated.
586 2013-01-28 14:25:08 <CodeShark> I'm doing a little research - if I have any questions, I'll bug you :)
587 2013-01-28 14:27:55 <BlueMatt> and you have to use the original byte value not the "real" value
588 2013-01-28 14:27:55 <BlueMatt> TD: yea, the +1 is obviously right...somehow I missed that subList is inclusive on the first parameter, exclusive on the second
589 2013-01-28 14:27:55 <BlueMatt> when doing the checkSig, you sign the (hash of the txn+sigType byte) not just the hash
590 2013-01-28 14:27:56 <BlueMatt> TD: feel free to just add it
591 2013-01-28 14:28:07 <TD> ok
592 2013-01-28 14:28:40 <BlueMatt> TD: anyway, re: test-cases, I know the script tests include at least one of each opcode except for sig checking, I was just apparently not paying attention and the the sig checking stuff went largely untested for non-SIGHASH_ALL
593 2013-01-28 14:28:50 <TD> maybe it's simpler to just scrap the enum then.
594 2013-01-28 14:29:00 <TD> or maybe it's still better API. i need to look at that code again.
595 2013-01-28 14:29:04 <BlueMatt> may be, but it makes it way better for API
596 2013-01-28 14:29:04 <TD> ok
597 2013-01-28 14:29:18 <BlueMatt> and the way it is thats all its used for
598 2013-01-28 14:30:07 <TD> i guess so
599 2013-01-28 14:30:48 <jgarzik> CodeShark: This is a useful template to start with: https://github.com/jgarzik/picocoin/blob/master/configure.ac
600 2013-01-28 14:31:13 <jgarzik> CodeShark: see also autogen.sh, and *.am from https://github.com/jgarzik/picocoin/
601 2013-01-28 14:31:19 <CodeShark> ok, thanks
602 2013-01-28 14:36:22 <CodeShark> jgarzik: I added that AM_INIT_AUTOMAKE line to my configure.ac and automake keeps giving me "configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found."
603 2013-01-28 14:37:01 <jgarzik> CodeShark: take picocoin's configure.ac and modify it to suit. order is important, for each macro line.
604 2013-01-28 14:37:17 <jgarzik> CodeShark: don't start from scratch. take a working one, and delete the unneeded bits near the bottom.
605 2013-01-28 14:37:44 <jgarzik> CodeShark: I have never run into that error :) Also, make sure you are using autogen.sh, not running it manually.
606 2013-01-28 14:38:03 <CodeShark> hmmm, but I want to understand what everything is
607 2013-01-28 14:38:19 <jgarzik> CodeShark: the order is -very- important for the first several lines
608 2013-01-28 14:38:48 <jgarzik> CodeShark: that will take forever ;-)
609 2013-01-28 14:39:03 <CodeShark> nah...
610 2013-01-28 14:39:14 <CodeShark> it's not conceptually difficult - just tedious
611 2013-01-28 14:41:27 <jgarzik> nod -- tedious for hysterical raisins, as you'll find out :)
612 2013-01-28 14:42:28 <jgarzik> some macros just break, if in the wrong order. and some macros had to be placed, and executed, early in configure.ac for automake-implementation-related reasons, not anything related to your own code.
613 2013-01-28 14:42:37 <CodeShark> I just had to run autoreconf, apparently
614 2013-01-28 14:42:40 <CodeShark> now that error is gone
615 2013-01-28 14:43:29 <CodeShark> ok, excellent - automake gave no errors now :)
616 2013-01-28 14:48:06 <Cryo> is it really supposed to take over 2 days for the block sync when bitcoin-qt hasn't been run in a couple months?
617 2013-01-28 14:48:20 <Cryo> or is my connection to the irc server going via pluto
618 2013-01-28 14:49:31 <jgarzik> Cryo: version 0.7.x I presume? it is possible, yes :( you can try closing the program and restarting, to find a new network peer.
619 2013-01-28 14:49:38 <jgarzik> Cryo: is your hard drive running 100%?
620 2013-01-28 14:50:18 <Cryo> hmm, yes it is. I thought that was supposed to be fixed a while back
621 2013-01-28 14:50:40 <Cryo> not 100% bandwidth of it, just doing constant read/write
622 2013-01-28 14:54:03 <jgarzik> Cryo: if the hard drive is running 100% of the time, it is probably not sitting around waiting for the network :/
623 2013-01-28 14:54:27 <jgarzik> Cryo: You can try a pre-0.8 release, which is much much faster: https://bitcointalk.org/index.php?topic=129861.0
624 2013-01-28 15:01:59 <Cryo> nope, sipa only has winux builds
625 2013-01-28 15:02:45 <Cryo> I'll create a ramdisk and try that
626 2013-01-28 15:02:52 <sipa> Cryo: using truecrypt, perhaps?
627 2013-01-28 15:03:14 <Cryo> nope, just regular HFS+ journaled
628 2013-01-28 15:04:08 <Cryo> it's just been a while since I fired up to test :)
629 2013-01-28 15:05:02 <Cryo> ok, maybe no ramdisk on THIS machine
630 2013-01-28 15:05:04 <Cryo> 10.0M\t./database
631 2013-01-28 15:05:04 <Cryo> 5.8G\t.
632 2013-01-28 15:05:21 <Cryo> these dat files are hugemongous
633 2013-01-28 15:05:30 <SomeoneWeird> that they are
634 2013-01-28 15:11:32 <muhoo> 5G is normal now, it seems
635 2013-01-28 15:12:41 <muhoo> what's the status of pruning? coming in 0.8?
636 2013-01-28 15:13:03 <Luke-Jr> muhoo: not a real priority, afaik
637 2013-01-28 15:13:06 <Luke-Jr> probably not in 0.8
638 2013-01-28 15:13:30 <Luke-Jr> but probably not hard to add yourself, if you're looking for something to code :p
639 2013-01-28 15:16:43 <sipa> not in 0.8, indeed
640 2013-01-28 15:16:59 <sipa> we first need a mechanism for clients to distinguish between pruned servers and non-pruned ones
641 2013-01-28 15:17:14 <sipa> as they'd try to do IBD from pruned ones otherwise
642 2013-01-28 15:17:49 <sipa> this requires adding a network bit, and rolling out clients that know about it
643 2013-01-28 15:17:57 <sipa> when that is done, we can start having pruned servers :)
644 2013-01-28 15:18:08 <sturles> How about half-pruned servers? I'l like to keep the last 2 GiB of blockchain, and prune the first on a very fast server due to disk qouta (university alumni account).
645 2013-01-28 15:18:38 <sipa> sturles: same problem
646 2013-01-28 15:18:44 <gmaxwell> sturles: thats even harder still??? but if we don't do that there is significant risk that lots of people will turn on pruning and make it impossible to initilize a full node.
647 2013-01-28 15:19:18 <sturles> I will keep full nodes, but my full nodes will have slower connections.
648 2013-01-28 15:21:00 <gmaxwell> sturles: the 'last' 2GiB is not what you'd want??? for safty and security the system will force keeping some of the very latest in any case.. otherwise a reorg kills you.
649 2013-01-28 15:21:37 <gmaxwell> sturles: what you'd want to do is also keep some random segment before the last so that even if many nodes are pruned the full chain would still be highly available.
650 2013-01-28 15:21:49 <gavinandresen> sipa: I'm working on issue 2201 (Catch LevelDB I/O errors), and thinking that throwing an exception, at least in the Read()/Exists() routines, is not the right thing to do. Read and Write already return bools for success/failure...
651 2013-01-28 15:22:14 <gmaxwell> (I misunderstood you at first)... but then that requires communicating which segmnts nodes have.
652 2013-01-28 15:22:24 <sipa> gavinandresen: seen #2224 ?
653 2013-01-28 15:22:36 <sipa> gavinandresen: that already catches write errors
654 2013-01-28 15:24:30 <muhoo> gmaxwell: interesting. almost bittorrent-like?
655 2013-01-28 15:25:07 <gmaxwell> muhoo: uh. very superficially.
656 2013-01-28 15:25:23 <sipa> gavinandresen: only problem is how to convey a failed read
657 2013-01-28 15:25:30 <sipa> api-wise
658 2013-01-28 15:25:40 <gavinandresen> sipa: I think just return false from Read() is sufficient
659 2013-01-28 15:25:51 <sipa> no, that means NotFound
660 2013-01-28 15:26:05 <sturles> gmaxwell: True. Some bittorrent-like system where the entire file is collcted from bits from random nodes.
661 2013-01-28 15:26:06 <sipa> well, it can be changed to mean something else
662 2013-01-28 15:26:18 <gavinandresen> false from Exists means not found....
663 2013-01-28 15:26:40 <gavinandresen> (unless i'm misunderstanding, which is always possible)
664 2013-01-28 15:26:51 <sipa> gavinandresen: from Read as well, and in most cases, you don't do Exists + Read if you're going to read the data anyway
665 2013-01-28 15:26:56 <gavinandresen> I'm working from the outside in-- randomly corrupting leveldb files and seeing what happens
666 2013-01-28 15:27:15 <sipa> plus, that's just moving the problem to Exists, as that also has no way to distinguish between failed read an not found
667 2013-01-28 15:27:35 <gmaxwell> Then you end up rejecting blocks when they don't validate, and get that problem I ran into on out of space.
668 2013-01-28 15:27:48 <gmaxwell> (where the node never recovers)
669 2013-01-28 15:27:56 <sipa> please, see #2224
670 2013-01-28 15:28:37 <gavinandresen> sipa: ok, I'll test 2224. Is that intended to be pulled before the 0.8rc1 ?
671 2013-01-28 15:28:46 <sipa> gavinandresen: i'd like that, yes
672 2013-01-28 15:29:00 <sipa> i feel the current code is too fragile
673 2013-01-28 15:30:24 <sipa> gavinandresen: imho the easiest solution is defining an exception in leveldb.h or txdb.h, and throwing that on read or write error
674 2013-01-28 15:30:41 <sipa> but that would certainly need testing
675 2013-01-28 15:31:06 <sipa> without an exception, you need a way to pass "failed read" through the CCoins interface
676 2013-01-28 15:31:11 <CodeShark> I totally concur, sipa :)
677 2013-01-28 15:31:32 <CodeShark> no point in having to deal with these errors at every single level of the stack
678 2013-01-28 15:31:41 <gavinandresen> sipa: simply throwing a runtime_error gives bad behavior (core dump with uncaught exception in Init)
679 2013-01-28 15:31:48 <CodeShark> it needs to be caught
680 2013-01-28 15:31:54 <gavinandresen> okey dokey
681 2013-01-28 15:31:55 <sipa> it needs to be caught in main
682 2013-01-28 15:33:43 <gavinandresen> Well, current behavior seems to be correct; I get "Error: Corrupted block database detected. Please restart the client with -reindex." A throw/catch at the very top level would give a less useful message
683 2013-01-28 15:34:02 <sipa> gavinandresen: not the same thing
684 2013-01-28 15:34:17 <gavinandresen> not the same thing as???. what?
685 2013-01-28 15:34:17 <sipa> what you're seeing is an application-level consistency check failing
686 2013-01-28 15:34:34 <sipa> of course you hope that those cause any problems with the chain data if they exist at startup
687 2013-01-28 15:35:09 <sipa> but that has nothing to do with correctly dealing with leveldb i/o errors
688 2013-01-28 15:35:17 <sipa> it's another layer of defense
689 2013-01-28 15:36:10 <sipa> it's just stupid to throw away information that exists at the leveldb level
690 2013-01-28 15:36:11 <sipa> it'
691 2013-01-28 15:36:33 <sipa> it can perfectly detect "hey dude, i can't give you any useful data, as what i'm seeing on disk is bullshit"
692 2013-01-28 15:36:45 <sipa> and we're like "nevermind, just give us something and we'll see what happens"
693 2013-01-28 15:37:09 <gavinandresen> ?
694 2013-01-28 15:37:09 <gavinandresen> ok, let me pop a level and ask directly: what needs to change to get 0.8rc1 out the door
695 2013-01-28 15:37:36 <gavinandresen> ??? and how can I help?
696 2013-01-28 15:37:49 <sipa> i'd like to have #2224 + some interface that reports failed read/writes upwards
697 2013-01-28 15:38:14 <sipa> i'll code something this evening, ok?
698 2013-01-28 15:38:28 <gavinandresen> ok, so Read()/Exists()/Write() either throw exceptions, and everyplace that calls them catches, or they return something other than a bool?
699 2013-01-28 15:38:34 <gmaxwell> I'm currently casually testing 2061.patch 2221.patch 2224.patch 2229.patch on a node here, fwiw.
700 2013-01-28 15:38:34 <sipa> exactly
701 2013-01-28 15:39:20 <CodeShark> well, you only need to catch them at some point on the stack
702 2013-01-28 15:39:30 <gavinandresen> sipa: let me know how I can help, we need to get a 0.8rc out soon
703 2013-01-28 15:39:32 <CodeShark> not necessarily at the point where Read/Exists/Write are called
704 2013-01-28 15:39:37 <sipa> CodeShark: sure
705 2013-01-28 15:40:20 <CodeShark> catching them at the top level might be good enough if you intend to immediately shutdown
706 2013-01-28 15:41:01 <sipa> well, #2224 adds a mechanism to report "runtime error during validation, try to shutdown cleanly"
707 2013-01-28 15:41:37 <CodeShark> right - cleanup must be performed where appropriate
708 2013-01-28 15:41:46 <Luke-Jr> #1583 seems trivial enough for 0.8, but also no big deal if it's missed
709 2013-01-28 15:42:09 <gmaxwell> Hm. Why would I get three add addresses from in my log from the same node right next to each other?
710 2013-01-28 15:42:23 <HM> oO
711 2013-01-28 15:42:39 <sipa> gmaxwell: maybe it sent 3 addr messages?
712 2013-01-28 15:42:49 <sipa> getaddr may result in several addr's
713 2013-01-28 15:43:06 <Luke-Jr> sipa: did #2042 end up fixed by something else?
714 2013-01-28 15:43:20 <sipa> no
715 2013-01-28 15:44:18 <sipa> Luke-Jr: i'm ok with the first commit in that pullreq, by the way
716 2013-01-28 15:44:33 <Luke-Jr> yeah, that's probably the more important part
717 2013-01-28 15:44:54 <Luke-Jr> the next commit almost certainly needs a rebase on top of the other problmes
718 2013-01-28 15:45:55 <gmaxwell> sipa: duh, yea. thats it. Just looked a bit odd.
719 2013-01-28 15:48:10 <Luke-Jr> sipa: actually??? looking at this commit again, it looks like it always truncates files not opened read-only? :/
720 2013-01-28 15:48:20 <Luke-Jr> either I wasn't thinking when I made it, or I'm not now..
721 2013-01-28 15:49:18 <sipa> Luke-Jr: i can't remember precisely, but i do remember that you convinced me the current code is very wrong
722 2013-01-28 15:49:37 <Luke-Jr> doesn't help if the new code is more wrong >_<
723 2013-01-28 15:57:22 <MC1984> 52 connections 224mb ram uptime about a week
724 2013-01-28 15:57:26 <MC1984> thats good right?
725 2013-01-28 15:57:59 <HM> my bitcoind has 60 and is using about a gig
726 2013-01-28 15:58:22 <HM> so yeah
727 2013-01-28 15:58:24 <MC1984> what build you got
728 2013-01-28 15:58:41 <HM> 0.7.2 debian
729 2013-01-28 15:59:51 <MC1984> im using pre 0.8 builds
730 2013-01-28 16:00:41 <HM> well debian stable isn't a great system to develop on if you want bleeding edge things
731 2013-01-28 16:01:02 <HM> and i don't want to run unstable on a VPS
732 2013-01-28 16:01:37 <gmaxwell> What reduced the memory usage recently?
733 2013-01-28 16:01:37 <MC1984> wit didnt they just manage to get the debian guys to update the package from 0.4 or something lol
734 2013-01-28 16:02:15 <HM> it was 0.7.2 hit a week or so ago
735 2013-01-28 16:02:29 <HM> well for amd64, i noticed it was available for other platforms first :|, even Itanium
736 2013-01-28 16:03:28 <MC1984> who the hell is doing builds for itanium?
737 2013-01-28 16:03:42 <epscy> is there a sparc build too?
738 2013-01-28 16:04:27 <MC1984> someone roll a dec alpha
739 2013-01-28 16:04:53 <MC1984> actually an arm build might be a good idea