1 2015-04-30 02:58:53 <cfields_> jgarzik: re univalue, what's the blocker there? I'd love to nuke a chunk of boost, anything in particular need to be done to make it ready?
  2 2015-04-30 02:59:35 <jgarzik> cfields_, fails numeric tests, after full-tree conversion
  3 2015-04-30 03:00:29 <cfields_> jgarzik: i'm happy to poke at those if you're not currently
  4 2015-04-30 03:01:20 <jgarzik> cfields_, Feel free: https://github.com/jgarzik/bitcoin/tree/2014_univ_conv
  5 2015-04-30 03:02:18 <cfields_> jgarzik: great! will do
  6 2015-04-30 03:02:24 <jgarzik> tnx
  7 2015-04-30 03:03:21 <cfields_> jgarzik: i won't play with it 'til tomorrow but i'm curious.. which tests fail exactly?
  8 2015-04-30 03:03:25 <jgarzik> cfields_, the conversions are pretty easy and mechanical for the most part.  if that axiom fails to be true, then univalue needs an update
  9 2015-04-30 03:03:29 <cfields_> if you remember off-hand
 10 2015-04-30 03:03:54 <jgarzik> cfields_, stuff like converting "0.00000001" properly to/from native C++ data types
 11 2015-04-30 03:04:06 <jgarzik> er, string <-> native
 12 2015-04-30 03:04:43 <cfields_> ok
 13 2015-04-30 03:18:02 <maraoz> is all the UTXO set maintained in memory?
 14 2015-04-30 05:07:45 <roasbeef> maraoz: no, it's all in leveldb
 15 2015-04-30 05:55:28 <sipa> roasbeef, maraoz: in leveldb on, cached in memory
 16 2015-04-30 05:56:03 <sipa> jgarzik: i don't like monoculture for dns seeds :)
 17 2015-04-30 05:58:41 <maraoz> good to know. is the full set in memory or are old outputs deleted to save RAM? (you could store the output identifier for all utxos but not the script, to save space?)
 18 2015-04-30 05:59:38 <sipa> maraoz: if you make the cache large enough, it will fit entirely
 19 2015-04-30 05:59:47 <sipa> but that would be several gb
 20 2015-04-30 06:03:35 <maraoz> sipa: thanks.
 21 2015-04-30 06:05:07 <sipa> and not saving the script wouldn't help... we need the script any time we need the rest anyway
 22 2015-04-30 06:32:40 <jonasschnelli> sipa: with monoculture you mean the fact that most/all dns seeds run the same software?
 23 2015-04-30 06:33:59 <sipa> yes, especially my own crappy one :)
 24 2015-04-30 06:36:22 <jonasschnelli> Hehe. I was thinking if I should tweak a djbdns (Bernstein) to work as seed. Use you implementation as data crawler and use djbdns as daemon/DNS
 25 2015-04-30 06:37:59 <sipa> jonasschnelli: feel free
 26 2015-04-30 06:38:22 <sipa> would be harder to make it return random subsets of data, i suppose
 27 2015-04-30 06:44:27 <wumpus> jgarzik: no opinion on that, it can't hurt to have fallbacks, if it's not too much trouble to keep it running
 28 2015-04-30 08:39:16 <jgarzik> sipa, RE dns seed monoculture - indeed.  My seed was always intended to be (a) ddos protected, (b) -not-using normal seed software, and (c) dynamically updated.
 29 2015-04-30 08:39:23 <jgarzik> achieved (a) and (b) but not (c)
 30 2015-04-30 08:49:33 <kinlo> how did you achieve a ?
 31 2015-04-30 09:36:31 <jgarzik> kinlo, used a ddos-protected dns service, dnspark ;p
 32 2015-04-30 12:27:50 <jonasschnelli> i can't find the reason why travis fails here: https://travis-ci.org/bitcoin/bitcoin/jobs/60529741
 33 2015-04-30 12:28:13 <jonasschnelli> It ends with "No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself."
 34 2015-04-30 12:34:51 <harding> jonasschnelli: it looks like the problem is the Java exception just above that line.  That looks like it caused the comparison tool to stop working without returning failure, so Travis killed the build after 10 minutes of non-output.
 35 2015-04-30 12:36:00 <jonasschnelli> hmm.. right. Thanks harding. Will try to run the java comparison tool locally.
 36 2015-04-30 13:40:52 <jonasschnelli> sdaftuar: there?
 37 2015-04-30 13:41:05 <sdaftuar> yes, here
 38 2015-04-30 13:41:23 <jonasschnelli> --tracerpc runs fine... i think i'm facing a issue with "asyncore.loop(0.1, True)"
 39 2015-04-30 13:41:33 <jonasschnelli> looks after http://bugs.python.org/issue10878
 40 2015-04-30 13:41:44 <jonasschnelli> (which is not rated as a bug)
 41 2015-04-30 13:41:59 <sdaftuar> which version of python do you run?
 42 2015-04-30 13:42:29 <jonasschnelli> Python 2.7.8
 43 2015-04-30 13:43:09 <sdaftuar> i want to try to reproduce locally.  you're talking about the issue with maxblocksinflight.py right?
 44 2015-04-30 13:43:20 <sdaftuar> i think invalidblockrequest.py was failing differently for you, with an actual test error
 45 2015-04-30 13:44:08 <jonasschnelli> invalidblockrequest.py fails with the asyncore.loop issue
 46 2015-04-30 13:45:02 <jonasschnelli> maxblocksinflight.py also
 47 2015-04-30 13:45:02 <sdaftuar> oh, that's odd -- your paste in the pull for 5981 showed a different failure point.  perhaps there are two issues?
 48 2015-04-30 13:45:24 <sdaftuar> "Assertion failed: Test failed at test 3"
 49 2015-04-30 13:45:51 <jonasschnelli> Right. This was when i running over rpc-tests.sh... let me try again
 50 2015-04-30 13:47:17 <jonasschnelli> ./qa/pull-tester/rpc-tests.sh invalidblockrequest gives now also the asyncore.loop issue...
 51 2015-04-30 13:47:29 <jonasschnelli> now running the all tests and see if it's the same
 52 2015-04-30 13:51:56 <jonasschnelli> strange: now both tests end with "Bad file descriptor" from asyncore.py
 53 2015-04-30 13:52:46 <sdaftuar> but no other issues?  looks like i just need to make my usage of asyncore more compatible across python versions...
 54 2015-04-30 13:53:53 <jonasschnelli> maybe: https://github.com/fail2ban/fail2ban/pull/918
 55 2015-04-30 13:54:14 <jonasschnelli> maybe it's a python2.7 issue
 56 2015-04-30 13:54:34 <sdaftuar> i'm running python 2.7.6 myself
 57 2015-04-30 13:54:44 <sdaftuar> and haven't run into this
 58 2015-04-30 13:55:06 <jgarzik> RE Bad file descriptor - sounds like a constrained shell running out of fd's
 59 2015-04-30 13:55:16 <jgarzik> too many sockets/files open
 60 2015-04-30 13:55:21 <jonasschnelli> changing to 'asyncore.loop(use_poll=True)' fixes the issue
 61 2015-04-30 13:55:51 <jonasschnelli> jgarzik: indeed. Looks after some missing close()'es
 62 2015-04-30 13:56:36 <sdaftuar> jonasschnelli: so taking out the timeout fixes it?  that seems very odd...
 63 2015-04-30 13:56:53 <jonasschnelli> sdaftuar: right.
 64 2015-04-30 13:57:23 <jonasschnelli> now trying with python 2.7.9
 65 2015-04-30 13:57:27 <jonasschnelli> same issue.
 66 2015-04-30 13:59:57 <jonasschnelli> sdaftuar: what's the potential drawback of removing the timeout and use polling?
 67 2015-04-30 14:00:28 <sdaftuar> this code does use polling -- asyncore(0.1, True) sets the timeout to 0.1, and use_poll to True
 68 2015-04-30 14:00:45 <jonasschnelli> ah. Right. I changed it to false for testing. :)
 69 2015-04-30 14:00:46 <sdaftuar> i think the issue is some kind of timing thing, maybe 0.1 is triggering that behavior issue in asyncore that you found
 70 2015-04-30 14:01:02 <sdaftuar> (but it makes the tests run faster -- the default is 30(!) seconds)
 71 2015-04-30 14:02:06 <sdaftuar> oh
 72 2015-04-30 14:02:08 <jonasschnelli> sdaftuar: i think 0.1 as timeout is to short.
 73 2015-04-30 14:02:19 <jonasschnelli> if i use 1 sec test running fine
 74 2015-04-30 14:02:36 <jonasschnelli> probably a timeout/close issue
 75 2015-04-30 14:02:39 <sdaftuar> looks like it is the select code that is triggering for some reason.  the error is in select.select, which is not supposed to be called
 76 2015-04-30 14:03:11 <sdaftuar> does asyncore(timeout=0.1, use_poll=True) fail?
 77 2015-04-30 14:04:11 <jonasschnelli> asyncore.loop(0.1, use_poll=True) fails   |   asyncore.loop(1, True) succeed
 78 2015-04-30 14:04:27 <jonasschnelli> i think 0.1 as timeout is not ideal.
 79 2015-04-30 14:05:08 <sdaftuar> you may be right that 0.1 is too short, but i am puzzled why there is an error at select.select if use_poll is true... it looks like the wrong function in asyncore.py is being called
 80 2015-04-30 14:08:04 <sdaftuar> ah
 81 2015-04-30 14:08:08 <sdaftuar> you're on a mac right?
 82 2015-04-30 14:08:25 <jonasschnelli> right.
 83 2015-04-30 14:08:58 <sdaftuar> i think hasattr(select, 'poll') returns false maybe on your platform?
 84 2015-04-30 14:09:03 <sdaftuar> so it's always using select?
 85 2015-04-30 14:10:08 <jonasschnelli> hasattr(select, 'poll')==false on my system...
 86 2015-04-30 14:10:31 <sdaftuar> ok that explains my confusion then.  i'll fix either my raising the timeout or some other suitable workaround.  thanks for debugging!
 87 2015-04-30 14:10:38 <sdaftuar> by*
 88 2015-04-30 14:11:06 <jonasschnelli> no worries. Thanks for figuring out.
 89 2015-04-30 14:11:43 <jonasschnelli> i also try to shuffel some files. The qa/rpc-test folder is unorganized
 90 2015-04-30 14:11:58 <sdaftuar> yeah i was wondering if i should maybe move all the p2p tests into their own directory?
 91 2015-04-30 14:12:08 <sdaftuar> not obvious to me what organization makes sense
 92 2015-04-30 14:12:26 <jonasschnelli> i would propose that all non-test classes gets moved into a util/ dir or something like this
 93 2015-04-30 14:12:43 <sdaftuar> that seems reasonable...
 94 2015-04-30 14:12:44 <jonasschnelli> maybe use a prefix for tests p2p_<testname>
 95 2015-04-30 14:13:03 <wumpus> I prefer keeping the tests in one directory
 96 2015-04-30 14:13:18 <jonasschnelli> right. But the util classes should go into a subdir
 97 2015-04-30 14:13:27 <jonasschnelli> so you can distinct between tests and helper classes
 98 2015-04-30 14:13:46 <wumpus> shallow directory structures are generally better, there's not *that* many, prefixing is fine with me though
 99 2015-04-30 14:14:02 <wumpus> jonasschnelli: you can distinguish based on the +x bit in git :-)
