00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:02:11  <MI6>libuv-master-gyp: #236 FAILURE windows-x64 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/236/
00:02:37  <mmalecki>hmm, being unemployed is so nice, I'm browsing all the libuv issues again
00:03:59  <mmalecki>(also, if you know some good stoner comedies, throw them my way!)
00:08:05  * mcavagequit (Remote host closed the connection)
00:08:39  * mcavagejoined
00:12:56  * mcavagequit (Ping timeout: 256 seconds)
00:18:42  * bradleymeckjoined
00:33:40  * jmar777joined
00:34:43  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
00:36:09  * wwicksjoined
00:42:24  * dshaw_1quit (Quit: Leaving.)
00:43:03  * inolenjoined
00:44:01  * inolenquit (Client Quit)
00:55:07  * Ralithquit (Ping timeout: 272 seconds)
01:05:04  * dap_quit (Quit: Leaving.)
01:05:42  * julianduquejoined
01:07:56  * mcavagejoined
01:08:14  * kenansulaymanquit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
01:09:29  * mcavagequit (Remote host closed the connection)
01:09:57  * mcavagejoined
01:14:31  * mcavagequit (Ping timeout: 260 seconds)
01:17:16  * kenansulaymanjoined
01:22:04  * kenansulaymanquit (Ping timeout: 264 seconds)
01:24:40  * Ralithjoined
01:30:34  * abraxasjoined
01:32:45  * st_lukejoined
01:36:03  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:37:28  * indexzerojoined
01:42:25  * mikealquit (Quit: Leaving.)
01:45:09  * dlmanningquit (Ping timeout: 248 seconds)
01:56:49  * indexzeroquit (Quit: indexzero)
01:57:26  * st_lukequit (Remote host closed the connection)
01:58:05  * st_lukejoined
01:59:36  * david3joined
02:00:46  * dshaw_joined
02:02:13  * st_lukequit (Ping timeout: 248 seconds)
02:05:25  * dshaw_quit (Ping timeout: 248 seconds)
02:07:49  * mikealjoined
02:20:41  * mcavagejoined
02:25:39  * mcavagequit (Ping timeout: 268 seconds)
02:26:02  * julianduquequit (Ping timeout: 264 seconds)
02:36:22  * dominictarr_joined
02:40:22  * brsonquit (Read error: Operation timed out)
02:40:36  * dominictarr_quit (Ping timeout: 245 seconds)
02:45:26  * st_lukejoined
02:45:37  * david3changed nick to dlmanning
02:48:08  * AvianFlujoined
02:58:15  * mikealquit (Quit: Leaving.)
02:59:12  * mikealjoined
03:30:33  * st_lukequit (Remote host closed the connection)
03:31:09  * st_lukejoined
03:35:38  * st_lukequit (Ping timeout: 264 seconds)
03:45:28  * julianduquejoined
03:54:27  * jmar777quit (Remote host closed the connection)
03:54:51  * defunctzombie_zzchanged nick to defunctzombie
03:55:05  * jmar777joined
03:59:21  * jmar777quit (Ping timeout: 245 seconds)
04:03:38  <isaacs>mmalecki: The Big Lebowski
04:03:48  <isaacs>mmalecki: it is canonical
04:04:24  * AvianFluquit (Remote host closed the connection)
04:04:54  <mmalecki>isaacs: saw it, loved it. great idea tho. gonna watch it next, thanks
04:05:31  <isaacs>mmalecki: https://twitter.com/TheNodeLebowski
04:06:14  <mmalecki>haha, of course I follow it
04:07:47  * c4milojoined
04:09:45  * EhevuTovjoined
04:28:38  * einarosquit (Remote host closed the connection)
04:29:22  * einarosjoined
04:31:16  * indexzerojoined
04:34:06  * st_lukejoined
04:45:56  * defunctzombiechanged nick to defunctzombie_zz
04:56:01  * st_lukequit (Remote host closed the connection)
04:56:39  * st_lukejoined
05:01:01  * st_lukequit (Ping timeout: 245 seconds)
05:05:37  * bradleymeckquit (Quit: bradleymeck)
05:07:26  * mikealquit (Quit: Leaving.)
05:08:40  * mikealjoined
05:11:43  * EhevuTovquit (Quit: This computer has gone to sleep)
05:17:34  * julianduquequit (Quit: leaving)
05:23:39  * c4miloquit (Remote host closed the connection)
05:24:16  * c4milojoined
05:28:51  * c4miloquit (Ping timeout: 260 seconds)
05:29:51  * dominictarr_joined
05:32:58  * indexzeroquit (Quit: indexzero)
05:36:49  * dominictarr_quit (Ping timeout: 268 seconds)
05:46:18  * paddybyersjoined
05:51:33  * paddybyersquit (Quit: paddybyers)
05:59:04  * EhevuTovjoined
06:21:56  * st_lukejoined
06:23:25  * st_luke_joined
06:26:01  * st_lukequit (Ping timeout: 245 seconds)
06:26:18  * paddybyersjoined
06:27:50  * dlmanningquit (Ping timeout: 240 seconds)
06:30:04  * EhevuTovquit (Quit: Leaving)
06:30:53  * ibobrikquit (Quit: ibobrik)
06:36:35  * rendarjoined
06:41:15  * dlmanningjoined
06:44:59  <MI6>nodejs-v0.10-windows: #275 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/275/
06:45:05  * kazuponjoined
06:57:07  * wwicksquit (Read error: Connection reset by peer)
06:57:26  * wwicksjoined
07:01:40  * FROGGSjoined
07:24:59  * st_luke_quit (Remote host closed the connection)
07:32:44  * dominictarr_joined
08:25:49  * dominictarr_quit (Quit: dominictarr_)
08:26:24  * hzjoined
08:33:01  * kenansulaymanjoined
08:36:03  * rendarquit (Quit: reboot)
08:52:11  * bnoordhuisjoined
09:01:26  * wwicksquit (Ping timeout: 245 seconds)
09:01:51  * wwicksjoined
09:10:01  * bnoordhuisquit (Ping timeout: 272 seconds)
09:10:27  * bnoordhuisjoined
09:17:23  * rendarjoined
09:37:57  <bnoordhuis>saghul: *whispers* s/removed/remove/ - and maybe explain in one or two lines why it's unneeded in the commit log
09:38:03  * hzquit
09:38:18  <saghul>bnoordhuis okidoki
09:40:27  <saghul>bnoordhuis better now?
09:40:32  <bnoordhuis>https://github.com/v8/v8/commit/bac5808 <- record allocation stack traces!
09:40:47  <bnoordhuis>great minds, just last week i was investigating how to implement that
09:41:19  <bnoordhuis>saghul: yep, lgtm
09:41:31  <saghul>bnoordhuis thnx
09:42:32  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 20edfc7 : windows: remove unneeded check - http://git.io/Nw3A1w
09:46:04  * inolenjoined
09:46:14  * kazuponquit (Remote host closed the connection)
09:46:43  <MI6>libuv-master: #296 UNSTABLE windows (5/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/296/
09:48:24  <MI6>libuv-master-gyp: #237 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/237/
09:51:20  * Kakerajoined
09:54:21  <MI6>libuv-node-integration: #281 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/281/
10:05:23  <rendar>bnoordhuis: thats interesting..basically they save the actual stack state, on every allocation happening?
10:12:27  <bnoordhuis>rendar: yes, and write that to the heap snapshot
10:14:49  <MI6>joyent/libuv: Ben Noordhuis master * 9ab5ee2 : include: document pipe path truncation behavior - http://git.io/Lz_UTA
10:18:34  <MI6>libuv-master: #297 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/297/
10:19:39  <rendar>bnoordhuis: thats absolutely clever for debugging purposes
10:20:03  <rendar>bnoordhuis: in this way you can always have a insight on who and how allocated memory
10:20:22  <MI6>libuv-master-gyp: #238 FAILURE windows-x64 (5/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/238/
10:22:51  * wwicks_joined
10:24:07  * wwicksquit (Ping timeout: 272 seconds)
10:24:08  * wwicks_changed nick to wwicks
10:26:06  <MI6>libuv-node-integration: #282 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/282/
10:27:16  * paddybyersquit (Ping timeout: 268 seconds)
10:35:38  <bnoordhuis>rendar: yeah. i'm very pleased they added that. particularly because it means i won't have to :)
10:40:50  <rendar>eheh
10:41:59  <rendar>bnoordhuis: iirc, time ago we were speaking about how a nanosleep() put in a place before(?) accept4 on linux, would increase performance..can this be possible or i've just dreamt that?
10:42:22  <indutny>ouch
10:42:32  <indutny>allocation-tracker
10:49:07  <MI6>nodejs-v0.10: #1549 UNSTABLE smartos-x64 (5/603) smartos-ia32 (4/603) linux-x64 (2/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1549/
10:51:45  <bnoordhuis>rendar: well, it doesn't exactly increase performance. quite the contrary actually. but it can improve fair load balancing when you have multiple threads or processes polling the same listen socket
10:55:35  <saghul>bnoordhuis any estimation when 0.12 will be branched out / released?
10:56:12  <rendar>bnoordhuis: hmmm i see, but how it works? how it can balance load more fair?
10:56:14  <bnoordhuis>saghul: i've given up on guessing, really :(
10:56:38  <saghul>bnoordhuis ok, then I have time to get some things in :-)
10:56:57  <bnoordhuis>rendar: by putting process A to sleep with nanosleep, processes B, C, etc. get a chance to call accept() as well
10:57:19  <bnoordhuis>rendar: without the sleep period, process A will likely accept() all pending connections
10:58:36  <bnoordhuis>saghul: basically the only requirement i have right now is that we keep libuv in a releasable state. apart from that, (almost) everything goes
10:58:49  <rendar>bnoordhuis: oh i see
10:58:50  <saghul>bnoordhuis sweet
10:59:27  <rendar>bnoordhuis: that little nanosleep reduces contention of accept, but where to put it? after accept()? and what about the time sleeping?
10:59:47  <bnoordhuis>then again, libuv HEAD is supposed to be in a releasable state anyway so that's not really a change of strategy :)
11:00:34  <bnoordhuis>rendar: libuv does it after the accept callback returns. it calls nanosleep with a one nanosecond timeout
11:00:49  <bnoordhuis>rendar: just enough to put it briefly to sleep
11:01:10  <bnoordhuis>if you call it with a zero timeout though, the syscall returns immediately so don't do that :)
11:02:48  <saghul>bnoordhuis yeah, it's just another minor thing like the pipe name, basically to have a common way for fsevent / fspoll to know what they are monitoring
11:03:02  <rendar>bnoordhuis: is ee
11:03:44  <rendar>bnoordhuis: i see -- obviously this is totally unuseful for single threaded i/o, or for single threaded dedicated for accept()s
11:05:20  <bnoordhuis>saghul: the libuv user knows what he's monitoring, right?
11:05:44  <saghul>bnoordhuis he might forget!
11:05:51  <saghul>also, we already have it for fsevent
11:06:05  <bnoordhuis>we do?
11:06:13  <saghul>and it's called filename, which is weird, I'd go for "path"
11:06:17  <bnoordhuis>you mean the path argument that gets passed to the callback?
11:06:18  <bnoordhuis>right
11:06:30  <bnoordhuis>yeah, path is a better name for it
11:06:54  <saghul>bnoordhuis https://github.com/joyent/libuv/blob/master/include/uv.h#L1767
11:07:34  <bnoordhuis>oh. i think that accidentally ended up in the api
11:08:33  <saghul>I actually thought it was part of it and exposed it in pyuv
11:08:43  <saghul>should it not be there?
11:09:41  <bnoordhuis>well, not according to me
11:10:15  <bnoordhuis>i guess we could deprecate it in v0.12 and remove in v0.14
11:11:08  <saghul>I see, would you be in favor of having uv_fs_event|poll_getpath ?
11:22:11  * paddybyersjoined
11:23:12  * kenansulaymanquit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
11:24:13  * kenansulaymanjoined
11:25:51  * bnoordhuisquit (Ping timeout: 245 seconds)
11:28:01  * abraxasquit (Remote host closed the connection)
11:52:02  * bnoordhuisjoined
12:01:00  * bnoordhuisquit (Ping timeout: 268 seconds)
12:40:36  * FROGGSquit (Ping timeout: 245 seconds)
13:00:12  * FROGGSjoined
13:01:23  * kellabytequit (Remote host closed the connection)
13:05:32  * bradleymeckjoined
13:07:34  * bnoordhuisjoined
13:10:17  * jmar777joined
13:12:03  <bnoordhuis>and back
13:18:02  * pachetjoined
13:18:02  * pachetquit (Changing host)
13:18:02  * pachetjoined
13:26:55  * kellabytejoined
13:27:05  * kellabytequit (Changing host)
13:27:06  * kellabytejoined
13:27:06  * kellabytequit (Changing host)
13:27:06  * kellabytejoined
13:42:19  <indutny>bnoordhuis: heya
13:42:38  <indutny>bnoordhuis: so I didn't manage to fix O(n) and memory nits, but fixed all other stuff in https://github.com/joyent/libuv/pull/958
13:51:06  * vptrjoined
13:53:21  <bnoordhuis>so, f#. it's basically ml / ocaml, right?
13:55:40  <bnoordhuis>but with decent .net / cil integration, of course
14:06:18  * bradleymeckquit (Quit: bradleymeck)
14:06:51  <indutny>bnoordhuis: hahahaha
14:06:56  <indutny>bnoordhuis: decent and .net
14:07:03  <indutny>something is wrong in this sentence
14:08:23  * FROGGSquit (Quit: Verlassend)
14:08:53  <indutny>bnoordhuis: anyway
14:08:56  <indutny>what about reviewing? :)
14:12:15  <bnoordhuis>not today probably. i've a lot on my plate
14:12:32  <bnoordhuis>maybe ask saghul or piscisaureus
14:14:20  * FROGGSjoined
14:18:00  <indutny>saghul: ? :)
14:22:37  * defunctzombie_zzchanged nick to defunctzombie
14:23:26  <saghul>indutny i'll have a look in a bit
14:24:28  <indutny>thank you
14:25:10  * dominictarr_joined
14:38:12  * bradleymeckjoined
14:38:45  * defunctzombiechanged nick to defunctzombie_zz
14:39:38  * mikealquit (Quit: Leaving.)
14:40:42  * mikealjoined
14:44:55  * mikealquit (Client Quit)
14:50:34  * dap_joined
15:00:38  * mcavagejoined
15:05:01  * mcavagequit (Ping timeout: 245 seconds)
15:05:43  * bradleymeckquit (Quit: bradleymeck)
15:15:02  <saghul>indutny done
15:16:07  <bnoordhuis>indutny, isaacs, tjfontaine, trevnorris: what's the word on upgrading v8?
15:17:00  <bnoordhuis>indutny, isaacs, tjfontaine, trevnorris: more to the point, what's the word on upgrading v8 to 3.21.x?
15:19:34  * bradleymeckjoined
15:20:41  <MI6>nodejs-master: #635 UNSTABLE smartos-ia32 (5/648) smartos-x64 (9/648) linux-ia32 (1/648) http://jenkins.nodejs.org/job/nodejs-master/635/
15:23:37  * mcavagejoined
15:24:12  * dap_quit (Quit: Leaving.)
15:26:25  * AvianFlujoined
15:29:37  * FROGGSquit (Quit: Verlassend)
15:46:44  * FROGGSjoined
15:47:26  * indexzerojoined
15:54:05  <bnoordhuis>http://www.youtube.com/watch?v=GMIF93jqRN8 <- chet faker covering burial's archangel. great song, great drummer
16:00:26  <tjfontaine>bnoordhuis: land the upgrade to 3.21.x
16:00:53  <tjfontaine>isaac is going to be slightly late due to a snafu on the bart this morning
16:03:36  <bnoordhuis>okay, cool
16:04:21  <tjfontaine>bert and sblom
16:04:35  <tjfontaine>are ont he call
16:04:41  <bnoordhuis>what's the link?
16:05:08  <tjfontaine>https://plus.google.com/hangouts/_/calendar/aXNhYWNzY2hsdWV0ZXJAZ21haWwuY29t._8gr32d1p611k8b9o6cr48b9k6op3eba18cr32b9k88s3cgpi8d2k8dq560
16:05:38  <bnoordhuis>right, i got "This party is over..." with another link :)
16:06:44  <tjfontaine>trevnorris: hey there
16:06:51  <tjfontaine>indutny: also you, call?
16:08:31  * piscisaureus_joined
16:09:33  * sblomjoined
16:11:42  * inolen1joined
16:11:42  <trevnorris>hey, sorry i'm late
16:11:42  * inolenquit (Read error: Connection reset by peer)
16:12:03  <trevnorris>be in in a min. need to reinstall the plugin
16:17:27  <sblom>trevnorris: that happened to me recently, too. it seems to be a thing. can't wait for hangouts to work with native webrtc.
16:18:28  <trevnorris>mine is because I reinstalled my OS
16:18:38  * dshaw_joined
16:22:22  <indutny>tjfontaine: yeah, I'm probably in
16:22:29  <indutny>are you still on the line?
16:22:46  <trevnorris>yeah
16:26:07  * mikealjoined
16:26:08  * mikealquit (Remote host closed the connection)
16:27:26  * kenansulaymanquit (Quit: ≈ and thus my mac took a subtle yet profound nap ≈)
16:27:37  * mikealjoined
16:28:14  * indexzeroquit (Quit: indexzero)
16:32:22  * bradleymeckquit (Quit: bradleymeck)
16:32:32  * st_lukejoined
16:32:56  * piscisaureus_quit (Ping timeout: 245 seconds)
16:34:37  * bradleymeckjoined
16:39:30  * Ralithquit (Ping timeout: 256 seconds)
16:46:21  * st_lukequit (Remote host closed the connection)
16:47:09  * TooTallNatejoined
16:50:53  <trevnorris>bnoordhuis: don't know if you have an idea why, but lldb doesn't read the debugger symbols from a debug build.
16:51:37  * dap_joined
16:51:58  <trevnorris>was troubleshooting this on #llvm, but no one there could figure it out.
16:52:59  <tjfontaine>trevnorris: you're actually loading up node_g right?
16:53:07  <trevnorris>tjfontaine: yeah
16:53:19  <tjfontaine>weird, it works for me on osx+lldb
16:53:38  <trevnorris>here's a bunch of debugging info I got on it, fwiw: https://gist.github.com/trevnorris/7092473
16:54:00  <trevnorris>but yeah, run lldb -- ./node_g <some script> and no debugging info shows up
16:54:21  * bnoordhuisquit (Ping timeout: 245 seconds)
16:54:37  * dap_quit (Client Quit)
16:54:52  <tjfontaine>trevnorris: you might want to verify at what level optimizations are actually happening
16:55:32  <trevnorris>tjfontaine: ok. i took an objdump of the sections, and all the .debug_* are there
16:55:40  <trevnorris>that's what had the llvm dudes stumped
16:56:30  <indutny>back
16:56:39  <tjfontaine>trevnorris: I generally `cd out; lldb out/Debug/node`
16:56:44  <tjfontaine>er
16:56:48  <tjfontaine>lldb Debug/node
16:57:01  <tjfontaine>maybe it has to do with the symlink?
16:57:11  <trevnorris>ok. i'll give that a try. maybe. that'd be strange though
16:57:22  <tjfontaine>indeed
17:02:28  * brsonjoined
17:04:03  <trevnorris>tjfontaine: no go. even "list" doesn't show any of the code. maybe there's some lldb additional package I don't have installed. bugger.
17:05:29  <tjfontaine>I haven't done much with llvm/clang since starting here, so I haven't been paying much attention, the releases themselves that I consume via the osx channel seem reliable though
17:08:13  * trevnorrisquit (Quit: IRCRelay - http://ircrelay.com)
17:08:29  * trevnorrisjoined
17:13:51  <trevnorris>tjfontaine: what version of lldb are you on?
17:15:10  <tjfontaine>lldb -v
17:15:10  <tjfontaine>lldb-300.2.49
17:15:27  * AvianFluquit (Remote host closed the connection)
17:16:15  <trevnorris>300? that's one hellofa version, must be an osx thing
17:16:18  <trevnorris>i'm on 3.4
17:18:28  <tjfontaine>it's their internal versioning
17:18:28  <tjfontaine>clang -v
17:18:29  <tjfontaine>Apple LLVM version 5.0 (clang-500.2.78) (based on LLVM 3.3svn)
17:20:36  * inolen1quit (Quit: Leaving.)
17:21:16  <trevnorris>ah ok.
17:21:38  * AvianFlujoined
17:22:08  <trevnorris>well, hopefully one of these days i'll get it figured out. really like to use lldb instead of gdb
17:26:43  <indutny>why?
17:27:06  <indutny>not that I doubt it, just curious
17:27:09  * bradleymeckquit (Quit: bradleymeck)
17:27:27  <tjfontaine>hm?
17:27:33  <trevnorris>the backtraces from lldb are more useful
17:29:23  * Ralithjoined
17:40:03  * piscisaureus_joined
17:40:22  * bradleymeckjoined
17:45:30  <indutny>ah
17:45:33  <indutny>only that?
17:45:50  <trevnorris>well, that's all I've been able to do since I can't load the debug symbols
17:46:11  <trevnorris>but for some reason gdb is missing a good chunk of the backtrace
17:46:34  <trevnorris>i.e. the frame is just an address, but doesn't tell me what function was called.
17:47:46  <isaacs>ok, so, fuckit. i'm gonna post a blog and tweet and whatnot to disclose all the details.
17:49:12  * skebcioquit (Remote host closed the connection)
17:53:07  <MI6>libuv-master: #298 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/298/
17:54:43  <isaacs>any objections?
17:56:35  <isaacs>https://gist.github.com/isaacs/2b28efaa9d0b63a9926c
17:56:47  <isaacs>piscisaureus_, trevnorris, tjfontaine, bnoordhuis, indutny ^
17:57:01  * kenperkinsjoined
17:57:38  <indutny>lgtm
17:59:04  * skebciojoined
18:00:36  * bnoordhuisjoined
18:00:46  <MI6>libuv-node-integration: #283 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/283/
18:02:23  <MI6>joyent/node: isaacs v0.10 * 97813ae : blog: HTTP server DoS vulnerability details - http://git.io/vJOzzg
18:03:31  <trevnorris>isaacs: fyi, mozilla wasn't really susceptible to the attack because their load balancer would automatically throttle the connection.
18:03:48  <trevnorris>then after N requests it would automatically disconnect the client.
18:05:08  * bnoordhuisquit (Ping timeout: 240 seconds)
18:12:53  <MI6>nodejs-v0.10: #1550 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) linux-x64 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1550/
18:17:21  <MI6>nodejs-v0.10-windows: #276 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/276/
18:24:51  * paulfryzeljoined
18:26:24  * mikealquit (Quit: Leaving.)
18:29:20  * mikealjoined
18:45:02  <MI6>nodejs-master-windows: #428 UNSTABLE windows-x64 (21/648) windows-ia32 (22/648) http://jenkins.nodejs.org/job/nodejs-master-windows/428/
18:54:03  * dshaw_quit (Quit: Leaving.)
19:03:26  <trevnorris>bugger. updated tmux, now has this stupid reflow. can't figure out how to disable it :P
19:13:28  <indutny>:)
20:13:26  <indutny>finally, I'm going to fix fsevents on 10.9
20:15:44  * bajtosjoined
20:17:03  <trevnorris>piscisaureus_: fwiw, running NODE_USE_DOMAINS=1 ./node ./benchmark/http_simple.js then hitting it w/ wrk. pre asyncListeners: 11k req/sec. post asyncListeners 15k req/sec
20:20:26  <indutny>nice!
20:20:39  <indutny>which reminds me that I should get back to reviewing it
20:20:44  <indutny>gosh
20:20:46  <indutny>my inbox is exploding
20:20:49  <trevnorris>heh
20:28:31  * bnoordhuisjoined
20:28:54  <indutny>bnoordhuis: hey
20:28:56  <indutny>have a minute?
20:30:21  * vptrquit (Quit: WeeChat 0.4.1)
20:32:25  * jmar777quit (Remote host closed the connection)
20:33:04  * jmar777joined
20:33:32  * AvianFlu_joined
20:34:16  * AvianFluquit (Disconnected by services)
20:34:58  * st_lukejoined
20:35:51  * dominictarr_quit (Quit: dominictarr_)
20:37:33  * jmar777quit (Ping timeout: 272 seconds)
20:38:09  * st_lukequit (Remote host closed the connection)
20:38:34  * julianduquejoined
20:39:12  <trevnorris>groundwater_: can you send me a link to those tests again?
20:39:32  <groundwater_>trevnorris: sure, let me find them
20:45:03  * sblomquit (Ping timeout: 272 seconds)
20:46:03  <groundwater_>trevnorris: https://github.com/jacobgroundwater/node/commit/03fe70e554802fe482dc2c2febbe4e43b6b4a893
20:46:19  <trevnorris>thanks :)
20:46:41  <groundwater_>last i ran them, which was last week, they all pass
20:52:26  <groundwater_>cc/ othiym23: ^
20:52:52  <trevnorris>hm. test-asynclistener-error-throw-in-error failed for me.
20:53:19  <groundwater_>trevnorris: that one gave me trouble, it's only checking the exit code of the child process
20:53:37  <groundwater_>i actually don't know what it *shoudl* be but i think at one point it was exiting with 7
20:53:43  <trevnorris>ok, if you're expecting an error, then just needs to be > 0
20:53:58  <trevnorris>yeah, 7 is what i was getting
20:54:02  <othiym23>I had to do some surgery on that one so that I could get it to work for 0.8, but it works with the polyfill now
20:54:06  <groundwater_>hmm…
20:54:22  <groundwater_>let me pull your latest change and run it
20:54:35  <groundwater_>just leave that one out for now
20:55:07  <trevnorris>erm wait. i'm getting 2.
20:55:12  <trevnorris>not 7
20:55:35  <groundwater_>so i'm purposefully exiting with 1, or 2 if the child dies in a way other than what i'd intended
20:55:43  <othiym23>trevnorris: I tracked it down to the code in node.cc, and 7 was the correct return code for that situation
20:55:46  <othiym23>hold on
20:56:24  <trevnorris>well, in the test it has: process.exit(2);
20:56:31  <trevnorris>so I'm not sure why we wouldn't expect 2
20:56:34  <othiym23>trevnorris: https://github.com/joyent/node/blob/master/src/node.cc#L1967
20:56:48  <othiym23>because you want the process to get shot in the head, not to reach the exit
20:56:51  <groundwater_>so that means the error handler is being called twice, when i think it should only have been called once
20:57:11  <groundwater_>anywhere i write "process.exit( )" is a place it *shouldn't* exit
20:57:18  <trevnorris>ok, really need a comment about that. confusing.
20:57:34  <groundwater_>sure
20:57:34  <trevnorris>i'm taking care of it.
20:57:47  <trevnorris>groundwater_: i cherry-picked your tests and i'm just going to do a little cleanup.
20:57:54  <groundwater_>much appreciated!
20:58:00  <groundwater_>i can give them a look over afterwards too
20:59:27  <trevnorris>thanks
21:00:19  <trevnorris>groundwater_: what's w/ the <name>.simple.js?
21:00:42  <groundwater_>oh… that's a way othiym23 was naming tests ported from core to the polyfill
21:00:54  <groundwater_>we can change the names
21:01:15  <trevnorris>cool. i'm just going to drop the .simple part
21:01:47  <groundwater_>yah sounds good
21:02:11  * wwicksquit (Quit: http://www.linkedin.com/in/williamwicks)
21:02:13  <othiym23>thumbs up
21:02:28  * sblomjoined
21:05:59  * dshaw_joined
21:06:06  <trevnorris>groundwater_: man, you really went all out. these tests are great.
21:06:10  <trevnorris>thanks.
21:06:14  <trevnorris>this saves me a lot of work.
21:06:34  <othiym23>trevnorris: the best part is that I think all of them pass on both 6011 and the polyfill
21:06:45  <trevnorris>sweet
21:06:54  <groundwater_>i enjoy trying to break code
21:07:00  <trevnorris>haha
21:07:15  <groundwater_>but there wasn't much to break
21:07:37  <trevnorris>well, since part of the point of this code is to find when other code is broken, good to make sure it's unbreakable :)
21:08:23  * Kakeraquit (Quit: Leaving)
21:08:23  <groundwater_>trevnorris: so i just ran the error-throw-in-error test
21:08:30  * kenansulaymanjoined
21:08:42  <groundwater_>is the error handler being called twice?
21:09:06  <trevnorris>taking a look now
21:09:51  <groundwater_>i'm throwing from *within* the error handler, which should just basically kill the process hard
21:09:54  <trevnorris>ok. so if error throws, error callbacks will be called once more so information can be collected, if possible, then it dies
21:10:34  * Kakerajoined
21:10:59  <trevnorris>tried to add a small level of backtraceability there.
21:11:09  <groundwater_>ahh okay, i misunderstood you then
21:11:25  <groundwater_>and if it throws again?
21:11:35  <trevnorris>error callbacks are ignored
21:11:36  <groundwater_>i guess it's already in the process of exiting
21:11:54  <trevnorris>well, since it happens synchronously, you can get infinite recursion
21:11:57  <groundwater_>okay, i'll have to redesign this test to account for that
21:12:22  <trevnorris>one sec. want to double check some of this against my code.
21:12:53  <groundwater_>i don't think it's urgent however, but the polyfil does not call error handlers if it throws within an error handler cc/ othiym23
21:13:18  <trevnorris>well, if you just remove the "if(once++ === 0) process.exit(2);" it works fine
21:13:44  <trevnorris>the alternative is that there's infinite recursion and it never dies.
21:13:44  * Kakeraquit (Read error: Connection reset by peer)
21:14:02  <groundwater_>yes, i am also using these tests to keep the polyfil in line, so we'll have to adjust it
21:14:07  <othiym23>I'll need to look at how this affects the polyfill, but I think this way of doing things is actually less nervous-making for me
21:14:24  <trevnorris>othiym23: define "this way"
21:15:19  <tjfontaine>walk this way ... talk this way ...
21:15:33  <trevnorris>haha
21:15:38  <bnoordhuis>indutny: shoot
21:15:55  <othiym23>trevnorris: 6011's way of doing things
21:16:38  <groundwater_>trevnorris: i think the test actually has an error in it
21:17:16  <groundwater_>it shouldn't be "if(once++ ===0) process.exit(2)" it should be if(once++ !==0) process.exit(2)
21:17:25  * piscisaureus_quit (Read error: Connection reset by peer)
21:18:11  * piscisaureus_joined
21:18:17  <trevnorris>bnoordhuis: have you had any problems using lldb on linux? i can't seem to get the debugger symbols to load
21:18:35  <bnoordhuis>trevnorris: i don't use lldb much and never on linux
21:19:02  <bnoordhuis>i only use it on os x when gdb craps out
21:19:10  <trevnorris>bnoordhuis: ok. thanks. lldb's just giving me better bt's than gdb
21:19:29  <trevnorris>where I can actually see the call chain when it goes from c++ to js and back to c++
21:19:40  <trevnorris>gdb just gives me a long list of addresses
21:20:24  <bnoordhuis>not sure what you mean with call chain here
21:20:33  <bnoordhuis>gdb doesn't know how to decode js stack frames, that's true
21:21:03  <bnoordhuis>but neither does lldb, right?
21:21:08  <tjfontaine>lldb doesn't really either, unless something radical has changed
21:21:16  * julianduquequit (Ping timeout: 245 seconds)
21:21:43  <tjfontaine>trevnorris: maybe give us a gist of the two back traces and point out the parts you like
21:21:53  <tjfontaine>maybe lldb does a bit more interpretation of the inlining?
21:22:07  * piscisaureus_quit (Read error: Connection reset by peer)
21:22:09  <trevnorris>tjfontaine, bnoordhuis: here's the same script run and using bt in lldb and gdb: https://gist.github.com/trevnorris/7108392
21:22:17  * julianduquejoined
21:22:40  <tjfontaine>right actually lldb is omitting a lot of frames it would seem
21:22:54  * piscisaureus_joined
21:23:00  <trevnorris>but it's giving me information about AsyncWrap that gdb isn't
21:23:05  <trevnorris>and in this case that's the important part
21:23:06  <bnoordhuis>looks like it. i wonder what the algorithm is
21:23:30  <tjfontaine>trevnorris: you never see the entry point in gdb?
21:24:11  <trevnorris>tjfontaine: that bt is all I get. the script is basically: setTimeout(function() { process.abort(); }, 10);
21:24:13  <tjfontaine>for apples to apples, are you using gcc/g++ to compile what you use in gdb? (not that it should really matter all that much, but I suppose there could be some dwarf differences here)
21:24:29  <othiym23>see?
21:24:31  <trevnorris>ah, i'm compiling w/ clang 3.4
21:24:35  <othiym23>I told you guys you gotta feed the dwarves
21:24:38  <tjfontaine>heh
21:25:25  <trevnorris>hey, that's a reference I actually get. dudes on #llvm were helping me debug dwarf last night
21:25:55  <tjfontaine>it shouldn't be breaking this bad, but it's possible you found a bug
21:26:08  <tjfontaine>are you on HEAD or on a release branch?
21:26:14  <othiym23>at the average Node meetup, I can say with pinpoint accuracy when dap loses 90% of the audience, and that's the first time he says, "dwarf"
21:26:31  <tjfontaine>hah
21:26:31  <trevnorris>tjfontaine: lldb --version lldb version 3.4 ( revision )
21:26:51  <tjfontaine>I guess that's a release version?
21:27:00  <trevnorris>I just installed it w/ apt-get
21:27:08  <tjfontaine>oh, well there's your problem ;)
21:27:32  <tjfontaine>anyway, lldb isn't necessarily the problem here so moving on
21:27:39  * Kakerajoined
21:29:02  <indutny>bnoordhuis: please please review
21:29:17  <indutny>brb
21:29:20  <indutny>updating OSX
21:31:04  <bnoordhuis>meh, it's 23.30 here. i'm answering some emails and then i'm off to bed
21:31:19  <bnoordhuis>maybe tomorrow but don't hold your breath
21:31:35  <bnoordhuis>because, you know, that would probably be fatal
21:35:00  <trevnorris>heh, night bnoordhuis
21:35:45  <bnoordhuis>yeah, you too, trevor :)
21:36:20  <tjfontaine>night ben!
21:37:35  * FROGGSquit (Ping timeout: 260 seconds)
21:38:08  * isaacschanged nick to ISAACS
21:38:15  <ISAACS>ITS CAPSLOCKDAY
21:38:16  <LOUDBOT>"TREK XI WAS THE BEST ONE, LIKE, EVEN BETTER THAN WRATH OF KHAN"
21:38:23  <ISAACS>LOUDBOT: TELL ME MORE!
21:38:23  <LOUDBOT>ISAACS: DAY CHANGE OF AWESOME!
21:38:26  <ISAACS>LOUDBOT: TELL ME MORE!
21:38:27  <LOUDBOT>ISAACS: ACHIEVEMENT UNLOCKED: HOPE AND CHANGE
21:38:28  <ISAACS>LOUDBOT: TELL ME MORE!
21:38:29  <LOUDBOT>ISAACS: SING THAT WHALING SONG
21:38:34  <ISAACS>LOUDBOT: SEARCH CAPSLOCK
21:38:34  <LOUDBOT>ISAACS: <apeiron:##turtles> IK CAN WE LET CAPSLOCK DAY GO THROUGH THE WEEKEND PLEASE
21:38:43  <ISAACS>LOUDBOT: TWITLAST
21:38:44  <LOUDBOT>http://twitter.com/LOUDBOT/status/392766997865304064 (apeiron/##turtles)
21:40:07  <tjfontaine>PRAISE BE THE CAPSLOCK
21:40:07  <LOUDBOT>MY LAST SHIT FLOATED AT THE 60% POINT, I THINK I NEED TO EAT LESS STYROFOAM
21:40:22  <tjfontaine>good safety tip
21:41:57  <trevnorris>othiym23: so, just because i'm lazy, exit code 2 isn't use by node. so just making sure that !== 2 would prevent needing to keep up tests w/ any proper exit codes.
21:42:27  <trevnorris>(since the actual number of the code is just to indicate where it exited, and it's mainly internal for debugging, it's not "stable")
21:42:42  <groundwater_>trevnorris: the test is only checking for an exit code of 7
21:42:51  <groundwater_>so exiting anything other than 7 will fail the test
21:43:09  <groundwater_>so in many ways, choosing 2 is arbitrary
21:43:40  * bradleymeckquit (Quit: bradleymeck)
21:43:45  <trevnorris>groundwater_: yeah, but you did it right :) i'm modifying the tests now to be "more" like the other tests.
21:44:01  <groundwater_>but the test is actually wrong
21:44:13  <trevnorris>yeah. i'm fixing that too.
21:44:20  <groundwater_>it should be (once++ !== 0)
21:44:44  <groundwater_>which means the error handlers only gets called once, which actually passes
21:45:29  <trevnorris>eh? it should be called twice. once for the error in setImmediate and once more for the error in error
21:46:12  <trevnorris>and (once++ !== 0) will always fail because once = 0 at the beginning.
21:46:18  <trevnorris>wait... nm
21:47:12  * bajtosquit (Ping timeout: 265 seconds)
21:47:30  <groundwater_>process.exit(2) should only occur if the error handler is called more than once
21:47:31  * piscisaureus_quit (Ping timeout: 245 seconds)
21:47:44  <trevnorris>yeah, but it'll be called twice.
21:47:45  <groundwater_>so the first time, when once=0 it should skip it, and throw the error
21:48:01  <groundwater_>the second time, it should exit 2
21:48:07  <groundwater_>the test passes though
21:48:09  * bajtosjoined
21:48:40  <trevnorris>ok. i'm double checking a few things.
21:49:01  <groundwater_>unless process.exit(2) is somehow exiting with 7
21:49:07  * rendarquit
21:49:09  <trevnorris>no, that's not possible.
21:49:23  <groundwater_>didn't think so
21:49:25  <trevnorris>ok. well error _should_ fire twice. so then there's a bug in my code.
21:49:38  <groundwater_>yah, looks like it's not
21:49:59  <trevnorris>ok. pretty sure I know what the bug it. should be a quick fix.
21:50:29  <groundwater_>ahh okay
21:50:32  <groundwater_>awesome!
21:50:51  <groundwater_>i mean, if you're throwing errors in error handlers, all bets are kinda off, but i figure we should lock this down
21:51:49  <trevnorris>i'm allowing to call error callbacks _once_ if an error throws. so you can capture any last state just in case you have another listener alive and you want to capture state just before the program dies.
21:52:08  <groundwater_>yah that makes sense, othiym23 agrees with that behaviour too
21:52:30  <tjfontaine>bnoordhuis: you still there?
21:52:46  <groundwater_>trevnorris: if you modify the test, we can pull it into the polyfil
21:53:18  * bajtosquit (Quit: bajtos)
21:53:20  <trevnorris>groundwater_: ok. yeah i'm doing that now. once I get the tests ready they'll be added to my branch as a separate commit
21:53:25  <trevnorris>then you can pull them in.
21:53:32  <groundwater_>trevnorris: thanks!
21:53:42  <trevnorris>hey, thank you for all the tests :)
21:54:16  <groundwater_>no problem!
21:54:16  <tjfontaine>didn't ben land a thing where on abort it would dump the stack trace and a whole bunch of information about the state of the v8 object heap and etc?
21:54:39  <trevnorris>tjfontaine: I think that was a module he wrote.
21:54:48  <tjfontaine>hrm, I'm pretty sure it was in core
21:55:09  <trevnorris>ah, ok. I wrote a module that dumps out stuff on fatal error.
21:55:30  <bnoordhuis>tjfontaine: sadly yes
21:55:43  <tjfontaine>bnoordhuis: did that get removed for the multicontext stuff?
21:55:54  <tjfontaine>oh sadly you're still here
21:55:55  <tjfontaine>:)
21:56:09  <tjfontaine>iow, you can totally answer tomorrow sometime :)
21:56:18  <bnoordhuis>tjfontaine: indeed. :) and no, that never landed in the first place
21:56:35  <tjfontaine>ok, but I wasn't crazy you did have it :)
21:56:54  <bnoordhuis>yeah. first as a module, then as a work-in-progress patch for core
21:57:03  <bnoordhuis>i can dust if off if there is interes
21:57:06  <bnoordhuis>*interest
21:57:43  <tjfontaine>well, as i was thinking about this toggling debugger thing, I am just skeptical of how it would be used, if you're in a state where you might want to mutate state and keep a process alive it's kind of scary
21:58:18  <tjfontaine>and it got me to thinking it would be interesting to have a programmatic way to dump the state that you had there, that was slightly less painful than abort()
21:58:50  * dshaw_quit (Quit: Leaving.)
21:59:13  <bnoordhuis>what state in particular would you want to dump?
21:59:41  <bnoordhuis>i got to the point where it can decode js and c++ stack frames plus some js function arguments
21:59:56  <tjfontaine>I'm not sure really, I'm just thinking about what tooling we could provide that would be somewhat comparable to the type of information available from the mdb stuff
22:00:30  <tjfontaine>process.on('SIGUSR2', process._dumpInfo)
22:00:53  <bnoordhuis>SIGUSR2 is reserved by node-heapdump :)
22:01:00  <bnoordhuis>but yeah, i get your point
22:01:03  <tjfontaine>hehe
22:01:18  <tjfontaine>I'm also somewhat interested in doing something like heapdump in core
22:01:54  <bnoordhuis>i think that will make a lot of people happy
22:02:03  <bnoordhuis>even more so now that heapdumps also contain allocation sites
22:02:19  <bnoordhuis>i.e. you can track what code created what objects (win!)
22:02:29  <tjfontaine>right
22:02:44  <tjfontaine>anyway it's something I've been thinking about
22:03:00  <bnoordhuis>yeah, me too. better tooling is a big part of strongloop's raison d'etre
22:03:25  * AvianFlu_quit (Remote host closed the connection)
22:03:36  <bnoordhuis>i have big plans but unfortunately only limited time :-/
22:03:45  <trevnorris>ISAACS: i'm trying to use process._rawDebug() in a child process to write to the parent on exit. I thought it should, but doesn't seem to.
22:03:48  <tjfontaine>heh don't we all
22:04:26  <trevnorris>i.e. thought fflush() would cause the data to be written before the program exits.
22:04:45  * AvianFlujoined
22:04:56  * AvianFluquit (Remote host closed the connection)
22:05:04  <bnoordhuis>trevnorris: it should unless stderr is closed (which usually indicates a bug)
22:05:37  * jmar777joined
22:05:44  <trevnorris>bnoordhuis: ok. well process.on('exit', fn() { process._rawDebug('msg'); }); isn't reaching the parent process from spawn()
22:05:53  * Kakeraquit (Read error: Connection reset by peer)
22:06:15  <bnoordhuis>trevnorris: `strace -f` is your friend here
22:06:20  <trevnorris>ok thanks
22:07:28  * sblomquit (Ping timeout: 240 seconds)
22:07:28  <bnoordhuis>maybe curb the output with `-fe write` :)
22:07:57  <bnoordhuis>okay, now i'm really off to bed. have a good night everyone
22:08:08  <trevnorris>night :)
22:10:42  * Kakerajoined
22:12:14  * bnoordhuisquit (Ping timeout: 240 seconds)
22:15:11  <ISAACS>trevnorris: yeah, it should.
22:15:23  <trevnorris>ISAACS: ok, it's not. i'm debugging it now.
22:16:03  * FROGGSjoined
22:21:03  * FROGGSquit (Ping timeout: 272 seconds)
22:23:17  <trevnorris>wtf
22:23:42  <trevnorris>it's because of async listener. for some reason it's like the on exit callback isn't running.
22:24:08  <trevnorris>well, that's definitely a bug
22:28:08  <trevnorris>aahhh... ok.
22:28:31  * mikealquit (Quit: Leaving.)
22:29:20  * paddybyersquit (Quit: paddybyers)
22:29:44  * dshaw_joined
22:33:17  * dshaw_1joined
22:33:17  * dshaw_quit (Read error: Connection reset by peer)
22:38:25  * dshaw_1quit (Ping timeout: 272 seconds)
22:39:29  * bajtosjoined
22:47:16  * dshaw_joined
22:49:00  * Kakeraquit (Ping timeout: 260 seconds)
22:54:04  * bajtosquit (Quit: bajtos)
22:57:26  * bajtosjoined
22:59:50  * c4milojoined
23:01:18  * AvianFlujoined
23:03:33  * bajtosquit (Quit: bajtos)
23:03:36  * mikealjoined
23:04:54  * FROGGSjoined
23:07:20  * dominictarrjoined
23:12:09  * paulfryzelquit (Remote host closed the connection)
23:12:45  * paulfryzeljoined
23:13:15  * FROGGSquit (Ping timeout: 272 seconds)
23:15:35  * AvianFlu_joined
23:17:06  * paulfryzelquit (Ping timeout: 245 seconds)
23:18:41  * bnoordhuisjoined
23:18:53  * dshaw_quit (Quit: Leaving.)
23:19:30  * dominictarrquit (Quit: dominictarr)
23:20:00  * AvianFlu_quit (Ping timeout: 265 seconds)
23:22:55  * bnoordhuisquit (Ping timeout: 245 seconds)
23:23:47  <trevnorris>oy. hate my fix, but not going to worry about it for now.
23:26:27  * bajtosjoined
23:27:39  * dominictarrjoined
23:28:33  <othiym23>trevnorris: every time you say "oy", a picture of a little Jewish grandparent flashes into my brain
23:28:41  <trevnorris>hehe
23:30:38  * bajtosquit (Ping timeout: 240 seconds)
23:31:26  * dshaw_joined
23:31:34  <trevnorris>othiym23: usability question, would you rather have the Error stack printed for the code that caused the "error" callback to run, or the stack from the "error" callback itself.
23:32:35  <trevnorris>because right now I have it where if the error callback also throws, it'll pass that error to all the "error" callbacks. but then finish throwing the original
23:32:40  <othiym23>trevnorris: how does "both" sound to you?
23:32:49  <othiym23>the existing domains behavior confuses the shit out of people
23:32:57  <othiym23>that was by far the #1 question people asked me at NodeConf
23:33:01  <trevnorris>haha.
23:34:29  <othiym23>something like "Error handler threw: <stacktrace> when handling error: <stacktrace>"
23:34:45  <trevnorris>um.....
23:35:05  <trevnorris>you realize that <stacktrace> is multiline, right?
23:35:50  <othiym23>well yes
23:35:58  <othiym23>barring formatting
23:40:07  <trevnorris>othiym23: it seems overkill to not only call all the error callbacks one more time if one of them throws, and _also_ print out multiple stack traces for how we got there.
23:40:26  * julianduquequit (Ping timeout: 245 seconds)
23:45:59  * FROGGSjoined
23:46:21  <trevnorris>ISAACS: ping
23:46:50  <trevnorris>or tjfontaine, just need an opinion.
23:47:20  <tjfontaine>sup?
23:48:15  <trevnorris>read the last 10-20 lines above please, and let me know what you think about the error handling proposal. :)
23:48:50  <tjfontaine>oh, hm ok
23:50:55  * dshaw_quit (Quit: Leaving.)
23:52:00  <othiym23>trevnorris: it may be overkill, but by that point cost is irrelevant and I'd argue that it will make debugging a lot simpler
23:52:58  <trevnorris>othiym23: oy vey. it's just, all this error handling code is marring my patch :(
23:53:09  <othiym23>that's asynchronous error handling!
23:53:45  <trevnorris>well, I have a patch. give me a minute to clean up some debugger comments and I'll throw it up.
23:55:17  * FROGGSquit (Ping timeout: 265 seconds)
23:56:05  <trevnorris>tjfontaine: mainly the part I want feedback on is the custom error message with dual stack traces.
23:56:35  <tjfontaine>right we're both in a meeting atm, not enough cycles necessary to think :)
23:56:44  <trevnorris>no worries :)
23:58:14  <trevnorris>othiym23: should I emit process exit event before or after the second round of error handlers have been called?
23:58:52  <MI6>libuv-master-gyp: #239 FAILURE linux-x64 (1/195) windows-x64 (4/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/239/
23:59:28  * dominictarrquit (Quit: dominictarr)
23:59:36  <othiym23>after, probably
23:59:42  <trevnorris>k
23:59:53  <othiym23>give everything as much time to deal as possible