00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:06  * julianduquejoined
00:02:48  <isaacs>trevnorris: aha. i think i figured it out. in the deeply nested case, there are some situations where the throw prevents the thing from being scheduled
00:03:48  * octetcloudquit (Ping timeout: 240 seconds)
00:04:34  * mikealquit (Quit: Leaving.)
00:05:23  * mikealjoined
00:05:58  * st_lukejoined
00:07:01  <isaacs>trevnorris: yeah, the "setInterval - nested" and "setImmediate - nested" errors aren't getting thrown reliably
00:14:05  <isaacs>trevnorris: yeah, i think the issue is that the throws from one timeout function are preventing the other timeout functions from running. each section works fine individually,but not all in the same program. (scratch my suggestion from earlier about separating them!)
00:14:44  <othiym23>that error-handling logic is pretty mindbending
00:14:55  <othiym23>the polyfill version works as long as I don't look at it too closely
00:15:04  <othiym23>polyfill polyfilled
00:16:52  * mikealquit (Quit: Leaving.)
00:21:23  * mikealjoined
00:31:35  * kazuponjoined
00:35:02  * bnoordhuisquit (Ping timeout: 240 seconds)
00:41:12  * abraxasjoined
00:43:09  <othiym23>mmm: https://github.com/othiym23/async-listener/commit/d4a5ad108b744d552792fbed16608d74b1cf6d38
00:43:42  <tjfontaine>who wants to see a pretty graph?
00:44:22  <isaacs>tjfontaine: I DO
00:44:23  * zz_karupanerurachanged nick to karupanerura
00:44:27  <isaacs>LOUDBOT: sup
00:44:27  <LOUDBOT>isaacs: I WOULDN'T MIND A KIDDIE POOL FILLED WITH FIVERS
00:44:34  <isaacs>THATS WHAT IM SAYIN
00:44:34  <LOUDBOT>'HELLO GUISE, DO YOU TAKE MARIJUANA AS WELL?'
00:45:20  <tjfontaine>isaacs: http://us-east.manta.joyent.com/tjfontaine/public/graphs.12.svg
00:45:45  <isaacs>tjfontaine: that JS is all "IVE BEEN FRAMED"
00:45:58  <tjfontaine>isaacs: those are the stack traces for the allocations for things that have been malloc()'d that haven't been free()'d
00:46:03  * abraxasquit (Ping timeout: 272 seconds)
00:46:09  <isaacs>tjfontaine: interesting
00:46:09  <othiym23>mmmm mangling
00:46:26  <isaacs>"JSFrame" is less useful than it could be.
00:46:29  <tjfontaine>isaacs: ya, I had to translate that because umem doesn't know jstack
00:46:37  <isaacs>ahh, ok
00:47:09  <isaacs>could it at least dump the 08f003ad numbers, and let you do ::jsprint on them or whatever?
00:48:00  <isaacs>i've gotta run
00:48:05  <tjfontaine>yes, but those frames don't exist anymore
00:48:09  <isaacs>oh, ok
00:48:17  <isaacs>right, because you do't have a core for it?
00:48:28  <isaacs>i guess one approach would be to teach umem about jsstack
00:49:03  <isaacs>tjfontaine: looks like there's a juicy target in the middle there
00:49:16  <tjfontaine>yup
00:49:26  <isaacs>also, both are in http_parser callbacks from uv__read
00:49:38  <isaacs>which is interesting.
00:50:03  <tjfontaine>it *looks* like a handlescope leak
00:50:23  <isaacs>hm.
00:50:32  <isaacs>ok, i really do have to head out.
00:50:50  <isaacs>tjfontaine: nice work gathering, though, that certainly at least *looks* like progress.
00:50:53  <isaacs>;)
00:51:41  <tjfontaine>:)
00:52:28  * isaacs&
00:52:28  <LOUDBOT>I GOT A PULL REQUEST ON MY MRUBY NGINX STUFF
00:57:18  * st_lukequit (Remote host closed the connection)
00:57:58  * st_lukejoined
01:02:14  * st_lukequit (Ping timeout: 240 seconds)
01:11:06  * c4milojoined
01:11:30  * AvianFluquit (Remote host closed the connection)
01:12:01  * AvianFlujoined
01:12:14  * kazuponquit (Remote host closed the connection)
01:12:41  * kazuponjoined
01:15:53  * mikealquit (Quit: Leaving.)
01:17:25  * kazuponquit (Ping timeout: 248 seconds)
01:18:22  * kazuponjoined
01:22:38  * kazuponquit (Ping timeout: 240 seconds)
01:37:04  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:41:15  * sblomjoined
01:41:38  * abraxasjoined
01:42:15  * AvianFluquit (Remote host closed the connection)
01:43:10  * c4miloquit (Remote host closed the connection)
01:43:42  * c4milojoined
01:43:54  * AvianFlujoined
01:45:30  * sblomquit (Ping timeout: 246 seconds)
01:46:35  * dshaw_joined
01:48:29  * c4miloquit (Ping timeout: 272 seconds)
01:53:05  * amartensquit (Quit: Leaving.)
01:53:55  * rphillips_joined
01:57:10  * rphillips_quit (Client Quit)
01:59:25  * rphillips_joined
02:02:23  * rphillipsquit (Remote host closed the connection)
02:02:39  * rphillips_changed nick to rphillips
02:04:20  * abraxasquit (Remote host closed the connection)
02:05:46  <wolfeidau>wow nice work LOUDBOT
02:10:16  * inolenjoined
02:13:53  <trevnorris>wow. my screen just got flooded w/ dialog boxes.
02:14:26  <trevnorris>isaacs: I haven't been able to reproduce the failure. i'll try running it on the smartos server to see if I can.
02:14:42  <trevnorris>tjfontaine: thanks much for the quick run.
02:16:47  <wolfeidau>trevnorris: Have you ever compiled a list or seen a list of things your using to debug/trace node and libuv?
02:17:29  <wolfeidau>trevnorris: outside of the trail of gists which are filled with the odd gem :)
02:20:51  <trevnorris>isaacs: let the loop run 10,000 times in the background and no failures. will need to find a way to make it fail on another machine.
02:22:00  <trevnorris>wolfeidau: um.... strace, valgrind, perf (which has a lot of options). like, compile node with:
02:22:01  <trevnorris>CFLAGS="-fno-omit-frame-pointer" CXXFLAGS="-fno-omit-frame-pointer" make -j8
02:22:01  <trevnorris>then run perf record -g fp -e cycles:u, then perf report -g -G
02:22:33  <trevnorris>othiym23: yeah. I'll refrain from asking for the benchmarks ;)
02:23:03  <wolfeidau>trevnorris: Interesting haven't used perf before
02:23:34  <wolfeidau>trevnorris: You used LatencyTOP at all?
02:24:13  <trevnorris>wolfeidau: nope.
02:24:40  <wolfeidau>trevnorris: Quite handy see under issues in linux
02:25:27  <trevnorris>interesting, i'll take a look
02:34:22  <trevnorris>isaacs: can't reproduce the problem on the smartos server either. not sure what to do since I can't analyze the issue.
02:38:56  <trevnorris>isaacs: here you'll see there's duplicate output, which means that process.exit is being called twice: http://jenkins.nodejs.org/job/node-review/lastSuccessfulBuild/DESTCPU=ia32,label=windows/tapTestReport/test.tap-4/
02:38:57  * abraxasjoined
02:41:23  * c4milojoined
02:41:33  <trevnorris>isaacs: and here, either the parent is exiting before the child so child.on('exit' isn't being called, or the assertion there is passing but process._rawDebug isn't making it to the parent: http://jenkins.nodejs.org/job/node-review/lastSuccessfulBuild/DESTCPU=ia32,label=windows/tapTestReport/test.tap-12/
02:42:17  <trevnorris>isaacs, tjfontaine: also fyi, the http flood test is failing sometimes: http://jenkins.nodejs.org/job/node-review/lastSuccessfulBuild/DESTCPU=x64,label=linux/tapTestReport/test.tap-299/
02:54:07  * amartensjoined
02:55:08  <trevnorris>isaacs: ok, i'm going to add a bunch of logging to the tests so it'll give me more information. right now that's the best I can think of until I manage to reproduce the errors.
02:56:01  <trevnorris>like, the one where windows is catching 3 additional errors. that shouldn't be possible. i'm only throwing 12 times. so it'd have to be calling the _fatalException handler 3 extra times for some reason.
02:57:19  * toothrchanged nick to toothrot
02:58:38  * amartensquit (Ping timeout: 256 seconds)
03:04:04  <tjfontaine>trevnorris: can you check to see if that happens before the last libuv upgrade?
03:04:38  * bradleymeckjoined
03:10:11  * c4miloquit (Remote host closed the connection)
03:11:58  * dshaw_quit (Quit: Leaving.)
03:12:05  * julianduquequit (Ping timeout: 248 seconds)
03:12:43  * brsonquit (Ping timeout: 272 seconds)
03:13:33  * mikealjoined
03:13:58  * mikealquit (Client Quit)
03:26:19  * octetcloudjoined
03:42:50  * dshaw_joined
03:54:51  * amartensjoined
03:58:45  * kazuponjoined
03:59:51  * amartensquit (Ping timeout: 272 seconds)
04:07:53  * dshaw_quit (Quit: Leaving.)
04:09:09  * dshaw_joined
04:12:07  * AvianFluquit (Remote host closed the connection)
04:12:38  * AvianFlujoined
04:13:52  * kazuponquit (Remote host closed the connection)
04:14:12  * kazuponjoined
04:15:20  * paulfryzelquit (Remote host closed the connection)
04:20:33  * kazuponquit (Read error: Connection reset by peer)
04:20:54  * kazuponjoined
04:21:24  * amartensjoined
04:25:58  * amartensquit (Ping timeout: 245 seconds)
04:59:32  * c4milojoined
05:04:40  * c4miloquit (Ping timeout: 264 seconds)
05:18:29  * octetcloudquit (Ping timeout: 248 seconds)
05:22:21  * amartensjoined
05:27:37  * amartensquit (Ping timeout: 272 seconds)
05:35:19  * mikealjoined
05:38:27  * octetcloudjoined
05:42:49  * AvianFluquit (Remote host closed the connection)
05:43:19  * AvianFlujoined
05:44:38  * octetcloudquit (Ping timeout: 240 seconds)
05:47:52  * AvianFluquit (Ping timeout: 264 seconds)
05:48:05  * piscisaureus_joined
05:55:26  * piscisaureus_quit (Ping timeout: 256 seconds)
06:00:03  * piscisaureus_joined
06:03:49  * jcrugzzquit (Ping timeout: 248 seconds)
06:08:21  * niska`quit (Ping timeout: 245 seconds)
06:12:22  * bradleymeckquit (Quit: bradleymeck)
06:12:28  * niskajoined
06:34:33  * kazuponquit (Remote host closed the connection)
06:35:02  * kazuponjoined
06:39:33  * kazuponquit (Ping timeout: 248 seconds)
06:40:17  * kazuponjoined
06:48:29  * c4milojoined
06:52:40  * c4miloquit (Ping timeout: 246 seconds)
07:04:20  <MI6>nodejs-v0.10-windows: #296 UNSTABLE windows-ia32 (12/603) windows-x64 (14/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/296/
07:27:04  * rendarjoined
07:33:09  * `3E|ZZchanged nick to `3rdEden
07:36:24  * bajtosjoined
07:57:52  * paddybyersjoined
08:24:08  * inolenquit (Ping timeout: 240 seconds)
08:24:31  * amartensjoined
08:24:47  * inolenjoined
08:26:11  * loladiroquit (Quit: loladiro)
08:28:18  * paddybyersquit (Quit: paddybyers)
08:29:16  * amartensquit (Ping timeout: 264 seconds)
08:36:35  * c4milojoined
08:41:02  * c4miloquit (Ping timeout: 240 seconds)
08:52:52  * paddybyersjoined
09:05:44  * bajtosquit (Quit: bajtos)
09:07:52  * dshaw_quit (Quit: Leaving.)
09:18:49  <trevnorris>piscisaureus_: real quick before I head to bed. this test result shouldn't be possible: http://jenkins.nodejs.org/job/node-review/lastSuccessfulBuild/DESTCPU=ia32,label=windows/tapTestReport/test.tap-4/
09:19:02  <trevnorris>piscisaureus_: windows is firing the process.on('exit' event twice
09:19:21  <piscisaureus_>trevnorris: uhh.
09:19:27  <piscisaureus_>trevnorris: sounds like a node bug
09:19:43  <piscisaureus_>:)
09:19:56  <piscisaureus_>trevnorris: I don't think windows is responsible for firing 'exit' and neither is libuv...
09:20:44  <trevnorris>piscisaureus_: yeah. just letting you know. I haven't been able to get any of the async listener tests to fail for me yet on smartos or linux. and I don't have a windows or mac available to test
09:21:02  <piscisaureus_>trevnorris: right. I might take a look
09:21:09  <piscisaureus_>trevnorris: but, ehm, busy :(
09:21:26  * bajtosjoined
09:21:43  <trevnorris>piscisaureus_: no worries. just a status update. 2:30am here. time for bed. just can't figure out how it's catching more bugs than i'm throwing.
09:21:45  <trevnorris>so strange.
09:22:11  <rendar>does libuv has an api for timed wait of a child process completion?
09:22:17  * trevnorris&
09:22:18  <LOUDBOT>WAND MASSAGERS IS WHAT THEY ARE CALLED
09:23:47  <piscisaureus_>rendar: timed wait?
09:24:04  <piscisaureus_>rendar: I don't think so. But you can start a timer and uv_kill the process if it doesn't exit in a timely fashion.
09:24:15  <piscisaureus_>er, *uv_process_kill
09:24:31  <rendar>piscisaureus_, yeah, like WaitForSingleObject(hProcess, 500); which waits until 500ms
09:24:52  <piscisaureus_>rendar: you mean, block the event loop? No.
09:24:57  <rendar>piscisaureus_, i see..nop i don't want to kill, only see if it has finished :)
09:25:13  * amartensjoined
09:25:31  <piscisaureus_>rendar: you'll get a callback when it has finished :)
09:25:41  <rendar>ok
09:25:43  <piscisaureus_>rendar: you can also check by sending it signal 0 and see if that succeeds
09:25:43  <rendar>:)
09:26:15  <rendar>piscisaureus_, so, since libuv uses completion callbacks (when the process finishes) it doesn't make sense to synchronous wait for it
09:26:16  <piscisaureus_>(uv_process_kill will return something nonzero when the process is already dead)
09:26:26  <piscisaureus_>rendar: indeed
09:26:32  <rendar>ok right :)
09:29:28  * amartensquit (Ping timeout: 246 seconds)
09:38:43  * dshaw_joined
09:40:26  * dshaw_1joined
09:40:53  * dshaw_quit (Read error: Connection reset by peer)
09:52:13  * dshaw_1quit (Ping timeout: 246 seconds)
09:55:23  * bnoordhuisjoined
09:59:57  * bnoordhuisquit (Ping timeout: 272 seconds)
10:05:31  * kazuponquit (Remote host closed the connection)
10:06:00  * kazuponjoined
10:10:59  * kazuponquit (Ping timeout: 272 seconds)
10:24:47  * c4milojoined
10:25:53  * amartensjoined
10:26:24  * karupanerurachanged nick to zz_karupanerura
10:29:25  * c4miloquit (Ping timeout: 248 seconds)
10:30:16  * amartensquit (Ping timeout: 256 seconds)
10:36:55  * inolenquit (Quit: Leaving.)
10:40:25  * inolenjoined
10:42:54  * bnoordhuisjoined
10:43:00  * inolenquit (Client Quit)
10:49:07  <MI6>nodejs-v0.10: #1572 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) osx-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1572/
10:56:33  <bnoordhuis>indutny: https://github.com/joyent/node/issues/6427 <- is clang optimizing away the 'return NULL'?
10:56:47  <indutny>bnoordhuis: I'm not quite sure
10:56:54  <indutny>bnoordhuis: it seems to be generating wrong condition
10:56:58  <bnoordhuis>because that v8 code looks borderline illegal
10:57:01  <indutny>bnoordhuis: it should be je
10:57:08  <indutny>not jne
10:57:10  <indutny>AFAIK
10:58:12  <bnoordhuis>owner_ - kFailureTag <- the compiler is free to assume owner_ != NULL when doing pointer arithmetic
10:58:22  <indutny>right
10:58:26  <indutny>the real problem is that it does
10:58:32  <indutny>owner_ & Mask
10:58:33  <indutny>then
10:58:39  <indutny>cmp result^, Tag
10:58:47  <indutny>jne skip_accessing_owner
10:58:51  <indutny>ah, wait
10:58:54  <indutny>yeah
10:59:00  <indutny>it should not assume it is NULL
10:59:04  <bnoordhuis>come to think of it, wasn't this or a similar bug fixed in v8 a while ago?
10:59:13  <indutny>not sure
10:59:14  * bajtosquit (Quit: bajtos)
10:59:41  <bnoordhuis>my git grep fu is weak today, can't seem to find it
10:59:48  <bnoordhuis>as is my git log fu
11:00:02  <indutny>the code seems to be absolutely the same
11:00:28  <indutny>aaaaaaaah
11:00:29  <indutny>fuck
11:00:30  <indutny>sorry
11:00:43  <indutny>b3775cf3
11:00:50  <indutny>pointer arithmetic
11:01:03  <indutny>I'll push fix in a bit
11:01:04  <indutny>to v0.8
11:01:04  <bnoordhuis>hah yeah, that's the one
11:01:38  <bnoordhuis>"a while ago"... Thu Jan 31 15:36:24 2013
11:01:51  <indutny>rebuilding :P
11:01:59  <indutny>I'm sure it'll fix it
11:02:15  <indutny>god, where can I read about all that undefined behaviour shit?
11:02:20  <indutny>is there a way to get free C++ spec?
11:03:21  <bnoordhuis>indutny: there's this https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Coding+Standard
11:03:37  <bnoordhuis>it's for c, of course, though i believe a c++ coding standard is underway
11:03:44  <indutny>bnoordhuis: thank
11:03:46  <indutny>you
11:03:47  <indutny>:P
11:03:49  <bnoordhuis>still, a lot of things that are true for c are also true in c++
11:04:01  <indutny>yeah, they're not that insane :P
11:04:04  <bnoordhuis>one interesting difference though, NULL + 0 is legal in c++ and illegal in c
11:04:11  <indutny>btw, I'm going to write series of blog posts
11:04:15  <indutny>on how to implement JIT
11:04:24  <indutny>do you think it is a good idea?
11:04:37  <bnoordhuis>i don't think it's necessarily a bad idea
11:04:44  <bnoordhuis>what in particular are you going to write about?
11:04:48  <rendar>usually i don't use NULL, just 0 instead
11:04:57  <bnoordhuis>same difference though
11:05:56  * Kakera_joined
11:07:33  <indutny>bnoordhuis: well, start with basics
11:07:41  <indutny>bnoordhuis: compiling AST directly into assembly
11:07:44  <indutny>then move to SSA
11:07:47  <indutny>representations
11:07:49  <indutny>no
11:07:57  <indutny>probably second step should be implementing heap
11:09:22  <MI6>joyent/node: Fedor Indutny v0.8 * 532f9ff : v8: backport b3775cf3 from upstream - http://git.io/tL7g3g
11:09:27  <indutny>and only after that to SSA
11:15:10  <bnoordhuis>heap == garbage collector?
11:15:26  <bnoordhuis>because that subject alone could fill entire blogs
11:15:30  <MI6>nodejs-v0.8: #56 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.8/56/
11:15:32  * abraxasquit (Remote host closed the connection)
11:17:04  <indutny>bnoordhuis: yes
11:17:21  <indutny>bnoordhuis: there's always a simple way
11:17:24  <indutny>bnoordhuis: to get into things
11:17:31  <indutny>and that's what I'm going to show
11:17:40  <indutny>brb
11:26:48  * amartensjoined
11:27:57  * abraxasjoined
11:31:25  * amartensquit (Ping timeout: 272 seconds)
11:48:41  * dshaw_joined
11:51:35  * niskaquit (Read error: Connection reset by peer)
11:53:03  * dshaw_quit (Ping timeout: 252 seconds)
11:53:33  * inolenjoined
11:53:33  * inolenquit (Client Quit)
11:53:47  * bajtosjoined
11:59:47  * niskajoined
12:05:09  * abraxasquit (Remote host closed the connection)
12:05:28  * abraxasjoined
12:06:42  * abraxasquit (Remote host closed the connection)
12:13:07  * c4milojoined
12:17:56  * c4miloquit (Ping timeout: 256 seconds)
12:27:48  * amartensjoined
12:32:06  * amartensquit (Ping timeout: 256 seconds)
12:35:50  * bnoordhuisquit (Ping timeout: 240 seconds)
12:43:41  * loladirojoined
12:47:28  * loladiroquit (Client Quit)
12:49:10  * dshaw_joined
12:53:45  * dshaw_quit (Ping timeout: 272 seconds)
13:02:39  * bnoordhuisjoined
13:10:04  * bnoordhuisquit (Ping timeout: 256 seconds)
13:10:43  * inolenjoined
13:14:52  * inolenquit (Ping timeout: 246 seconds)
13:17:16  * AvianFlujoined
13:23:27  * bajtosquit (Quit: bajtos)
13:28:16  * amartensjoined
13:29:54  * piscisaureus_quit (Ping timeout: 256 seconds)
13:30:34  * loladirojoined
13:30:59  * `3rdEdenchanged nick to `3E|GONE
13:33:01  * amartensquit (Ping timeout: 272 seconds)
13:40:21  * AvianFluquit (Remote host closed the connection)
13:40:51  * AvianFlujoined
13:42:20  * bnoordhuisjoined
13:45:08  * AvianFluquit (Ping timeout: 245 seconds)
13:47:35  * bnoordhuisquit (Ping timeout: 272 seconds)
13:49:05  * paulfryzeljoined
13:49:40  * dshaw_joined
13:53:25  * piscisaureus_joined
13:53:51  * dshaw_quit (Ping timeout: 246 seconds)
13:59:28  * loladiroquit (Quit: loladiro)
14:01:26  * c4milojoined
14:02:52  * paulfryzelquit (Remote host closed the connection)
14:05:39  * julianduquejoined
14:06:41  * c4miloquit (Ping timeout: 272 seconds)
14:07:20  * abraxasjoined
14:07:34  * bradleymeckjoined
14:12:24  * abraxasquit (Ping timeout: 256 seconds)
14:15:22  * pachetjoined
14:15:22  * pachetquit (Changing host)
14:15:22  * pachetjoined
14:22:11  * bajtosjoined
14:22:12  * piscisaureus_quit (Ping timeout: 246 seconds)
14:23:46  * bnoordhuisjoined
14:27:14  * defunctzombie_zzchanged nick to defunctzombie
14:32:01  <MI6>joyent/libuv: Ben Noordhuis master * 21c37a7 : linux: use CLOCK_MONOTONIC_COARSE if available - http://git.io/Qsxstg
14:50:19  * dshaw_joined
14:51:39  * bajtosquit (Read error: Connection reset by peer)
14:54:36  * inolenjoined
14:55:27  * dshaw_quit (Ping timeout: 272 seconds)
14:57:12  <MI6>joyent/libuv: Ben Noordhuis master * 3c172ea : build: make systemtap probes work with gyp build - http://git.io/0niMMQ
14:58:52  <MI6>joyent/node: Ben Noordhuis master * c4def50 : build: use zero overhead systemtap probes - http://git.io/y22ZjQ
15:00:52  * `3E|GONEchanged nick to `3rdEden
15:01:10  <indutny>bnoordhuis: heya
15:01:27  <indutny>bnoordhuis: I'm making serious progress here https://github.com/indutny/jit.js/blob/master/test/x64-test.js :P
15:01:48  <indutny>and I think I finally found good language to write JIT
15:02:41  <bnoordhuis>you're rewriting all the jits in js?
15:02:55  <bnoordhuis>so you can have a jit in your jit while you jit?
15:02:58  * inolenquit (Quit: Leaving.)
15:02:58  <bnoordhuis>that's awesome
15:03:43  * bajtosjoined
15:05:09  * AvianFlujoined
15:10:49  * mikealquit (Quit: Leaving.)
15:14:14  <SquirrelCZECH>guys
15:14:28  <SquirrelCZECH>how would you suggest to combine loops of GUI and libuv?
15:14:37  <SquirrelCZECH>(pyuv - python, but this shoudln't matter)
15:16:16  <bnoordhuis>SquirrelCZECH: there's a couple of approaches. uv_backend_fd() + uv_backend_timeout() lets you integrate libuv in another event loop
15:16:29  <MI6>nodejs-master: #660 UNSTABLE osx-x64 (2/655) smartos-ia32 (8/655) linux-x64 (1/655) smartos-x64 (10/655) osx-ia32 (3/655) linux-ia32 (2/655) http://jenkins.nodejs.org/job/nodejs-master/660/
15:16:33  <bnoordhuis>SquirrelCZECH: another approach is to run libuv in thread A and the other event loop in thread B
15:16:59  <SquirrelCZECH>bnoordhuis: hmm
15:17:06  <SquirrelCZECH>bnoordhuis: second one sounds simpler and more robust
15:17:17  <SquirrelCZECH>bnoordhuis: more like second process?
15:17:31  * SquirrelCZECHis afraid that thread in python are locked to one core?
15:17:48  <bnoordhuis>oh, you mean the GIL. i guess so, i'm not a python expert
15:18:04  <SquirrelCZECH>me neither
15:18:05  <SquirrelCZECH>:D
15:18:48  <wrl>a related question: if i'm building a UI toolkit and i want to use libuv as my event loop, what's the best way to handle that?
15:19:17  <SquirrelCZECH>wrl: 1. thing I suppose would be to study how UI lops work ?
15:19:20  * superjoe30joined
15:19:29  <SquirrelCZECH>bnoordhuis: yep, GIL prevents from using multiple cores
15:19:44  <SquirrelCZECH>but just instead of "multithread" library one have to use "multiprocessing" :D
15:19:55  <wrl>well i basically have an fd for the events from the window system (on linux at least) and then a timer for the frame rendering
15:20:20  * jcrugzzjoined
15:20:45  <SquirrelCZECH>wrl: fd can be maybe handled with ttyHandle? and for timer timerHandle?
15:20:47  <SquirrelCZECH>mybe? dunno :D
15:20:49  <bnoordhuis>wrl: you could make that work with a uv_poll_t and a uv_timer_t
15:24:54  * bajtosquit (Quit: bajtos)
15:25:01  <wrl>yeah that's how i'm doing it right now
15:25:15  <wrl>i'm getting some really weird behavior though, sometimes uv just misses things that happen on the poll fd
15:25:32  <bnoordhuis>wrl: what platform is that on?
15:25:34  <wrl>i have to drain the event queue in the timer callback as well
15:25:41  <wrl>bnoordhuis: linux, fd comes from xlib/xcb
15:25:49  <bnoordhuis>okay. what kind of fd is it?
15:26:01  <wrl>that's a really good question
15:26:04  <wrl>let me check
15:26:17  <wrl>(iirc unix socket since i'm connecting to a local xorg server)
15:26:41  <bnoordhuis>right. there shouldn't really be issues with those
15:26:55  <wrl>i'm definitely missing events though
15:26:57  <wrl>sometimes like
15:27:11  <wrl>a mouse click will "stick" even when i have released the button
15:27:28  * FROGGSquit (Ping timeout: 264 seconds)
15:27:31  <wrl>if i drain the fd in the timer callback everything is fine
15:27:38  <wrl>but if i leave uv to do it all on its own i miss events
15:27:40  <wrl>or rather
15:27:42  <wrl>they're delayed
15:27:44  <bnoordhuis>have you tried stracing it? it'd be interesting to see what the gui sends to the socket and what libuv sees on the other end
15:28:08  <wrl>could do
15:28:16  <wrl>it's just going to be x11 protocol stuff though
15:28:27  <bnoordhuis>i'm assuming you add the fd with UV_READABLE | UV_WRITABLE?
15:28:42  <wrl>i just add it with readable
15:28:44  <wrl>should i have both?
15:29:04  <bnoordhuis>well, only if you need to send back data
15:29:14  <bnoordhuis>or is this a one-way thing?
15:29:17  <wrl>the details of that stuff are deep in xlib
15:29:23  <wrl>there's definitely data being sent back on the socket
15:29:32  <wrl>but nothing that uv should need to care about, i think
15:29:36  <bnoordhuis>okay
15:29:44  <bnoordhuis>how does xlib know when it's okay to write though?
15:29:55  * amartensjoined
15:30:06  <MI6>nodejs-master: #661 UNSTABLE osx-x64 (2/655) smartos-ia32 (6/655) linux-x64 (1/655) smartos-x64 (10/655) osx-ia32 (1/655) linux-ia32 (1/655) http://jenkins.nodejs.org/job/nodejs-master/661/
15:30:29  <bnoordhuis>man, smartos...
15:30:29  * octetcloudjoined
15:30:33  <wrl>xlib's a fucking mess, that's how it knows
15:30:39  <bnoordhuis>heh, okay :)
15:30:42  <wrl>tbqh i'd just assume it writes whenever it feels like it
15:31:07  <bnoordhuis>right, workable strategy if not terribly efficient
15:31:12  <wrl>yeah
15:31:58  <wrl>a lot of the code dates from before the uv model of async i/o was common
15:32:09  <wrl>i'll try adding writable though
15:32:29  <bnoordhuis>yeah, but you only want to do that when you actually have something to write
15:32:45  <bnoordhuis>else you'll effectively be busy looping when the socket is writable
15:33:05  <wrl>exactly, and that's what i see
15:33:05  * AvianFluquit (Ping timeout: 272 seconds)
15:33:29  <wrl>fixes the responsiveness but increases my CPU hit unacceptably
15:33:57  <bnoordhuis>yeah. people on laptops and mobile devices will hate you for that
15:34:10  * amartensquit (Ping timeout: 246 seconds)
15:35:11  <wrl>yep
15:35:17  <wrl>so, i don't know
15:35:44  <wrl>tbqh just draining the fd in the timer callback is an acceptable solution to me, hack as it is
15:39:08  <bnoordhuis>wrl: if you can get usable strace output from it, i can look into it
15:39:27  * FROGGSjoined
15:39:28  <bnoordhuis>just open an issue, post it there and link to your code or add an example
15:40:00  * mikealjoined
15:40:02  <bnoordhuis>mmalecki: are we still on for tonight? 'no' is an acceptable answer :)
15:41:32  <mmalecki>bnoordhuis: hmm, remind me the time?
15:41:48  <bnoordhuis>mmalecki: i don't know. 8-ish?
15:41:54  <bnoordhuis>is bert coming along?
15:42:00  <bnoordhuis>he's back in the low lands
15:42:18  <bnoordhuis>he mumbled something about a restraining order though
15:42:25  <mmalecki>bnoordhuis: we could do it tomorrow when Bert is after the jetlag
15:42:52  <bnoordhuis>he's been back for a few days now
15:43:06  * dshaw_joined
15:43:13  <mmalecki>oh, okay
15:43:18  * AvianFlujoined
15:43:23  <bnoordhuis>wait, i'll ping him on skype
15:43:30  * indexzerojoined
15:43:31  <bnoordhuis>(yes, i've succumbed to using skype. woe be me)
15:43:42  <octetcloud>ask him where his domain.task() WIP branch is...
15:43:43  <mmalecki>hahaha
15:43:54  <bnoordhuis>octetcloud: hah, will do :)
15:44:22  <mmalecki>oh yeah, I'd love to know that too
15:44:32  <mmalecki>it looked great when he showed me it
15:45:26  * defunctzombiechanged nick to defunctzombie_zz
15:46:41  <bnoordhuis>not online on skype, not reachable by phone. he's probably in court then
15:47:22  * loladirojoined
15:47:27  * inolenjoined
15:47:53  * inolenquit (Client Quit)
15:47:55  * dshaw_quit (Ping timeout: 272 seconds)
15:49:04  <wrl>bnoordhuis: could reproduce it, have a really interesting strace output actually
15:49:13  <mmalecki>bnoordhuis: #npmalloc - node-like C modules
15:49:24  <mmalecki>bnoordhuis: (free discussion at this point ;) )
15:49:43  * c4milojoined
15:50:41  * c4miloquit (Read error: Connection reset by peer)
15:51:01  * defunctzombie_zzchanged nick to defunctzombie
15:51:03  * c4milojoined
15:51:04  <mmalecki>bnoordhuis: you wanna wait until tomorrow to get him to go with us?
15:53:41  <bnoordhuis>mmalecki: on the phone, 1 sec
15:54:07  <wrl>bnoordhuis: where do you want me to put this strace output? put it in a gist and link it from the issue?
15:56:12  * inolenjoined
15:56:13  * inolenquit (Client Quit)
15:58:44  * inolenjoined
15:58:44  * inolenquit (Client Quit)
16:06:10  * mikealquit (Quit: Leaving.)
16:06:19  * mikealjoined
16:08:37  * abraxasjoined
16:09:13  <MI6>nodejs-master-windows: #448 UNSTABLE windows-x64 (26/655) windows-ia32 (27/655) http://jenkins.nodejs.org/job/nodejs-master-windows/448/
16:13:03  * abraxasquit (Ping timeout: 245 seconds)
16:14:40  * c4miloquit (Remote host closed the connection)
16:15:13  * c4milojoined
16:18:53  <mmalecki>bnoordhuis: so what's hood?
16:19:17  * c4miloquit (Ping timeout: 240 seconds)
16:21:38  * TooTallNatejoined
16:21:46  * indexzeroquit (Ping timeout: 246 seconds)
16:24:44  * dap_joined
16:29:01  <bnoordhuis>mmalecki: sorry, took a bit longer than expected
16:29:16  * amartensjoined
16:29:17  <bnoordhuis>mmalecki: how about we move it tomorrow?
16:29:29  <bnoordhuis>or saturday, whatever works best for you
16:29:34  <mmalecki>bnoordhuis: sure, both work
16:30:01  <mmalecki>bnoordhuis: /join #npmalloc
16:30:03  <bnoordhuis>wrl: a gist probably works best if it's big
16:30:15  <bnoordhuis>mmalecki: maybe later, dinner is ready here :)
16:30:26  <bnoordhuis>okay, gotta run. biab!
16:30:27  <mmalecki>bnoordhuis: a'ight. talk to you tomorrow then
16:31:09  <MI6>libuv-master: #314 ABORTED smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/314/
16:31:10  <MI6>libuv-master-gyp: #256 FAILURE smartos-ia32 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/256/
16:35:38  * st_lukejoined
16:35:56  * inolenjoined
16:36:09  * c4milojoined
16:36:31  * mikealquit (Quit: Leaving.)
16:37:01  * mikealjoined
16:39:55  <indutny>bnoordhuis: heya
16:40:01  <indutny>bnoordhuis: what do you think https://github.com/indutny/blog/commit/32f9e1523f21c1abc89509744a0eed10e9774340
16:40:07  <indutny>bnoordhuis: my blog post wip
16:40:21  <indutny>not finished yet, but pretty intriguing, isn't it? :)
16:40:49  * paddybyers_joined
16:41:22  * paddybyersquit (Ping timeout: 246 seconds)
16:41:23  * paddybyers_changed nick to paddybyers
16:41:27  <indutny>mmalecki: I'd glad if you'll look at it too
16:41:36  <indutny>isaacs: tjfontaine : trevnorris : TooTallNate : you guys are also invited
16:41:38  <indutny>:)
16:41:48  <TooTallNate>a party you say?
16:41:51  * mikealquit (Ping timeout: 272 seconds)
16:41:58  <indutny>TooTallNate: haha
16:42:00  <indutny>if you wish so
16:42:06  * c4miloquit (Remote host closed the connection)
16:42:37  <indutny>I'm going to add code generation chapter today
16:42:43  * c4milojoined
16:42:44  <indutny>after a bottle of beer
16:43:07  * bnoordhuisquit (Ping timeout: 272 seconds)
16:43:39  * dshaw_joined
16:45:10  <tjfontaine>flamegraph of active malloc location stacks -- http://us-east.manta.joyent.com/tjfontaine/public/graph.20.svg
16:45:12  * wwicksjoined
16:47:18  * c4miloquit (Ping timeout: 252 seconds)
16:48:03  * dshaw_quit (Ping timeout: 245 seconds)
16:51:08  * wwicksquit (Quit: wwicks)
16:52:37  * wwicksjoined
16:52:40  <wwicks>k
16:53:15  * mcavage_quit (Remote host closed the connection)
16:53:42  * mcavagejoined
16:54:30  * loladiroquit (Quit: loladiro)
16:55:28  <MI6>libuv-master: #315 ABORTED smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/315/
16:55:31  <MI6>libuv-master-gyp: #257 ABORTED smartos-ia32 (3/195) smartos-x64 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/257/
16:56:33  <isaacs>indutny: looking
16:58:18  * mcavagequit (Ping timeout: 252 seconds)
16:59:38  <hueniverse1>I can report that last night during a stress test, the node processes held up at over 3gb (this is new - usually die around 1.8gb). Eventually we reached max v8 size and they went boom, but I consider this a slight improvement.
17:00:03  <tjfontaine>presumably you have set max-old-space and max-new-space
17:00:48  * dshaw_joined
17:00:49  <tjfontaine>hueniverse1: did you see that flamegraph link above? that's where the memory "leak" is happening, still looking into why it seems like we're leaking v8 handlescopes there
17:01:41  <tjfontaine>hueniverse1: also, when they go boom do you collect the cores?
17:02:41  <isaacs>dap_: /join #npmalloc if you're interested
17:03:12  * loladirojoined
17:05:51  * brsonjoined
17:09:32  * bradleymeckquit (Quit: bradleymeck)
17:10:05  <hueniverse1>tjfontaine: we should have cores, but I am not expecting to learn anything. we just overwhelm them until they run out of memory
17:10:28  <hueniverse1>tjfontaine: they lasted longer than other systems upstream...
17:10:47  <tjfontaine>so this is pure DDoS stress test? :)
17:11:05  <hueniverse1>tjfontaine: that's one way to call Black Friday
17:11:26  * defunctzombiechanged nick to defunctzombie_zz
17:11:27  <tjfontaine>heh ok
17:13:59  * st_lukequit (Read error: Connection reset by peer)
17:14:07  * st_lukejoined
17:20:35  * AvianFluquit (Remote host closed the connection)
17:23:49  <indutny>isaacs: thanks
17:25:48  <hueniverse1>tjfontaine: do you know what we are leaking? are those buffer handles?
17:26:10  <tjfontaine>they appear to be handlescope data
17:27:03  <hueniverse1>what's that?
17:27:26  <tjfontaine>a HandleScope is what roots object creation so the GC knows not to free Local's that were created inside it
17:28:03  * paulfryzeljoined
17:28:17  <tjfontaine>in this case though, it seems like HandleScope's are being created, but not being free'd, but also being kept in a list somewhere so they're still referenced and thus not appearing in leak detection
17:28:42  * AvianFlujoined
17:32:48  <hueniverse1>can you tell what that list is?
17:32:57  * mcavagejoined
17:33:08  * defunctzombie_zzchanged nick to defunctzombie
17:33:23  <tjfontaine>not yet
17:38:32  <isaacs>trevnorris: eureka! simplified test case: https://gist.github.com/isaacs/7253804
17:39:34  <isaacs>trevnorris: it looks like the immediate queue isn't being handled the same way that the timeout queue is
17:39:45  * tjfontaineruns away
17:40:01  * TooTallNatequit (Remote host closed the connection)
17:40:20  * bradleymeckjoined
17:40:32  * TooTallNatejoined
17:42:36  <isaacs>trevnorris: good call
17:42:56  <tjfontaine>o0
17:44:51  <isaacs>trevnorris: simplest test case i can come up with: https://gist.github.com/isaacs/7253804
17:45:12  <isaacs>actually, the nextTick isn't necessary there
17:49:17  * bnoordhuisjoined
17:53:09  <isaacs>trevnorris: close to a fix!
17:53:33  <isaacs>basically, setImmediate isn't doing the try/finally junk that setTimeout/Interval do
17:53:47  <isaacs>i'm guessing this is already a bug with domains in master
17:53:58  * bnoordhuisquit (Ping timeout: 256 seconds)
17:53:59  <tjfontaine>this happened with the queue rework?
17:55:31  * st_lukequit (Read error: Connection reset by peer)
17:56:00  * st_lukejoined
18:01:00  * dshaw_quit (Quit: Leaving.)
18:03:26  * loladiroquit (Quit: loladiro)
18:05:02  * loladirojoined
18:09:32  * abraxasjoined
18:12:51  * mikealjoined
18:14:20  * abraxasquit (Read error: Operation timed out)
18:14:30  * inolenquit (Quit: Leaving.)
18:15:06  * inolenjoined
18:21:23  <MI6>libuv-master: #316 ABORTED osx (1/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/316/
18:24:45  * c4milojoined
18:25:22  * einarosquit (*.net *.split)
18:29:18  * c4miloquit (Ping timeout: 245 seconds)
18:32:25  * austojoined
18:33:43  * loladiroquit (Quit: loladiro)
18:34:43  * loladirojoined
18:34:54  * loladiroquit (Client Quit)
18:39:02  * loladirojoined
18:40:47  <MI6>libuv-master-gyp: #258 FAILURE http://jenkins.nodejs.org/job/libuv-master-gyp/258/
18:45:45  <MI6>libuv-master-gyp: #259 ABORTED smartos-ia32 (2/195) smartos-x64 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/259/
18:46:28  <MI6>libuv-master-gyp: #260 FAILURE http://jenkins.nodejs.org/job/libuv-master-gyp/260/
18:48:26  <trevnorris>isaacs: thanks a lot dude.
18:58:57  * loladiroquit (Quit: loladiro)
18:59:37  * bradleymeckquit (Quit: bradleymeck)
19:01:02  * bradleymeckjoined
19:01:46  <MI6>nodejs-master-windows: #449 UNSTABLE windows-x64 (29/655) windows-ia32 (28/655) http://jenkins.nodejs.org/job/nodejs-master-windows/449/
19:02:46  * kevinswiberjoined
19:04:06  <trevnorris>isaacs: ah, see why the large test doesn't show that case, at least on my box. even though the two setImmediate's are called right next to each other, they're not called close together for some reason.
19:05:19  * dshaw_joined
19:05:28  <trevnorris>isaacs: ah, and the fact that it's happening w/ setImmediate makes other issues make sense (because _tickCallback is called using setImmediate as well. which could also screw with the execution order)
19:06:13  <trevnorris>indutny: nice little post. i'm looking forward to reading the rest of it. let me know when you're done :)
19:06:21  <indutny>haha
19:06:21  <indutny>thanks
19:06:23  <indutny>will do
19:06:27  <indutny>I'm working on the example
19:07:55  <isaacs>ugh, the naming in this _linklist thing always fucks with me so hard.
19:08:05  <trevnorris>haha
19:08:15  <isaacs>i'm trying to write a L.concat(head,tai) function
19:08:25  <isaacs>also, the "loop to self means empty" is weird.
19:08:40  <trevnorris>isaacs: but at the least this seems not to be a bug in my code?
19:08:47  <isaacs>trevnorris: in this case, now
19:08:48  <isaacs>*no
19:09:02  <isaacs>trevnorris: except insofar as your code lacks a patch to make setImmediate handle errors properly :)
19:09:09  * trevnorristhanks the heavens
19:09:10  <isaacs>trevnorris: but arguably that's an error in my and tjfontaine's codes
19:09:11  <trevnorris>heh
19:09:18  <isaacs>we all share code here.
19:09:57  <indutny>trevnorris: was it clear?
19:10:06  <trevnorris>isaacs: just wonder what it is about the systems that made those tests fail just that way, but, except for your simplified test case, haven't been able to reproduce on my box.
19:10:35  <tjfontaine>_linklist is just a pain in the ass to deal with, we need a proper tree library in core :/
19:11:33  <isaacs>trevnorris: yeah, seems to be particular to other stuff going on
19:11:37  <trevnorris>indutny: yeah it was. coming from a guy that has zero experience in almost all of those areas, at the least it let me know what more I need to learn about.
19:11:43  <isaacs>trevnorris: the setImmediates and setTimeouts have to line up just right
19:11:52  <indutny>trevnorris: cool, thanks
19:12:18  <trevnorris>isaacs: i still wonder how the execution failed just right to get the process on exit callback to fire twice on the windows machine.
19:12:33  <trevnorris>must have something to do with the setImmediate(process._tickCallback)
19:12:53  <isaacs>ok, screwit, i'm just gonna do the while(shift())push() approach
19:12:59  * AvianFluquit (Remote host closed the connection)
19:13:18  <isaacs>L.concat is failing to deliver what i want, unless i make it insane to match the insanity of linklist
19:14:43  <tjfontaine>the concepts of prev and next for our linklist are kinda bonkers, it's always basically opposite of what I want to say they mean
19:15:14  <tjfontaine>at least from how the shift works
19:17:11  * c4milojoined
19:18:01  * einarosjoined
19:24:25  <indutny>trevnorris: just in case, if you're curious
19:24:32  <indutny>trevnorris: here is what I'll get to in result - https://github.com/indutny/jit.js-example/blob/master/main.js
19:24:49  <indutny>surprisingly it works
19:24:52  * AvianFlujoined
19:25:04  <isaacs>trevnorris: https://gist.github.com/isaacs/63f8e7fd092e71ddfc34
19:25:19  <isaacs>trevnorris: running the whole suite again
19:26:37  <trevnorris>isaacs: that's one heck of a test :)
19:26:48  <trevnorris>isaacs: nice job, and thanks for tracking this down.
19:26:52  <isaacs>trevnorris: no problem
19:27:53  * bradleymeckquit (Quit: bradleymeck)
19:29:12  <isaacs>hrm, test/simple/test-tls-client-reject.js is failing on master
19:29:42  <trevnorris>indutny: dude, that's nuts. pretty cool stuff. honestly seeing it done in js makes it simpler for people w/ web dev backgrounds like myself :)
19:29:52  <indutny>great!
19:29:57  <indutny>isaacs: seriously?
19:30:02  <indutny>is it stable?
19:30:22  <isaacs>indutny: yep
19:30:23  <isaacs>ba7c9ce9649886edf77d01cdcec216c8a0c76f48 is the first bad commit
19:30:23  <isaacs>commit ba7c9ce9649886edf77d01cdcec216c8a0c76f48
19:30:23  <isaacs>Author: Fedor Indutny <fedor.indutny@gmail.com>
19:30:23  <isaacs>Date: Mon Oct 28 16:10:10 2013 +0400
19:30:25  <isaacs>tls: do not default to 'localhost' servername
19:30:31  <indutny>shit
19:30:38  <indutny>ahh
19:30:49  <indutny>I overlooked test failures, sorry
19:30:57  <indutny>the commit is ok, we just need to fix tests
19:31:03  <isaacs>indutny: it's ok, it happens :) please fix asap.
19:31:03  <indutny>and servername: where applicable
19:31:15  <isaacs>indutny: seems like the only test affected is that one
19:31:20  <indutny>ok
19:31:21  <indutny>thanks
19:31:24  <indutny>and sorry
19:31:41  <isaacs>indutny: no worries. fixing the bug is better than an apology :)
19:32:07  <isaacs>indutny: looks like you're right, the test is just incorrect
19:32:32  <isaacs>trevnorris: that's the only failure i'm seeing, so if you wanna pull that patch for setImmediate, if it lgty, then 6011 lgtm
19:32:34  <indutny>yep
19:33:28  <trevnorris>isaacs: awesome. i'll bring it in then push to 6011-isfinal for one last run. if that passes applicable tests then i'll merge it.
19:34:17  <isaacs>k great!
19:34:23  * FROGGSquit (Ping timeout: 272 seconds)
19:34:36  * amartensquit (Read error: Connection reset by peer)
19:35:41  * bnoordhuisjoined
19:37:17  * octetcloudquit (Quit: WeeChat 0.4.2)
19:39:36  <tjfontaine>trevnorris: weee
19:40:21  <MI6>joyent/node: Fedor Indutny master * 21fbbd5 : test: fix tls-client-reject after ba7c9ce96 - http://git.io/15Iflg
19:40:36  <indutny>bnoordhuis: tjfontaine: isaacs: trevnorris: may I ask you guys to proof read it https://github.com/indutny/blog/commit/0371b8d707e0fa6548822813cb13f2edf4dd3cf3 ?
19:40:39  <indutny>please
19:40:49  <indutny>I'm still quite borked at engrish :P
19:41:12  <trevnorris>indutny: sure, just give me a bit to get 6011 in. :)
19:41:17  <indutny>thanks!
19:42:44  * octetcloudjoined
19:42:45  * bradleymeckjoined
19:44:44  <tjfontaine>indutny: yup I will
19:44:50  <indutny>thank you, man
19:44:53  * loladirojoined
19:49:26  * FROGGSjoined
19:49:32  * loladiroquit (Ping timeout: 268 seconds)
19:53:51  * kevinswiberquit (Remote host closed the connection)
19:54:26  * kevinswiberjoined
19:58:07  <MI6>nodejs-master: #662 UNSTABLE smartos-ia32 (7/655) linux-x64 (1/655) smartos-x64 (9/655) http://jenkins.nodejs.org/job/nodejs-master/662/
19:59:21  * kevinswiberquit (Ping timeout: 272 seconds)
20:00:40  * amartensjoined
20:01:01  * loladirojoined
20:10:09  * st_lukequit (Remote host closed the connection)
20:10:21  * abraxasjoined
20:11:13  <bnoordhuis>indutny: reviewed :)
20:11:38  <indutny>bnoordhuis: thanks
20:11:42  <indutny>bnoordhuis: what do you think about it?
20:11:43  <indutny>btw
20:11:50  <indutny>where the stack grows if not upwards?
20:12:02  <indutny>in my opinion address = 0 is up
20:12:06  <indutny>and 0xffffff... is a botto
20:12:08  <indutny>bottom
20:13:47  <bnoordhuis>oh, like that
20:14:09  <bnoordhuis>most people would qualify that as a stack that grows downwards :)
20:14:49  <isaacs>Wikis are the best thing ever for documentation until the day when they're suddenly the worst thing ever for documentation.
20:15:17  * abraxasquit (Ping timeout: 272 seconds)
20:15:56  <indutny>bnoordhuis: haha
20:16:02  <indutny>bnoordhuis: well, I feel sorry
20:16:09  <indutny>but I'l lleave it as it is!
20:16:24  <bnoordhuis>sure, it's your blog post
20:18:18  * bradleymeckquit (Quit: bradleymeck)
20:18:55  <MI6>nodejs-master-windows: #450 UNSTABLE windows-x64 (25/655) windows-ia32 (28/655) http://jenkins.nodejs.org/job/nodejs-master-windows/450/
20:19:18  <MI6>joyent/node: Sam Roberts v0.10 * 155df9c : doc: document node signal handling - http://git.io/PUAb7A
20:24:22  * bradleymeckjoined
20:26:58  <indutny>bnoordhuis: thank you again!
20:31:00  <MI6>nodejs-v0.10: #1573 UNSTABLE smartos-x64 (4/603) smartos-ia32 (5/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1573/
20:32:00  <octetcloud>bnoordhuis: #6365, thoughts?
20:33:11  <octetcloud>anybody... how on earth do you remember the set of node issues you are interested in? there isn't any way to search node issues for all the ones that you have commented on?
20:33:40  <octetcloud>there is a mentions:, but that doesn't cover your own comments
20:36:12  <MI6>joyent/node: isaacs v0.10 * 849c92f : doc: Correct and add several items - http://git.io/ZdEoeA
20:37:19  <isaacs>added link to nodejsrections ^
20:37:25  <isaacs>(finally)
20:42:21  <hueniverse1>trevnorris: https://gist.github.com/trevnorris/7204785#file-timeout-hammer-revised-js-L38
20:42:35  <hueniverse1>trevnorris: have not seen this style before. what is 'this' here?
20:42:47  <hueniverse1>trevnorris: I'm assuming 'req' but who binds it?
20:43:25  <trevnorris>hueniverse1: EventEmitter#emit() uses call/apply and passes the context along.
20:43:53  <hueniverse1>trevnorris: INTERESTING...
20:44:59  <hueniverse1>trevnorris: but since you are already passing callback, might as well just pass req too into finish and save the call()
20:45:22  <bnoordhuis>octetcloud: remember issue numbers? surely you jest, mr. roberts
20:46:06  <trevnorris>hueniverse1: can't do that because of req._timeoutId = setTimeout
20:46:18  <trevnorris>or, I guess you could and just check if the argument is set
20:47:06  * jcrugzzquit (Ping timeout: 252 seconds)
20:47:09  <indutny>bnoordhuis: and we're live http://blog.indutny.com/4.how-to-start-jitting
20:47:12  <indutny>bnoordhuis: thanks again :P
20:47:18  * hueniverse1quit (Quit: Leaving.)
20:47:37  * hueniversejoined
20:47:44  <bnoordhuis>np :)
20:47:51  <MI6>nodejs-v0.10: #1574 UNSTABLE smartos-x64 (5/603) smartos-ia32 (4/603) linux-x64 (1/603) osx-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1574/
20:48:16  * piscisaureus_joined
20:48:35  <MI6>nodejs-v0.10-windows: #297 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/297/
20:48:55  <indutny>trevnorris: just FYI http://blog.indutny.com/4.how-to-start-jitting
20:49:02  <trevnorris>indutny: thanks :)
20:49:05  <indutny>haha
20:49:07  <indutny>no, thank you
20:49:34  <indutny>whoa
20:49:37  <indutny>I can finally return to work
20:50:16  * TooTallNatequit (Remote host closed the connection)
20:52:01  * TooTallNatejoined
21:01:49  * bradleymeckquit (Quit: bradleymeck)
21:08:48  * robonerdjoined
21:09:02  * loladiroquit (Quit: loladiro)
21:09:53  <isaacs>ok, i'm sold. i really like #6011
21:09:57  <isaacs>trevnorris: good job.
21:10:01  <robonerd>hello, can anyone help me understand how to decide between libev/uv/event/other for platform portable, highly concurrent, sync & async capable C network programming library please?
21:10:18  <isaacs>a feature that is useful for finding bugs in other features is always welcome :)
21:11:05  <trevnorris>isaacs: heh, thanks. i'm almost ready with it. just incorporating the error handling info I've learned into the tests.
21:11:57  * c4miloquit (Remote host closed the connection)
21:13:25  <bnoordhuis>robonerd: what are your criteria?
21:13:30  <trevnorris>groundwater_: ping, have you ever signed the CLA?
21:13:47  <bnoordhuis>robonerd: libev isn't really cross-platform btw, unless you only count unices
21:14:45  <robonerd>which one has good portable support bnoordhuis ?
21:15:00  <robonerd>i heard libuv has good windows support, although my primary platform personally is freebsd
21:15:05  <hueniverse>othiym23: lab now allows running tests directly with node test.js
21:15:23  <bnoordhuis>robonerd: yeah, windows is a first-class citizen in libuv
21:16:01  <bnoordhuis>robonerd: libevent supports windows as well, i think. not sure though how well
21:16:23  <bnoordhuis>robonerd: when we reviewed it for the windows port of node years ago, it was found lacking
21:16:45  <bnoordhuis>that was in 2010 or 2011 though. things may have changed
21:19:01  <MI6>nodejs-v0.10-windows: #298 UNSTABLE windows-ia32 (13/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/298/
21:19:07  <MI6>joyent/node: Trevor Norris 011-isfinal * 6eaaaca : doc: add docs for AsyncListeners (+8 more commits) - http://git.io/2fz_eA
21:20:02  <trevnorris>tjfontaine: if jenkins hasn't, mind kick starting this ^
21:20:08  <tjfontaine>it should be fine
21:20:11  <trevnorris>thanks :)
21:22:06  * loladirojoined
21:22:19  * piscisaureus_quit (Ping timeout: 272 seconds)
21:23:32  <robonerd>i think libuv might have it
21:23:36  <robonerd>what is libuv's license?
21:23:40  <tjfontaine>mit
21:24:05  <robonerd>bsd compatible, yes!
21:24:28  * AvianFluquit (Remote host closed the connection)
21:25:11  <robonerd>what is th eofficial home page of libuv?
21:25:34  <robonerd>https://github.com/joyent/libuv <- this?
21:25:43  <indutny>just curious
21:25:51  <indutny>is MIT compatible with every license except GPL?
21:25:51  <bnoordhuis>robonerd: yes, more or less. libuv.org is where we put up tarballs
21:26:12  <indutny>bnoordhuis: not https
21:26:15  <indutny>not secure :P
21:26:48  <robonerd>bnoordhuis https://github.com/joyent/libuv <- ?
21:27:08  <bnoordhuis>yep
21:27:26  <robonerd>okie
21:27:36  <robonerd>libuv should have a home page like sinatrarb.com has
21:27:43  <robonerd>get all web 3.0
21:27:58  <bnoordhuis>i think it's fair to say that none of us are great web designers :)
21:28:10  * AvianFlujoined
21:28:29  <robonerd>anyone here using libuv on freebsd?
21:28:33  <trevnorris>hey, get me a design and I can implement it :)
21:28:44  * bnoordhuisraises hand
21:29:08  <robonerd>bnoordhuis seriously? freebsd is my primary distribution platform
21:29:27  <bnoordhuis>well, one of my systems is a freebsd system
21:29:37  <robonerd>i'm building a grid/node platform (partly why i'm evaluating network libs vs doing it directly myself in C)
21:29:51  <robonerd>know of many freebsd shops using libuv?
21:29:57  <robonerd>shops/projects
21:30:20  <bnoordhuis>not really, i think. but i don't know that many freebsd shops at all
21:30:30  <bnoordhuis>node and rust use libuv, of course, and both run on freebsd
21:30:43  <bnoordhuis>julia too, though i don't know if freebsd is a supported platform
21:31:35  <bnoordhuis>seems it is
21:31:48  <tjfontaine>we should also help julia get onto a release branch/tag
21:32:20  <bnoordhuis>last i heard they were working on that and pretty close
21:32:42  <robonerd>oo, rust
21:32:44  <robonerd>nice family
21:32:54  <robonerd>wtf is julia
21:33:31  <bnoordhuis>a programming language. like R, but fast and non-crufty
21:33:42  <trevnorris>bnoordhuis: been thinking about your idea of making libuv pull based instead of pushed based. every day that seems more awesome.
21:33:50  <bnoordhuis>robonerd: https://github.com/JuliaLang/julia
21:34:13  <robonerd>trevnorris what does that mean, to make the lib pull based vs pushed based?
21:36:32  <trevnorris>robonerd: instead of immediately firing events when ready they're queued then you ask for them when your ready.
21:36:46  <tjfontaine>more or less
21:36:56  <bnoordhuis>robonerd: push-based means libuv pushes events to you through callbacks
21:37:10  <bnoordhuis>robonerd: pull-based means libuv would give you events when you ask for them
21:37:26  * amartensquit (Quit: Leaving.)
21:37:39  <bnoordhuis>callbacks are convenient for c and c++ code but they're often hell for people that have to deal with ffis
21:37:52  <robonerd>ah, what i always wonder in a pull based design, how do the clients know when to ask for them
21:38:16  <robonerd>as soon as server finishes, it pushes. simple. how does the other direction work?
21:38:37  <bnoordhuis>there's a couple of options
21:38:48  <bnoordhuis>you could have a uv_poll() function which kind of works like uv_run()
21:39:01  <bnoordhuis>but instead of invoking callbacks it just hands you a list of event objects
21:39:10  <robonerd>isn't polling bad practice for high performance?
21:39:10  <bnoordhuis>then it's up to you to dispatch them or whatever
21:39:21  <trevnorris>bnoordhuis: i'm curious though, how would you handle back pressure from incoming data? give it a max amount of data to hold before automatically pausing the connection?
21:39:21  <bnoordhuis>only if you're busy-looping :)
21:39:22  * AvianFlu_joined
21:39:59  <bnoordhuis>uv_poll() would look something like int uv_poll(uv_event_t* events, unsigned nevents, int timeout);
21:40:19  <bnoordhuis>that is, block until the timeout expires or return early when events are ready
21:40:33  <bnoordhuis>(actual api subject to change, of course)
21:40:56  <bnoordhuis>trevnorris: something like that. dealings with reads is one of the open questions actually
21:41:09  * AvianFluquit (Ping timeout: 268 seconds)
21:41:37  <trevnorris>bnoordhuis: cool. was having this discussion w/ a co-worker about the proposed w3 streams api. hadn't noticed it until he pointed it out. almost gave me a heart attack.
21:42:22  <bnoordhuis>i understand people are not pleased with the proposal?
21:42:40  <robonerd>i think i'm looking for something that uses libuv, but is 1 level higher of astraction. so in the way sinabrarb.com gives abstract interface to reacting to http events, i'd like a C library giving me high level interface to abstract network events in general, no matter the protocol
21:42:43  <trevnorris>imo, it' a mess.
21:42:47  <trevnorris>*it's
21:43:08  <robonerd>something that handles platform portable concurrency and asynchronous network
21:43:12  <tjfontaine>trevnorris: you weren't awake when Domenic_ and isaacs were talking about it in here?
21:43:19  * amartensjoined
21:43:30  <bnoordhuis>robonerd: libuv has that in spades but it's deliberately low-level-ish
21:43:41  <trevnorris>tjfontaine: nope. how long ago? i'll look back through the logs
21:44:01  <bnoordhuis>robonerd: maybe libevent or qt might better suit your requirements?
21:44:11  * jcrugzzjoined
21:44:16  <tjfontaine>trevnorris: this week, maybe yesterday even
21:44:23  <robonerd>bnoordhuis can you explain how low levelish you mean?
21:45:22  <bnoordhuis>robonerd: well, libuv provides the basic building blocks. it's up to you to make something out of it
21:45:37  <bnoordhuis>robonerd: it's basically the opposite of the 'batteries included' mentality
21:45:43  <trevnorris>come on windows! almost there. then I can merge this thing.
21:46:19  <robonerd>ok
21:46:22  <robonerd>sounds like a challenge
21:46:50  <robonerd>i've spent 1.5 years doing a lot of C. before that 4 years objc and before that ruby. how much challenge would you estimate?
21:46:52  <bnoordhuis>most people seem to like it. you should think of it as a library, not a framework
21:47:23  <MI6>libuv-v0.10-gyp: #90 FAILURE windows-x64 (7/189) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/90/
21:47:49  <bnoordhuis>the api is designed to be pretty easy to use but you will need some c skills
21:48:30  <bnoordhuis>you could always consider using node, of course. you'd still be using libuv, only indirectly :)
21:48:47  <robonerd>bnoordhuis what would the approach look like to implement concurrency? (meaning system worker threads)
21:48:52  <robonerd>would i bring in another lib?
21:49:59  <bnoordhuis>no. libuv has functions for creating threads, mutexes, rwlocks, etc.
21:50:28  <bnoordhuis>but they're all basic primitives though. don't expect an AbstractSynchronizedQueue or anything like that :)
21:50:54  <tjfontaine>FinalAbstractSealedSynchronizedQueueFactory
21:51:10  <robonerd>bnoordhuis but they are platform portable threads/etc?
21:51:13  <bnoordhuis>yeah. i knew mine was too easy
21:51:18  <bnoordhuis>robonerd: yes
21:51:22  <robonerd>er better way to say it: platform portable concurrency toolbox
21:51:27  <tjfontaine>it's not OOP if the class name doesn't fill 80columns
21:51:41  <bnoordhuis>robonerd: yep. i worked very hard to make it that way, even on windows xp :)
21:51:52  <robonerd>how long did it take you to make this?
21:52:24  <bnoordhuis>the threading/locking functions? a few man days, i think. got some pull requests from others
21:53:17  <isaacs>trevnorris: how goes the 6011 merging?
21:53:25  <robonerd>took you a few days to make something a ton of ppl have used as a lib?
21:53:38  <trevnorris>isaacs: just waiting for jenkins to give me the go on windows. almost done.
21:53:39  <robonerd>if it's so 'easy' why do ppl even use the lib and not just code it directly?
21:53:45  <isaacs>trevnorris: fantastic
21:54:00  <bnoordhuis>robonerd: i guess because it's only easy if you know all the ins and outs
21:54:23  <robonerd>bnoordhuis how much experience do you have with network programming?
21:54:59  <bnoordhuis>a lot, i guess. i started with unix networking in the mid '90s
21:55:16  <bnoordhuis>when 8 MB RAM was still a lot
21:55:31  <tjfontaine>640k is all you'll ever need
21:55:50  <bnoordhuis>you can get a lot done with 640k, 'tis true
21:56:02  <robonerd>bnoordhuis how many years have you actively worked with network programming i mean, not just the first time
21:56:11  <groundwater_>trevnorris: I have signed the CLA, but not under my newrelic.com address
21:56:16  <bnoordhuis>my first home computer was a c64. good times, i still know most 6502 opcodes
21:56:44  <bnoordhuis>robonerd: 15+ years now
21:57:43  <robonerd>ah so it's your specialty
21:57:54  <robonerd>how many years have you worked with C?
21:58:13  <bnoordhuis>about the same, i think
21:58:35  <bnoordhuis>i think i picked up c shortly before making the switch to unix
21:58:43  <robonerd>that's great. i really enjoy C
21:58:51  <robonerd>i'm sure it has 'worn well' on you in those years
21:59:00  <bnoordhuis>yeah :)
22:01:31  * pachetquit (Quit: leaving)
22:05:04  <MI6>node-review: #102 UNSTABLE osx-x64 (1/671) smartos-x64 (9/671) centos-x64 (1/671) windows-x64 (27/671) windows-ia32 (29/671) centos-ia32 (1/671) smartos-ia32 (7/671) http://jenkins.nodejs.org/job/node-review/102/
22:05:26  <tjfontaine>it looks scary, but probably not
22:07:32  * piscisaureus_joined
22:08:33  <bnoordhuis>piscisaureus_: what ho, bertje. coming to utrecht tomorrow?
22:08:59  <tjfontaine>trevnorris: http://jenkins.nodejs.org/job/node-review/102/DESTCPU=ia32,label=windows/tapTestReport/test.tap-4/ and http://jenkins.nodejs.org/job/node-review/102/DESTCPU=ia32,label=windows/tapTestReport/test.tap-11/ the last one is weird though: "AssertionError: -1 != -1" :)
22:09:09  <trevnorris>tjfontaine: yeah. looking now.
22:09:50  <trevnorris>bugger. I seriously need a windows env to debug this crap.
22:10:02  <trevnorris>it passed with flying colors on all the other systems.
22:10:15  <trevnorris>tjfontaine: but, i mean. look how many other tests are failing: http://jenkins.nodejs.org/job/node-review/DESTCPU=x64,label=windows/102/tapTestReport/
22:10:21  <tjfontaine>oh I know
22:10:28  <tjfontaine>master+windows is in very bad shape.
22:11:10  <tjfontaine>there's going to need to be a sprint on fixing it before release
22:11:19  * abraxasjoined
22:11:32  <tjfontaine>hopefulyl we can recruit someone with time and interest in windows who will help maintain it :)
22:11:50  * piscisaureus_quit (Ping timeout: 240 seconds)
22:13:23  <wrl>"interest in windows"
22:13:59  <tjfontaine>are you volunteering? :)
22:14:24  <wrl>let's not get hasty now
22:14:38  <wrl>i don't need to go grey any faster than i already am ;)
22:14:45  <MI6>libuv-master-gyp: #261 FAILURE smartos-ia32 (2/195) windows-x64 (8/196) http://jenkins.nodejs.org/job/libuv-master-gyp/261/
22:15:02  <tjfontaine>sigh, libuv on windows is now hanging on the last test
22:15:09  <tjfontaine>or a test
22:15:22  * AvianFlu_quit (Remote host closed the connection)
22:15:34  <tjfontaine>right last test, or waiting for the test runner to clean up
22:16:06  * jcrugzzquit (Ping timeout: 246 seconds)
22:16:08  * abraxasquit (Ping timeout: 260 seconds)
22:24:48  <trevnorris>isaacs: got a tiny over zealous w/ the tests and made a bad assumption about the number of data events that could occur. have a fix for the test.
22:29:22  <trevnorris>hahaha. man. error handling is awesome. I need to verify something. it looks like if an error handler is placed on both the server and the client request then a client event error will also fire on the server listener.
22:31:52  * austoquit (Quit: austo)
22:32:32  <bnoordhuis>about to sign off. any last questions, comments, pleas..?
22:33:08  <bnoordhuis>no? sleep tight then, people
22:33:13  <tjfontaine>war, what is it good for?
22:33:25  <bnoordhuis>innovation, overpopulation
22:33:47  <tjfontaine>heh
22:34:03  * rendarquit (Quit: good night)
22:37:16  <indutny>bnoordhuis: sleep tight
22:38:12  * bnoordhuisquit (Ping timeout: 252 seconds)
22:43:23  * superjoe30quit (Ping timeout: 272 seconds)
22:45:09  * austojoined
22:59:39  <trevnorris>it's like my personal hell. race conditions in asynchronous error handling.
23:00:39  <isaacs>trevnorris: which test?
23:00:59  <trevnorris>isaacs: http://jenkins.nodejs.org/job/node-review/DESTCPU=x64,label=windows/102/tapTestReport/test.tap-4/
23:02:07  * loladiroquit (Quit: loladiro)
23:02:49  <isaacs>trevnorris: that is weird..
23:02:56  * defunctzombiechanged nick to defunctzombie_zz
23:04:28  <isaacs>trevnorris: you're pushing the message into the list, and then it's not found?
23:04:43  <trevnorris>isaacs: so, there's some race condition I think in the order of processing the error events that cause the error on connection.on('data' to be processed by the error handler twice
23:04:48  <isaacs>trevnorris: oh, i see, you're getting an extra data event, it looks like
23:05:02  <trevnorris>not extra data events, that's what i've been looking for
23:05:07  <trevnorris>extra error events.
23:06:23  * austoquit (Quit: austo)
23:08:07  * dshaw_quit (Quit: Leaving.)
23:11:17  * austojoined
23:11:31  <trevnorris>isaacs: so I created an almost duplicate test that just adds the listener at the beginning of the script, and verified that the connection and server still have listeners on them. but for some reason adding it after the fact is causing it to explode.
23:13:01  <isaacs>trevnorris: but it's throwing from your callbacksObj.error handler
23:13:19  <isaacs>Error: Message not found: net - server data
23:13:21  <trevnorris>isaacs: another issue is that if I use process._rawDebug from the error event then it finishes differently.
23:13:22  * austoquit (Client Quit)
23:13:45  <trevnorris>isaacs: yeah. so it pushes 3 messages to the queue and removes one for each error it receives w/ that message
23:13:57  <isaacs>trevnorris: right
23:14:03  <trevnorris>isaacs: so it removes the 3 messages from the queue then receives it again.
23:14:15  <isaacs>so, if, instead of getting a three 'data' events on the server, you get 4, then you'll have exactly this behavior
23:15:41  <trevnorris>in all my testing I only receive 3 data events (checked by keeping counters, printing, etc) but the error event is triggered twice.
23:15:50  <trevnorris>for each data event
23:16:13  <isaacs>trevnorris: interesting.
23:16:32  <isaacs>trevnorris: when yo usay "error event" you mean the callbackObj.error function gets called twice for each uncaught exception?
23:16:53  <trevnorris>isaacs: yes. on the connection.on('data' specifically
23:18:47  * austojoined
23:19:34  * austoquit (Client Quit)
23:21:46  <trevnorris>isaacs: ok, forget everything I've said. i was using console.log() from obj.error(), which for some reason was the trigger, on my machine, for the uncaught exception being called twice.
23:22:24  <trevnorris>isaacs: but when I switched to process._rawDebug for logging it doesn't do that anymore. which means the windows test _could_ be failing from receiving an extra data event.
23:22:47  <trevnorris>isaacs: but still don't exactly know for sure.
23:22:54  <isaacs>trevnorris: lemme try on windows
23:23:05  <isaacs>trevnorris: it'll be a while. i don't really remember how to do node on windows from source.
23:25:04  * piscisaureus_joined
23:25:33  * Kakera_quit (Ping timeout: 245 seconds)
23:25:41  <trevnorris>isaacs: thanks. i'm going to start logging pretty much everything from the test and update 6011-isfinal. keep hoping i've figured out everything I'd need.
23:25:59  <trevnorris>guess this is one reason why we tell people not to lightly handle errors :P
23:35:38  <MI6>joyent/node: Trevor Norris 011-isfinal * 3cf90b4 : doc: add docs for AsyncListeners (+6 more commits) - http://git.io/PD_2zg
23:36:43  <isaacs>\o/
23:36:51  <isaacs>Fly, bots! Fly!
23:36:56  <trevnorris>heh
23:39:15  <isaacs>windows is still "Generating code"
23:40:21  <tjfontaine>THANK GOD FOR CL.EXE
23:40:22  <LOUDBOT>LET'S GIVE UP NOW AND FORM AN AGRARIAN SOCIETY
23:40:28  <tjfontaine>exactly.
23:42:30  <isaacs>tjfontaine: what's cl.exe?
23:42:54  <tjfontaine>the msvc linker, that's what's happening when you see "generating code"
23:43:21  <isaacs>ah, riight
23:44:25  * bnoordhuisjoined
23:45:12  * paulfryzelquit (Remote host closed the connection)
23:49:21  * bnoordhuisquit (Ping timeout: 272 seconds)
23:53:06  <trevnorris>seriously can't believe how much longer it takes to build/run these on windows.
23:54:44  <tjfontaine>welcome to my world.
23:55:03  <tjfontaine>isaacs: can you do an email introduction for me so I can get azure to donate some vms?
23:55:56  <MI6>node-review: #103 UNSTABLE smartos-x64 (9/672) centos-x64 (3/672) windows-x64 (26/672) linux-x64 (2/672) windows-ia32 (26/672) centos-ia32 (1/672) smartos-ia32 (5/672) http://jenkins.nodejs.org/job/node-review/103/
23:57:42  <isaacs>tjfontaine: oh, ok, sure
23:57:53  <isaacs>trevnorris: so... yes, it's definitely calling the errorHandler twice
23:57:56  <isaacs>for the second data event