1 2013-10-01 00:27:34 <BlueMatt> ;;seen jgarzik
2 2013-10-01 00:27:35 <gribble> jgarzik was last seen in #bitcoin-dev 1 day, 1 hour, 47 minutes, and 25 seconds ago: <jgarzik> I keep meaning to switch bitcoind over to multi-threaded asio for both RPC and network, speaking of I/O engines. But it's so damn annoying to program. Their multi-threaded, do-nothing http server example is over 1,000 lines.
3 2013-10-01 00:34:53 <soixante> l
4 2013-10-01 00:35:20 <soixante> ;;seen Luke-Jr
5 2013-10-01 00:35:21 <gribble> Luke-Jr was last seen in #bitcoin-dev 7 hours, 37 minutes, and 52 seconds ago: <Luke-Jr> hobbes1981-00: libblkmaker has an example
6 2013-10-01 00:35:42 <gribble> MagicalTux was last seen in #bitcoin-dev 5 weeks, 6 days, 15 hours, 48 minutes, and 16 seconds ago: <MagicalTux> would need help from a miner
7 2013-10-01 00:35:42 <soixante> ;;seen MagicalTux
8 2013-10-01 00:43:22 <Luke-Jr> soixante: ?
9 2013-10-01 00:44:15 <Krellan_> Boost compilation question
10 2013-10-01 00:45:25 <Krellan_> I can compile bitcoind just fine but src/qt/test gives undefined reference about boost::filesystem::whatever
11 2013-10-01 00:47:05 <sipa> git head?
12 2013-10-01 00:47:25 <Krellan_> Yes, just updated to master
13 2013-10-01 00:47:39 <sipa> what boost version?
14 2013-10-01 00:47:41 <Krellan_> I put in the suggested one-line fix to my pong patch
15 2013-10-01 00:48:28 <Krellan_> I'm running Gentoo and it's boost 1.52.0-r6
16 2013-10-01 00:48:54 <sipa> hmm, may be something to report to cfields
17 2013-10-01 00:49:22 <warren> hmm, I've seen something like that
18 2013-10-01 00:49:38 <warren> Krellan_: can I see the build log?
19 2013-10-01 00:50:19 <Krellan_> Sure
20 2013-10-01 00:50:25 <Krellan_> Let me put it up on pastebin
21 2013-10-01 00:53:19 <Krellan_> OK http://pastebin.com/index/ZRHgFc6k
22 2013-10-01 00:53:43 <Krellan_> bitcoind (regular, not bitcoin-qt) works nicely. The compile of bitcoin-qt won't get past that test phase.
23 2013-10-01 00:53:58 <warren> ok, that's a different error than what I saw
24 2013-10-01 00:54:38 <Krellan_> Tried getting sneaky and setting LDFLAGS to -lboost_filesystem-mt = Didn't help.
25 2013-10-01 00:55:17 <sipa> can you build bitcoin-qt without test?
26 2013-10-01 00:55:52 <Krellan_> Tried doing make in the qt directory, it recursed into test and then died there. What's clean way to cause it to skip that?
27 2013-10-01 00:55:54 <sipa> --disable-tests or something like that?
28 2013-10-01 00:56:07 <sipa> passed to configurr
29 2013-10-01 00:58:08 <sipa> perhaps just 'make bitcoin-qt' in the qt direcotry
30 2013-10-01 00:58:11 <warren> yes --disable-tests
31 2013-10-01 00:59:17 <Krellan_> OK compiling it now
32 2013-10-01 01:08:42 <Krellan_> Yay, it fully compiles! Have working bitcoin-qt.
33 2013-10-01 01:10:04 <Krellan_> So it only died in the compile of the test, which is interesting.
34 2013-10-01 01:10:08 <warren> forget about the tests =P
35 2013-10-01 01:10:31 <warren> there were a few other cases of test compile failure, qt5 fails there too for a different reason
36 2013-10-01 01:11:32 <Krellan_> Good to know.
37 2013-10-01 01:11:43 <Krellan_> https://github.com/bitcoin/bitcoin/pull/2937 = Got it up and running against latest master.
38 2013-10-01 01:11:55 <Krellan_> Clean rebase, no changes needed.
39 2013-10-01 01:49:20 <cfields> Krellan_: still around?
40 2013-10-01 02:21:45 <Krellan_> cfields: Hi
41 2013-10-01 02:22:37 <cfields> Krellan_: hi. mind helping out with debugging that problem? It'd be a big help
42 2013-10-01 02:23:01 <Krellan_> the library problem?
43 2013-10-01 02:23:47 <Krellan_> I could look at it later tonight perhaps but that makefile is :O
44 2013-10-01 02:23:55 <cfields> yes
45 2013-10-01 02:24:07 <cfields> Krellan_: would just take 2min if you could try something for me and paste the output
46 2013-10-01 02:24:15 <Krellan_> Oh I can certainly do that
47 2013-10-01 02:24:26 <Krellan_> does the same bug happen on other systems too, or is mine unique somehow?
48 2013-10-01 02:24:30 <cfields> ./configure without the tests disabled
49 2013-10-01 02:24:47 <cfields> my guess is that gentoo has a newer lib than most, with some abi change incorporated
50 2013-10-01 02:25:05 <Krellan_> Did you see the pastebin I had earlier, which was from that?
51 2013-10-01 02:25:31 <Krellan_> http://pastebin.com/index/ZRHgFc6k
52 2013-10-01 02:26:25 <cfields> yea, but i need to see the link line
53 2013-10-01 02:26:45 <cfields> ./configure without the tests disabled. then cd src/qt/test, then make V=1
54 2013-10-01 02:26:52 <cfields> that'll show what's going on
55 2013-10-01 02:26:56 <Krellan_> Nice, I was just going to ask how to get make to be verbose.
56 2013-10-01 02:29:51 <Krellan_> That's really weird. I tried it, and it *worked*. I cd into that directory first, though, not compiling anything else.
57 2013-10-01 02:31:04 <cfields> ...
58 2013-10-01 02:31:44 <cfields> ok, back up to the main dir, then. make clean && make
59 2013-10-01 02:32:10 <Krellan_> yep that's what I'm trying now
60 2013-10-01 02:44:21 <Krellan_> Well, I'll be. It all passed!
61 2013-10-01 02:44:28 <Krellan_> It even built the tests.
62 2013-10-01 02:44:42 <cfields> heh
63 2013-10-01 02:44:45 <cfields> so, what changed?
64 2013-10-01 02:47:16 <Krellan_> Unfortunately, no idea.
65 2013-10-01 02:47:52 <Krellan_> Will play around with it more later and see if I can get it to fail again.
66 2013-10-01 02:48:38 <cfields> no system changes? building from the same branch?
67 2013-10-01 02:49:59 <dizko> *** You have been kicked off channel #bitcoin by midnightmagic (bye)
68 2013-10-01 02:50:22 <dizko> can someone please unban me from #bitcoin, and remove ops from this person
69 2013-10-01 02:56:15 <Luke-Jr> dizko: I'm sure he had a good reason. And next you can be banned here for bringing up off-topic garbage if you continue complaining about it. This channel is for development.
70 2013-10-01 02:56:25 <dizko> he didnt
71 2013-10-01 02:56:58 <dizko> where would you recommend i file a greivance then
72 2013-10-01 02:57:35 <Luke-Jr> dizko: I'd recommend you drop it and stop whatever he banned you for.
73 2013-10-01 02:57:44 <dizko> i dont know what he banned me for
74 2013-10-01 02:58:59 <Luke-Jr> then re-read your log.
75 2013-10-01 02:59:14 <Luke-Jr> point is we don't care to hear it here.
76 2013-10-01 02:59:47 <dizko> that's fine i wont speak about it further, though rest assured he is in the wrong
77 2013-10-01 03:19:23 <Luke-Jr> https://github.com/jbangert/trapcc "This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete." O.o
78 2013-10-01 04:04:03 <warren> FYI: Folks working on autotools and gitian build upgrades/cleanups are in #bitcoin-build. The channel is also to help people better understand gitian so more people join the gitian.sigs process.
79 2013-10-01 04:20:39 <phantomcircuit> Luke-Jr, in other words, rootkit which defies debugging
80 2013-10-01 04:21:08 <Luke-Jr> phantomcircuit: hmm
81 2013-10-01 04:25:59 <jgarzik> FYI: I plan on discussing and working on build stuff in #bitcoin-dev, and don't see the need for yet another IRC channel just for build stuff
82 2013-10-01 04:26:51 <jgarzik> I can see the value if discussions start getting into the weeds, but, it is inevitable that bitcoin build system will be discussed here as well
83 2013-10-01 04:27:02 <CodeShark> yeah, building is part of dev
84 2013-10-01 04:27:37 <warren> jgarzik: there's weeds in there.
85 2013-10-01 04:28:10 <warren> jgarzik: I didn't create the group originally.
86 2013-10-01 04:28:13 <Luke-Jr> jgarzik++
87 2013-10-01 04:28:39 <Luke-Jr> all this channel proliferation has me hitting freenode's limits :/
88 2013-10-01 04:28:42 <CodeShark> so here's a build question - have any of you successfully built qt using x86_64-w64-mingw32 on linux?
89 2013-10-01 04:28:59 <CodeShark> not necessarily bitcoind - any app
90 2013-10-01 04:29:15 <jgarzik> does ubuntu have mingw64? I've been too lazy to investigate fully. I know Fedora does.
91 2013-10-01 04:29:15 <Luke-Jr> CodeShark: I'd be using Qt's official binaries for any other app
92 2013-10-01 04:29:35 <CodeShark> jgarzik: yes
93 2013-10-01 04:29:53 <CodeShark> jgarzik: you mean as a package?
94 2013-10-01 04:29:58 <warren> CodeShark: there's a PR to fix that build now, and cfields has comprehensive cleanups of that and all other gitian recipes coming.
95 2013-10-01 04:30:06 <jgarzik> CodeShark, yes, packaged
96 2013-10-01 04:30:10 <jgarzik> apt-get'able
97 2013-10-01 04:30:17 <CodeShark> jgarzik: yes, itdoes
98 2013-10-01 04:31:18 <CodeShark> Luke-Jr: so the follow-up question: have you built and deployed w64 qt apps from linux?
99 2013-10-01 04:31:18 <warren> jgarzik: recent master merge switched gitian win32 to 12.04 which has a far less buggy mingw. i686-w64-mingw32
100 2013-10-01 04:31:34 <warren> CodeShark the gitian recipes show how
101 2013-10-01 04:31:41 <Luke-Jr> CodeShark: not that far, no. w64, yes; qt, yes; but not the combo
102 2013-10-01 04:32:47 <jgarzik> warren, BTW RE RPC threads
103 2013-10-01 04:33:02 <jgarzik> warren, AFAICT the thread-grouping for RPC is simply broken by definition
104 2013-10-01 04:33:42 <jgarzik> warren, (1) Our RPC thread code assumes a connection runs to the end, which (2) worked fine for thread-per-connection, but (3) fails utterly if more than X threads are kept alive
105 2013-10-01 04:34:23 <CodeShark> yeah, we should probably move to using asio
106 2013-10-01 04:34:37 <warren> jgarzik: regarding 0.8.2, something became worse in this regard around that time. I'm just repeating what I've been told.
107 2013-10-01 04:34:50 <jgarzik> warren, in my email reply, I pinpoint the broken commit
108 2013-10-01 04:35:20 <gmaxwell> CodeShark: the rpc stuff is using ASIO.
109 2013-10-01 04:35:26 <jgarzik> gmaxwell, not really
110 2013-10-01 04:35:40 <gmaxwell> enough to make it difficult to debug in any case.
111 2013-10-01 04:35:50 <jgarzik> gmaxwell, using the API != having a multiple connection, single thread async I/O model
112 2013-10-01 04:35:58 <jgarzik> underscore underscore
113 2013-10-01 04:36:08 <jgarzik> gmaxwell, which is why Gavin's commit broke stuff
114 2013-10-01 04:36:21 <gmaxwell> jgarzik: can you reproduce the hang?
115 2013-10-01 04:36:28 <jgarzik> gmaxwell, yes, quite easily
116 2013-10-01 04:36:35 <CodeShark> jgarzik: correct - I'm not talking just about the library - I'm talking about running worker threads that can run multiple handlers
117 2013-10-01 04:36:40 <Luke-Jr> jgarzik: single thread would make longpolling 100x more complicated unless someone does some serious redesign :/
118 2013-10-01 04:36:44 <gmaxwell> jgarzik: sweet.
119 2013-10-01 04:37:28 <CodeShark> longpolling is a horrible hack :)
120 2013-10-01 04:37:35 <jgarzik> gmaxwell, It is quite obvious: our RPC is stlll single threaded, functionally speaking. The code is in no way, shape or form async. It MUST be run in its own thread, because it does blocking I/O.
121 2013-10-01 04:38:07 <jgarzik> gmaxwell, now consider: thread group size == 4. I create 4 TCP connections, each of which is keep-alive, causing 4 threads to enter blocking read-http/write-http loops.
122 2013-10-01 04:38:07 <Luke-Jr> CodeShark: not that horrible
123 2013-10-01 04:38:18 <jgarzik> Luke-Jr, what I just described is ;p
124 2013-10-01 04:38:46 <Luke-Jr> jgarzik: of course
125 2013-10-01 04:39:01 <jgarzik> gmaxwell, Our faux-ASIO is just an embarrassment, which is intended more to utilize SSL infrastructure than accomplish anything asynchronous.
126 2013-10-01 04:39:15 <CodeShark> jgarzik: exactly :)
127 2013-10-01 04:40:02 <jgarzik> And yes, I have direct experience here: https://github.com/jgarzik/rpcsrv
128 2013-10-01 04:40:18 <jgarzik> That is a skeleton, multi-threaded JSON-RPC-over-HTTP server using boost asio properly.
129 2013-10-01 04:40:54 <jgarzik> It is ridiculously large :/
130 2013-10-01 04:41:09 <jgarzik> But it was built to prototype then test a proper bitcoind json-rpc server
131 2013-10-01 04:41:18 <jgarzik> using boost::asio's own m-t http server example
132 2013-10-01 04:41:56 <CodeShark> I've implemented a bitcoin node that uses boost::asio
133 2013-10-01 04:41:58 <jgarzik> in theory, we can drop that in and replace bitcoinrpc.cpp's server
134 2013-10-01 04:42:13 <jgarzik> but the LOC just makes me shiver and hate boost
135 2013-10-01 04:42:23 <jgarzik> regardless, it is a viable solution
136 2013-10-01 04:43:47 <CodeShark> I have both sync and async I/O versions
137 2013-10-01 04:44:17 <Luke-Jr> ACTION makes plans to troll jgarzik at work Friday.
138 2013-10-01 04:44:24 <CodeShark> if you copy buffers before passing into message handlers, at the small cost of copying you get rid of synchronization issues in many cases
139 2013-10-01 04:44:27 <jgarzik> warren, gmaxwell: tl;dr it is reproducible that bitcoind cannot exceed $thread_group_size HTTP keep-alive threads, following commit 21eb5adadbe3110a8708f2570185566e1f137a49
140 2013-10-01 04:44:49 <jgarzik> (which introduced RPC thread groups, dropping thread-per-connection)
141 2013-10-01 04:44:56 <jgarzik> I had missed commit 21eb5adadbe3110a8708f2570185566e1f137a49 completely.
142 2013-10-01 04:47:38 <CodeShark> also, using C++11 lambdas can help make async code more readable in many cases
143 2013-10-01 04:49:21 <jgarzik> If you look at https://github.com/jgarzik/rpcsrv you can see what a mess is made of (a) new connections, (b) asynchronously processed buffers, and (d) in general requiring 2-4 LOC to accomplish a single callback/bind, resulting in equally unreadable error and warning messages out of the compiler.
144 2013-10-01 04:49:30 <jgarzik> P.S. There is no because I hate xchat.
145 2013-10-01 04:53:36 <gmaxwell> jgarzik: I think it was known to everyone else that bitcoind cannot exceed $thread_group_size HTTP keep-alive threads.
146 2013-10-01 04:54:20 <jgarzik> gmaxwell, hum, well it's a horribly broken limitation. No HTTP server worth anything does that ;p
147 2013-10-01 04:54:37 <jgarzik> gmaxwell, and it is certainly a regression
148 2013-10-01 04:56:41 <gmaxwell> Yea, I think it's lame too, but: unbounded thread usage is also not good. I forwarded you the offlist discussion I had wit slush.
149 2013-10-01 04:56:50 <gmaxwell> er with*
150 2013-10-01 04:58:13 <CodeShark> here's the async implementation for the p2p protocol: http://pastebin.com/fL11spZh
151 2013-10-01 04:59:46 <jgarzik> gmaxwell, I upgrade from lame to regression+broken ;p Clearly 4 is too low as it generates user issue reports, and behaves unlike most other HTTP servers deployed out in the field.
152 2013-10-01 04:59:49 <CodeShark> it does have copious amounts of buffer copying and dynamic allocation - but these things are not the bottleneck
153 2013-10-01 05:00:15 <jgarzik> CodeShark, well my recent P2P code change increased message copying a bit anyways, so maybe its a wash
154 2013-10-01 05:00:40 <jgarzik> ACTION rewrote the core network messsage collecting/dispatch code
155 2013-10-01 05:00:46 <CodeShark> jgarzik: it's the price to pay for simplification of synchronization code
156 2013-10-01 05:01:15 <jgarzik> The price to pay for being a bit more parallel
157 2013-10-01 05:02:01 <gmaxwell> jgarzik: one obvious thing to do in response would just be to disable keepalive on the last connection.
158 2013-10-01 05:02:21 <gmaxwell> then you keep thread count constant but don't allow blocking.
159 2013-10-01 05:03:12 <gmaxwell> jgarzik: I'm unsure if its generating user reports or not. :( I could believe some users wouldn't know if they were pinning up connections with keep alive or not but that wouldn't apply, for example, to chris double.
160 2013-10-01 05:05:04 <gmaxwell> though it seems a bit drainbramaged that an idle keepalive connections has to consume a whole thread.
161 2013-10-01 05:05:11 <gmaxwell> "so much for async"
162 2013-10-01 05:06:33 <jgarzik> hence "faux-ASIO"
163 2013-10-01 05:06:47 <jgarzik> we could do it all in one thread, with async I/O
164 2013-10-01 05:07:15 <jgarzik> the multi-thread thing is not for CPU resources, but because our http server code is so damn dumb
165 2013-10-01 05:08:07 <jgarzik> Satoshi wrote it one night while drinking Jaegermeister, after someone told him for the 1000x time that bitcoin must have a server, that it could not be Windows-only forever and still succeed.
166 2013-10-01 05:08:21 <dizko> jgarzik: i use your python-bitcoinrpc, its unclear to me that it is using keepalive, or that there is something different i can do to keep those connections alive
167 2013-10-01 05:08:31 <jgarzik> and that shitty blocking I/O code remaining, to this day, mangled and mushed by keep-alive into threads
168 2013-10-01 05:08:37 <jgarzik> *remains
169 2013-10-01 05:08:43 <dizko> i cleaned up mycode so i hit rpc far less, but it was / is stil lcausing me trouble
170 2013-10-01 05:09:00 <jgarzik> dizko, make sure to re-use the object
171 2013-10-01 05:09:51 <dizko> i also get a ton of TIME_WAITs, something isnt sending a FIN maybe?
172 2013-10-01 05:10:25 <dizko> is there a method to close the connection and close the socket gracefully?
173 2013-10-01 05:11:37 <jgarzik> dizko, if you want to close the connection, destroy the object (do not reuse)
174 2013-10-01 05:12:45 <dizko> i only learned python recently, how do you do that, obj = None ?
175 2013-10-01 05:14:23 <dizko> ah, del
176 2013-10-01 05:17:14 <dizko> thanks, though double checking, i am reusing the same obj. i was doing a lot of getbalance's for logging purposes, realized that most of the tiems it crapped out it was on one of those
177 2013-10-01 05:17:57 <dizko> even though it was running getsinceblock and getrawtransaction many more times
178 2013-10-01 05:18:09 <dizko> is getbalance an expensive operation?
179 2013-10-01 07:15:07 <rusty> Dumb q: history of the checksum in the network protocol. Was there really evidence of TCP corruption? Any pointers?
180 2013-10-01 07:18:08 <sipa> not tcp corruption
181 2013-10-01 07:18:18 <sipa> just a serialization bu
182 2013-10-01 07:20:27 <Krellan> cfields: Hi again. I think what was going on earlier was the "make clean" actually cleaned out some cruft that was in the way from before, causing the build to succeed. I hadn't done "make clean" in a while.
183 2013-10-01 07:21:54 <rusty> sipa: ah... not sure how a checksum helps a serialization issue though?
184 2013-10-01 07:22:25 <sipa> rusty: end-of-message boundaries were crossed
185 2013-10-01 07:22:32 <sipa> checksums definitely help there
186 2013-10-01 07:24:16 <rusty> sipa: ah, right, that'd get completely desynchronized. This means a checksum fail for the overrunning message, rahter than a weird error on the "next" one?
187 2013-10-01 07:25:08 <sipa> right
188 2013-10-01 07:26:01 <rusty> sipa: thanks, that's exactly the clue I was looking for.
189 2013-10-01 07:34:39 <gmaxwell> rusty: tcp corruption does happen, the tcp crc is lamesauce (... it's fantastic then when a error gets past the tcp crc SSH, for example, just drops the connection). Bitcoin's flooding model makes that maybe very slightly worse than it would be for other protocols, but not enough to justify it on its own.
190 2013-10-01 07:36:10 <rusty> gmaxwell: that's been my experience too, but wanted to confirm there wasn't some bitcoin-specific subtlety. Checksums are unusual in higher level protocols.
191 2013-10-01 07:37:02 <sipa> it's certainly overkill
192 2013-10-01 07:37:28 <sipa> especially truncated-double-sha256 checksums...
193 2013-10-01 09:08:46 <warren> sipa: https://github.com/bitcoin/bitcoin/pull/2888 does your comment here mean this current implementation is good enough?
194 2013-10-01 09:40:52 <swulf--> there's an interesting .. quirk .. in the test_bitcoin project that MSVC is barfing on
195 2013-10-01 09:43:15 <swulf--> wallet_test's "CWallet wallet;" static initializer is called before util.cpp's LockedPageManager::instance's initializer -- and normally this wouldn't be a problem, but MSVC's STL allocates 1 byte in vector<>'s constructor (in debug build)...
196 2013-10-01 09:49:15 <sipa> swulf--: that's interesting
197 2013-10-01 09:52:45 <swulf--> sipa: if I'm serious about getting msvc going, I'll need to figure out the best solution for this -- one is to just disable the locked page allocator in the test_bitcoin build, the other is to use an instance method (i.e., GetInstance())
198 2013-10-01 09:53:30 <swulf--> LockedPageManager::instance is only referenced in a small handful of places
199 2013-10-01 09:58:03 <sipa> swulf--: if you find potential generic problems with the code, feel free to send pull requests to fix
200 2013-10-01 09:59:34 <swulf--> should I keep a change like this separate from my msvc changes?
201 2013-10-01 10:01:23 <swulf--> a separate, clean branch is probably best
202 2013-10-01 10:03:43 <warren> swulf--: what version of MSVC?
203 2013-10-01 10:05:08 <warren> swulf--: I'm slowly working on generic CPU features detection for Bitcoin/Litecoin. I know MSVC can't do inline assembly so I already have some code to use a native library to get the cpu features.
204 2013-10-01 10:05:34 <warren> swulf--: do you have the ability to export the complete list of all preprocessor defines in MSVC? I could use one with a 32bit and 64bit binary target.
205 2013-10-01 10:06:01 <swulf--> warren: MSVC 2010
206 2013-10-01 10:06:15 <swulf--> warren: I could probably figure out how to do that...
207 2013-10-01 10:06:40 <swulf--> I'm pretty sure msvc has intrinsics for those things
208 2013-10-01 10:07:14 <warren> swulf--: yeah, but I need to know the preprocessor defines available to automatically use windows intrinsics instead of linux or mac
209 2013-10-01 10:08:08 <warren> swulf--: https://togami.com/~warren/temp/MINGW-precise.txt all preprocessor defines from the 12.04 i686-w64-mingw32 cross-compiler
210 2013-10-01 10:08:34 <warren> would be very helpful to have a similar list to this
211 2013-10-01 10:09:36 <swulf--> warren: did you see my last few lines?
212 2013-10-01 10:12:24 <swulf--> warren: I'll try and put together a list like this
213 2013-10-01 10:19:53 <kuzetsa> warren: you're mistaken, you can totally do inline assembler using MSVC --> http://msdn.microsoft.com/en-us/library/5f7adz6y.aspx
214 2013-10-01 10:20:13 <warren> kuzetsa: not with the most recent 64bit versions
215 2013-10-01 10:20:39 <kuzetsa> =o.O=
216 2013-10-01 10:21:00 <kuzetsa> what are you using 64 bit for?
217 2013-10-01 10:21:24 <kuzetsa> it's not like bitcoin stuff normally needs more than 1-2 gigabytes of address space
218 2013-10-01 10:22:12 <swulf--> 64-bit disabled inline asm, yeah
219 2013-10-01 10:36:08 <swulf--> sipa: https://github.com/bitcoin/bitcoin/pull/3046
220 2013-10-01 10:40:01 <warren> kuzetsa: 64bit can have more performance in some ways
221 2013-10-01 10:40:18 <warren> kuzetsa: sipa's secp256k1 is omgwtf faster on 64bit
222 2013-10-01 10:42:16 <_dr> yeah like... whenever your doing >32bit calculations ;)
223 2013-10-01 10:42:30 <_dr> ever tried multiplying two 64bit numbers using 32bit registers
224 2013-10-01 11:10:33 <warren> _dr: swulf--: also 64bit is guaranteed to have SSE2... easier to implement things. 32bit you need to detect cpu features and have multiple implementations, which is harder.
225 2013-10-01 11:11:18 <_dr> I don't see how 64bit mandates the existence of sse
226 2013-10-01 11:11:41 <warren> _dr: just when the CPU's happened, all x86-64 has SSE2
227 2013-10-01 11:11:54 <swulf--> warren: the intrinsics should be available in both targets, however
228 2013-10-01 11:12:15 <_dr> yeah but the speed you'll get with intrinsics can be much lower than assembly
229 2013-10-01 11:12:28 <warren> swulf--: you can't build the entire 32bit binary that way due to risk of auto-vectorization
230 2013-10-01 11:12:50 <_dr> #pragma novec?
231 2013-10-01 11:12:52 <swulf--> dr: if you're hand-editing the assembly, sure
232 2013-10-01 11:13:26 <_dr> warren: where do you risk auto-vectorization?
233 2013-10-01 11:13:36 <warren> #pragma for compiler options in different parts of the file was broken for g++ until gcc-4.7.x I think
234 2013-10-01 11:13:53 <warren> _dr: in boring code
235 2013-10-01 11:14:29 <_dr> a compiler can only auto-vectorize code that will remain semantically intact when vectorized
236 2013-10-01 11:14:31 <warren> _dr: you need to separately build generic and SSE2 optimized code paths and switch to one or another depending on the CPU features available
237 2013-10-01 11:14:35 <_dr> so you can't break anything with it
238 2013-10-01 11:14:40 <warren> _dr: no
239 2013-10-01 11:14:41 <i2pRelay> You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes.
240 2013-10-01 11:15:05 <warren> _dr: binary distributions for 32bit windows for example need to support all possible processors
241 2013-10-01 11:15:18 <_dr> no
242 2013-10-01 11:15:53 <_dr> windows runs on PCs. the binaries all use the x86 instruction set
243 2013-10-01 11:16:00 <_dr> (32-bit)
244 2013-10-01 11:18:35 <_dr> pentium uses 'mul' to multiply, core uses 'mul' nehalem uses 'mul' sandy bridge uses 'mul' haswell uses 'mul', amd uses ... 'mul' not 'amd_mul'
245 2013-10-01 11:32:24 <warren> _dr: with auto vectorization it's possible for SSE2 instructions to leak into parts of the code that doesn't need it
246 2013-10-01 11:32:57 <warren> _dr: you need runtime detection to choose between generic and SIMD implementations of performance sensitive code
247 2013-10-01 11:34:09 <_dr> that's a different story. but it's not that hard. 5 lines of code and some Makefile modifications to build for multiple archs, right?
248 2013-10-01 11:34:54 <warren> _dr: you want a single binary that swiches to the fastest implementation for that particular hardware
249 2013-10-01 11:35:20 <warren> _dr: I already have code to do 90% of this, will push to bitcoin after there's a reason to do it.
250 2013-10-01 11:35:40 <_dr> yeah. you just link all your object files (generated by gcc for different uarchs) and use cpuid during runtime to choose the right function
251 2013-10-01 11:36:16 <_dr> wouldn't that be sufficient? I haven't done it myself but it doesn't seem overly complicated. the cpuid behaviour is also really well documented so there shouldn't be any problems
252 2013-10-01 11:41:40 <warren> _dr: you'd be surprised. there's a few different ways of getting cpuid. the typical inline assembler method doesn't build with the ancient gcc used for Bitcoin builds on mac.
253 2013-10-01 11:41:55 <warren> _dr: it crashes for unknonw reasons with the 10.04 ancient mingw32 compiler for gitian win32
254 2013-10-01 11:42:03 <warren> works fine for gitian linux32 though
255 2013-10-01 11:42:44 <_dr> heh. I guess sometimes compilers cause more problems than they cause :)
256 2013-10-01 11:42:57 <_dr> maybe you shouldn't use inline assembly but a real .S file
257 2013-10-01 11:43:15 <_dr> s/cause/solve/2
258 2013-10-01 11:45:32 <_dr> I think intel even has a template in their manual, hang on
259 2013-10-01 11:49:01 <warren> _dr: not concerned about old compilers here
260 2013-10-01 11:49:14 <warren> _dr: bitcoin 0.9 already upgraded to a modern mingw32
261 2013-10-01 11:49:27 <warren> _dr: and mac will drop support for older releases soon
262 2013-10-01 11:49:30 <i2pRelay> You've given me 5 invalid commands within the last minute; I'm now ignoring you for 10 minutes.
263 2013-10-01 11:50:37 <sipa> warren: not mingw32, mingw-w64 :)
264 2013-10-01 11:50:38 <sipa> no?
265 2013-10-01 11:53:11 <warren> sipa: right
266 2013-10-01 11:53:21 <warren> sipa: I'm not too versed in hte difference
267 2013-10-01 11:53:44 <t7> w64 is new better faster stronger
268 2013-10-01 11:53:46 <warren> sipa: mingw32 in 12.04 seems to be a compat version to build things that relied on the old crapppy compiler bugs
269 2013-10-01 12:55:26 <CodeShark> speaking of mingw-w64, I'm having trouble with exceptions - I think I'm building libraries that are incompatibleâ¦some use sjlj, some use seh
270 2013-10-01 12:55:36 <CodeShark> anyone have some advice on how to troubleshoot this?
271 2013-10-01 12:58:18 <CodeShark> oh!!!
272 2013-10-01 12:58:53 <swulf--> figure it out? :P
273 2013-10-01 12:58:56 <CodeShark> I was using posix-seh instead of win32-sjlj in my windows build, I think
274 2013-10-01 12:59:22 <CodeShark> I don''t think gcc versions < 4.8 support seh
275 2013-10-01 12:59:44 <CodeShark> well, crap - that means I have to rebuild Qt5 :p
276 2013-10-01 13:01:03 <swulf--> warren: are you the maintainer of the mingw build?
277 2013-10-01 13:50:27 <swulf--> warren: http://pastebin.com/xSXvfpjj msvc 2010 definitions, best I can find..
278 2013-10-01 13:57:19 <jgarzik> mornin'
279 2013-10-01 14:27:33 <jgarzik> Neat. KNCMiner Jupiter is 0.5 TH.
280 2013-10-01 14:27:39 <jgarzik> and shipping today
281 2013-10-01 14:46:13 <Anduck> is libqt needed for bitcoind only?
282 2013-10-01 14:46:23 <sipa> no
283 2013-10-01 14:46:30 <Anduck> i am like totally noob currently when i can't find makefile.unix
284 2013-10-01 14:46:43 <Anduck> ./autogen doesn't work....
285 2013-10-01 14:47:16 <Anduck> any fast tip on how to build bitcoind only?
286 2013-10-01 14:48:15 <nkuttler> Anduck: it's in the src dir
287 2013-10-01 14:48:23 <sipa> ./autogen.sh && ./configure --without-qt && make
288 2013-10-01 14:48:28 <nkuttler> unless you use trunk, might have been removed there
289 2013-10-01 14:48:28 <sipa> nkuttler: no, Makefile.unix is gone
290 2013-10-01 14:49:01 <nkuttler> no qmake necessary either?
291 2013-10-01 14:49:11 <Anduck> autoreconf: command not found
292 2013-10-01 14:49:14 <sipa> no, qmake is gone too
293 2013-10-01 14:49:19 <sipa> Anduck: you'll need to install autotools
294 2013-10-01 14:49:23 <Anduck> ahh
295 2013-10-01 14:49:43 <sipa> sudo aptitude install autoconf
296 2013-10-01 14:49:50 <Anduck> why is there no mention about this in build-unix
297 2013-10-01 14:50:20 <sipa> well, it's git head, and there are still autotools cleanups happening
298 2013-10-01 14:50:27 <sipa> documentation will be updated before release
299 2013-10-01 14:50:33 <Anduck> btw works now,thx for help
300 2013-10-01 14:50:34 <Anduck> ok
301 2013-10-01 15:52:37 <helo> can there be arbitrary fields added to payment requests?
302 2013-10-01 15:54:33 <helo> e.g. a user to rate and the rating to give upon fulfillment
303 2013-10-01 15:54:55 <sipa> that seems like something to put in the memo field
304 2013-10-01 15:55:52 <sipa> if there's demand there may be some use for a 'structured data' field in the payment, and a format specification for it in the request
305 2013-10-01 15:55:55 <sipa> but that seems far out
306 2013-10-01 15:55:56 <helo> maybe a WoT signature by the rating user
307 2013-10-01 15:56:39 <helo> (yeah, a little redundant, but WoT doesn't do x509)
308 2013-10-01 15:57:35 <sipa> well WoT-like things could be added as a different authentication system
309 2013-10-01 15:57:39 <sipa> separate from x509
310 2013-10-01 16:06:26 <sipa> ;;genrate 11333
311 2013-10-01 16:06:27 <gribble> The expected generation output, at 11333.0 Mhps, given difficulty of 148819199.805, is 0.0382977435585 BTC per day and 0.00159573931494 BTC per hour.
312 2013-10-01 16:11:35 <cfields> Krellan: ah, ok. thanks for reporting back
313 2013-10-01 16:20:17 <helo> seems like bitcoin signatures would be a good candidate for payment protocol authentication
314 2013-10-01 16:20:54 <helo> x509 makes sense for mass adoption, but it would be pretty neat to be able to generate and sign a payment request with the reference client
315 2013-10-01 16:22:04 <helo> using a designated authentication privkey/address
316 2013-10-01 16:22:07 <gmaxwell> helo: you can sign anything you want, but bitcoin signatures are in no way an alternative to x509...
317 2013-10-01 16:22:27 <helo> 'none' is an alternative to x509, so why not bitcoin sigs?
318 2013-10-01 16:23:27 <gmaxwell> helo: bitcoin sigs are none for that purpose (though if you want to hash your payment request and sign it with $whatever you can)
319 2013-10-01 16:24:29 <gmaxwell> helo: the x509 integration is there so it can display a human comprehensible name for the requesting party. Bitcoin signatures don't do anything for that. They just sign. If you want to just sign, then just sign.
320 2013-10-01 16:25:32 <helo> seems like an obvious application of signmessage if there ever was one
321 2013-10-01 16:25:38 <gmaxwell> ...
322 2013-10-01 16:25:42 <gmaxwell> It really isn't.
323 2013-10-01 16:25:54 <gmaxwell> But you can signmessage things if you want, nothing is stopping you.
324 2013-10-01 16:26:03 <helo> WoT already uses it to identify/auth users
325 2013-10-01 16:26:07 <gmaxwell> Signmessage was created for things like eligius' accountless configuration.
326 2013-10-01 16:26:58 <helo> would be pretty easy to add a user to your address book and be shown that user's name/info if you receive a payment request from them
327 2013-10-01 16:30:45 <denisx> hah, bike ist fertig
328 2013-10-01 16:30:46 <denisx> bis spaeter
329 2013-10-01 16:55:04 <CircusPeanut> hi
330 2013-10-01 17:22:10 <sipa> helo: i'm sure you could plug ecdsa/secp256k1 signatures into x509
331 2013-10-01 17:22:23 <sipa> or you could create a PKI on top of signmessage
332 2013-10-01 17:22:29 <sipa> but they're orthogonal
333 2013-10-01 17:23:02 <helo> yeah, i get that
334 2013-10-01 17:42:01 <michagogo> ;;google http code 405
335 2013-10-01 17:42:36 <michagogo> ;;ping
336 2013-10-01 17:42:37 <gribble> pong
337 2013-10-01 17:43:08 <gribble> An error has occurred and has been logged. Please contact this bot's administrator for more information.
338 2013-10-01 17:47:11 <michagogo> Is it just me or if github being weird?
339 2013-10-01 17:49:34 <swulf--> github is dead for me too
340 2013-10-01 17:50:19 <michagogo> Looks like it's working if you refresh enough
341 2013-10-01 17:50:34 <swulf--> michagogo: hehe, perhaps that's contributing to the problem? ;)
342 2013-10-01 17:50:48 <michagogo> same if you're trying to fetch/push/pull: if it's frozen after a few secs, ctrl-c,up,enter
343 2013-10-01 17:50:49 <michagogo> Maybe.
344 2013-10-01 18:15:51 <CodeShark> anyone ever gotten a "localtime_r not defined" error with mingw-w64?
345 2013-10-01 18:16:30 <swulf--> CodeShark: you're developing on windows?
346 2013-10-01 18:16:55 <CodeShark> I'm trying to build some libraries in windows so I can copy them over to my linux cross build environment
347 2013-10-01 18:17:03 <swulf--> ah
348 2013-10-01 18:17:21 <swulf--> sounds like a lovely nightmare
349 2013-10-01 18:17:35 <CodeShark> to say it's tedious would be an understatement :p
350 2013-10-01 18:18:06 <CodeShark> but it's the kind of thing one has to do from time to time if one wants to amass an allpowerful arsenal of tools :)
351 2013-10-01 18:18:31 <swulf--> what's the goal? to build a windows executable from your linux environment?
352 2013-10-01 18:18:37 <Luke-Jr> CodeShark: localtime_r is not necessary on Windows IIRC
353 2013-10-01 18:19:41 <CodeShark> Luke-Jr: I'm building Qt5 on windows and a source file calls this function
354 2013-10-01 18:19:52 <Luke-Jr> I imagine Qt has another solution somewhere
355 2013-10-01 18:20:11 <Luke-Jr> localtime_r is a POSIX workaround to thread-unsafe localtime
356 2013-10-01 18:20:17 <Luke-Jr> but Windows has localtime itself thread-safe
357 2013-10-01 18:20:37 <Luke-Jr> there's also a minor compatibility issue if people do localtime(struct timeval.tv_sec)
358 2013-10-01 18:20:46 <Luke-Jr> since struct timeval.tv_sec is a different size than time_t on Windows
359 2013-10-01 18:21:02 <Luke-Jr> BFGMiner has a workaround in compat.h, but Qt should build already..
360 2013-10-01 18:21:07 <sipa> do they have a thread-local variable for localtime?
361 2013-10-01 18:21:40 <Luke-Jr> sipa: right, the static buffer is thread-local
362 2013-10-01 18:21:46 <sipa> makes sense
363 2013-10-01 18:22:02 <Luke-Jr> yeah, I guess POSIX didn't do it because of lack of threading primitives in the standard library back then?
364 2013-10-01 18:22:08 <sipa> i assume so
365 2013-10-01 18:22:21 <Luke-Jr> or maybe because it was already thread-unsafe and they didn't want a silent compat break
366 2013-10-01 18:22:30 <Luke-Jr> better to throw an error than silently have race conditions
367 2013-10-01 18:23:36 <CodeShark> https://qt.gitorious.org/qt/qtdeclarative/source/b67667d0d9ae3d3d438942116690eaac2bc1303e:src/qml/qml/v4/qv4dateobject.cpp line 305
368 2013-10-01 18:24:36 <sipa> #ifdef WIN32 #define localtime_r localtime
369 2013-10-01 18:24:50 <Luke-Jr> sipa: not that simple :P
370 2013-10-01 18:24:57 <Luke-Jr> CodeShark: I imagine they have a macro for it
371 2013-10-01 18:25:23 <michagogo> Does Diapolo go by a different name on IRC than on github
372 2013-10-01 18:25:24 <michagogo> ?
373 2013-10-01 18:25:36 <Luke-Jr> no, he's just not on IRC mcuh
374 2013-10-01 18:25:39 <michagogo> k
375 2013-10-01 18:25:47 <CodeShark> Luke-Jr: might there be a configure option for it?
376 2013-10-01 18:25:48 <michagogo> D'you know his timezone?
377 2013-10-01 18:26:03 <Luke-Jr> CodeShark: dunno
378 2013-10-01 18:26:18 <sipa> michagogo: CET/CEST
379 2013-10-01 18:26:32 <michagogo> that's...
380 2013-10-01 18:26:36 <michagogo> UTC+2 atm?
381 2013-10-01 18:26:43 <sipa> one hour earlier than where you are
382 2013-10-01 18:26:49 <michagogo> so yes
383 2013-10-01 18:26:54 <sipa> indeed
384 2013-10-01 18:27:30 <michagogo> Anyway, he suggested that I upgrade release-process.md to using https
385 2013-10-01 18:27:52 <michagogo> Is using `wget --no-check-certificate 'https://...` any better than using `wget 'http://...` ?
386 2013-10-01 18:29:55 <Luke-Jr> michagogo: no
387 2013-10-01 18:30:23 <sipa> it's more secure against a passive attacker
388 2013-10-01 18:30:56 <swulf--> if you issued the cert yourself and are pulling from one of your trusted sites, then it's probably safe?
389 2013-10-01 18:31:02 <helo> if <some stuff>, it's just as good!
390 2013-10-01 18:31:02 <swulf--> but there are a lot of assumptions there
391 2013-10-01 18:31:20 <sipa> it's certainly not worse, except perhaps for a false sense of securiy
392 2013-10-01 18:33:31 <michagogo> when wgetting bdb, trying to use https produces ERROR: no certificate subject alternative name matches requested host name âdownload.oracle.comâ.
393 2013-10-01 18:34:04 <michagogo> So I was wondering if I should leave that as http in release-process.md, or add --no-check-certificate
394 2013-10-01 18:35:16 <jgarzik> I love telling recruiters that their tech is boneheaded.
395 2013-10-01 18:35:23 <sipa> jgarzik: ?
396 2013-10-01 18:35:40 <jgarzik> "You were referred as a Senior Technical Lead for Ruby on Rails position!"
397 2013-10-01 18:36:08 <jgarzik> "Whoever made that referral was drinking heavily. Ruby on Rails is the worst additional to the technology landscape since COBOL."
398 2013-10-01 18:36:19 <jgarzik> *addition
399 2013-10-01 18:37:26 <Luke-Jr> sipa: and more typing
400 2013-10-01 18:37:40 <sipa> Luke-Jr: and more CPU
401 2013-10-01 18:37:53 <Luke-Jr> jgarzik: hahahahaha
402 2013-10-01 18:38:01 <michagogo> ...so is that a "leave it as http", then?
403 2013-10-01 18:38:16 <Luke-Jr> sipa: and doesn't work on routers without SSL support!
404 2013-10-01 18:38:19 <Luke-Jr> <.<
405 2013-10-01 18:38:28 <sipa> Luke-Jr: ...
406 2013-10-01 18:38:32 <Luke-Jr> lol
407 2013-10-01 18:38:34 <sipa> you mean those from the NSA?
408 2013-10-01 18:39:14 <Luke-Jr> I mean OpenWrt
409 2013-10-01 18:39:21 <Luke-Jr> or at least the build Avalon uses
410 2013-10-01 18:39:43 <Luke-Jr> but no idea why you'd be building bitcoind on a router with 4 MB flash
411 2013-10-01 18:40:06 <jgarzik> heh
412 2013-10-01 18:40:26 <jgarzik> + nor much RAM
413 2013-10-01 18:40:41 <jgarzik> I guess your router could always do NBD/iSCSI/NFS ;p
414 2013-10-01 18:40:43 <jgarzik> ACTION shivers
415 2013-10-01 18:42:02 <Luke-Jr> just use the NSA's cloud
416 2013-10-01 18:42:13 <michagogo> updated https://github.com/bitcoin/bitcoin/pull/3028
417 2013-10-01 18:46:00 <CodeShark> lol, apparently this same issue has come up numerous times in other modules of Qt as the changelog indicates
418 2013-10-01 18:46:04 <CodeShark> but this one might have been missed
419 2013-10-01 18:46:21 <sipa> "who uses qt-declarative anyway?"
420 2013-10-01 18:46:31 <Luke-Jr> CodeShark: are you trying to build Qt from git or something?
421 2013-10-01 18:46:41 <CodeShark> Luke-Jr: yes
422 2013-10-01 18:46:48 <Luke-Jr> why?
423 2013-10-01 18:47:22 <CodeShark> why not?
424 2013-10-01 18:47:41 <Luke-Jr> â¦
425 2013-10-01 18:47:46 <sipa> because it's unreleased?
426 2013-10-01 18:47:53 <sipa> and may have known bugs
427 2013-10-01 18:48:19 <Luke-Jr> CodeShark: Qt's git code is on-topic in #qt-devel, nowhere else
428 2013-10-01 18:48:28 <CodeShark> lol
429 2013-10-01 18:48:37 <CodeShark> anyhow, I think I found a patch :)
430 2013-10-01 18:50:12 <CodeShark> and I can always checkout the release version in git
431 2013-10-01 18:51:14 <sipa> sure; have you tried whether the last release works?
432 2013-10-01 18:51:31 <CodeShark> I'm gonna try the patched stable branch first
433 2013-10-01 19:06:42 <warren> swulf--: we are all maintainer of *.
434 2013-10-01 19:09:40 <swulf--> warren:)
435 2013-10-01 19:10:11 <swulf--> warren: does this help at all? http://pastebin.com/xSXvfpjj
436 2013-10-01 19:11:09 <warren> swulf--: yes thanks
437 2013-10-01 20:20:45 <jgarzik> ACTION pushes out (pwalletMain != NULL) checks
438 2013-10-01 20:20:59 <jgarzik> part of no-wallet support, but separate from all shed-painting ;p
439 2013-10-01 20:26:45 <sipa> jgarzik: posthumous ACK
440 2013-10-01 20:27:42 <gmaxwell> poor sipa, we knew him well
441 2013-10-01 20:27:42 <warren> posthumous?
442 2013-10-01 20:27:51 <warren> undead
443 2013-10-01 20:28:10 <sipa> pusthumous as in the pullreq is already dead (well, assimilated)
444 2013-10-01 20:28:59 <jgarzik> shrunk
445 2013-10-01 20:29:04 <michagogo> cloud|(I hope it doesn't affect the gitian build process? :-P)
446 2013-10-01 20:29:10 <sipa> nah
447 2013-10-01 20:29:18 <jgarzik> PR was: pwalletmain NULL checks, cosmetic code move, add disable wallet
448 2013-10-01 20:29:29 <jgarzik> PR now: cosmetic code move, add disable wallet
449 2013-10-01 20:29:38 <jgarzik> (well, after I finish the rebase anyway)
450 2013-10-01 20:30:07 <michagogo> cloud|Anyone have comments on #3028?
451 2013-10-01 20:30:14 <jgarzik> just lopped off the big commit that was (a) not controversial yet (b) breaking all the time
452 2013-10-01 20:30:43 <jgarzik> (patch rebase was breaking, not the code itself)
453 2013-10-01 20:31:29 <sipa> ACTION breakz da code
454 2013-10-01 21:11:40 <warren> jgarzik: breaking all the time?
455 2013-10-01 21:14:38 <michagogo> cloud|warren: I think jgarzik means that because the changes were in many places throughout the code, rebasing with manual conflict resolution was needed often
456 2013-10-01 21:41:44 <CodeShark> is there a tool that does the reverse of nm? that's to say, you give it a library's exported symbol and it tells you which library contains the function
457 2013-10-01 21:48:43 <michagogo> Has anyone gitian-built win32 19e5ae7369?
458 2013-10-01 21:56:07 <CodeShark> I improvised such a tool: for file in <root>/lib/* ; do nm --defined-only -A $file; done | fgrep <symbol>
459 2013-10-01 22:04:13 <warren> hmm
460 2013-10-01 22:04:14 <warren> leveldb/libleveldb.a: could not read symbols: Bad value
461 2013-10-01 22:04:14 <warren> /usr/bin/ld: leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
462 2013-10-01 22:04:32 <sipa> warren: cd src/leveldb; make clea
463 2013-10-01 22:04:34 <sipa> make clean
464 2013-10-01 22:04:52 <warren> k
465 2013-10-01 22:05:09 <sipa> (just once)
466 2013-10-01 22:05:48 <warren> this is the second time I've done it once =)
467 2013-10-01 22:06:45 <michagogo> ACTION didn't know mtgox met the criteria for group registration
468 2013-10-01 22:32:47 <warren> CXX libbitcoinqt_a-transactiondescdialog.o
469 2013-10-01 22:32:47 <warren> hmm
470 2013-10-01 22:32:48 <warren> from walletmodel.h:7,
471 2013-10-01 22:32:48 <warren> In file included from ../../src/wallet.h:19:0,
472 2013-10-01 22:32:49 <warren> from sendcoinsdialog.cpp:4:
473 2013-10-01 22:32:52 <warren> ../../src/ui_interface.h:108:1: internal compiler error: Segmentation fault
474 2013-10-01 23:25:23 <jaychristopher> on json rpc for php, sendtoaddress fails but everything else works just fine.. it says "" fopen(http://...@127.0.0.1:8332/): failed to open stream: HTTP request failed! HTTP/1.1 500 Internal Server Error "" -- any idea what could cause this?
475 2013-10-01 23:27:39 <jaychristopher> it works just fine from linux command line on the same client
476 2013-10-01 23:28:06 <jaychristopher> wracking my brain for the past couple hours and finding nothing in google
477 2013-10-01 23:35:55 <sipa> jaychristopher: can you try a different rpc client?
478 2013-10-01 23:36:05 <sipa> (one which shows the actual error returned)
479 2013-10-01 23:40:33 <jaychristopher> Hmm I am not sure, I have only ever used one client for it. The odd thing is that it's a duplication of another server. I changed wallets, but could it be an issue in some other config item since it's the same bitcoind install?
480 2013-10-01 23:40:47 <jaychristopher> the original server works fine btw
481 2013-10-01 23:41:10 <jaychristopher> to change the wallet, i just deleted the old one and started the program
482 2013-10-01 23:41:22 <sipa> was the wallet on the first encrypted?
483 2013-10-01 23:41:32 <jaychristopher> no
484 2013-10-01 23:41:44 <sipa> can you just try using the command-line client once?
485 2013-10-01 23:41:52 <sipa> ./bitcoind sendtoaddress <whatever>
486 2013-10-01 23:41:55 <jaychristopher> it works on command linke
487 2013-10-01 23:41:55 <jaychristopher> line
488 2013-10-01 23:42:07 <sipa> uhh
489 2013-10-01 23:42:10 <jaychristopher> it has no issue there
490 2013-10-01 23:42:55 <jaychristopher> $txid = $bitcoin->sendtoaddress("1AD3PSd5cYGmr1nqXRW3rumCw3PY3pw9CT", "0.003");
491 2013-10-01 23:43:29 <jaychristopher> whereas $address = $bitcoin->getnewaddress(); written in the same line of code works
492 2013-10-01 23:44:32 <sipa> the amount has to be sent as a number, iirc
493 2013-10-01 23:44:35 <sipa> not as a string
494 2013-10-01 23:44:43 <jaychristopher> hmm that might be it!
495 2013-10-01 23:44:48 <jaychristopher> let me try
496 2013-10-01 23:45:25 <jaychristopher> boom
497 2013-10-01 23:45:25 <jaychristopher> it worked
498 2013-10-01 23:45:35 <jaychristopher> grr, i hate when its something simple.
499 2013-10-01 23:45:38 <jaychristopher> I spent hours on that
500 2013-10-01 23:45:50 <jaychristopher> thanks a ton, can i tip you some btc for the help? :)