100 2015-04-30 14:14:16 <wumpus> but sure moving utility classes to a directory makes sense
101 2015-04-30 14:14:47 <jonasschnelli> Hah. Right. Yes.
102 2015-04-30 14:15:27 <jonasschnelli> What about extening the pull-tester/rpc-tests.sh script so it can run in a "extended" mode where all more exhausting tests get done?
103 2015-04-30 14:15:45 <jonasschnelli> currently it's a bit odd to run the time-consuming tests manually
104 2015-04-30 14:15:51 <jonasschnelli> (one by one)
105 2015-04-30 14:15:54 <wumpus> to a "package" in python-speak
106 2015-04-30 14:16:15 <jonasschnelli> ?
107 2015-04-30 14:16:42 <wumpus> that continued on <wumpus> but sure moving utility classes to a directory makes sense
108 2015-04-30 14:17:00 <jonasschnelli> ah. Right .... __a_python_package__ :)
109 2015-04-30 14:17:10 <wumpus> yes
110 2015-04-30 14:17:51 <jonasschnelli> Yes. I think having the helper/utility classed within a util/ package (subdir) makes sense.
111 2015-04-30 14:17:53 <wumpus> a run-all-tests mode makes sense, though it is very useful to run individual tests
112 2015-04-30 14:18:12 <wumpus> (so that functionality should not go away)
113 2015-04-30 14:18:27 <jonasschnelli> ./qa/pull-tester/run-tests.sh <testname> still can run a single test
114 2015-04-30 14:19:03 <wumpus> right
115 2015-04-30 14:19:22 <jonasschnelli> maybe it would somehow be possible to run the comparison tests in travis against the master...
116 2015-04-30 14:19:39 <jonasschnelli> but would probably mean compile twice
117 2015-04-30 14:19:49 <wumpus> that's what it does, right?
118 2015-04-30 14:19:51 <sdaftuar> you mean against the latest release or something?
119 2015-04-30 14:20:20 <jonasschnelli> for PR's it could make sense to run against master? For master it would make sense to run against last release
120 2015-04-30 14:20:38 <wumpus> travis runs tests against master, and every branch, as well as every PR
121 2015-04-30 14:20:40 <jonasschnelli> wumpus: the comparison tool only triggers when you use --refbinary as arg to a test IMO
122 2015-04-30 14:20:55 <sdaftuar> oh right.  yeah i think that would be awesome someday but not sure the existing tests justify making that feasible...
123 2015-04-30 14:21:45 <jonasschnelli> (sorry, the term comparison tool could be confusing. I'm speaking NOT from the java tool. I mean the new python comparison possibilities)
124 2015-04-30 14:22:45 <wumpus> ok, yes that's confusing terminology
125 2015-04-30 14:24:26 <wumpus> I think travis could cache the bitcoind from the master build, and use the in testing a PR, but I'm not sure
126 2015-04-30 14:24:43 <cfields_> yes
127 2015-04-30 14:25:13 <wumpus> are there any tests where checking the versions together is better than checking them individually?
128 2015-04-30 14:27:05 <jonasschnelli> wumpus: script_test.py? Compare test output from PR agains master? But not sure if this would not already get detected in unit tests?
129 2015-04-30 14:27:11 <cfields_> if desired, instead of caching the current master, we could cache a 'reference' master, snapshotted prior to scary merges
130 2015-04-30 14:27:56 <wumpus> jonasschnelli: so, what you'd really want is to cache *test output* from master, to compare
131 2015-04-30 14:28:32 <jonasschnelli> wumpus: would also be possible. But we just merge a framework who can compare outputs while running and testing binaries.
132 2015-04-30 14:28:42 <wumpus> (at least, that reduces runtime compared to launching a master branch bitcoind every time)
133 2015-04-30 14:29:02 <wumpus> cfields_: if it's a manual action, we're bound to forget it :)
134 2015-04-30 14:30:05 <wumpus> jonasschnelli: I'm not convinced that is better, though. If the output is deterministic, you'll get the same output every time until something is merged that changes the respective code, which could also be detected by hardcoding what the output should be.
135 2015-04-30 14:30:45 <sdaftuar> tests like script_test.py launch 2 bitcoind's already; it's just a question of which binaries to launch.  (but script_test.py itself isn't such a useful test, it's just a proof of concept to show what can be done.)
136 2015-04-30 14:30:49 <wumpus> (a in the unit tests - we don't compare unit test output to a previous version, we just compare it to what it should be - but maybe I'm missing something)
137 2015-04-30 14:30:53 <jonasschnelli> Agreed. A static output representation from a release version (or the master) is probably better.
138 2015-04-30 14:31:02 <jonasschnelli> But how would you cache this information?
139 2015-04-30 14:31:14 <wumpus> put it in git?
140 2015-04-30 14:31:19 <jonasschnelli> manually?
141 2015-04-30 14:31:27 <wumpus> at least if it's only supposed to change rarely that's fine
142 2015-04-30 14:32:09 <kanzure> for comparing logged test output from the previous release to the current master branch's test output?
143 2015-04-30 14:32:15 <wumpus> sdaftuar: if the test really needs the interactivity, sure, then it makes sense, that's why I asked above
144 2015-04-30 14:33:24 <wumpus> (e.g. if it tests how an old version and a new version communicate)
145 2015-04-30 14:34:37 <jonasschnelli> btw: how do i run the java comparison tool locally? make check-local always response with "Error: Unable to access jarfile ye"?
146 2015-04-30 14:35:06 <sdaftuar> right -- it's somewhat unfortunate than non-critical changes to the p2p protocal break the java comparison tool
147 2015-04-30 14:35:14 <sdaftuar> well, potentially break
148 2015-04-30 14:36:52 <wumpus> well, that's only unfortunate because BlueMatt is the only one that knows how to update it :) in principle, having to adapt a test when you change something is not problematic, it just means that the test correctly covers current behavior
149 2015-04-30 14:40:50 <sdaftuar> yes, agreed
150 2015-04-30 14:51:38 <NyeFe> Any security experts here?
151 2015-04-30 14:54:44 <sturles> NyeFe: Your question is very unspecific and probably in the wrong channel.  Any expert in security, e.g. burglar alarms or prison door systems, will qualify, but none of them are going to answer because they have no idea what kind of expertise you are looking for.
152 2015-04-30 14:54:50 <sipa> sturles: too late
153 2015-04-30 14:55:43 <Hasimir> sturles, and also may not care if someone can't pick their channels correctly  ;)
154 2015-04-30 14:59:53 <cfields_> jgarzik: ping
155 2015-04-30 15:01:08 <cfields_> jgarzik: from a very cursory look at the test problems in univalue, looks like we need to add a Real vtype. Thoughts?
156 2015-04-30 15:01:46 <sipa> cfields_: yuck
157 2015-04-30 15:02:06 <sipa> that was the nice part about univalue... that it kept number representations as string
158 2015-04-30 15:02:15 <sipa> (or maybe i don't know what i'm talking about)
159 2015-04-30 15:02:40 <cfields_> sipa: yes, still kept as string, but bookkeeping to note that they were originally doubles
160 2015-04-30 15:02:56 <sipa> ah
161 2015-04-30 15:04:35 <cfields_> backing up, i'm not sure what values are ok to break. in json output, i'm not sure if the world would end if "0.00000000" became "0.0". so i suppose that's a better initial question
162 2015-04-30 15:05:11 <cfields_> my usual approach would be to make sure that all output matches 1:1 before/after the change
163 2015-04-30 15:07:36 <sipa> cfields_: well i think part of the perceived benefit of univalue is exactly this (slight) semantic change
164 2015-04-30 15:08:01 <sipa> making it first imitate old behaviour to afterwards switch to its intended improved version may be silly
165 2015-04-30 15:09:02 <cfields_> sipa: ok thanks, that answers my question. It would take some weird hacks to get the old behavior. So my next step is definitely to research  the reasonable changes
166 2015-04-30 15:09:05 <cfields_> thanks a bunch
167 2015-04-30 15:24:37 <dhill> is testnet-seed.alexykot.me dead?
168 2015-04-30 18:43:59 <BlueMatt> wumpus: huh? no, you just git clone bitcoinj and mvn build or something like that
169 2015-04-30 18:44:04 <BlueMatt> wumpus: its really easy to update, actually
170 2015-04-30 19:32:21 <notplato> In following Nitrogenics' post at https://bitcointalk.org/index.php?topic=149479.0 for compiling for Windows, he points out that when bitcoin is configured without --disable-tests, the hexdump he recommends (https://github.com/wahern/hexdump) will require a change to src/Makefile.test.include (in v 0.10).  My goal is a patch that accommodates this, but perhaps it's unnecessary if we use a hexdump program that works like the one
171 2015-04-30 19:32:25 <notplato> was written.
172 2015-04-30 19:36:39 <jonasschnelli> notplato have you tried to cosscompile for window on linux?
173 2015-04-30 19:37:04 <jonasschnelli> the "official" binaries are cross compiled on linux
174 2015-04-30 19:37:28 <cfields_> notplato: 'od' could be used instead, iirc that'd be easier on *bsd as well
175 2015-04-30 19:37:41 <cfields_> do you have that in your environment?
176 2015-04-30 19:38:22 <sipa> cfields_: heh, i knew hd; never heard about od
177 2015-04-30 19:39:02 <cfields_> sipa: od ships with coreutils iirc, so it's pretty much guaranteed to be in a unixy environment
178 2015-04-30 19:39:12 <notplato> I have tried several things over the years, and Nitrogenics' instructions were the only ones that worked.  They worked for 0.9.4 and for the master as of some time yesterday afternoon.  I am only interested in helping others using his thread to compile bitcoin to be able to use the unit tests on Windows.  If it means he needs to specify a different hexdump, that's fine.
179 2015-04-30 19:39:25 <cfields_> hd is a symlink to hexdump :)
180 2015-04-30 19:39:54 <cfields_> notplato: can you see if 'od' is present in your mingw (or whatever) environment ?
181 2015-04-30 19:40:08 <sipa> cfields_: hmm, /usr/bin/hexdump: 27080 bytes, /usr/bin/od: 64224 bytes
182 2015-04-30 19:40:28 <sipa> i did not know that octal decoding require 37k of machine code!
183 2015-04-30 19:41:10 <cfields_> you'd think it'd be ~13.5k :p
184 2015-04-30 19:41:43 <sipa> indeed!
185 2015-04-30 19:43:33 <moa> better rewrite then
186 2015-04-30 19:44:11 <cfields_> jgarzik: ugh, after banging my head against the wall for ~.5 day, i think i found the major problem with univalue
187 2015-04-30 19:44:24 <cfields_> ping me when you get a chance
188 2015-04-30 19:50:51 <notplato> cfields_: od is there.  I'll see if using it instead of the hexdump he recommended works with the original src/Makefile.test.include code.
189 2015-04-30 19:51:53 <sipa> why do you need a hexdump?
190 2015-04-30 19:51:57 <cfields_> notplato: it won't work as-is. I can throw together a quick patch for you
191 2015-04-30 19:52:16 <cfields_> sipa: it's used to generate c++ arrays from json
192 2015-04-30 19:56:26 <notplato> sipa: hexdump is used by the tests - the goal is a Windows compile from Nitro's post (see above) that doens't require any changes to the current code.
193 2015-04-30 19:56:52 <notplato> oops ... a compile without --disable-tests, I mean.
194 2015-04-30 19:57:02 <sipa> ic
195 2015-04-30 19:58:43 <notplato> cfields_: I'm kind of using this as a learning project, so if you just point me in the right direction (might require a lot of pointing), then maybe I can make the patch...
196 2015-04-30 19:59:32 <cfields_> notplato: ok. well it's a quick fix to get it working. but for something mergeable, we'll want to keep compat with the old 'hexdump' tool as well.
197 2015-04-30 19:59:55 <cfields_> for the quick fix, it should just be a matter of switching to use the correct od flags
198 2015-04-30 20:01:47 <notplato> I'm assuming there is no windows program that acts exactly like the Linux hexdump that Makefile.test.include uses, so yeah, the patch would check for hexdump and, if missing, check for od, and if od is there, then it would set up for od flags.  I guess that would go in Makefile.test.include, eh?
199 2015-04-30 20:02:17 <cfields_> that logic goes into configure.ac
200 2015-04-30 20:02:51 <cfields_> you'll just substitute in the correct (new) variables in Makefile.test.include
201 2015-04-30 20:09:05 <cfields_> notplato: note that i haven't verified 100% that od can easily produce the same output, just a guess based on a quick google
202 2015-04-30 20:17:04 <notplato> cfields_: I think od might work.  I am compiling now.  Is "make check" the fastest way to see if it's sufficient?
203 2015-04-30 20:18:09 <cfields_> notplato: yes, but that won't regenerate them if you end up with busted output while testing
204 2015-04-30 20:18:57 <cfields_> make bitcoin_test_clean && make check
205 2015-04-30 20:19:56 <notplato> cfields_: Ok, I see the default output of hexdump is different from od, so my project is to figure out how to translate (if possible) using the flags and then set that up in configure.ac.  Thanks for your help!
206 2015-04-30 20:20:11 <cfields_> np, good luck!
207 2015-04-30 20:22:26 <sipa> less-offtopic-than-it-seems english question: i need some nice prefix/term to use in code to denote "multiple", however, i can't use "multi" (that would be ambiguous in my particular case)
208 2015-04-30 20:22:36 <sipa> specifically: it's about doing multiple multiplications at once :)
209 2015-04-30 20:24:11 <jonasschnelli> i think there is something wrong with travis tests [no-wallet]
210 2015-04-30 20:24:20 <jonasschnelli> Luke-Jr also ran into: https://travis-ci.org/bitcoin/bitcoin/jobs/60727651
211 2015-04-30 20:24:53 <jonasschnelli> i had the same issue recently and solved it by re-pushing re-travis[ing]
212 2015-04-30 20:25:40 <jonasschnelli> It looks like that it has something to do with the java comparison tool
213 2015-04-30 20:25:46 <jonasschnelli> L2410: Exception in thread "main" java.lang.NullPointerException
214 2015-04-30 20:26:12 <Luke-Jr> is Travis slow for everyone or just me? <.<
215 2015-04-30 20:26:35 <jonasschnelli> was it ever fast?
216 2015-04-30 20:26:46 <cfields_> i'm almost ready to switch us over to their new quicker infrastructure, just holding on a few stupid things
217 2015-04-30 20:27:16 <Luke-Jr> cfields_: the one their site is saying they're not deploying? <.<
218 2015-04-30 20:27:43 <cfields_> Luke-Jr: nah, that was just their new env rollout. seems those go south about 50% of the time :\
219 2015-04-30 20:28:02 <Luke-Jr> wasn't there some way to tell Travis to redo a build?
220 2015-04-30 20:28:19 <cfields_> only an admin can iirc
221 2015-04-30 20:28:23 <Luke-Jr> oh, lame
222 2015-04-30 20:28:26 <cfields_> otherwise, just force-push
223 2015-04-30 20:28:34 <Luke-Jr> do I have to? :p
224 2015-04-30 20:28:43 <Luke-Jr> I mean, it's just strings..
225 2015-04-30 20:28:54 <cfields_> oh, heh
226 2015-04-30 20:29:09 <Luke-Jr> meh, fine
227 2015-04-30 20:29:12 <Luke-Jr> easy enough
228 2015-04-30 20:29:40 <cfields_> jonasschnelli: have there been any changes lately that could possibly break that? i suspect it's probably just a mem issue or similar
229 2015-04-30 20:30:02 <jonasschnelli> right. Looks after some serious mem/cpu issue
230 2015-04-30 20:30:35 <jonasschnelli> lol #6087
231 2015-04-30 20:31:07 <notplato> sipa: How about plexi?
232 2015-04-30 20:32:09 <jonasschnelli> cfields_: since hours im trying to solve https://github.com/bitcoin/bitcoin/issues/6078
233 2015-04-30 20:32:10 <cfields_> jonasschnelli: lol. I'd like that feature too.
234 2015-04-30 20:32:55 <sipa> notplato: plexi?
235 2015-04-30 20:33:07 <jonasschnelli> cfields_: it's a local/WCHAR/char/utf16 boost filesystem issue
236 2015-04-30 20:33:14 <jonasschnelli> very strange
237 2015-04-30 20:33:22 <cfields_> jonasschnelli: heh, sounds like you've been deep down the rabbit-hole
238 2015-04-30 20:34:08 <sipa> jonasschnelli: i've been working for ages on 6087, but it doesn't work!
239 2015-04-30 20:34:20 <sipa> (seriously, what is that guy trying to do?)
240 2015-04-30 20:35:02 <jonasschnelli> lol
241 2015-04-30 20:35:08 <cfields_> jonasschnelli: i hope that it's not also related to low-level libc stuff
242 2015-04-30 20:35:37 <jonasschnelli> hmm... i fear it could be this or boost? did we recently changed version? between 0.10 and 0.10.1?
243 2015-04-30 20:35:56 <jonasschnelli> was there a libc change between 0.10 and 0.10.1?
244 2015-04-30 20:35:57 <jgarzik> cfields_, I'm online
245 2015-04-30 20:36:34 <cfields_> remember that we link everything static for win32, so if locale issues are usually affected (no clue if they are) by the runtime env, we wouldn't be seeing that for our builds
246 2015-04-30 20:37:14 <cfields_> jgarzik: i'm still working through the issues, but i have the list cut down a good bit
247 2015-04-30 20:38:08 <cfields_> jgarzik: one of the nasty issues was that in your wrapper, you typedef'd Array -> UniValue. However, that doesn't set the VType to array, so all kinds of crazy things happen
248 2015-04-30 20:41:08 <cfields_> i'll push up a branch once all the tests pass. Would you like me to try to rebase to master as well?
249 2015-04-30 20:51:24 <go1111111> BlueMatt: should the Bitcoin PPA be updated to 0.10.1?
250 2015-04-30 20:52:05 <sipa> ;;later tell BlueMatt < go1111111> BlueMatt: should the Bitcoin PPA be updated to 0.10.1?
251 2015-04-30 20:52:06 <gribble> The operation succeeded.
252 2015-04-30 20:52:26 <BlueMatt> go1111111: yes
253 2015-04-30 20:52:27 <BlueMatt> it should be
254 2015-04-30 20:52:31 <jonasschnelli> BlueMatt: frt, i'm happy if you take over
255 2015-04-30 20:52:45 <BlueMatt> jonasschnelli: ok, I'll just open a new pull with that branch
256 2015-04-30 20:52:49 <jonasschnelli> BlueMatt: i think you are more into frt now than i am.
257 2015-04-30 20:53:10 <BlueMatt> yes, its a dependency for another project
258 2015-04-30 20:53:14 <jonasschnelli> yes. I'll close mine then.
259 2015-04-30 20:54:29 <jonasschnelli> BlueMatt: it looks like that you have rewritten the whole thing.. :)
260 2015-04-30 20:54:35 <BlueMatt> kk, its #6088 now
261 2015-04-30 20:54:52 <BlueMatt> jonasschnelli: not really, big chunks, yes, though all the test cases are pretty much copied verbatim
262 2015-04-30 21:01:45 <kanzure> BlueMatt: thanks for the shout out
263 2015-04-30 21:02:11 <BlueMatt> I stole code, might as well attribute it :)
264 2015-04-30 21:12:19 <notplato> sipa: I came up with plexi as "multiple multi" because of the "plex" in "googolplex".
265 2015-04-30 21:13:03 <notplato> You could also do exp- although "exponent" is probably not what you mean.
266 2015-04-30 21:13:06 <michagogo> uh, I don't know that that works
267 2015-04-30 21:13:47 <michagogo> You could do what PHP does and use Hebrew :P
268 2015-04-30 21:13:58 <michagogo> mispar-hachpalot
269 2015-04-30 21:14:46 <michagogo> (context: http://en.wikipedia.org/wiki/Scope_resolution_operator#PHP)
270 2015-04-30 21:50:52 <StephenM347> There's nothing like walletnotify for any transaction, is there? i.e. some sort of a -txnotify
271 2015-04-30 22:00:27 <jgarzik> StephenM347, the ZeroMQ patch
272 2015-04-30 22:01:16 <jgarzik> cfields_, some of that should simply be avoided, if a perfect solution doesn't present itself
273 2015-04-30 22:01:29 <jgarzik> cfields_, don't want to push too much into type overloading
274 2015-04-30 22:01:31 <ajweiss> i just rebased it to work with master
275 2015-04-30 22:01:45 <ajweiss> is anybody working on it or is it ripe for picking up?
276 2015-04-30 22:01:56 <ajweiss> (zmq patch, that is)
277 2015-04-30 22:02:12 <jgarzik> ajweiss, yes.  There is a current PR
278 2015-04-30 22:02:22 <jgarzik> ajweiss, I updated jcorgan's older PR
279 2015-04-30 22:02:33 <ajweiss> yeah but now that's old : )
280 2015-04-30 22:05:02 <ajweiss> it needed some tweaks to run with current master.  i also noticed that it had formatting/whitespace that was inconsistent with the rest of teh project...
281 2015-04-30 22:05:54 <ajweiss> i was contemplating cleaning it up a bit more, adding some tests, and maybe adding a json payload mode
282 2015-04-30 22:31:42 <cfields_> jgarzik: i came up with a quick/dirty inheritance model that works enough to illustrate the problem. By no means a solution, but a starting point
283 2015-04-30 22:32:11 <phantomcircuit> jgarzik, zeromq is really not written for an adversarial environment
284 2015-04-30 22:32:20 <phantomcircuit> i assume that patch is connect() not bind() ?
285 2015-04-30 22:32:49 <Luke-Jr> --disable-zeromq also enables it in the current PR :p
286 2015-04-30 22:32:58 <jgarzik> phantomcircuit, nod
287 2015-04-30 22:33:16 <phantomcircuit> Luke-Jr, heh
288 2015-04-30 22:33:38 <phantomcircuit> personally i think triggering something to poll for changes is probably superior to pushing the change
289 2015-04-30 22:34:13 <phantomcircuit> it's relatively easy to get the latter wrong
290 2015-04-30 23:07:44 <chickenledel_> hello?
291 2015-04-30 23:08:07 <chickenledel_> anyone able to help with bitcoinj implementation?
292 2015-04-30 23:11:15 <chickenledel_> looking for help with bitcoinj and making a blockchain parser
293 2015-04-30 23:18:52 <notplato> I am trying to understand configure.ac.  Autoconf processes `configure.ac' with the M4 macro processor, right?  So I looked at https://www.gnu.org/software/m4/manual/m4.html to find out if I can use if ... else, but "if" isn't even in there.  What am I missing?
294 2015-04-30 23:36:08 <cfields_> notplato: just look around the file and copy a construct from somewhere else