2900+ entries in 0.383s
phf: williamdunne: not builtin, but here's a generic object printer,
http://paste.lisp.org/display/153363. if you have an instance of a class, you'll get #<FOO (A . 1) (B . "
test") C #x123123> (where C is unbound)
mod6: awe shoot, realized i gotta wait until later tonight for ubuntu 14.04
test. my bad.
shinohai: Try the new
test script. So easy a redditard *might* could build it.
mod6: once we have that, and a new patch from trinque, i can complete my script and have a rotor that builds these
test bundles with x86-64
phf: come to think of it i should probably
test that it fails without the flag but with bullet present. i'll spin that up now..
assbot: Logged on 07-08-2015 18:44:44; gernika: General question - is there value in continuing to
test stator, and future versions of it, on OpenBSD? Or should I abandon that and just
test on Gentoo from now on?
mod6: <+ben_vulpes> twould please him no end to see
test reports coming in from that platform << certainly let me know how it goes. yeah, might have issues with rotor on there. I'm still sync'ing my obsd bitcoind build (patched up through -verifyall).
ben_vulpes: twould please him no end to see
test reports coming in from that platform
gernika: General question - is there value in continuing to
test stator, and future versions of it, on OpenBSD? Or should I abandon that and just
test on Gentoo from now on?
☟︎ ben_vulpes: i'll have to cook up a
test case or so
pete_dushenski: it's hard enough to get people to
test therealbitcoin, i'm not holding my breath that anyone will rise to the challenge here
assbot: Logged on 05-08-2015 04:12:14; ben_vulpes: from experience i know that the more difficult it is to
test the software, the less likely anyone is to actually do so.
ben_vulpes: from experience i know that the more difficult it is to
test the software, the less likely anyone is to actually do so.
☟︎ ben_vulpes: "i don't know, let's
test it during code review"
BingoBoingo:
Test was not a planned
test. Popped hard drive with weirdOS in laptop and it fucked BIOS clock.
assbot: Logged on 02-08-2015 00:40:37; mircea_popescu: very few people still use 32bit, might be interesting
test case.
mircea_popescu: very few people still use 32bit, might be interesting
test case.
☟︎ BingoBoingo: Oh
test node with megalocks is now at 367863
BingoBoingo: <mircea_popescu> BingoBoingo not clear yet. << Well just a few minutes until my pure blockchain finishes copying to safety so I can
test something
mircea_popescu: tx passed the
test, and is now a tx. should get something for this.
trinque: punkman: yeah, I was thinking my 4u could be a build/
test box
mod6: the idea was; put out this
test bundle and see if we're on the right track and if anyone hits any problems with any of the patches.
mod6: well, i've been pushin pretty hard as far as work load -- what scares me is taking on buildroot and trying to bundle/
test the entire thing.
assbot: Logged on 30-07-2015 00:37:59; trinque: mod6: maybe you guys need a build/
test crew.
trinque: mod6: maybe you guys need a build/
test crew.
☟︎ mircea_popescu: a monopoly is a monopoly. it is not better somehow magically for "being justified". it takes no justification whatever past the very simple
test of its existence.
williamdunne: pete_dushenski: No error my side, did you post a
test?
pete_dushenski: williamdunne let me know when you're ready for another
test.
williamdunne: pete_dushenski feel free to
test, but he should work with multiple posts in quick succession now
ascii_field: i wasn't going to post this quite yet, had been sitting on it for a bit, because no time lately to
test much
shinohai: I'll help
test as always mod6, in between this pogo crash-course I am doing
mod6: my plan for tonight is to put out the bitcoin-v0_5_4-TEST1.tar.gz bundle to the ML tonight if possible. This is a pre-patched tarball of all of ascii's patches (and one of my fixes) up through verifyall. Should work only on x86-64 deb6/ubuntu 14.04/gentoo nomultilib glibc - if anyone wants to help
test.
mod6: ascii_field: im doing this because ive put stator.sh into the
test bundle, and I wanna ensure that it works on gentoo/deb6/unbuntu before i notify people on the ML.
trinque: I bothered to take the first myers-briggs
test on your penultimate post
solrodar: but then he wasn't able/willing to
test it himself
mod6: whole thing takes < 30 minutes to dl, build, &
test.
mod6: Have a bunch of automated tests (cucumber) that now builds the new
test bundle, verify, check binary,
test -connect, dumpblock, eatblock. ima post a log here in just a bit.
trinque: eh I'll still send it through as a
test case then
mod6: i still need to update the old how-to-patch guide etc. im actually pretty much complete on that... as soon as we give the green light on the
test bundle i'll post my changes for that too.
mod6: and perhaps as soon as we send up the patched
test bundle, someone could try compiling the static R.I. on there.
mod6: if anyone else wants to
test the gentoo guide, gimme a holler. would like to get it verified before the end of the month.
mod6: wanna help
test gentoo guide this weekend instead?
assbot: Logged on 24-07-2015 01:51:42; mod6: asciilifeform: so we'd like to have dumpblock go into the release if possible -- both dump and eat need a bunch of testing and I've got some automated
test scenarios working around dumpblock already. but I ran into the seg fault lastnight with too few parameters, i think i fixed it with this simple change:
http://dpaste.com/2SRW78V.txt mod6: asciilifeform: so we'd like to have dumpblock go into the release if possible -- both dump and eat need a bunch of testing and I've got some automated
test scenarios working around dumpblock already. but I ran into the seg fault lastnight with too few parameters, i think i fixed it with this simple change:
http://dpaste.com/2SRW78V.txt ☟︎ mircea_popescu: "Fuzzer results: Though Rosario's fuzzers found numerous crashing
test cases, like most fuzzer outputs few of them appeared exploitable. One of the first crashes that looked exploitable was an IE10 memory corruption that was patched within a week of its discovery. Soon after, Rosario found a Firefox crash that looked exploitable but only appeared to occur under memory pressure. Despite months of analysis, Hacking Team
mod6: ok i think i fixed the dumpblock param issue, but it'll hvae to wait until tomorrow or when i have a bit more time to
test mod6: really, the main question at this point should be: do you wanna run the v0.5.3.1-RELEASE or are you looking to help
test with the latest (pre)v0.5.4 patches?
mod6: this one shows that we can connect with -connect & -myip, sleep for a bit, check connection count, shutdown bitcoind, then sleep a bit more (in case we restart bitcoind on the next
test, we wanna allow some time for the DB to sync etc.)
solrodar: as well as generating the call graph, I was able to actually build bitcoind against that version, though I didn't
test it
mod6: if you're looking for something to keep you busy for an evening, you can
test out the gentoo x86-64 nomultilib guide
mod6: well, thanks for putting in the effort to
test this stuff, we appreciate it.
mod6: gonna have to
test prune by hand, and then
test and ensure that these empty dirs will persist indifiniately.
mod6: <+mod6> so... yah, a bash script or removal by hand. would be fine i'd think. but now i gotta
test it a bit harder. if we leave empty directories in there, im worred that patch might come along at a later time and be helpful again, removing those object output diretories. << so if i do remove them by hand, have to ensure that these empty dirs wont get nuked later on accident
mod6: the only thing in the obj-
test directory before applying that patch is '.gitignore' so why wouldn't it be removed like obj/
test and obj/nogui?
mod6: well, thats weird. it seems to remove obj/
test and obj/nogui, but NOT obj-
test which is left empty?!!?
mod6: i might just be dumb. build a
test env with
http://dpaste.com/23VKWD8.txt and see if anyone can get the rm_gitignore.patch file to apply without removing the obj/
test obj/nogui or obj-
test dirrs
mod6: so... yah, a bash script or removal by hand. would be fine i'd think. but now i gotta
test it a bit harder. if we leave empty directories in there, im worred that patch might come along at a later time and be helpful again, removing those object output diretories.
mod6: ben reminded me to add a patch that removes the 5 .gitignore files. seems easy enough, so crated a quick patch, attempted to apply, worked fine -- I didn't notice that it blew away the directories as well though. : obj/
test obj/nogui obj-
test mod6: So this can be used as a
test platform for all the patches, etc. . If you're really ambitious you can install gentoo as above ^^ then use this to pull down the v0.5.3.1 basecode and apply these patches:
http://dpaste.com/23VKWD8.txt assbot: Logged on 19-07-2015 00:41:04; ben_vulpes: ;;later tell solrodar hey man i need a hand compiling boost in order to
test your callgraph visualizer