00:00:34  * isaacstopic: liberal utopian vacation ~ "Shit came real!" --indutny ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
00:01:15  * c4miloquit (Remote host closed the connection)
00:01:33  <bnoordhuis>the failures seem to be all over the place, don't they?
00:02:00  <tjfontaine>well that dgram failure is relatively reproducible
00:02:32  <nodejs-ci>Project nodejs-master-windows » x64,windows build #23:STILL FAILING in 12 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/23/
00:02:33  <bnoordhuis>you mean simple/test-cluster-dgram-2?
00:03:18  <tjfontaine>yes, but I've seen 3 spurious udp failures, including this one that just happened test-dgram-udp4.js
00:03:44  <trevnorris>isaacs: how many if some misc. ones are removed? ;-)
00:03:46  <trevnorris>git log --author=isaacs --pretty="%s" | egrep -v "^(2012|2013|blog|lint|Now|Merge|Revert)" | wc -l
00:04:36  <tjfontaine>otoh, windows 19 failures are pretty damn conssitent
00:04:44  <isaacs>trevnorris: dude, doing releases or blog posts should count extra.
00:04:57  <trevnorris>isaacs: that's true. and those merges can be a bitch.
00:05:32  <tjfontaine>(probably because a lot of tests don't actually run on winders)
00:06:14  <trevnorris>isaacs: almost have the model done for the benchmarks. this paper gave some good examples: http://bit.ly/13rBWJv
00:06:19  * bradleymeckjoined
00:06:40  <bnoordhuis>curious thing, that dgram-2 test never fails on linux but it does occasionally stall
00:06:57  <trevnorris>isaacs: and if all commits are prefixed (e.g. http) then there might be a way to only run a sub-selection of tests that would pertain to the specific commit.
00:07:00  <bnoordhuis>where master and workers just hang in epoll_wait for some reason
00:07:25  <isaacs>trevnorris: well, it's not really safe to assume that.
00:07:47  <trevnorris>isaacs: yeah. I should have made it an uppercase MIGHT. =)
00:07:53  <tjfontaine>bnoordhuis: my current belief is to blame txdv, however my bisecting wasnt' able to really pin point it
00:09:57  * indexzeroquit (Quit: indexzero)
00:10:22  * benoitcquit (Excess Flood)
00:11:07  <bnoordhuis>tjfontaine: blaming txdv is always the right course of action
00:11:29  <bnoordhuis>Error: write EBADF - cannot write to IPC channel. <- interesting
00:11:34  <tjfontaine>bnoordhuis: I figured
00:12:02  <tjfontaine>I could also blame bert, because he hasn't been around
00:12:55  <bnoordhuis>looks like it was fedor after all
00:14:05  <tjfontaine>sblom: haha, twooff
00:14:45  <tjfontaine>sblom: right now I'm testing with /p:PlatformTarget=%msiplatform% as well, what are you testing with your change?
00:15:10  <nodejs-ci>Project nodejs-master-windows » x86,windows build #23:STILL FAILING in 25 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/23/
00:15:56  <bnoordhuis>hmm, looks like the handle is corrupted
00:16:09  <tjfontaine>ya, I've seen 0x0 and 0x4
00:16:24  * hzquit (Read error: Connection reset by peer)
00:16:39  <tjfontaine>which feels like someone is casting it and setting a flag on the wrong thing
00:16:45  <bnoordhuis>bert!
00:16:55  <tjfontaine>absolutely
00:17:04  * benoitcjoined
00:17:25  * hzjoined
00:19:10  <trevnorris>isaacs: ok, so for commit-to-commit testing we can use a random sampling technique that will speed things up. then
00:19:33  <trevnorris>isaacs: between a specific interval (release?) a more complete spread can be run.
00:19:56  <trevnorris>isaacs: meant to ask, plan on having these stored somewhere?
00:20:14  <tjfontaine>probably, that seems sensible
00:20:39  <tjfontaine>I'd personally prefer to use something client side for graphing, but that's just me
00:21:11  <tjfontaine>in that case the client can tick the boxes they're interested in and then get a google-chart (as an example)
00:22:01  <trevnorris>yeah, that'd be the plan.
00:22:31  <trevnorris>tjfontaine: just pick a few of your favorites from https://github.com/mbostock/d3/wiki/Gallery
00:22:56  * bradleymeckquit (Quit: bradleymeck)
00:23:24  <trevnorris>i personally like a difference chart http://bl.ocks.org/mbostock/3894205
00:24:38  <isaacs>i think in our case we may as well just run the benchmarks on every commit.
00:24:40  <isaacs>i mean, why not?
00:24:53  <isaacs>the sun is over the pacific for 8 hours each day where we're not pushing commits.
00:25:02  <isaacs>if the bench server cant' keep up with us, we're doing too muhc :)9
00:25:16  <tjfontaine>trevnorris: ya d3 is another one I've played with, but the google timeline chart also works as a "lets get some visibility asap"
00:25:46  <tjfontaine>just need to setup the harness and start collecting the data
00:26:01  <tjfontaine>everyone else can play with making it pretty, as that is not my forte
00:26:25  * bradleymeckjoined
00:26:26  <trevnorris>isaacs: what I was planning was to do random sampling of each test, then if high variation is detected proceed with the complete swath.
00:26:44  <trevnorris>isaacs: i mean, it would whiz through lint commits
00:27:03  <trevnorris>tjfontaine: making pretty dashboards is actually what i'm paid to do for mozilla. ;-)
00:28:32  <tjfontaine>trevnorris: sounds great then :)
00:29:47  * karupaneruraquit (Excess Flood)
00:30:18  <tjfontaine>o0 http://jenkins.nodejs.org//job/nodejs-master-fnt/5/DESTCPU=x64,label=linux//tapTestReport/test.tap-585/
00:30:49  * karupanerurajoined
00:31:25  * qmx|brbchanged nick to qmx
00:34:26  <isaacs>trevnorris: why not just run every benchmark every time?
00:34:38  <isaacs>trevnorris: i mean, it's not like we have to sit and wait for it
00:35:06  <isaacs>trevnorris: how many minutes does it take to run?
00:36:10  <isaacs>TooTallNate: thoughts on https://github.com/joyent/node/pull/4878?
00:36:28  <isaacs>bnoordhuis: if you're curious about the thing that i was going to ask you about before your meeting, https://github.com/joyent/node/pull/4878 is the resolution of it
00:37:10  <trevnorris>isaacs: not sure yet. part of what I need to test is stabilizing variance. some tests stabilize very quickly so they don't need to run many times. others like the fs ones don't.
00:37:21  <TooTallNate>isaacs: LGTM in general. I haven't pulled the code to try it out yet. I'm assuming it'll break a couple of my modules… but that's the price of bleeding edge :P
00:37:35  <TooTallNate>isaacs: luckily it's only Readable changing
00:37:42  <TooTallNate>and Writable and even Transform are the same
00:37:45  <TooTallNate>so that's good
00:38:41  <TooTallNate>isaacs: any benchmark changes? should go a little faster i'd imagine
00:38:53  <isaacs>TooTallNate: oh! it breaks some tests, apparently.
00:39:07  <isaacs>TooTallNate: i'd checked that, but apparently i changed some stuff before pushing, and didn't re-check
00:39:11  <isaacs>so... i'll fix that :)
00:39:25  <TooTallNate>isaacs: also, what does .unshift() mean in the context of a Transform stream? does the "chunk" get re-transformed?
00:39:33  <TooTallNate>that would probably not be right if that's the case
00:43:53  * kazuponjoined
00:45:15  * kazuponquit (Remote host closed the connection)
00:45:54  * kazuponjoined
00:49:12  <bnoordhuis>isaacs: does that mean i don't have to do anything or have an opinion anymore?
00:49:25  <bnoordhuis>if so, great :)
00:50:12  <bnoordhuis>tjfontaine: what's up with that swaj fellow?
00:50:54  <tjfontaine>bnoordhuis: oh, I know him from other places, so I was just harassing him
00:51:37  <tjfontaine>bnoordhuis: has been a problem? if so I can correct his behavior
00:51:54  <tjfontaine>*has he
00:52:16  <bnoordhuis>oh not at all
00:52:32  <tjfontaine>k didn't expect him to be
00:56:22  * kazuponquit (Remote host closed the connection)
00:59:16  * mikealquit (Quit: Leaving.)
01:00:44  <trevnorris>isaacs: will we guarantee that all tests within a subdir (e.g. benchmark/net/*) will all use the same options?
01:04:51  <MI6>joyent/libuv: Ben Noordhuis master * 2a8d2a5 : darwin: fix spurious uv_write2() segfault We abuse uv_write2() to send o - http://git.io/NXSvEQ
01:04:54  <MI6>joyent/node: Ben Noordhuis master * bb43153 : deps: upgrade libuv to 2a8d2a5 - http://git.io/IE7__A
01:05:22  <tjfontaine>sblom: is this too ugly? https://github.com/tjfontaine/node/compare/windows-nightly
01:06:01  <tjfontaine>bnoordhuis: interesting
01:06:32  <bnoordhuis>tjfontaine: the problem is i'm not sure who to blame now
01:06:52  <nodejs-ci>Project libuv-master » smartos build #11:STILL FAILING in 1 min 55 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/11/
01:07:41  <tjfontaine>bnoordhuis: I'm sticking with txdv
01:08:58  <isaacs>TooTallNate: no, unshift only puts it in the readable side, not back in the writable side.
01:09:09  <isaacs>foudn the test breakage.
01:09:12  <TooTallNate>isaacs: oh right, good point
01:09:12  <isaacs>stupid thing.
01:09:31  <isaacs>removed a console.log(), but left the if() on the line before it.
01:09:33  <isaacs>derp.
01:09:40  <nodejs-ci>Yippie, build fixed!
01:09:40  <nodejs-ci>Project nodejs-master » ia32,linux build #24:FIXED in 4 min 41 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/24/
01:09:55  <tjfontaine>we have another shot at a green board on master
01:10:02  <isaacs>force-pushed
01:10:52  <nodejs-ci>Project libuv-master » linux build #11:STILL FAILING in 5 min 55 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/11/
01:11:07  <MI6>joyent/node: Ben Noordhuis master * c116120 : net: omit superfluous 'connect' event Don't emit a 'connect' event on so - http://git.io/erW9HA
01:12:25  <tjfontaine>bnoordhuis: are you not seeing this on your linux? http://jenkins.nodejs.org//job/libuv-master/label=linux/11//tapTestReport/test.tap-107/ or is there more to come after your process title revamp from osx?
01:13:51  <bnoordhuis>tjfontaine: i made it use only the argv space and not the environ
01:14:22  <bnoordhuis>overwriting the environ might not always be a safe thing to do
01:14:36  <tjfontaine>ah
01:14:46  * trevnorrisquit (Quit: Leaving)
01:15:30  <bnoordhuis>i haven't noticed it failing on my linux boxes but let me double-check
01:15:42  <tjfontaine>I'm failing consistently on that test
01:15:51  <tjfontaine>it could be kernel rev related i suppose
01:16:37  <bnoordhuis>there's a sysctl knob that controls it but i forgot what it's called
01:16:44  <nodejs-ci>Project nodejs-master-windows » x64,windows build #24:STILL FAILING in 11 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/24/
01:16:53  <tjfontaine>ah yes, it could be build slave related
01:18:03  <isaacs>TooTallNate: fwiw: http://static.izs.me/gh-4878.html
01:18:29  <isaacs>TooTallNate: the greens outweigh the reds, but neither outweighs the inherent jitter.
01:18:55  <TooTallNate>isaacs: so not too drastic of a change basically
01:18:57  <TooTallNate>perf-wise
01:19:02  <TooTallNate>API-wise it's great
01:20:25  <isaacs>TooTallNate: so you +1 on it, then? indutny was +1 on the concept, but dunno if he's up to review impl
01:21:11  <nodejs-ci>Project nodejs-master » ia32,linux build #25:FAILURE in 4 min 47 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/25/
01:21:12  <nodejs-ci>Project nodejs-master » x64,linux build #25:FAILURE in 4 min 49 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/25/
01:21:32  <bnoordhuis>tjfontaine: apparently i was wrong and it's (no longer?) a sysctl, it depends on the arch among other things
01:22:06  <tjfontaine>ah
01:24:22  <bnoordhuis>on x86 and x86_64, it's stack_size/4 in case you're wondering
01:24:45  <bnoordhuis>and the default stack size is 2M, i think
01:25:33  <tjfontaine>clearly we need stack_size/9001
01:27:16  <nodejs-ci>Project nodejs-master-windows » x86,windows build #24:STILL FAILING in 22 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/24/
01:27:36  * dapquit (Quit: Leaving.)
01:28:33  * kazuponjoined
01:30:02  * mikealjoined
01:38:28  * mikealquit (Ping timeout: 245 seconds)
01:38:36  <nodejs-ci>Project nodejs-master-windows » x64,windows build #25:STILL FAILING in 11 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/25/
01:38:38  <MI6>joyent/node: isaacs master * 4926ffd : doc: Provide 2 examples of SimpleProtocol parser The first example uses (+3 more commits) - http://git.io/d-I1Lw
01:40:24  <sblom>tjfontaine: that NODE_VERSION thing looks fine to me.
01:40:34  <tjfontaine>ok I'll make a PR for it
01:41:37  <tjfontaine>https://github.com/joyent/node/pull/4879
01:43:20  <nodejs-ci>Project nodejs-master » x64,linux build #26:STILL FAILING in 4 min 38 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/26/
01:43:20  <nodejs-ci>Yippie, build fixed!
01:43:21  <nodejs-ci>Project nodejs-master » ia32,linux build #26:FIXED in 4 min 38 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/26/
01:44:11  * abraxasjoined
01:44:45  <MI6>joyent/node: Timothy J Fontaine master * f0f87d8 : build: windows should append date if nightly - http://git.io/314_LA
01:46:21  <tjfontaine>hmm can't get that dgram-udp4 test to fail on osx, lets see if I can convince smartos
01:49:21  <nodejs-ci>Project nodejs-master-windows » x86,windows build #25:STILL FAILING in 21 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/25/
01:50:28  <sblom>tjfontaine: Here's the change I'm trying to test https://github.com/MSOpenTech/node/tree/sblom-wix-fix
01:51:11  <sblom>tjfontaine: I've been pulled away from my computer several times this afternoon, but I'm back on this now.
01:51:28  <tjfontaine>sblom: ya, I looked at that, it seems sane
01:51:49  <isaacs>ok, if you just got 15 emails about the weekly call, i apologize
01:51:58  <isaacs>iCal and google calendar are in a fight, it seems
01:53:58  <sblom>isaacs: I made sure to send an accept from Outlook just to try to confuse your computer even more.
01:54:06  <nodejs-ci>Project nodejs-master » x64,linux build #27:STILL FAILING in 4 min 36 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/27/
01:54:07  <nodejs-ci>Project nodejs-master » ia32,linux build #27:FAILURE in 4 min 38 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/27/
01:55:05  <tjfontaine>you know what udp, fuck you.
01:56:15  <isaacs>sblom: you're the only one that google calendar thinks is coming.
01:56:22  <isaacs>sblom: (including me)
01:56:41  <sblom>isaacs: Somehow I'm surprised that even worked.
01:56:51  <tjfontaine>[google still hasn't informed me of my invite]
01:57:25  * isaacsis going to start mailing, and DEMANDING, written invitations to meetings.
01:59:05  <nodejs-ci>Project nodejs-master » x64,smartos build #27:FAILURE in 9 min 35 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/27/
02:04:02  <nodejs-ci>Project nodejs-master-windows » x64,windows build #26:STILL FAILING in 14 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/26/
02:04:49  <sblom>tjfontaine: Looks like my fix didn't fix us. I'll think about what to try next on my walk home.
02:10:11  * kazuponquit (Remote host closed the connection)
02:15:46  <nodejs-ci>Project nodejs-master-windows » x86,windows build #26:STILL FAILING in 26 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/26/
02:30:09  * mikealjoined
02:34:21  * mikealquit (Ping timeout: 240 seconds)
02:40:18  * mikealjoined
02:44:17  * qmxchanged nick to qmx|away
02:56:36  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:00:53  * bradleymeckquit (Quit: bradleymeck)
03:02:21  * mikealquit (Quit: Leaving.)
03:06:07  * indexzerojoined
03:11:17  * sblomquit (Ping timeout: 248 seconds)
03:17:38  * hzquit
03:20:39  * kazuponjoined
03:21:54  * bradleymeckjoined
03:24:12  * bradleymeckquit (Client Quit)
03:24:24  * loladiroquit (Quit: loladiro)
03:25:24  * kazuponquit (Ping timeout: 264 seconds)
03:26:54  * bradleymeckjoined
03:29:07  * bradleymeckquit (Client Quit)
03:30:29  * bradleymeckjoined
03:33:34  * brsonquit (Quit: leaving)
03:54:52  * bnoordhuisquit (Ping timeout: 244 seconds)
03:57:20  * TooTallNatejoined
04:01:39  * TooTallNatequit (Ping timeout: 248 seconds)
04:04:08  * TooTallNatejoined
04:42:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
05:00:48  * bnoordhuisjoined
05:05:39  * bnoordhuisquit (Ping timeout: 248 seconds)
05:24:16  * kazuponjoined
05:30:11  * wolfeidauquit (Remote host closed the connection)
05:42:35  * kazuponquit (Remote host closed the connection)
05:45:33  * loladirojoined
05:50:30  * wolfeidaujoined
05:57:42  * mikealjoined
06:38:14  * mmaleckichanged nick to mmalecki[fly|zzz
06:38:17  * mmalecki[fly|zzzchanged nick to mmalecki[fly|zz]
06:52:59  * kazuponjoined
06:57:25  * kazuponquit (Ping timeout: 248 seconds)
07:03:28  * indexzero_joined
07:03:33  * indexzero_quit (Client Quit)
07:04:21  * indexzeroquit (Ping timeout: 248 seconds)
07:29:41  * rendarjoined
07:29:58  * indexzerojoined
07:33:53  * benoitcquit (Excess Flood)
07:33:59  * TooTallNatejoined
07:41:08  * benoitcjoined
07:56:23  * TooTallNatequit (Quit: Computer has gone to sleep.)
08:05:53  * stagasquit (Ping timeout: 248 seconds)
08:13:00  * AvianFluquit (Remote host closed the connection)
08:26:45  * kazuponjoined
08:55:17  * slaskisjoined
09:38:54  * `3rdEdenjoined
09:44:51  * piscisaureus_joined
09:47:43  * indexzeroquit (Quit: indexzero)
09:47:51  <piscisaureus_>isaacs: you've been restarting slurp alot lately?
10:14:27  * stagasjoined
10:21:07  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner])
10:21:36  * loladiroquit (Quit: loladiro)
10:25:12  * kazuponquit (Remote host closed the connection)
10:29:22  * stagasjoined
10:34:24  <rendar>piscisaureus_: i have tried to make a lot of connections with libuv in Windows7, but only the first 200 tcp connections are accepted, the others are not accepted and the error is "connection refused" -- i read that it could be caused by tcpip.sys that limits the incoming connections in Windows7 and clients version of Windows, is that a normal thing?! should i have to try Windows Server for such
10:34:25  <rendar>tests?
10:34:37  * indexzerojoined
10:39:57  * abraxasquit (Remote host closed the connection)
10:50:41  * hzjoined
11:29:51  * bnoordhuisjoined
11:31:04  <piscisaureus_>rendar: never noticed something like that - but I'm on win7 ultimate so maybe you have a cheaper version which does that
11:31:31  <piscisaureus_>rendar: you can also try to make connections at a slower pace. Maybe the backlog fills up.
11:37:42  <bnoordhuis>piscisaureus_: back in +31?
11:38:21  <rendar>piscisaureus_: yeah, but i was trying to measure how many connections it can accept, i have also tried in the my friend's windows7, and i got the same result, about 200 connections connected, the other refused! instead in windows XP (on x64) i get almost 34.000 connections accepted, the others are closed with no buffer memory available (i fire 50.000 clients)
11:42:42  * saghulquit (Ping timeout: 264 seconds)
11:57:03  <piscisaureus_>bnoordhuis: yup
11:57:32  <piscisaureus_>rendar: the xp problem is most likely due to using a 32-bit system
11:57:56  <piscisaureus_>rendar: windows allocates quite a bit of unpaged pool for tcp connections. on 64-bit machines this should not be a problem
12:00:31  <piscisaureus_>rendar: what do you get if you enter `netsh int tcp show security` on the 7 machine?
12:01:39  <rendar>piscisaureus_: yeah exactly
12:03:41  <rendar>piscisaureus_: hmm, i have to check, i'm not on that machine at the moment, i'll tell you, btw i have tried to tuning all those netsh parameters, such as the choke, and so on! but nothing happened. then i have read about that TCP-Z utility, used to crack tcpip.sys to solve this problem, but someone in serverfault said that no matter of what you do, windows client version will always limit your
12:03:41  <rendar>incmoing connections number
12:04:46  <piscisaureus_>rendar: when I use loopback I can easily get to 10k connections (with node.js) so either your win7 version is different and it matters, or something else is wrong
12:04:57  <piscisaureus_>rendar: although I should add I disabled the firewall
12:05:16  <rendar>yeah i disabled that too
12:05:39  <rendar>piscisaureus_: what version of windows 7 do you have?
12:05:45  <piscisaureus_>rendar: ultimate
12:08:53  <piscisaureus_>rendar: try this:
12:08:53  <piscisaureus_>node -e "var net=require('net'),c=0,conn=function(){net.connect(12345)};net.createServer(function(){console.log(++c);conn()}).listen(12345);conn()"
12:09:02  <piscisaureus_>:D
12:09:35  <piscisaureus_>for me it stops with ENOBUFS at 64447 connections
12:09:45  <piscisaureus_>although really ENOBUFS means out of ephemeral ports here
12:12:18  <MI6>joyent/node: Ben Noordhuis v0.8 * f26362e : http: use socket.once, not socket.on Register the 'close' event listener - http://git.io/z9ocRw
12:16:19  <bnoordhuis>rendar, piscisaureus_: virus scanner?
12:16:58  * sgallaghjoined
12:27:03  * indexzeroquit (Quit: indexzero)
12:33:57  * piscisaureus_quit (Ping timeout: 248 seconds)
13:08:40  * slaskisquit (Quit: slaskis)
13:36:56  * benoitcquit (Excess Flood)
13:39:41  * benoitcjoined
14:03:29  * piscisaureus_joined
14:14:39  * qmx|awaychanged nick to qmx
14:41:45  * benoitcquit (Excess Flood)
14:50:10  * benoitcjoined
14:59:15  <rendar>bnoordhuis: nope, i don't have any virus scanner in windows 7, its just a bare windows7 :)
14:59:25  <rendar>bnoordhuis: but i'll make more tests
15:02:07  <piscisaureus_>rendar: did you try my node one-liner ?
15:02:41  <rendar>piscisaureus_: well not yet, but i will try :) i have to reboot to go there, but i can't for now
15:22:58  * benoitcquit (Excess Flood)
15:23:57  * c4milojoined
15:28:53  * AvianFlujoined
15:32:41  * benoitcjoined
15:35:12  * mikealquit (Quit: Leaving.)
15:42:50  <tjfontaine>piscisaureus_: isaacs has been restarting slurp a lot, but I think it's more a byproduct of freenode splits than anything else
15:43:17  * `3rdEdenquit (Quit: [email protected]!)
15:44:41  * chobiequit (*.net *.split)
15:44:41  * pquernaquit (*.net *.split)
15:45:38  * chobiejoined
15:45:38  * pquernajoined
16:08:08  * mmalecki[fly|zz]changed nick to mmalecki
16:14:31  * mikealjoined
16:20:44  * TooTallNatejoined
16:22:17  * TooTallNatequit (Client Quit)
16:29:28  * bradleymeckquit (Quit: bradleymeck)
16:34:37  * dapjoined
16:35:41  * mikealquit (Quit: Leaving.)
16:37:39  <isaacs>piscisaureus_: i set it to restart daily
16:37:46  <isaacs>piscisaureus_: otherwise netsplits kill it permanently
16:38:03  <isaacs>piscisaureus_: did the same with ircretary, which i gather uses the same netsplit-unaware node irc lib
16:38:32  <piscisaureus_>isaacs: hmm - maybe something to fix? :)
16:38:39  <isaacs>piscisaureus_: meh. probably.
16:38:51  <isaacs>piscisaureus_: it's not high priority, so i fixed it with duct tape and chewing gum.
16:38:59  <piscisaureus_>isaacs: I don't like restarting it so often :)
16:39:10  <isaacs>piscisaureus_: ok. well, it's a trade-off.
16:39:15  <isaacs>how long of a gap would you like in the logs?
16:39:29  <isaacs>if you restart it weekly, then we'll miss a few days. restart it daily, we'll miss a few hours.
16:39:31  <piscisaureus_>It looks bad -> https://github.com/piscisaureus/slurp-logs/commits/master
16:39:57  <indutny>hoya
16:40:01  <isaacs>piscisaureus_: then change the message to "scheduled server reconnect"
16:40:03  <isaacs>piscisaureus_: :)
16:40:06  <isaacs>FTFY!
16:41:10  <isaacs>piscisaureus_: i mean, yeah, it's on my list to dig into irc.js and figure out how to detect netsplits and automatically reconnect (or just write a /who if there's no messages for a few minutes, and reconnect if it resets)
16:41:20  <isaacs>but it's not a priority
16:41:20  <piscisaureus_>isaacs: is it really netsplits?
16:41:29  <isaacs>piscisaureus_: well, that's my working theory.
16:41:37  <piscisaureus_>isaacs: if a netsplit really happens then it ususally shows up in the logs
16:41:59  <piscisaureus_>isaacs: as far as i can tell slurp only breaks when the network has connectivity issues
16:42:05  <piscisaureus_>which, at joyent, always seem to come in waves
16:42:25  <piscisaureus_>I've had uptime of months and then there is a shitty period again where it happens daily
16:42:25  <isaacs>oh, ok. not netsplits, then
16:43:12  <isaacs>but hte connection dies, and because we swallow econnresets, you cannot detect this except to go and check if the socket is destroyed or not
16:43:18  <isaacs>(bug, fixed in master)
16:44:44  * qmxchanged nick to qmx|away
16:45:26  <piscisaureus_>yeah
16:45:35  <piscisaureus_>ppl were quite upset that it was fixed in 0.8
16:51:48  <isaacs>piscisaureus_: yeah. we fixed it more gently in 0.8.21
16:52:11  <isaacs>it still isn't fixed in general
16:52:19  <isaacs>just in the one case where you try to write to a socket that is already reset
16:52:51  <piscisaureus_>maybe we can have a lame hack
16:53:20  <piscisaureus_>socket.emitConnesetErrors = true; // v0.8 only
16:53:41  <isaacs>meh
16:53:49  <isaacs>i'm kinda happy with 0.8.21 behavior
16:53:55  <isaacs>it doesn't leak, or crash
16:54:08  <isaacs>or rather, it leaks much less, and for only a short time
16:55:18  <MI6>joyent/node: isaacs master * 55aa973 : test: Put fs write test files in tmp This prevents fixture litter when t - http://git.io/u7AkCQ
16:55:40  <piscisaureus_>indutny why do you have 2 linkedin profiles?
16:55:45  <indutny>yeah
16:55:52  <indutny>that's a pain
16:55:55  <piscisaureus_>WHY
16:56:35  <indutny>why what?
16:56:45  <piscisaureus_>why you have 2?
16:57:58  <indutny>ah
16:58:01  <indutny>different emails
16:58:16  <indutny>I forgot about one of them
16:58:20  <indutny>when created the current one
17:00:03  <nodejs-ci>Project nodejs-master » x64,linux build #28:STILL FAILING in 4 min 39 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/28/
17:00:03  <nodejs-ci>Yippie, build fixed!
17:00:04  <nodejs-ci>Project nodejs-master » ia32,linux build #28:FIXED in 4 min 39 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/28/
17:00:50  * slaskisjoined
17:02:46  * saghuljoined
17:05:02  <nodejs-ci>Yippie, build fixed!
17:05:02  <nodejs-ci>Project nodejs-master » x64,smartos build #28:FIXED in 9 min 38 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/28/
17:07:44  <nodejs-ci>Project nodejs-master-windows » x64,windows build #27:STILL FAILING in 12 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/27/
17:10:33  * piscisaureus_quit (Ping timeout: 245 seconds)
17:11:14  <isaacs>bnoordhuis: can you review this? https://github.com/isaacs/node/commit/2e4d149a038deffce771c2fbeea30f5f35aa0f21
17:15:20  * bnoordhuisquit (Ping timeout: 240 seconds)
17:17:46  * bradleymeckjoined
17:18:44  <nodejs-ci>Project nodejs-master-windows » x86,windows build #27:STILL FAILING in 23 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/27/
17:19:49  * bradleymeckquit (Client Quit)
17:25:37  <indutny>isaacs: does fs.readFile really need `mode` option?
17:25:57  <isaacs>indutny: hm... i dunno
17:26:03  <indutny>just curious
17:26:05  <isaacs>probably not :)
17:26:12  <indutny>its not going to modify file anyway
17:26:15  <isaacs>right
17:26:29  <tjfontaine>{mode: 'reall-fast'}
17:26:36  <indutny>uh?
17:26:42  <tjfontaine>tis a joke
17:26:46  <indutny>ok
17:27:10  <isaacs>yeah, that's extraneous. i'll remove
17:32:37  * mikealjoined
17:33:28  * sgallaghquit (Remote host closed the connection)
17:35:27  <isaacs>indutny: pushed update https://github.com/isaacs/node/compare/GH-4841
17:36:39  * sgallaghjoined
17:41:49  * mikealquit (Quit: Leaving.)
17:45:13  <indutny>a little bit not DRY
17:45:15  <indutny>but lgtm
17:45:28  <indutny>https://github.com/isaacs/node/compare/GH-4841#L1R996
17:45:29  <indutny>oh
17:45:30  <indutny>gosh
17:45:36  <indutny>ok
17:46:01  <indutny>https://github.com/isaacs/node/compare/GH-4841#L3R104
17:46:03  <indutny>^^ wtf
17:46:07  <indutny>why not just 0600
17:46:27  <isaacs>indutny: because strict mode doesn't allow it
17:46:32  <indutny>oooh
17:46:35  <indutny>but you do it in another test
17:46:45  <isaacs>indutny: tests don't have to be strict mode :)
17:47:00  <indutny>well
17:47:04  <indutny>not sure I follow :)
17:47:11  <indutny>one test is using parseInt("0600", 8)
17:47:14  <indutny>another 0600
17:47:15  <isaacs>oh, you mean, why does thte test do parseint
17:47:16  <isaacs>i dunno
17:47:18  <isaacs>meh
17:47:27  <indutny>otherwise lgtm :)
17:47:33  <isaacs>k, i'll change that and push
17:50:35  * mikealjoined
17:50:36  <isaacs>i'm seeing some sporadic failures on test-child-process-fork-getconnections
17:58:28  <MI6>joyent/node: isaacs master * 0928a52 : fs: Support mode/flag options to read/append/writeFile Fix #4841 - http://git.io/a2ZsWQ
18:01:12  * c4miloquit (Remote host closed the connection)
18:02:32  <MI6>joyent/libuv: isaacs created tag node-v0.9.11 - http://git.io/CNsx0g
18:02:43  <_ry>isaacs++
18:03:13  <nodejs-ci>Yippie, build fixed!
18:03:14  <nodejs-ci>Project nodejs-master » x64,linux build #29:FIXED in 4 min 40 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/29/
18:03:19  <_ry>so when is 0.10 ?
18:03:36  <_ry>cause it's march
18:04:19  <isaacs>_ry: yeah, it is.
18:04:20  <_ry>the jenkins thing is cool
18:04:23  <isaacs>_ry: soon.
18:04:41  <isaacs>_ry: yeah, it's rad.
18:04:49  <isaacs>graphs and weather images
18:04:57  <_ry>yeah looks stormy
18:05:01  <tjfontaine>it's raining builds
18:05:10  <isaacs>_ry: it's linux's fault
18:05:33  * _rynods
18:05:36  <tjfontaine>v0.8 has a green board from last build
18:05:41  <tjfontaine>last 2 actually
18:05:41  <isaacs>tjfontaine: nice
18:06:07  <_ry>you guys are awesome. the jenkins thing is super cool
18:06:47  <isaacs>dude, process.title actually works all the way in darwin now.
18:06:51  <isaacs>bnoordhuis++
18:13:48  <nodejs-ci>Project nodejs-master-windows » x64,windows build #28:STILL FAILING in 15 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x64,label=windows/28/
18:17:11  <indutny>haha
18:17:21  <indutny>ben is fucking genious
18:19:30  <MI6>joyent/node: isaacs created branch v0.9.11-release - http://git.io/-6VFcw
18:19:32  <isaacs>review changelogs? ^
18:20:52  <indutny>looks good
18:21:56  <MI6>joyent/node: isaacs v0.9.11-release * d9e294b : 2013.03.01, Version 0.9.10 (Unstable) * V8: downgrade 3.14.5 * openssl: (+1 more commits) - http://git.io/85Ez3w
18:22:08  <isaacs>had to fix the blog generation. our path.join checking bit me :)
18:23:25  <_ry>snow if only ben can get process.title to work in sun
18:23:49  <_ry>first he'll have to hack the kernel to add that feature
18:26:13  <nodejs-ci>Project nodejs-master-windows » x86,windows build #28:STILL FAILING in 27 min: http://jenkins.nodejs.org/job/nodejs-master-windows/./DESTCPU=x86,label=windows/28/
18:27:02  * TooTallNatejoined
18:31:40  * nsm_joined
18:39:07  * c4milojoined
18:40:41  * `3rdEdenjoined
18:41:11  * abraxasjoined
18:45:42  * trevnorrisjoined
18:46:20  * abraxasquit (Ping timeout: 272 seconds)
18:46:59  * bnoordhuisjoined
18:48:08  <trevnorris>isaacs: have you run make doc recently?
18:48:36  <trevnorris>i'm getting - path.js:360 throw new TypeError('Arguments to path.join must be strings');
18:48:55  <tjfontaine>[03-01] 13:22:08 <@isaacs> had to fix the blog generation. our path.join checking bit me :)
18:50:28  <indutny>removed all games from macbook
18:50:34  <indutny>looks like I'm back to work :)
18:51:29  <tjfontaine>it only looks like you're back to work, you're really playing nethack
18:51:57  * nodejs-ciquit
18:52:33  * nodejs-cijoined
18:52:34  <indutny>meh
18:56:45  <isaacs>oh, man, nethack...
18:56:53  <isaacs>it's been about 4 years since my last run at nethack
18:57:24  <indutny>I'm not sure if I ever run it
18:57:54  <isaacs>trevnorris: the doc is fixed in 0.9.11-release branch
18:58:02  <isaacs>i guess i could cp the commit over to master. one sec.
18:58:23  <trevnorris>isaacs: well, it will be merged back over soon, right?
18:58:28  <MI6>joyent/node: isaacs master * 687522c : blog: Do not pass undefined to path.join - http://git.io/xCliww
18:58:37  <trevnorris>heh, that was fast.
18:58:54  <tjfontaine>erm
18:58:56  <nodejs-ci>Project nodejs-master » ia32,windows build #30:ABORTED in 22 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/30/
18:58:56  <nodejs-ci>Project nodejs-master » x64,windows build #30:ABORTED in 22 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/30/
18:58:57  <nodejs-ci>Project nodejs-master » ia32,linux build #30:ABORTED in 22 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/30/
18:58:58  <nodejs-ci>Project nodejs-master » x64,linux build #30:ABORTED in 22 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/30/
18:59:23  <indutny>isaacs: what do you think about viral-licenses
18:59:36  <indutny>like 1. You should obey rules in this license
18:59:38  <MI6>joyent/node: isaacs v0.9.11-release * 8339240 : 2013.03.01, Version 0.9.10 (Unstable) * V8: downgrade 3.14.5 * openssl: - http://git.io/P9_DmQ
18:59:46  <indutny>2. You should send this source code to at least 1 person
18:59:47  <isaacs>indutny: i prefer my licenses to not be viral
18:59:56  <indutny>better 10 persons
19:00:04  <isaacs>better require at least 3
19:00:08  <indutny>depends
19:00:17  <isaacs>if those three people dont' comply with the license, YOU are liable
19:00:20  <indutny>I wonder if this thing could be legally possible
19:00:24  <trevnorris>isaacs: just fyi, still having that problem where "marked" just spins indefinitely with make doc. luckily everything else gets processed using -jN, but have to kill it afterwards.
19:00:24  <indutny>ahhaha
19:00:27  <isaacs>chain-licenses
19:00:31  <indutny>god
19:00:46  <indutny>this is awesome
19:00:54  <isaacs>trevnorris: that's weird
19:01:04  <isaacs>trevnorris: i only ever make doc on the mac
19:01:08  <isaacs>trevnorris: maybe it's a linux thing?
19:01:13  <trevnorris>isaacs: yeah. i've looked at it before and never been able to figure out why.
19:01:25  <trevnorris>could another linux user try running "make doc"?
19:02:19  <isaacs>i'll try on the linux build box
19:02:48  <isaacs>huh. seems to hang on bash tools/build-changelog.sh
19:02:59  <trevnorris>yeah. same thing I get
19:03:14  <nodejs-ci>Project nodejs-master » x64,windows build #31:FAILURE in 2 min 7 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/31/
19:03:28  <tjfontaine>er
19:03:49  <nodejs-ci>Project nodejs-master » ia32,windows build #31:FAILURE in 2 min 42 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/31/
19:04:04  <tjfontaine>oh right of course
19:04:15  <trevnorris>isaacs: iirc it hange on line 94 of tools/doc/node_modules/.bin/marked
19:05:52  <nodejs-ci>Project nodejs-master » x64,linux build #31:FAILURE in 4 min 45 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/31/
19:06:56  * sblomjoined
19:07:50  <isaacs>ok, this is the second time this has happened
19:08:06  <isaacs>sblom: somehow, i'm building node from a v0.9.11 tarball, and getting a thing called 0.8.21
19:08:10  <isaacs>sblom: !?!?
19:08:14  <isaacs>sblom: totally confused
19:08:32  <isaacs>oh, maybe this is to blame? Successfully signed: Release\node.exe
19:08:32  <isaacs>The process cannot access the file because it is being used by another process.
19:08:32  <isaacs>The system cannot find the file C:\Users\ISAACS~1\AppData\Local\Temp\node_versio
19:08:32  <isaacs>n.txt.
19:08:33  <isaacs>Building node-0.8.21
19:08:58  <tjfontaine>sounds like an issue with the getversion script
19:09:03  <isaacs>yeah
19:09:17  <isaacs>i think maybe this happens because i buld the ia32 and x64 versions at the same time
19:10:39  <isaacs>so it fails to open some temp file, because it's in use, and then craps out, and uses whatever the last built version was (which is usually the previous 0.8 release)
19:11:10  <sblom>isaacs: Yikes.
19:11:38  <isaacs>sblom: last time, i blamed it on operator error. people were confused that the 0.8 exe was reporting node -v of 0.9.something
19:11:47  <isaacs>sblom: but this time, i totally caught windows in teh act, being weird :)
19:11:58  <tjfontaine>you're building in the same git tree each time?
19:12:40  <isaacs>tjfontaine: nope
19:12:43  <isaacs>fresh tar unpack
19:13:36  <tjfontaine>interesting
19:13:37  <sblom>interesting. I'll see what creates this node_version.txt thing and see if we can push it down from global scope.
19:13:42  * brsonjoined
19:14:21  <sblom>tjfontaine: on our other thread, I haven't come up with anything else to try on the x64 build failure, but my next step is to repro it locally so I can do more invasive things.
19:15:38  <tjfontaine>sblom: ok, I have been making a single job for all the platforms, so not a huge rush on figuring that out just yet
19:16:30  <sblom>isaacs, tjfontaine: Awesome. We're using a temp file called node_version.txt simply because cmd.exe doesn't really have "set NODE_VERSION=`getnodeversion.py`"
19:16:44  <sblom>This is totally fixable.
19:17:20  <tjfontaine>excellent :)
19:18:14  <isaacs>sblom: w00t!
19:18:37  <isaacs>sblom: if you "fix" it by blowing up the whole procedure if the file doesn't write properly, that's fine, too
19:19:01  <MI6>joyent/node: isaacs created tag v0.9.11 - http://git.io/AAnqTw
19:19:47  <MI6>joyent/node: isaacs master * 4cda016 : Now working on 0.9.12 (+2 more commits) - http://git.io/IvYQrg
19:20:06  <nodejs-ci>Yippie, build fixed!
19:20:07  <nodejs-ci>Project nodejs-master » x64,windows build #32:FIXED in 13 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/32/
19:20:07  <nodejs-ci>Yippie, build fixed!
19:20:08  <nodejs-ci>Project nodejs-master » ia32,windows build #32:FIXED in 13 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/32/
19:20:16  <tjfontaine>uh
19:20:36  <sblom>isaacs: I guess, but that just means 3 weeks from now you'll be complaining about random crashes while you're building instead of random version numbers. :p
19:20:42  <isaacs>hahahh
19:20:44  <isaacs>net improvement!
19:20:45  <isaacs>:)
19:20:48  <sblom>true
19:20:54  <isaacs>random crashes are not nearly so bad.
19:21:21  <isaacs>also, i made the build go CRAZY FAST on windows!
19:21:23  <isaacs>13 seconds!!
19:21:27  * isaacsis a windows genius
19:21:29  <sblom>isaacs: very nice.
19:21:58  <sblom>isaacs: wait--is this all illusory gains?
19:22:22  * sblomnow realizes something _must_ be wrong. :(
19:23:29  <isaacs>whoops, changelog has the wrong version.
19:23:31  * isaacsle sigh
19:24:05  * isaacsso not doing another release for this
19:24:05  <MI6>joyent/node: isaacs master * 33aafbd : doc: Correct version in changelog - http://git.io/lk2PIw
19:24:09  <tjfontaine>we'll be automating it soon I promise :)
19:24:13  <isaacs>yes, please :)
19:24:49  <nodejs-ci>Project nodejs-master » ia32,linux build #32:FAILURE in 4 min 56 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/32/
19:24:51  <nodejs-ci>Project nodejs-master » x64,linux build #32:STILL FAILING in 4 min 57 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/32/
19:24:59  <MI6>joyent/node: isaacs v0.8 * be770a3 : blog: Post about v0.9.11 - http://git.io/0fLxRA
19:27:54  <isaacs>alrght, 0.9.11 is out there
19:27:57  <isaacs>loud and proud
19:34:26  <nodejs-ci>Yippie, build fixed!
19:34:26  <nodejs-ci>Project nodejs-master » x64,linux build #33:FIXED in 4 min 38 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/33/
19:34:54  * loladirojoined
19:35:03  <nodejs-ci>Yippie, build fixed!
19:35:04  <nodejs-ci>Project nodejs-master » ia32,linux build #33:FIXED in 5 min 16 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/33/
19:39:47  <nodejs-ci>Project nodejs-master » ia32,smartos build #33:FAILURE in 10 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/33/
19:40:55  <nodejs-ci>Project nodejs-master » x64,smartos build #33:FAILURE in 11 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/33/
19:41:28  * nsm_quit (Quit: nsm_)
19:47:41  * benoitcquit (Excess Flood)
19:48:11  <isaacs>refactoring Readable.onread made a pretty significant difference: http://static.izs.me/benchmark-0.9.11-vs-0.8.21.html
19:48:41  <isaacs>we're still not quite there, but i think inline-ifying Readable.read() and the various bits in Writable, and EventEmitter.emit, will probably get us over the finish line.
19:48:42  <tjfontaine>nice
19:48:48  <isaacs>trevnorris: ^
19:49:46  <isaacs>time to run. i'll be back in a few hours.
19:51:50  <indutny>good results!
19:51:59  <indutny>we're much closer
19:53:46  * benoitcjoined
19:58:46  * qmx|awaychanged nick to qmx
20:00:13  <nodejs-ci>Project nodejs-v0.8 » x64,windows build #7:FAILURE in 30 min: http://jenkins.nodejs.org/job/nodejs-v0.8/./DESTCPU=x64,label=windows/7/
20:10:50  <sblom>tjfontaine: https://github.com/joyent/node/pull/4887
20:12:04  <tjfontaine>that's pretty cute
20:12:22  <tjfontaine>batch is so silly at times
20:13:16  <sblom>lgty?
20:24:48  * einarosquit (Quit: reboot)
20:42:52  * sgallaghquit (Ping timeout: 272 seconds)
20:51:46  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:01:08  * TooTallNatejoined
21:13:37  <tjfontaine>sblom: yup
21:19:34  * bnoordhuisquit (Ping timeout: 244 seconds)
21:24:12  * mikealquit (Quit: Leaving.)
21:31:08  <MI6>joyent/node: Scott Blomquist master * 6366a30 : build/windows: don't use wrong version number We were using a global tem - http://git.io/hdxKzA
21:39:50  * txdvquit (Ping timeout: 255 seconds)
21:40:42  <nodejs-ci>Yippie, build fixed!
21:40:42  <nodejs-ci>Project nodejs-master » ia32,smartos build #34:FIXED in 9 min 27 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/34/
21:40:43  <nodejs-ci>Yippie, build fixed!
21:40:44  <nodejs-ci>Project nodejs-master » x64,smartos build #34:FIXED in 9 min 29 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/34/
21:41:08  <sblom>Is new committer's nerves a thing? https://twitter.com/sblom/status/307606104219713536
21:41:41  <tjfontaine>haha, no I totally have had it on multiple projects
21:41:47  <tjfontaine>hell I have it on submitting PRs :P
21:42:09  <sblom>Heh. I'm much less worried about PRs--I just _count_ on embarrassing myself with each of them. :)
21:42:19  * `3rdEdenquit (Remote host closed the connection)
21:42:26  <sblom>But I can totally understand.
21:42:43  <tjfontaine>ya, embarrassment is it
21:43:46  <sblom>It's funny--even when I worked on Windows and was breaking the build for like a thousand other developers, I wasn't as nervous as my first push to node master.
21:43:55  <tjfontaine>sblom: so I ended up doing something slightly evil, in order to get one job per branch and platform, I now use python to execute the platform dependent build scripts
21:44:09  <tjfontaine>sblom: public != work I guess :)
21:44:11  <nodejs-ci>Project libuv-v0.8 » osx build #3:FAILURE in 1 min 18 sec: http://jenkins.nodejs.org/job/libuv-v0.8/./label=osx/3/
21:44:20  <sblom>tjfontaine: I think that's definitely it.
21:44:50  <sblom>tjfontaine: oh, interesting. So like Jenkins is calling python which is setting up the environment and then building?
21:45:08  <nodejs-ci>Project libuv-master » osx build #12:FAILURE in 20 sec: http://jenkins.nodejs.org/job/libuv-master/./label=osx/12/
21:45:12  <tjfontaine>sblom: ya, which allows me to do different things on different platforms
21:45:15  <nodejs-ci>Project libuv-v0.8 » linux build #3:STILL FAILING in 2 min 22 sec: http://jenkins.nodejs.org/job/libuv-v0.8/./label=linux/3/
21:46:18  <tjfontaine>https://gist.github.com/tjfontaine/5068092
21:46:30  <tjfontaine>that VS100COMMTOOLS needs to go in the buildwrap.bat
21:47:05  <nodejs-ci>Project libuv-v0.8 » smartos build #3:STILL FAILING in 4 min 11 sec: http://jenkins.nodejs.org/job/libuv-v0.8/./label=smartos/3/
21:47:09  <sblom>Nice.
21:47:11  <nodejs-ci>Project libuv-master » smartos build #12:STILL FAILING in 2 min 24 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/12/
21:47:19  <sblom>Does that fix the WiX build failure? Or should I still be working on that?
21:47:36  <sblom>Oh, I get it.
21:47:46  <tjfontaine>I haven't tried yet, but I'm going to guess it doesn't as there's something fubar'd in my chain
21:47:57  <sblom>This just fixes the "how do we map Jenkins matrix strings to what everything else expects".
21:48:06  <sblom>Okay--I'll stay on the WiX thing, then.
21:48:09  <nodejs-ci>Project nodejs-master » x64,windows build #34:FAILURE in 16 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/34/
21:48:12  <nodejs-ci>Project nodejs-master » ia32,windows build #34:FAILURE in 16 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/34/
21:48:25  <tjfontaine>sblom: right
21:48:27  <nodejs-ci>Project libuv-master » linux build #12:STILL FAILING in 3 min 40 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/12/
21:49:02  * loladiroquit (Quit: loladiro)
21:51:47  <sblom>tjfontaine: Doesn't Jenkins have a way to separate build failures from test failures? Like an "Unstable" state or something like that.
21:51:57  <sblom>It'd be neat if Jenkins told us Windows is building but not passing tests.
21:52:46  <tjfontaine>sblom: it's mostly a deficiency in the irc bot, so I'm thinking of just replacing that par
21:52:49  <tjfontaine>t
21:53:24  <tjfontaine>sblom: so yes, there is a "don't fail the build" but then the bot doesn't say "hey guys somethings wrong here"
21:54:24  <sblom>got it
21:54:30  * mikealjoined
21:55:22  * bradleymeckjoined
22:03:08  * mikealquit (Ping timeout: 252 seconds)
22:10:14  * isaacsfg
22:10:55  * bradleymeckquit (Quit: bradleymeck)
22:11:22  <isaacs>sblom: no, new committer's nerves is totally a thing.
22:12:16  <isaacs>sblom: i actually fucked up node and got very terse unpleased emails from _ry a few times at first.
22:12:19  <isaacs>:)
22:12:28  <tjfontaine>heh
22:13:06  <isaacs>tjfontaine: is there any way to have it say what part it failed at?
22:13:39  <isaacs>sblom: PRs are good, though. i still always like to at least get 1 other committer to review it and say lgtm
22:13:57  <isaacs>sblom: sometimes we jsut do that sync with a /compare/... url or something, though
22:14:06  <tjfontaine>isaacs: not with the current irc-plugin/im-plugin infrastructure, notifications are the part at the moment I'm least satisfied with from jenkins
22:14:14  <isaacs>tjfontaine: gotcha
22:14:28  <isaacs>tjfontaine: that's just polish. we can tweak it later.
22:14:36  <tjfontaine>ya
22:15:50  <trevnorris>just read linus' emails to his maintainers. that will harden you up pretty quick.
22:16:03  <tjfontaine>I hate linus' attitude
22:16:25  <tjfontaine>on the other hand, his english has certainly improved over the past couple decades
22:17:57  <isaacs>oh, yeah. it's a testament to linux that it's able to withstand despite such a fucking insanely malevolent dictator
22:18:03  <tjfontaine>isaacs: we're fairly covered on the build slave fronts, and one job per branch, so aside from the fact that I can't yet generate msi's it's generally done
22:18:25  <isaacs>if anyone was half as much a dick in node as linus is, they'd be banned immediately.
22:18:37  <tjfontaine>indeed
22:21:40  <trevnorris>it's funny, iirc he didn't/doesn't care about linux being popular.
22:21:53  <MI6>joyent/node: Evan Oxfeld master * 16ddc54 : doc: Fix readable.unshift() example Slice the portion of the buffer to u - http://git.io/GDE65A
22:22:02  <trevnorris>"just for fun" gave an interesting insight into the evolution of linux.
22:22:58  * bnoordhuisjoined
22:26:23  * bnoordhu1sjoined
22:26:50  <MI6>joyent/node: isaacs master * fc22986 : doc: Clarify advisory-ness of stream._read() argument (+1 more commits) - http://git.io/O0-PeA
22:28:29  <trevnorris>isaacs: so those push changes made a big difference?
22:28:35  * EhevuTovjoined
22:31:11  * bnoordhu1squit (Ping timeout: 252 seconds)
22:31:56  * rendarquit
22:33:32  * piscisaureus_joined
22:35:11  <isaacs>trevnorris: well, they made a difference.
22:35:26  <isaacs>trevnorris: we're well within the margin of error now, between master and 0.8
22:35:36  <trevnorris>coolio. that's good news.
22:35:43  <isaacs>yeah, ti's fucking awesome news :)
22:36:04  <isaacs>next step is to do the same thing for EE.emit, Readable.read(), and Writable.everything
22:37:37  <isaacs>trevnorris: EE emulsify emit you said is ready for review, right?
22:37:41  <isaacs>i'll start in on that now.
22:37:48  <trevnorris>isaacs: yeah, it's ready.
22:37:50  <trevnorris>thanks
22:37:52  * qmxchanged nick to qmx|away
22:38:46  <isaacs>sblom: (`python "%~dp0tools\getnodeversion.py"`)
22:38:52  <isaacs>sblom: CMD CAN DO BACKTICKS!!??!?
22:39:12  <isaacs>OMG TELL ME IT IS TRUE!
22:39:23  <tjfontaine>only if you specify the right junk beforehand apparently
22:39:25  <nodejs-ci>Project nodejs-master » ia32,windows build #35:STILL FAILING in 17 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/35/
22:39:30  <nodejs-ci>Project nodejs-master » x64,windows build #35:STILL FAILING in 17 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/35/
22:40:29  <isaacs>oh, is that the "usebackq tokens=*" bit?
22:42:17  <tjfontaine>ya I believe so
22:42:29  * indexzerojoined
22:44:14  <nodejs-ci>Project nodejs-master » x64,linux build #36:FAILURE in 4 min 37 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/36/
22:44:31  <isaacs>trevnorris: i don't htink listenerLength should be internal.
22:44:32  <nodejs-ci>Project nodejs-master » ia32,linux build #36:FAILURE in 4 min 55 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/36/
22:44:39  <isaacs>trevnorris: that's a good thing. we should expose it and document it
22:44:46  <trevnorris>isaacs: i did that since the api said "Locked"
22:44:52  <trevnorris>i can make that change really quick though
22:45:02  <isaacs>hmmm... good point
22:45:03  <nodejs-ci>Project nodejs-master » x64,osx build #36:FAILURE in 5 min 26 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=osx/36/
22:45:11  <isaacs>and we did get a bunch of shit from addin gthe "domain" field there.
22:45:22  <bnoordhuis>so much red :(
22:45:22  <isaacs>but i mean... it's just as hazardous if it's internal
22:45:41  <trevnorris>yeah, i agree.
22:45:41  <isaacs>tjfontaine: you've got osx building? how's that work?
22:46:04  <tjfontaine>isaacs: another laptop sitting beside me for now
22:46:12  <isaacs>bnoordhuis: i just posted a bug on this: http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=x64,label=osx/36/tapTestReport/test.tap-25/
22:46:37  <isaacs>gtk i'm not crazy, i guess, since it disappeared after i posted it
22:46:53  <isaacs>but still, sporadic failures! >_<
22:46:53  <bnoordhuis>i've not been able to reproduce it so far
22:46:54  <tjfontaine>heh
22:47:05  <isaacs>bnoordhuis: try making your cpu do some other stuff while it's running
22:47:07  <tjfontaine>isaacs: you're crazy, but for other reasons
22:47:32  <bnoordhuis>193 failures <- wut?
22:47:42  <tjfontaine>who what where?
22:47:43  <bnoordhuis>ah... EADDRINUSE
22:47:46  <isaacs>bnoordhuis: like, while ./node test/simple/test-child-process-fork-getconnections.js; do true; done and then in another tab build v8
22:47:50  <bnoordhuis>tjfontaine: http://jenkins.nodejs.org/job/nodejs-master/DESTCPU=x64,label=linux/36/tapTestReport/
22:48:27  <tjfontaine>oh I think because I was running full nightly at the same time
22:48:45  <tjfontaine>I need to twiddle port spacing further based on job type as well
22:48:50  <trevnorris>EADDRINUSE happens to me every time if I try to test/build two different things at once.
22:49:16  <isaacs>trevnorris: yeah, tjfontaine added customizable port setting for tests recently
22:49:37  <tjfontaine>trevnorris: if you set NODE_COMMON_PORT you can override it
22:49:38  <isaacs>bnoordhuis: weigh in on this. adding "listenerLength" to EventEmitter class. make it public?
22:49:49  <trevnorris>ah, cool
22:50:08  <isaacs>bnoordhuis: i'm split on it. it's useful, and should be documented, i think. i'll end up using it in my own modules, i'm sure.
22:50:32  <isaacs>bnoordhuis: otoh, API is "locked", and people raise holy hell when we add fields to EE
22:50:39  <bnoordhuis>exactly
22:50:48  <bnoordhuis>i don't think new fields are really an option at this time
22:50:59  <isaacs>bnoordhuis: are you saying, not even underscored?
22:51:14  <isaacs>hm. we can put it on the root events object.
22:51:17  <bnoordhuis>well no, because people use underscored properties themselves
22:51:17  <isaacs>or EventEmitter class
22:51:27  <isaacs>EventEmitter.listenerLength(emitter)
22:51:37  <bnoordhuis>yes, namespaced off somewhere safe
22:51:39  <isaacs>like how the Object class gets methods to do stuf
22:51:43  <isaacs>yeah, i like that.
22:51:44  <isaacs>thanks
22:52:00  <isaacs>trevnorris: can you move _listenerLength to the EventEmitter class, public and documented?
22:52:48  <isaacs>trevnorris: the docs should have a heading like ## Class Method: EventEmitter.listenerLength(emitter)
22:52:59  <isaacs>so the json parseamajig can know what it is
22:54:12  * isaacsback to reviewing other bits...
22:55:07  * mikealjoined
22:55:45  <isaacs>trevnorris: and, let's hope no one notices that it's a new API addition in a locked section, and starts demanding crazy bullshit in other places :)
22:56:10  <trevnorris>isaacs: lol
22:57:41  <nodejs-ci>Project nodejs-master » ia32,windows build #36:STILL FAILING in 18 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=windows/36/
22:58:08  <bnoordhuis>why is it getting added btw?
22:58:27  <trevnorris>bnoordhuis: because it's being used in high traffic areas, and splicing an array just to get it's length is crap
22:58:37  <nodejs-ci>Project nodejs-master » x64,windows build #36:STILL FAILING in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=windows/36/
22:58:58  <trevnorris>(e.g. right now it's using emitter.listeners('name').length)
22:59:12  <trevnorris>isaacs: oh, damn
22:59:17  <sblom>isaacs: Yeah--it can do backticks, but notice the "usebackq" option. "Hey, cmd, please be less quaint."
22:59:26  <trevnorris>isaacs: how's that going to work? we'll need to also name the event
22:59:40  <trevnorris>isaacs: so it'd have to be EventEmitter.listenerLength(emitter, event)
22:59:47  * mikealquit (Ping timeout: 252 seconds)
23:00:16  <isaacs>oh, yeah
23:00:18  <isaacs>that way :)
23:00:20  <isaacs>trevnorris: ^
23:00:35  <trevnorris>ok
23:00:53  <isaacs>also, listeners() can be more inline friendly by setting a ret var and then doing `return ret` once at the end.
23:01:12  <isaacs>trevnorris: because V8 smiles harder on single-return functions for reasons.
23:01:28  <trevnorris>coolio.
23:01:29  <bnoordhuis>listenerLength looks so ugly... numListeners, listenerCount, howManyListeners
23:01:41  <isaacs>though, you've replaced almost every call to listeners() with listenerLength() anyway :)
23:01:49  <bnoordhuis>maybe listenerCount, one character less
23:01:50  <isaacs>i like listenerCount
23:01:58  <isaacs>IT IS DECIDED!
23:01:58  <trevnorris>heh, ok
23:02:08  <trevnorris>whoa. that was a long one
23:02:14  <isaacs>wow... loudbot got kinda introspective there..
23:02:21  <isaacs>!twitlast
23:02:28  <isaacs>LOUDBOT: twitlast
23:02:40  <isaacs>hm. loudbot's twitter connection is fubar, i guess.
23:02:45  * hzquit
23:03:35  <sblom>LOUDBOT: who do you work for?
23:04:20  <isaacs>sblom: loudbot is ik's
23:04:25  <isaacs>sblom: /join ##turtles
23:04:43  <trevnorris>isaacs, bnoordhuis: final check, api will be: EventEmitter.listenerCount(emitter, event) ?
23:05:02  <bnoordhuis>trevnorris: a +1 from me
23:05:08  <isaacs>trevnorris: lgtm
23:05:18  <isaacs>that's quorum
23:05:19  <trevnorris>damn api locks. that's so long...
23:06:25  <isaacs>trevnorris: it's faster if you do var EE = require('events').EventEmitter
23:06:44  <isaacs>you know, like 90% of the time, we're just checking if there are any listeners or not.
23:07:01  <isaacs>what about EE.any(emitter, type)
23:07:10  <isaacs>returns !!emitter._events[type]
23:07:41  <trevnorris>would be useful
23:08:07  * slaskisquit (Quit: slaskis)
23:08:09  <trevnorris>while where here, why not EE.has(emitter, event, fn). ;-)
23:11:27  <isaacs>ok... maybe getting carried away
23:12:29  <trevnorris>isaacs: did you want me to switch EventEmitter to EE, or were you just saying it could be?
23:12:41  <isaacs>trevnorris: i always alias it that way in my peorgrams
23:12:53  <isaacs>trevnorris: var EE = require('events').EventEmitter;
23:13:37  <isaacs>ok, let's stick with listenerCount for now
23:13:50  <trevnorris>isaacs: ok. if you want that in core then i'm going to swap out every instance of EventEmitter for EE in lib/
23:14:03  <isaacs>these are normal arrays, not DOMCollectionListKajiggers, so it's not like getting the length is costly
23:14:08  <isaacs>trevnorris: no, thanks.
23:14:12  <trevnorris>heh ok
23:14:18  <isaacs>EventEmitter.listenerCount(emitter,type) is fine
23:14:27  <isaacs>avoids adding a field.
23:14:44  <isaacs>trevnorris: if you have to add a *new* reference to EventEmitter, sure, call it EE, that'sfine
23:14:52  <trevnorris>ok
23:16:37  <trevnorris>isaacs: ok, each commit was made to pass all tests, so may just take an extra few for those to run.
23:18:14  <isaacs>trevnorris: it's ok to add it on after the rest.
23:18:35  <isaacs>unless you really want to make it all pretty :)
23:20:37  <isaacs>trevnorris: i'm about halfway through. may want to hold off, in case you feel like fixing anything else all in one go
23:22:10  <trevnorris>isaacs: i've become a rebase master, and i am obsessive about my commit sets.
23:22:21  <isaacs>btw, this is why events.js is locked. because changes require such meticulous review.
23:22:28  <isaacs>it's frankly just a pain in the ass to change it.
23:22:36  <isaacs>not worth it unless it's really valuable (i believe this is, in this case)
23:23:20  <trevnorris>i totally understand. and wasn't going to submit the patch unless I could show perf improvement.
23:23:34  <isaacs>trevnorris: clever: https://github.com/trevnorris/node/commit/b8f69f1fbfebeceaccf25c6f1cfbd9031b8c736f
23:23:46  <isaacs>normally i'd object. but here it's worthwhile.
23:24:06  <isaacs>ie, we're actually testing if it's an array, so isArray is correcter, but meh. fast is better here.
23:24:34  <trevnorris>heh, thanks.
23:26:05  <sblom>trevnorris: I call that obsession with well-groomed commit sets "bonsai git". I have that disease.
23:26:47  <trevnorris>lol
23:26:49  <sblom>(as opposed to banzai)
23:26:54  <isaacs>https://github.com/trevnorris/node/commit/9015d9862c9373459b77bc07df30edd74ec31d5f <-- unnecessary
23:26:54  * piscisaureus_quit (Ping timeout: 272 seconds)
23:27:11  <isaacs>trevnorris: "warned" is a property on an internal property, so it doesn't have to be _hidden
23:27:35  <isaacs>trevnorris: the typeof type === "string" check is worthwhile, though
23:29:16  <isaacs>trevnorris: on "events: emit cleanup"
23:29:28  <isaacs>trevnorris: global lookups are not slow? that's why i put that there in the first place.
23:29:39  <isaacs>trevnorris: that was several versions of V8 ago, of course, back in 0.7
23:31:21  <trevnorris>isaacs: re: warned. i'll change that back
23:31:56  <trevnorris>and in that case, just ignore the last commit.
23:32:08  <trevnorris>popped that on on at the last moment.
23:32:09  <isaacs>trevnorris: yeah, same for ._listener
23:32:14  <isaacs>kewl
23:32:31  <isaacs>emitter._events is difference, since emitter is public
23:32:55  <trevnorris>isaacs: i'll double check the global lookup benchmarks. or I can just pop it back in. either way doesn't matter to me.
23:33:03  <isaacs>trevnorris: well, it's a net win, so meh
23:33:14  <isaacs>trevnorris: i'm going to run the http and net benchmarks as well, see what the diff is there.
23:33:57  <isaacs>trevnorris: so, another potential speedup would be to split up emit() into several small functions, with a single return
23:33:59  * loladirojoined
23:34:39  <trevnorris>isaacs: i actually played with that. it could only help if there was no call/apply
23:34:51  <isaacs>hm.
23:35:00  <isaacs>well, emit() itself wouldn't be inlined
23:35:04  <isaacs>but maybe some of the workerbees would
23:35:05  <isaacs>i dunny
23:35:08  <isaacs>*duno
23:35:21  <isaacs>crap, i gotta run. housecleaners coming in the next 30 minutes, i'll bbiab.
23:35:27  <trevnorris>coolio
23:35:43  <isaacs>trevnorris: there are a few comments inline in the code, as wel..
23:35:50  <isaacs>i'll land when i get back online
23:35:57  <isaacs>thanks!
23:36:09  <trevnorris>thank you
23:46:49  * bradleymeckjoined
23:55:30  * mikealjoined
23:55:49  <tjfontaine>what if MI6 said: libuv-master build #16 FAILURE smartos (4/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/16/
23:56:24  <trevnorris>bnoordhuis: isaacs said to use "## Class Method:", you think he meant "### Class Method:" ?
23:56:41  <bnoordhuis>trevnorris: oh, probably
23:56:50  <trevnorris>coolio. just wanted to double check. thanks
23:58:38  <isaacs>trevnorris: or whatever the heading level would be to put it underneath Class: EventEmitter
23:58:57  <trevnorris>isaacs: i'm just going off how it's used in the Buffer docs.
23:59:07  <isaacs>trevnorris: sure
23:59:07  <trevnorris>so yeah, that's it
23:59:18  <isaacs>i build these thigns so that i dont' have to remember how they work :)
23:59:28  <trevnorris>lol. and that's a good thing