00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:14  * mralephquit (Ping timeout: 255 seconds)
00:08:49  * loladirojoined
00:09:43  * dominictarrquit (Quit: dominictarr)
00:16:20  <tjfontaine>sblom: is there a more appropriate way to instantiate the vs command environment than simply "call vcvarsall.bat"?
00:16:56  * kazuponjoined
00:28:01  * loladiroquit (Quit: loladiro)
00:30:07  * qmx|awaychanged nick to qmx
00:33:38  * trevnorrisquit (Quit: Leaving)
00:35:09  * loladirojoined
00:41:07  * kazuponquit (Remote host closed the connection)
00:43:16  <tjfontaine> v8_base.vcxproj -> ..\..\..\..\build\Release\lib\v8_base.lib
00:43:17  <tjfontaine>Build step 'Execute Windows batch command' marked build as failure
00:43:32  <tjfontaine>thanks for the useful information there guys
00:43:37  <isaacs>oh man
00:44:03  <isaacs>this is gonna be such a righteous pull re.
00:44:04  <isaacs>*req
00:44:18  <isaacs>so little code, so much aggravation resolved.
00:44:32  <tjfontaine>those should make you feel the most triumphant
00:52:00  <isaacs>https://github.com/joyent/node/pull/4858
00:52:06  <isaacs>indutny: you around?
00:52:09  * qmxchanged nick to qmx|away
00:54:25  <tjfontaine>isaacs: first pass looks good, glad you used the unrefd timeout in the client
00:54:57  <TooTallNate>isaacs: love it
00:54:58  <TooTallNate>haha
00:55:18  * c4miloquit (Remote host closed the connection)
00:55:20  <isaacs>TooTallNate: oh! you're around. wanna review?
00:55:43  <isaacs>sblom: do you by chance know if this problem happens in windows as well?
00:59:47  <TooTallNate>isaacs: so it looks like, calling EnableDebugSignalHandler on the main thread instead of the signal thread, and then some updates to tests for api changes?
00:59:47  <tjfontaine>sblom, TooTallNate: if you can happen to tell me why this windows build is failing I'd appreciate it at as well :) http://jenkins.nodejs.org/job/nodejs-oneoff/31/console
01:00:00  <tjfontaine>TooTallNate: more or less, yes
01:00:20  <TooTallNate>why is this part necessary? https://github.com/joyent/node/pull/4858/files#L1R22
01:01:57  <isaacs>TooTallNate: yes.
01:02:05  <isaacs>(re summary, not re necessary, looking now)
01:02:34  <isaacs>TooTallNate: well... it appears to not be relevant at all.
01:02:43  <isaacs>TooTallNate: i just made the two debugger-repl fixtures match one another
01:02:52  <TooTallNate>oh ok
01:02:56  <isaacs>TooTallNate: the alternative is to remove it from the other one
01:03:14  <isaacs>TooTallNate: since the test never gets there, it doesn't make a difference, really
01:03:47  <isaacs>TooTallNate: note that the two tests are now actually the same code.
01:08:40  * kazuponjoined
01:13:37  <MI6>joyent/node: isaacs master * ec378aa : test: Fix debugger repl tests This makes the output of simple/test-debug (+2 more commits) - http://git.io/kMCiCQ
01:14:37  * kazuponquit (Remote host closed the connection)
01:23:45  <nodejs-ci>Project nodejs-master » x64,smartos build #11:STILL FAILING in 10 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/11/
01:25:58  <TooTallNate>#/home/jenkins/.jenkins/workspace/nodejs-master/DESTCPU/x64/label/smartos/test/simple/test-debugger-client.js:34
01:25:58  <TooTallNate># throw new Error('timeout');
01:26:24  <isaacs>aha
01:26:28  <isaacs>we're not setting the port number
01:26:37  <isaacs>so it's timing out tryingto connect to one that failed to start up
01:34:17  <nodejs-ci>Project nodejs-master » x64,linux build #11:STILL FAILING in 20 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/11/
01:34:27  <nodejs-ci>Project nodejs-master » ia32,linux build #11:STILL FAILING in 20 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/11/
01:34:30  <isaacs>TooTallNate: https://gist.github.com/isaacs/5044137 <-- review?
01:35:30  <TooTallNate>isaacs: lgtm
01:35:30  <MI6>joyent/node: isaacs master * 937662b : test: Use common.PORT to determine debugger port - http://git.io/hBwKwQ
01:35:30  <isaacs>thanks
01:35:32  <isaacs>let's see if this pases...
01:37:58  <isaacs>I'm moving net-unreach to test/internet/
01:38:17  <isaacs>it's not a valid test unless you're online anyway, and it fails spuriously on linux a lot.
01:39:30  <MI6>joyent/node: isaacs master * 1b870b6 : test: Move test-net-connect-timeout to test/internet It is not a valid t - http://git.io/Sh_Z7A
01:44:29  * abraxasjoined
01:44:50  <nodejs-ci>Project nodejs-master » ia32,smartos build #12:FAILURE in 9 min 20 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/12/
01:44:53  <nodejs-ci>Yippie, build fixed!
01:44:54  <nodejs-ci>Project nodejs-master » x64,smartos build #12:FIXED in 9 min 23 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/12/
01:46:00  * loladiroquit (Quit: loladiro)
01:46:06  <TooTallNate>nice isaacs
01:46:56  * mralephjoined
01:52:28  <isaacs>!!!!!
01:52:31  <isaacs>tjfontaine: ^^
01:52:44  <isaacs>let's see if linux is fixed now, to
01:53:33  <isaacs>hm. test-http-timeout showing addrinuse
01:53:48  <isaacs>>_< var port = 12345;
01:54:30  <MI6>joyent/node: isaacs master * 586e160 : test: Use common.PORT in simple/test-http-timeout - http://git.io/drZInA
01:54:51  * abraxasquit (Remote host closed the connection)
01:55:46  <nodejs-ci>Project nodejs-master » ia32,linux build #12:STILL FAILING in 20 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/12/
01:55:46  <nodejs-ci>Project nodejs-master » x64,linux build #12:STILL FAILING in 20 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/12/
01:57:23  * sblomquit (Ping timeout: 246 seconds)
01:58:01  <isaacs>13 is building now
01:59:41  * loladirojoined
02:03:46  <TooTallNate>isaacs: i kinda like this new testing stuff :D
02:03:50  <TooTallNate>who set that up?
02:03:52  <TooTallNate>tjfontaine?
02:05:06  <nodejs-ci>Yippie, build fixed!
02:05:06  <nodejs-ci>Project nodejs-master » ia32,smartos build #13:FIXED in 9 min 12 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/13/
02:05:12  <isaacs>\o/
02:05:23  <isaacs>TooTallNate: yeah
02:05:27  <isaacs>we gotta get that machine some more juice, though
02:05:33  <TooTallNate>hahahah
02:05:33  <TooTallNate>ya
02:05:35  <TooTallNate>9mins
02:08:16  <isaacs>sweet, both smartos's passed
02:08:26  <isaacs>linux still in progress
02:11:27  <TooTallNate>isaacs: is windows possible or no?
02:11:35  <TooTallNate>i guess OS X is a similar situation
02:11:38  <TooTallNate>licensing and all
02:12:05  * abraxasjoined
02:13:20  <isaacs>TooTallNate: windows is possible
02:13:23  <isaacs>but not yet wired up
02:13:44  <isaacs>if linux passes right now, i'm sure everything will go un-green tomorrow or whenever tjfontaine gets windows wired up :)
02:14:10  <TooTallNate>haha
02:14:13  <TooTallNate>that windows
02:14:20  <isaacs>crazy crazy windows :)
02:14:21  <TooTallNate>always making things un-green
02:15:25  <nodejs-ci>Project nodejs-master » x64,linux build #13:STILL FAILING in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/13/
02:15:26  <nodejs-ci>Project nodejs-master » ia32,linux build #13:STILL FAILING in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/13/
02:15:48  <isaacs>d'h
02:15:51  <isaacs>d'oh
02:16:30  <isaacs>hm. debugger-client dying with EPIPE
02:22:34  <isaacs>weird
02:31:05  * qmx|awaychanged nick to qmx
02:32:47  * loladiroquit (Quit: loladiro)
02:34:30  * loladirojoined
02:35:25  * loladiroquit (Client Quit)
02:45:51  <tjfontaine>hehe, the linux box is woefully underpowered, I didn't realize the vcpus were tied to memory size
02:50:38  <isaacs>tjfontaine: yeah, provision something bigger.
02:50:50  <isaacs>tjfontaine: i resized the smartos up to 8gb
02:50:54  <isaacs>but linux lacks that magic
02:52:05  <tjfontaine>ya, but luckily it's trivial to do linux configs
02:52:09  <tjfontaine>I'm pretty handy at that part
02:52:50  <isaacs>kewl
02:53:13  <isaacs>tjfontaine: you should put the jenkins config stuff in a git repo somewhere.
02:53:25  <isaacs>tjfontaine: i can create one on gh/joyent if you'd like
02:53:54  <TooTallNate>now what i wanna know is how hard it would be to hook node-gyp builds into this O.O
02:54:02  <tjfontaine>ya, that sounds like a plan, I have to look on disk and see what is important
02:54:28  <MI6>joyent/node: isaacs master * 8643397 : stream: Writables are not pipe()able This handles the fact that stream.W - http://git.io/kFwV1g
02:54:36  <isaacs>TooTallNate: yep.
02:55:31  <tjfontaine>ya actually you should have privileges enough to do it now, but lets act like you don't :P
02:56:17  <isaacs>tjfontaine: privileges enough to do what now?
02:56:25  <TooTallNate>ya, hahah
02:56:31  <isaacs>tjfontaine: oh, do you have permission ot create new joyent repos?
02:57:02  <tjfontaine>isaacs: no I mean, privileges on github determine permissions on jenkins
02:57:09  <tjfontaine>so TooTallNate could create jobs today if he wanted
02:57:14  <isaacs>oh, right!
02:57:17  <isaacs>nice
02:57:20  <isaacs>TooTallNate: get crackin!
02:57:23  <isaacs>:D
02:57:29  <tjfontaine>haha not just yet :P
02:57:35  * TooTallNatecodes
02:57:43  * TooTallNateactually, dinner
02:58:28  * isaacs&
03:04:20  * bradleymeckquit (Quit: bradleymeck)
03:12:18  * kazuponjoined
03:14:00  <nodejs-ci>Project nodejs-master » ia32,linux build #14:STILL FAILING in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/14/
03:14:04  <nodejs-ci>Project nodejs-master » x64,linux build #14:STILL FAILING in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/14/
03:15:33  * indexzeroquit (Quit: indexzero)
03:21:05  * mikealquit (Quit: Leaving.)
03:24:18  * c4milojoined
03:24:42  <nodejs-ci>Project nodejs-master » ia32,linux build #15:STILL FAILING in 5 min 7 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/15/
03:24:44  <nodejs-ci>Yippie, build fixed!
03:24:44  <nodejs-ci>Project nodejs-master » x64,linux build #15:FIXED in 5 min 9 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/15/
03:30:35  <tjfontaine>master is 3/4 green
03:31:07  <tjfontaine>isaacs: ^^ also recreated ubuntu with 8gb to get the 8 vcpus, now it completes faster than smartos
03:50:44  * brsonquit (Ping timeout: 248 seconds)
03:51:07  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:53:37  * c4miloquit (*.net *.split)
03:55:42  * c4milojoined
03:57:11  * bnoordhuisjoined
04:10:21  <tjfontaine>wb bnoordhuis
04:10:55  <bnoordhuis>tjfontaine: merci
04:35:58  * trevnorrisjoined
04:43:54  * CoverSlidequit (Ping timeout: 276 seconds)
04:43:55  * piscisaureus_joined
04:53:07  * abraxasquit (Remote host closed the connection)
04:54:38  <bnoordhuis>piscisaureus_: mogge bertje
04:54:40  * piscisaureus_quit (Ping timeout: 256 seconds)
04:54:49  <tjfontaine>bnoordhuis: you scared him off
04:54:50  <bnoordhuis>and he's gone again :(
04:56:06  <tjfontaine>clearly afraid you were about to cause him work
04:56:52  <bnoordhuis>he's very resilient and resistent when it comes to that though
04:57:17  <tjfontaine>having spent the afternoon with windows, I can see how that is
04:57:34  <tjfontaine>on my worst days with osx, I would rather have it than windows
04:58:12  <bnoordhuis>i know your pain. to a programmer, windows is such a limited/constrained environment
04:58:38  * TooTallNatejoined
04:59:15  <bnoordhuis>it also doesn't have that comfy, lived in feeling of a unix terminal
04:59:22  <bnoordhuis>that might just be me though :)
04:59:49  <tjfontaine>no, absolutely how I felt
04:59:58  * CoverSlidejoined
05:00:03  <tjfontaine>at least these days rdp doesn't make me want to cut wrists
05:00:40  <tjfontaine>though trying to get a clean build of node on windows was certainly making me angsty
05:01:32  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-oneoff/31/console
05:01:38  * kazuponquit (Read error: Connection reset by peer)
05:02:06  * kazuponjoined
05:03:51  <bnoordhuis>is that msbuild? it's so chatty
05:03:51  * abraxasjoined
05:04:29  <tjfontaine>I turned it up so I could see wtf was going on
05:06:25  * loladirojoined
05:10:02  * loladiroquit (Client Quit)
05:10:15  * sblomjoined
05:10:37  <sblom>tjfontaine: I'm trying to figure out that build error.
05:10:40  <sblom>That's seriously baffling.
05:10:59  <sblom>It's like masm doesn't believe the .asm file when it says "please compile this for 686"
05:11:09  <sblom>cpuid has existed since, what, 386?
05:11:59  <bnoordhuis>pentium 1, i think
05:13:03  <bnoordhuis>at least, the 486 i had in the 90s didn't have a CPUID instruction
05:13:27  <sblom>bnoordhuis: Okay. Still--this should work. We're in the twentyteens now! :)
05:14:40  * c4miloquit (Remote host closed the connection)
05:16:56  <sblom>also to your earlier question, tjfontaine, "call vcvarsall.bat" is the right way to get the VS tools in your path.
05:19:05  * loladirojoined
05:25:14  <bnoordhuis>"translator does not define conversion for member" when i try to use curpsinfo->ps_args with dtrace
05:25:24  <bnoordhuis>i'm probably missing something obvious but what?
05:26:05  * qmxchanged nick to qmx|away
05:26:05  * loladiroquit (Quit: loladiro)
05:30:06  <sblom>bnoordhuis: curpsinfo->pr_psargs instead?
05:30:15  <sblom>(I think ps_args is misspelled.)
05:32:30  * benoitcquit (Excess Flood)
05:33:11  <bnoordhuis>sblom: ah sorry, i mistyped it yes
05:34:31  <sblom>bnoordhuis: I'm not clear if that fixed it for you.
05:34:45  * abraxasquit (Remote host closed the connection)
05:36:07  <bnoordhuis>it did. now to turn pr_psargs into something useful
05:36:15  * loladirojoined
05:36:30  <bnoordhuis>apparently pr_fname and pr_psargs contain the same thing on os x
05:37:19  * stagasjoined
05:37:38  * benoitcjoined
05:38:33  <sblom>tjfontaine: any way I can get access to your Jenkins Windows agent? I'm stumped by this MASM failure, but might be able to learn more if I could poke around just a bit.
05:40:37  <tjfontaine>sblom: sure I can arrange that
05:41:01  <sblom>tjfontaine: Actually, I just managed to repro the failure on my machine by syncing the exact rev that Jenkins was building.
05:41:08  <sblom>I bet I can figure out our problem from here.
05:41:14  <tjfontaine>ah ok
05:41:32  <sblom>Anyone know without looking if we updated deps/openssl recently?
05:41:45  <bnoordhuis>sblom: we did
05:42:13  <tjfontaine>so the asm files need regen'd don't they?
05:43:07  <sblom>tjfontaine: I'm not sure if they're written or generated, but the asm file is definitely the culprit. I see that this version is asking to use the 486 instruction set.
05:43:38  <tjfontaine>I'm not sure how bert did it before, I thought he wrote a script to generate them
05:44:02  <sblom>Okay. I'll see if I can do some archaeology to figure this out.
05:44:14  <sblom>If not, we'll hunt down piscisaureus at some point.
05:44:38  <tjfontaine>nod
05:50:53  <tjfontaine>bnoordhuis: is your debian package branch still valid? I'm toying with the idea of along with the binary tarball nightly I'll include .debs and throwing together a repo
05:59:15  * bradleymeckjoined
06:03:08  <bnoordhuis>tjfontaine: mostly valid, probably
06:03:21  <bnoordhuis>a deb would be good
06:03:42  <bnoordhuis>i can provide a .spec file too if you want, i have one that's mostly finished
06:03:43  <tjfontaine>ya, in for a penny
06:04:34  <tjfontaine>.spec might be nice, I'd have to dust off my -ba skills
06:05:19  <bnoordhuis>i'll finish it up today and push it
06:05:35  <tjfontaine>haven't built an rpm since I switched all those many years ago from mandrake to debian :)
06:05:59  <bnoordhuis>oh, it's easy - yum install fedora-packager && rpmbuild -ba
06:06:09  <tjfontaine>and frankly from my experiences with yum, I miss urpmi
06:06:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
06:07:16  * wolfeidauquit (Read error: Connection reset by peer)
06:07:28  * wolfeidaujoined
06:16:16  * wolfeidauquit (Read error: Connection reset by peer)
06:16:32  * wolfeidaujoined
06:22:31  * mikealjoined
06:23:08  * wolfeidauquit (Remote host closed the connection)
06:27:36  <sblom>tjfontaine: Okay--to regen the asm files, it's as simple as running 'make' in deps/openssl/asm. However, running it on my Mac I get two perl errors and apparently the wrong version of sed.
06:27:53  <sblom>I'm guessing that GNU sed will be happier than BSD sed.
06:28:38  <sblom>I'm looking into the significance of the perl errors.
06:33:02  <sblom>perl errors are warnings--we're fine. Now just to figure out if it'll be bad for me to drop the two unrecognized sed flags.
06:37:05  <sblom>Wow--BSD sed is really stupid compared to GNU sed. I guess I shouldn't be surprised.
06:41:56  <bnoordhuis>sblom: if it's a lot of trouble, you could just remove it - it's only there to remove superfluous whitespace
06:43:38  <sblom>Nah--macports had gsed lying around.
06:44:26  <indutny>morning
06:44:55  <indutny>I had same problem and fixed it by installing gnu sed
06:45:02  <indutny>and replacing this fucking retarded alternative
06:47:29  * bnoordhuisquit (Ping timeout: 255 seconds)
06:55:27  * wolfeidaujoined
07:03:46  <trevnorris>nextTick domain regression fixed.
07:03:52  <trevnorris>i hate domains so freakin much.
07:10:01  <sblom>This should fix Windows build: https://github.com/joyent/node/pull/4860
07:11:03  <sblom>(It's a super-easy review if anyone's motivated.)
07:23:39  <trevnorris>sblom: well, i'm not a windows guy, and i don't know asm but what the hell. lgtm =)
07:26:34  <MI6>joyent/node: Scott Blomquist master * f054fec : openssl: regenerate asm files for openssl 1.0.1e - http://git.io/acXgPw
07:31:15  <nodejs-ci>Yippie, build fixed!
07:31:16  <nodejs-ci>Project nodejs-master » ia32,linux build #16:FIXED in 4 min 34 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/16/
07:31:34  * `3rdEdenjoined
07:45:13  * abraxasjoined
07:53:17  * bnoordhuisjoined
07:54:17  * kazuponquit (Remote host closed the connection)
07:56:23  * kazuponjoined
07:58:15  * bnoordhuisquit (Ping timeout: 276 seconds)
08:00:48  * rendarjoined
08:08:55  * loladiroquit (Quit: loladiro)
08:15:18  * loladirojoined
08:22:33  * AvianFluquit (Remote host closed the connection)
08:22:37  * pooyaquit (Quit: pooya)
08:27:06  * sblomquit (Ping timeout: 264 seconds)
08:33:38  * kazuponquit (Remote host closed the connection)
08:36:12  * csaohjoined
08:45:17  * trevnorrisquit (Quit: Leaving)
08:51:15  * kazuponjoined
09:05:14  * kazuponquit (Remote host closed the connection)
09:10:56  * bradleymeckquit (Quit: bradleymeck)
09:27:39  * loladiroquit (Quit: loladiro)
09:33:55  * bradleymeckjoined
09:34:36  * loladirojoined
09:36:57  * loladiroquit (Client Quit)
10:23:07  * sblomjoined
10:27:38  * sblomquit (Ping timeout: 255 seconds)
11:12:22  * bradleymeckquit (Quit: bradleymeck)
11:19:50  * `3rdEdenchanged nick to `3E|lunch
11:22:57  * abraxasquit (Remote host closed the connection)
11:40:59  * csaohquit (Quit: csaoh)
11:44:08  * benoitcquit (Excess Flood)
11:46:39  * `3E|lunchchanged nick to `3rdEden
11:52:49  * benoitcjoined
11:53:15  * csaohjoined
12:03:30  * benoitcquit (Excess Flood)
12:09:18  * benoitcjoined
12:23:38  * sblomjoined
12:28:14  * sblomquit (Ping timeout: 255 seconds)
13:00:48  * qmx|awaychanged nick to qmx
13:23:37  * Raltquit (Read error: Operation timed out)
13:30:15  * Raltjoined
13:33:06  * benoitcquit (Excess Flood)
13:35:51  * benoitcjoined
13:50:23  * hzjoined
14:24:44  * benoitcquit (Excess Flood)
14:26:50  * benoitcjoined
14:32:09  * mikealquit (Quit: Leaving.)
14:51:28  * AvianFlujoined
15:04:16  * rendarquit
15:29:01  * bradleymeckjoined
15:35:00  * loladirojoined
15:44:00  * c4milojoined
15:53:36  * `3rdEdenquit (Remote host closed the connection)
15:58:36  * loladiroquit (Quit: loladiro)
16:05:22  * c4miloquit (Remote host closed the connection)
16:12:57  * sblomjoined
16:14:52  * sblomquit (Client Quit)
16:17:36  * pooyajoined
16:19:55  * c4milojoined
16:20:51  * pooyaquit (Client Quit)
16:42:47  * mikealjoined
16:44:23  * pooyajoined
16:50:58  * rendarjoined
16:51:21  * bradleymeckquit (Quit: bradleymeck)
16:52:00  * loladirojoined
16:56:33  * pooyaquit (Ping timeout: 248 seconds)
16:56:41  <rphillips>having an issue writing detach process support in luvit for windows
16:56:48  <rphillips>it's working on linux ok
16:56:59  * pooyajoined
16:57:13  <rphillips>it doesn't look like the process gets spawned, but I'm getting a pid back
16:57:49  * qmxchanged nick to qmx|lunch
17:03:00  * loladiroquit (Quit: loladiro)
17:13:01  <tjfontaine>aww no sblom, I scared him away
17:18:44  * bradleymeckjoined
17:19:27  * mikealquit (Quit: Leaving.)
17:25:50  * trevnorrisjoined
17:26:56  <trevnorris>isaacs: hold off w/ pr 4859 for a few. need to double check something.
17:28:26  <tjfontaine>things to do before trying to do the windows build, verify what everyone else is actually using to build it
17:28:49  <tjfontaine>https://github.com/joyent/node/issues/4242 apparently I'm hitting that as well
17:29:28  <tjfontaine>chromium lists 2010, I have a feeling I'm just being too ambitious
17:30:56  <rendar>tjfontaine: why too ambitious?
17:31:14  <tjfontaine>cause I started with express 2012 :P
17:31:37  <rendar>:P
17:41:15  * c4miloquit (Remote host closed the connection)
17:45:38  * AvianFluquit (Remote host closed the connection)
17:45:48  * loladirojoined
17:45:55  <trevnorris>isaacs: ping
17:47:21  * bradleymeckquit (Quit: bradleymeck)
17:47:47  * pooyaquit (Quit: pooya)
17:50:47  * c4milojoined
17:51:24  * mikealjoined
17:53:23  * bnoordhuisjoined
17:59:17  * loladiroquit (Quit: loladiro)
17:59:23  <tjfontaine>bnoordhuis: we should tie in mi6 to some arduino shocking system, so we can tell bert to get on irc
17:59:47  <bnoordhuis>hah, the windows build is broken?
18:00:47  <tjfontaine>only really for 2012
18:01:19  * sgallaghjoined
18:01:21  <tjfontaine>I've tried a few incantations, but I'm ready to rip and use vs2010 I guess
18:01:40  <tjfontaine>since that's what the consensus build env is atm
18:01:54  * dapquit (Read error: Connection reset by peer)
18:02:00  * dap1joined
18:02:05  <bnoordhuis>i think both bert and isaac build with 2010 so yes, do that
18:02:37  * bradleymeckjoined
18:03:48  <tjfontaine>lets see if it takes all the extra crap with it
18:04:04  * csaohquit (Quit: csaoh)
18:11:40  * loladirojoined
18:16:24  <tjfontaine>bnoordhuis: doh, you ask me to check that *after* I uninstall 2012? :P
18:20:59  * pooyajoined
18:21:23  * loladiroquit (Quit: loladiro)
18:23:00  * AvianFlujoined
18:24:30  * TooTallNatejoined
18:25:54  * qmx|lunchchanged nick to qmx
18:27:30  <MI6>joyent/libuv: Marc Schlaich master * 85124d7 : build, windows: allow override of python executable Fixes #723. - http://git.io/qpmhRQ
18:28:48  <nodejs-ci>Project libuv-v0.8 » linux build #2:STILL FAILING in 1 min 10 sec: http://jenkins.nodejs.org/job/libuv-v0.8/./label=linux/2/
18:28:54  <nodejs-ci>Project libuv-master » linux build #5:STILL FAILING in 1 min 17 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/5/
18:29:22  <tjfontaine>it should really say "still failing tests" I wonder if I can convince it of that
18:29:24  <nodejs-ci>Project libuv-v0.8 » smartos build #2:STILL FAILING in 1 min 47 sec: http://jenkins.nodejs.org/job/libuv-v0.8/./label=smartos/2/
18:29:43  <nodejs-ci>Project libuv-master » smartos build #5:STILL FAILING in 2 min 5 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/5/
18:33:10  <nodejs-ci>Project libuv-master » smartos build #6:STILL FAILING in 1 min 51 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/6/
18:34:24  <nodejs-ci>Project libuv-master » linux build #6:STILL FAILING in 3 min 5 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/6/
18:35:08  <tjfontaine>bnoordhuis: I suppose the platform test is always failing so that you can see the system info?
18:38:14  <trevnorris>you guys think we could defer to the spinner after Module._load?
18:39:51  <trevnorris>nope. nm.
18:45:36  * isaacskickin beehives
18:46:02  <isaacs>trevnorris: pong
18:46:22  <tjfontaine>sigh, LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt [g:\jenkins\workspace\nodejs-oneoff\node.vcxproj]
18:46:59  <tjfontaine>ha ha http://stackoverflow.com/questions/10888391/link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-invalid-or-c
18:47:17  <trevnorris>isaacs: the fix i posted for the domain regression is a hack for a hack (needing to run process.nextTick(Module.runMain)). any chance you know the root cause of that issue?
18:47:38  <isaacs>trevnorris: of which issue?
18:47:45  <tjfontaine>"I solved this problem eventually by doing a full uninstall of VS2012 RC, followed by a full uninstall of VS2010, then a reinstall from scratch of VS2010." :<
18:48:01  <trevnorris>isaacs: 4856
18:48:03  <isaacs>trevnorris: the reason we nextTick the runMain is to set up error handling, i think
18:50:03  * bradleymeckquit (Ping timeout: 260 seconds)
18:50:10  <trevnorris>isaacs: yeah. what I don't understand is why error handling doesn't kick in until after the current tick.
18:50:48  * bradleymeckjoined
18:51:00  * bradleymeckquit (Remote host closed the connection)
18:51:23  * bradleymeckjoined
18:52:12  <isaacs>hm. i guess there isn't a chance for the uncaughtException to get attached or something...
18:52:14  <isaacs>digging into this
18:56:00  * mikealquit (Quit: Leaving.)
19:00:43  <isaacs>trevnorris: ah, i see. it's because when there's a throw in the first tick of setting up the process object, we don't call process._fatalException.
19:01:04  <isaacs>what we ought to do is check if it's empty, and ReportException if not, or call process._fatalException() if it is, and ReportException if that throws.
19:01:07  <isaacs>pr coming up
19:01:16  <trevnorris>awesome. thanks much.
19:02:13  <isaacs>bnoordhuis: do you know anything about the different exit codes we use in node.cc for error exits?
19:05:05  <isaacs>hm. seems like they're just there so we know which exit(n) got hit.
19:05:13  <isaacs>at least according to unix, no special meanings ot any of them
19:07:21  <bnoordhuis>unless > 127, that usually indicates termination by signal
19:07:37  <bnoordhuis>or rather, can
19:07:54  <bnoordhuis>nothing stopping you from calling exit(128) of course
19:09:08  <isaacs>right
19:10:37  * mikealjoined
19:11:25  <isaacs>bnoordhuis: any objection to making all the exit() calls something in the 3+ range in src/node.cc so that we can know where an exit came from, in theory at least?
19:12:19  <isaacs>bnoordhuis: i'm not super strongly pro-that, but i just did it, and it made this error 100x easier to find.
19:12:32  * `3rdEdenjoined
19:12:32  <isaacs>i guess bash uses 2 for stuff, and 1 is just a generic catch-all
19:12:32  <isaacs>we could say that 3-13 are hte error exit()s in src/node.cc
19:14:22  * brsonjoined
19:14:23  <bnoordhuis>isaacs: and then what? i mean, what does the exit code signify?
19:15:19  * bsnotequit
19:15:24  <bnoordhuis>or is it to identify the line where the exit() statement lives
19:17:46  <isaacs>right
19:17:53  <isaacs>so i can do echo $? and know which exit it's actually hitting
19:17:57  <isaacs>because there are a whole bunch of them
19:18:21  <bnoordhuis>well, sure i guess
19:18:33  <bnoordhuis>if it makes your life easier, go for it
19:21:23  <bnoordhuis>why is the load on my MBA over 1.10 while htop says all cpus are idle?
19:24:27  <isaacs>bnoordhuis: probably because htop is lying to you./
19:24:31  <isaacs>bnoordhuis: that would be my guess.
19:26:01  <bnoordhuis>i suspect that's the case. dtrace doesn't show up much either though
19:27:28  <tjfontaine>well the gui tools tend to lie more than the cli
19:31:12  <bnoordhuis>it was a couple of node debugger processes >:(
19:34:08  <MI6>joyent/node: isaacs reviewme * caa355c : core: Remove the nextTick for running the main file Not necessary, since (+1 more commits) - http://git.io/SHjBCQ
19:34:20  <isaacs>anyone care to review that? ^
19:34:33  <tjfontaine>This comparison is big! We're only showing the most recent 250 commits
19:35:01  <isaacs>weird....
19:35:15  <isaacs>https://github.com/joyent/node/compare/reviewme
19:35:36  <tjfontaine>git.io race I'm sure
19:36:18  <isaacs>tjfontaine: could have confused it by pushign to a branch that was already a thing elsewhere
19:36:33  <tjfontaine>possibly
19:36:47  <isaacs>tjfontaine: looks like it's trying to compare the new reviewme to where it was previously, which was way way in the past.
19:36:50  * isaacsoff to yoga
19:37:01  <trevnorris>isaacs: if this fixes the domain issue, might want to add another commit (e.g. https://github.com/joyent/node/pull/4859/files, test-domain.js)
19:39:52  <isaacs>trevnorris: yeah, i guess i could just pull in that test and fix it while i'm in there.
19:40:36  <trevnorris>isaacs: the dude that filed the bug also made a pr (4857), but the test isn't complete. just fyi.
19:42:28  <trevnorris>isaacs: but thanks for taking a look. simple fix, but don't think i would have caught that.
19:42:38  * mikealquit (Quit: Leaving.)
19:46:59  <isaacs>hm... this breaks a few other tests, it seems.
19:47:16  <isaacs>i'll look into that in a few hours.
19:47:21  <trevnorris>=P bugger.
19:51:12  * isaacs&
19:51:21  <trevnorris>isaacs: for test-cluster-... it looks like the process is supposed to die in that case. but doesn't uncaughtexception keep the process alive?
20:02:09  * qmxchanged nick to qmx|errands
20:04:52  <trevnorris>isaacs: oh, whoops. nm. it's because you changed the exit code. nothing big.
20:07:13  <trevnorris>isaacs: "test-cluster-master-error" : "(code === 1)" -> "(code === 8)"
20:07:38  * sgallaghquit (Ping timeout: 252 seconds)
20:09:03  <indutny>evening
20:11:32  <trevnorris>isaacs: "test-cluster-master-error" : "var MAGIC_EXIT_CODE = 42;" -> "var MAGIC_EXIT_CODE = 11;"
20:13:04  * mikealjoined
20:13:40  * tellnesquit (Excess Flood)
20:14:07  <trevnorris>isaacs: also, the change seems to be allowing some output to get past 'make test' and reach the console.
20:17:18  <trevnorris>isaacs: specifically "test-domain-nested" and "test-exception-handler2"
20:22:05  * sgallaghjoined
20:22:44  * mikealquit (Ping timeout: 248 seconds)
20:23:04  <trevnorris>isaacs: hm... the last one is "test-exception-handler2". basically what's happening is that any setTimeout's set to run < 6ms will run before nextTick.
20:40:16  <trevnorris>bnoordhuis: with the change isaacs made, there's a sorta-race condition between timers set to run under 6ms and nextTicks that run from the spinner.
20:40:28  * mikealjoined
20:41:03  * `3rdEdenquit (Remote host closed the connection)
20:42:01  <trevnorris>basically uv_timer_start will run OnTimeout before the spinner has a chance to run _tickFromSpinner and run through the nextTick callbacks.
20:42:10  * bradleymeckquit (Quit: bradleymeck)
20:42:47  * loladirojoined
20:48:31  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:48:34  <saghul>Hum, the normal makefile doesn't seem to delete the object files when doing make clean, is this intentional somehow?
20:49:13  <tjfontaine>for libuv? are they the pic versions?
20:50:48  <bnoordhuis>trevnorris: is that bad?
20:51:13  <saghul>tjfontaine yes, for libuv, no, I think they are not the pic versions since I'm compiling the static version
20:51:45  <trevnorris>bnoordhuis: it's just causing "test-next-tick-ordering" to fail. didn't know if it was a problem or not.
20:53:37  <trevnorris>bnoordhuis: i don't know much about uv internals, but just noticed that with the changes an N number of uv_timer_start's w/ timeout < 6ms will cause them to run before the spinner is allowed to fire.
20:54:41  <trevnorris>even though _needTickCallback() was run before any of the setTimout's were run.
20:55:25  * brsonquit (Quit: leaving)
21:00:48  * qmx|errandschanged nick to qmx
21:02:23  * bradleymeckjoined
21:09:20  * nodejs-ciquit
21:09:53  <MI6>joyent/libuv: Ben Noordhuis master * cdf69db : build: add distclean target to out-of-tree builds (+4 more commits) - http://git.io/reFNeQ
21:09:56  * nodejs-cijoined
21:11:46  <bnoordhuis>saghul: lies!
21:11:54  <nodejs-ci>Project libuv-master » smartos build #7:STILL FAILING in 1 min 56 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/7/
21:12:09  <saghul>bnoordhuis heh, thanks man!
21:12:35  <tjfontaine>I just use `git clean -fdX` :P
21:13:08  <nodejs-ci>Project libuv-master » linux build #7:STILL FAILING in 3 min 10 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/7/
21:13:51  <bnoordhuis>some interesting test failures there...
21:14:10  <tjfontaine>did you see my question before about the platform test?
21:14:33  <bnoordhuis>no. what was it?
21:14:53  <tjfontaine>platform_output always fails so that way you can see info about the system?
21:15:09  <bnoordhuis>oh, i see it now :)
21:15:11  <bnoordhuis>but thanks
21:15:27  <bnoordhuis>i don't think it actually fails, it just always prints
21:15:47  <tjfontaine>hm
21:16:41  <bnoordhuis>$ (out/Debug/run-tests platform_output platform_output ; echo $?) | tail -1
21:16:41  <bnoordhuis>0
21:16:49  <tjfontaine>ahh
21:17:00  <tjfontaine>if (status != 0 || task->show_output) {
21:17:19  <tjfontaine>I put the `not ok` after that
21:17:56  <tjfontaine>ya this needs tweaked
21:17:58  <bnoordhuis>right, so if (tap_output && status != 0)
21:18:21  <tjfontaine>yup
21:18:32  <tjfontaine>do mind doing that?
21:18:37  <tjfontaine>or shall I make a pr
21:18:44  <bnoordhuis>nah, one-liner
21:18:45  * bradleymeckquit (Quit: bradleymeck)
21:19:12  <tjfontaine>k
21:19:59  <trevnorris>bnoordhuis: would you consider that a non-issue, and just change the test to match the new output?
21:21:33  <MI6>joyent/libuv: Ben Noordhuis master * 1821bba : test: fix tap output check Only report as an error when status != 0. St - http://git.io/t77_hA
21:22:31  <bnoordhuis>trevnorris: no. next-tick-ordering is fairly crucial
21:22:33  <bnoordhuis>if our test fails, people's code will too probably
21:24:23  <trevnorris>bnoordhuis: well, it's currently an issue.
21:24:29  <trevnorris>we just didn't notice it until now.
21:24:49  <bnoordhuis>trevnorris: then i suggest you fix it :)
21:24:51  <trevnorris>bnoordhuis: https://gist.github.com/trevnorris/5051872
21:24:53  <bnoordhuis>or someone at least
21:25:24  * TooTallNatejoined
21:25:27  <bnoordhuis>trevnorris: can you open an issue if there isn't already one?
21:25:46  <trevnorris>bnoordhuis: yeah. would this be a node or uv issue?
21:25:52  <bnoordhuis>node
21:25:55  <trevnorris>ok
21:26:04  <nodejs-ci>Project libuv-master » smartos build #8:STILL FAILING in 4 min 25 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/8/
21:26:04  <bnoordhuis>libuv is like honey badger
21:26:07  <bnoordhuis>honey badger doesn't care
21:26:54  <tjfontaine>bnoordhuis: so I'm going to make a pr, we did miss some semantics there
21:27:04  * sgallaghquit (Remote host closed the connection)
21:28:19  <trevnorris>bnoordhuis: ok, so do timers and the spinner come off uv__run_timers? i'm not sure how that sequencing works internally.
21:34:50  <trevnorris>bnoordhuis: here ya go: GH-4866
21:39:51  <bnoordhuis>trevnorris: look for uv_run in deps/uv/src/unix/core.c
21:40:44  <trevnorris>bnoordhuis: yeah. uv__run_timers runs before uv__run_idle. i assume setTimeout is tied to run_timers and the spinner to run_idle.
21:40:45  * wolfeidauquit (Remote host closed the connection)
21:40:47  <benoitc>how does libuv close the process? which signal is sent?
21:40:58  <benoitc>+ to the child
21:45:07  <trevnorris>bnoordhuis: so the timers are always processed before idle's. what i'm having a hard time seeing is why small "timeout" values cause OnTimeout to run before Spin.
21:45:22  <tjfontaine>bnoordhuis: https://github.com/tjfontaine/libuv/commit/75aabe433a4341498249d45a8cc20def23e9d93b acceptable?
21:45:31  <tjfontaine>trevnorris: have you seen the pretty flow chart?
21:45:40  <trevnorris>?
21:46:06  <nodejs-ci>Project libuv-master » linux build #8:STILL FAILING in 24 min: http://jenkins.nodejs.org/job/libuv-master/./label=linux/8/
21:46:36  <tjfontaine>trevnorris: https://github.com/joyent/node/pull/3872#issuecomment-7804775
21:46:45  <trevnorris>benoitc: have you read through http://nikhilm.github.com/uvbook/processes.html
21:48:10  <trevnorris>tjfontaine: yeah, so timers are prepared before idle's. get that. so is it that processing idle's takes longer than the ~6ms the timer is set to execute?
21:49:08  <bnoordhuis>tjfontaine: landed with a minor simplification
21:49:10  <MI6>joyent/libuv: Timothy J Fontaine master * 49d2ae3 : test: fix tap output even when ok but have output - http://git.io/Iuj6_Q
21:49:17  <trevnorris>tjfontaine: basically, in GH-4866 i'd expect nextTick to always fire first. but when coming off the spinner it doesn't.
21:49:57  <trevnorris>what needs to happen is having nextTick call _tickCallback directly. that's a change i've been trying to make, but unsuccessfully so far.
21:50:40  <tjfontaine>bnoordhuis: wasn't sure where the nesting styles started and ended :)
21:51:07  <nodejs-ci>Project libuv-master » smartos build #9:STILL FAILING in 1 min 53 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/9/
21:52:17  <tjfontaine>I have investigated some of those smartos failures, fs_event_watch_dir it's actually seeing a UV_CHANGE, and process_title is a noop
21:52:23  <nodejs-ci>Project libuv-master » linux build #9:STILL FAILING in 3 min 9 sec: http://jenkins.nodejs.org/job/libuv-master/./label=linux/9/
21:53:04  * sblomjoined
21:55:48  <bnoordhuis>tjfontaine: flat code is usually better but simple predicates are better still
21:56:02  <tjfontaine>bnoordhuis: sure
21:56:22  <sblom>tjfontaine: I see that you have the Windows build working on Jenkins now. What was still broken after the OpenSSL asm fix?
21:56:34  <tjfontaine>sblom: don't be mistaken, it's still broken :)
21:56:38  <tjfontaine>just in different ways
21:56:43  <sblom>tjfontaine: Okay--anything I can help with?
21:56:48  <tjfontaine>well
21:58:14  <sblom>I see now that the most recent build has a gray ball, not a blue one.
21:58:19  <tjfontaine>sblom: http://jenkins.nodejs.org/job/nodejs-oneoff/37/console is the error I've been getting most recently, according to the stack overflow page about it, we're in compliance with the gyp settings
21:58:42  <tjfontaine>sblom: ya I've been futzing with other things, trying to learn how jenkins executes batch
21:59:13  <tjfontaine>sblom: I was hoping to do the vcvarsall before I do vcbuild (or msbuild) but I haven't found the right incantation
22:00:31  <tjfontaine>for now before I launch the jenkins slave I run the vcvarsall
22:04:03  * qmxchanged nick to qmx|away
22:05:11  * wolfeidaujoined
22:05:44  <sblom>tjfontaine: can you give me privs on the nodejs-oneoff project config on Jenkins? I've signed in with my github user, so Jenkins should recognize my account.
22:06:12  <tjfontaine>silly github plugin, yes moment
22:06:16  <sblom>(I won't change anything without involving you--I just want to look at how things are configured to give me the best chance possible of reproducing locally.)
22:06:54  <tjfontaine>ok that should be set now
22:08:31  <tjfontaine>I had done /t:Build /config:Release in the msbuild this last time through though I let it pick
22:13:32  * loladiroquit (Quit: loladiro)
22:16:29  <bnoordhuis>trevnorris: ping
22:16:59  <trevnorris>bnoordhuis: sup? i think i understand, and even have a fix. it just has a single strange side effect on a test.
22:17:44  <bnoordhuis>trevnorris: you were saying the next-tick test is failing?
22:18:06  <trevnorris>yeah. with the change that isaacs made to fix another issue. =P
22:18:40  <trevnorris>it's basically the test case in GH-4866
22:18:45  <isaacs>trevnorris, bnoordhuis: I'm going to make the domain/next-tick thing work.
22:18:48  <isaacs>i'm almost done with it
22:18:52  <isaacs>not to worry.
22:18:57  <bnoordhuis>okay /me goes back to idling
22:19:03  <isaacs>also, it removes a FIXME that's about a year old.
22:19:16  <isaacs>bnoordhuis: wanna look into that openssl RSA stale error thing?
22:19:21  <isaacs>bnoordhuis: people are pinging me about that.
22:19:30  <bnoordhuis>isaacs: seen the patch?
22:19:43  <trevnorris>isaacs: have you read GH-4866? i'm curious how you plan on handling that case w/ your fix.
22:19:43  <bnoordhuis>if not, check your github email :)
22:19:43  <isaacs>um... no, did you fix it when i wasn't looking?
22:20:26  <trevnorris>i guess your change has nothing to do with that problem, but it's what alerted me to it.
22:20:40  <bnoordhuis>i pasted a patch that fixes it but it slowed down the tls benchmarks a little on my mba
22:21:18  * bnoordhuischecks on a real OS
22:21:29  <tjfontaine>heh
22:21:58  <CoverSlide>Haiku?
22:22:06  <bnoordhuis>no, freedos
22:22:19  <tjfontaine>CBM
22:22:21  <tjfontaine>er CPM
22:22:28  <bnoordhuis>also, node's plan9 port is coming along nicely
22:22:42  <CoverSlide>sweet!
22:22:44  <tjfontaine>I'm starting to wrry that it's real
22:22:57  <isaacs>bnoordhuis: slightly regressing bench-tls is fine.
22:23:02  * loladirojoined
22:23:04  <isaacs>bnoordhuis: those benchmarks are like 200% faster than v0.8
22:23:11  <isaacs>bnoordhuis: correctness is important here.
22:23:13  <bnoordhuis>ah okay, in that case
22:23:45  <bnoordhuis>still, i'll benchmark it some more for my own peace of mind
22:23:56  <isaacs>bnoordhuis: as long as it's faster than v0.8, i don't care much. of course, faster is better, so if we can do it a bit more cheaply, then great.
22:23:59  <isaacs>but otherwise, meh.
22:25:41  <isaacs>wtf. simple/test-cluster-dgram-2 is saying --CRASHED--, but only when run as part of make test, not when run directly, or through the test.py directly
22:27:02  <sblom>tjfontaine: any reason you're invoking msbuild directly instead of letting vcbuild.bat do it?
22:28:04  <tjfontaine>sblom: no particular reason, other than if I want to turn up/down verbosity as I'm figuring something out it's easier to do with invoking msbuild myself, or control any other flag without mucking with gyp
22:29:04  <sblom>That's a good enough reason for me. :) I'm looking to see if vcbuild and msbuild are doing anything redundant with/condradictory to each other.
22:29:34  <tjfontaine>it's possible because I'm *not* specifying the arch to the gyp generation it's trying to link disparate arch types?
22:30:07  <tjfontaine>well, no vcbuild defaults the target arch
22:35:32  <tjfontaine>sblom: I'm installing sp1 manually because apparently windows update doesn't do that for express
22:35:45  <tjfontaine>we'll see if that has any appreciable effect
22:36:53  <sblom>tjfontaine: I was just about to ask if this was SP1 or not. That's goofy that Express doesn't get updated. :(
22:37:21  <tjfontaine>though in reality I am using the vcvarsall from 2012
22:37:22  <trevnorris>isaacs: bugger. i need your patch before I can fix the nextTick timing problem. but your fix is causing "test-next-tick-ordering" to fail.
22:37:31  <tjfontaine>so it shouldn't matter
22:38:38  <sblom>tjfontaine: Hmmm. That could be related to this somehow... I see that msbuild is calling G:\VS2010\VC\bin\CL.exe to do the compilation.
22:38:46  <trevnorris>bnoordhuis: thanks. was able to figure it out.
22:39:10  <sblom>If we're mixing VS2010 and VS2012 tools, this COFF corruption thing is exactly the sorts of stuff that could happen.
22:39:33  <tjfontaine>lemme turn up verbosity, and see if that's what's happening currently
22:39:37  <sblom>Okay.
22:41:46  <tjfontaine>yup still happening
22:42:09  <tjfontaine>ok, so maybe PATH has some weirdness going on
22:43:15  <MI6>joyent/node: Ben Noordhuis master * c6e2db2 : crypto: clear error stack Clear OpenSSL's error stack on return from Con - http://git.io/4lBdPg
22:43:49  <bnoordhuis>dtrace is nice. and i say that as someone who's worked with systemtap alot
22:44:02  <bnoordhuis>or raw kprobes/uprobes for that matter
22:44:45  <tjfontaine>it is quite nice
22:44:47  <tjfontaine>also
22:44:51  <tjfontaine>oh hey I installed a software update, guess we better reboot
22:47:17  <isaacs>bnoordhuis, trevnorris: https://github.com/isaacs/node/compare/no-next-tick-main
22:47:37  <sblom>tjfontaine: Might be worth using vcvarsall.bat from VS2010 if that's what we're trying to build with. Or vsvars32.bat. I'm honestly not sure exactly what the difference is. I use the latter form, usually, but I know vcbuild.bat uses the former.
22:48:05  <tjfontaine>sblom: I'll use whatever form you tell me to :)
22:48:17  <tjfontaine>so long as it works is all I really care about
22:48:23  <trevnorris>isaacs: oh, that's slick.
22:48:52  <trevnorris>isaacs: nice, with that I should be able to call _tickCallback directly from nextTick if there were no other callback in queue.
22:49:00  <isaacs>trevnorris: i think maybe we can remove the extra tick spinner thingie
22:49:06  <trevnorris>yeah, we can.
22:49:14  <isaacs>weet. where was that?
22:49:19  <tjfontaine>sblom: even better if you can tell me how to convince jenkins to let me set that before calling vcbuild instead of having to set before launching the jenkins slave
22:49:22  <isaacs>i'll try it and see if the tests blow up
22:49:27  <sblom>Okay.
22:49:28  <sblom>Yeah.
22:49:28  <trevnorris>isaacs: L160
22:50:00  <trevnorris>isaacs: basically last line of startup()
22:50:06  <tjfontaine>sblom: I just assumed batch let me do something like vcvarsall && vcbuild
22:50:27  <sblom>tjfontaine: we can do that if we call msbuild on our own instead of using the msbuild Jenkins action.
22:51:00  <tjfontaine>right I'm fine with not doing our msbuild, because presumably things will be working :)
22:51:14  <isaacs>ok, this fixes the domain regression, too.
22:51:24  <isaacs>running the full suite with the extra needTickCallback removed.
22:52:12  <isaacs>trevnorris: oh, Module.runMain in debug mode won't call nextTicks
22:52:14  <isaacs>whoops
22:52:15  * wolfeidauquit (Remote host closed the connection)
22:52:22  <trevnorris>...
22:52:45  <nodejs-ci>Project nodejs-master » ia32,smartos build #17:FAILURE in 9 min 24 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/17/
22:52:49  * wolfeidaujoined
22:52:54  * rendarquit
22:53:26  <isaacs>should just put that in Module.runMain explicitly
22:53:50  <nodejs-ci>Project nodejs-master » x64,smartos build #17:FAILURE in 10 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/17/
22:53:55  <isaacs>omg, you guys.
22:54:10  <isaacs>i am noticing how much I'm NOT cringing when the test runner gets to "d"
22:54:15  <isaacs>this fucking rocks.
22:54:18  <tjfontaine>hehe
22:54:20  <tjfontaine>sblom: Build succeeded.
22:54:21  <tjfontaine>Time Elapsed 00:05:53.60
22:54:22  <isaacs>the little things in life, you know?
22:54:38  <tjfontaine>isaacs: I just had a successful windows build, I know *exactly* what you mean
22:54:56  <sblom>Oh, yay. So SP1 fixed us?
22:55:03  <tjfontaine>sblom: seems to have yes
22:56:44  <sblom>tjfontaine: I just made a change to the Jenkins build steps that I think will help you not have to call vcvarsall.bat before launching your agent.
22:57:02  <sblom>You want to take a look?
22:57:21  <sblom>It's just a conversation piece--I don't like that it has an opinion about the disk layout of the build agent...
22:57:41  <trevnorris>isaacs: um. i just noticed that max tick depth io deferral is enforced by _tickCallback. can that maxTickWarn be removed now, or need to wait until 0.11?
22:57:54  <tjfontaine>right, I had tried previous the multiple lines without luck, lemme see how this current run finishes wrt tests and then we'll play with command line mutations
22:57:55  <sblom>tjfontaine: Or vcbuild.bat knows how to find vcvarsall.bat on its own, I think, if we switch back to letting it build.
22:58:12  <sblom>tjfontaine: Ohhhh! We need to put a "call" in front of it.
22:58:13  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-oneoff/48/tapTestReport/ <-- hey look windows test failures :P
22:59:12  <tjfontaine>interesting that the tools/test.py doesn't do the right thing on windows for tap
22:59:19  <tjfontaine>anyway that's something I can do on my own
22:59:29  <tjfontaine>sblom: ok ready to do another run with your changes?
23:00:05  <sblom>Sure--I'll re-read my changes and click build now.
23:00:21  <tjfontaine>k, just go ahead and accept master as well
23:01:04  <sblom>tjfontaine: Sigh. This is one of the funnest parts of Windows unit tests.
23:01:16  <sblom>tjfontaine: They end up creating hard-to-delete files. :p
23:01:33  <sblom>(The git clean step failed.)
23:01:33  <tjfontaine>o0
23:01:37  <sblom>Yeah.
23:01:40  <tjfontaine>so um
23:01:55  <sblom>They're "long file names" which git doesn't know how to deal with.
23:02:04  <tjfontaine>ah
23:02:17  <tjfontaine>is vcbuild clean a better step here?
23:02:41  <isaacs>ok, this is passing all tests now.
23:02:43  <sblom>I don't know. I bet that just calls msbuild clean.
23:02:43  <tjfontaine>I jsut like the git option because it I can get a pretty predictable env
23:02:44  <isaacs>and i like it.
23:02:51  <sblom>tjfontaine: Yeah.
23:03:58  * mikealquit (Quit: Leaving.)
23:04:01  <sblom>tjfontaine: Lemme double-check what we're up against.
23:04:04  <tjfontaine>ok
23:04:39  * wolfeida_joined
23:07:40  * wolfeidauquit (Read error: Operation timed out)
23:12:04  <isaacs>someone wanna lgtm this? https://github.com/joyent/node/pull/4867
23:12:31  * bnoordhuisquit (Ping timeout: 276 seconds)
23:12:50  <trevnorris>isaacs: did you remove the extra _needTickCallback?
23:12:54  <sblom>tjfontaine: Okay--I've refreshed my memory. So what's killing us is the test called test-fs-long-path.js
23:13:00  <trevnorris>oop. yeah. see it
23:13:05  <sblom>tjfontaine: a really simple fix would be to have it clean up after itself.
23:13:14  <tjfontaine>that sounds ideal
23:13:22  <trevnorris>isaacs: lgtm
23:13:55  <sblom>Alright--I'll prep a one-line patch real quick.
23:14:02  <tjfontaine>sblom: in the mean time I need to delete via explorer?
23:15:51  <sblom>Hilariously, I think even it'll have problems. If you go to test/tmp at a command prompt, you can probably delete it using its short name which I think'll be xxxxxx~1
23:15:57  <sblom>dir /x will tell you for sure.
23:16:08  <tjfontaine>nod, it went away withotu issue indeed
23:16:17  <sblom>tjfontaine: okay.
23:16:42  <sblom>So a build should work now. But 2 builds won't. :)
23:16:45  <sblom>(Back to my patch.)
23:16:48  <tjfontaine>hehe
23:18:44  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-oneoff/50/console so I had tried that and got that that similar java error, and I'm not entirely sure why, is vcvarsall dropping the java_home or something?
23:19:07  * loladiroquit (Quit: loladiro)
23:22:25  <isaacs>hrm... it looks like github is not responding timely...
23:22:34  <trevnorris>isaacs: fyi, PR 4867 doesn't fix issue 4866. i'm working on a fix, but it requires your patch.
23:22:59  <tjfontaine>sblom: https://issues.jenkins-ci.org/browse/JENKINS-11992
23:23:56  <isaacs>trevnorris: i'm not sure why you want to remove that warning.
23:24:06  <isaacs>trevnorris: the warning is there because we're deferring IO for a long time
23:24:23  <isaacs>trevnorris: 1000 deep nexttick loop should probably be setImmediate or something
23:24:23  * loladirojoined
23:24:56  <sblom>tjfontaine: yikes. will Jenkins be okay with a 64-bit JRE?
23:25:02  <sblom>Seems like it.
23:25:21  <trevnorris>isaacs: i'm just saying that deferring the I/O to the spinner is forced. so it seems superfluous.
23:25:27  <tjfontaine>sblom: we're going to find out
23:25:30  <sblom>Heh.
23:25:35  <trevnorris>isaacs: and it said it would be removed on 0.11 anyways.
23:25:36  * sblomcrosses his fingers.
23:25:54  <isaacs>trevnorris: yeah, but it's a warning because in 0.11, we're going to just defer your IO forever.
23:25:59  <isaacs>trevnorris: if you keep doing nextTicks
23:26:10  <sblom>What's the right way to just run one unit test?
23:26:25  <isaacs>sblom: python tools/test.py simple/test-assert
23:26:26  <trevnorris>isaacs: ah, so you're saying that there will be no more checks for maxTickDepth in 0.11?
23:26:36  <isaacs>trevnorris: that's the vague plan, yes
23:26:45  <isaacs>trevnorris: we'll just keep next ticking forever.
23:26:59  <sblom>node test/simple/test-name-here.js seemed to work
23:27:05  <isaacs>sblom: or that :)
23:27:17  <isaacs>sblom: occasionally there are subtle differences when run by python vs run directly
23:27:28  <sblom>isaacs: Cool--thanks. I'll switch to the python incantation.
23:27:38  <tjfontaine>I'm about to curl up in a corner, downloading x64 jre caused chrome to freeze
23:27:56  <trevnorris>isaacs: oh, ok. makes more sense. though the message was just saying the warning was going to be removed.
23:27:58  <isaacs>sblom: if it fails directly, of course, then that's also a bug :)
23:28:03  * loladiroquit (Client Quit)
23:28:20  * mikealjoined
23:28:29  <trevnorris>isaacs: and that will hold true for calling a nextTick inside a domain's error handle?
23:28:47  <trevnorris>because right now no warning is broadcast for that, but it is checked.
23:28:47  <isaacs>trevnorris: yeah
23:28:49  <trevnorris>ok
23:29:07  <isaacs>trevnorris: i don't consider it a 0.10 release blocker anyway
23:29:25  <trevnorris>oh, I don't either. just figured i'd throw it in, since it was a quick fix.
23:29:28  <isaacs>trevnorris: is the event emit emulsify pr in good shape?
23:30:02  <trevnorris>isaacs: hasn't failed any of my testing or benchmarks.
23:30:28  <tjfontaine>sblom: ok, I fixed it twice, once by using x64 and also installing it in my own path :)
23:30:30  <trevnorris>isaacs: it's pretty much the same. mainly was removing unecessary checks, using faster checks and adding some argument type checking.
23:30:30  <isaacs>trevnorris: k, i'll take a look at it.
23:30:35  <trevnorris>cool
23:31:02  <isaacs>i also gotta split up the Readable push/shift/onread stuff, and then release 0.9.11
23:31:16  <isaacs>anyone else seeing fatal: Unable to look up github.com (port 9418) (nodename nor servname provided, or not known) from github?
23:31:19  <tjfontaine>sblom: I should have googled that java error earlier today :)
23:32:45  <isaacs>ok, i give up. bbiab, in search of better wifi.
23:34:51  * brsonjoined
23:35:53  * c4miloquit (Remote host closed the connection)
23:44:40  * pooyaquit (Quit: pooya)
23:47:00  * hzquit (Ping timeout: 264 seconds)