00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:56  * c4miloquit (Remote host closed the connection)
00:06:17  * defunctzombiechanged nick to defunctzombie_zz
00:09:09  * EhevuTovquit (Quit: This computer has gone to sleep)
00:11:31  * paulfryzelquit (Remote host closed the connection)
00:12:06  * paulfryzeljoined
00:12:25  * mikealquit (Quit: Leaving.)
00:13:55  * wwicks_joined
00:16:16  * wwicksquit (Ping timeout: 260 seconds)
00:16:16  * wwicks_changed nick to wwicks
00:16:36  * paulfryzelquit (Ping timeout: 252 seconds)
00:17:53  * Benviejoined
00:31:31  * indexzeroquit (Read error: Operation timed out)
00:32:37  * indexzerojoined
00:38:39  * julianduquejoined
00:39:40  * dapquit (Quit: Leaving.)
00:39:41  * kazuponjoined
00:42:58  * dominictarrquit (Quit: dominictarr)
00:55:34  * dshaw_joined
01:02:45  * c4milojoined
01:07:59  * mikealjoined
01:11:17  * mikealquit (Client Quit)
01:37:15  * inolenquit (Ping timeout: 272 seconds)
01:50:28  * AvianFlu_joined
01:50:35  * brsonquit (Quit: leaving)
01:56:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:09:15  * dshaw_quit (Quit: Leaving.)
02:16:12  * defunctzombie_zzchanged nick to defunctzombie
02:16:19  * abraxasjoined
02:59:27  * mikealjoined
03:03:23  * kazuponquit (Remote host closed the connection)
03:04:00  * kazuponjoined
03:05:48  * kazuponquit (Read error: Connection reset by peer)
03:08:47  * inolenjoined
03:17:29  * inolen1joined
03:17:32  * inolenquit (Read error: Connection reset by peer)
03:18:13  * julianduquequit (Ping timeout: 246 seconds)
03:25:45  * julianduquejoined
03:29:28  * mikealquit (Quit: Leaving.)
03:31:50  * kazuponjoined
03:32:44  * mikealjoined
03:33:53  * indexzero_joined
03:34:41  * indexzeroquit (Ping timeout: 272 seconds)
03:34:42  * indexzero_changed nick to indexzero
03:36:21  * AvianFluquit (Remote host closed the connection)
03:36:50  * AvianFlujoined
03:41:15  * AvianFluquit (Ping timeout: 248 seconds)
03:43:03  * st_lukejoined
03:43:23  * indexzeroquit (Ping timeout: 248 seconds)
03:43:38  * indexzerojoined
03:47:37  * mcavagequit (Remote host closed the connection)
03:48:05  * mcavagejoined
03:48:43  * mcavage_joined
03:48:43  * mcavagequit (Read error: Connection reset by peer)
04:06:20  * julianduquequit (Ping timeout: 260 seconds)
04:16:24  * indexzero_joined
04:18:45  * indexzeroquit (Ping timeout: 245 seconds)
04:18:45  * indexzero_changed nick to indexzero
04:25:36  * defunctzombiechanged nick to defunctzombie_zz
04:25:42  * mcavage_quit (Remote host closed the connection)
04:26:09  * mcavagejoined
04:30:48  * mcavagequit (Ping timeout: 256 seconds)
04:36:59  * st_lukequit (Remote host closed the connection)
04:37:36  * st_lukejoined
04:38:29  * st_luke_joined
04:40:02  * kazuponquit (Remote host closed the connection)
04:41:50  * st_lukequit (Ping timeout: 240 seconds)
04:49:23  * indexzero_joined
04:51:57  * indexzeroquit (Ping timeout: 272 seconds)
04:51:58  * indexzero_changed nick to indexzero
04:56:42  * mcavagejoined
05:00:13  * kazuponjoined
05:05:10  * mcavagequit (Ping timeout: 260 seconds)
05:06:26  * TooTallNatejoined
05:13:13  * TooTallNatequit (Ping timeout: 265 seconds)
05:13:16  * Benvie_joined
05:13:24  * kazuponquit (Remote host closed the connection)
05:13:26  * Benvie_quit (Client Quit)
05:25:10  * kazuponjoined
05:25:51  * c4miloquit (Remote host closed the connection)
05:45:27  * paddybyersjoined
05:46:50  * st_luke_quit (Remote host closed the connection)
05:49:51  * rendarjoined
05:53:08  * octetcloudquit (Ping timeout: 240 seconds)
05:55:57  * bajtosjoined
05:57:40  * AvianFlu_quit (Remote host closed the connection)
06:01:14  * mcavagejoined
06:05:47  * mcavagequit (Ping timeout: 260 seconds)
06:25:46  * paddybyersquit (Quit: paddybyers)
06:32:51  * inolenjoined
06:32:52  * inolen1quit (Read error: Connection reset by peer)
06:41:07  <MI6>nodejs-v0.10-windows: #262 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/262/
07:31:38  * mcavagejoined
07:35:50  * mcavagequit (Ping timeout: 245 seconds)
07:49:53  * paddybyersjoined
08:13:03  * karupa64quit (*.net *.split)
08:18:12  * karupa64joined
08:36:20  * indexzero_joined
08:38:22  * hzjoined
08:38:51  * indexzeroquit (Read error: Operation timed out)
08:39:55  * indexzerojoined
08:41:51  * indexzero_quit (Ping timeout: 272 seconds)
08:54:39  * dshaw_joined
09:07:32  * kazuponquit (Remote host closed the connection)
09:08:06  * kazuponjoined
09:12:28  * kazuponquit (Ping timeout: 265 seconds)
09:16:07  * kazuponjoined
09:32:20  * mcavagejoined
09:37:19  * mcavagequit (Ping timeout: 272 seconds)
09:39:45  * Kakerajoined
09:55:01  * bnoordhuisjoined
10:15:14  * bajtosquit (Quit: bajtos)
10:16:50  * piscisaureus_joined
10:17:24  * abraxasquit (Remote host closed the connection)
10:18:00  * abraxasjoined
10:20:16  * Benvie_joined
10:22:05  * Benviequit (Ping timeout: 265 seconds)
10:22:28  * abraxasquit (Ping timeout: 260 seconds)
10:22:42  * indexzeroquit (Quit: indexzero)
10:26:14  * dshaw_quit (Quit: Leaving.)
10:26:40  * roxlujoined
10:32:42  * mcavagejoined
10:32:46  * paddybyersquit (Quit: paddybyers)
10:32:54  * AvianFlujoined
10:32:54  * AvianFluquit (Remote host closed the connection)
10:33:31  * AvianFlujoined
10:36:37  * mcavagequit (Ping timeout: 240 seconds)
10:37:53  * paddybyersjoined
10:39:15  * kazuponquit (Remote host closed the connection)
10:39:47  * kazuponjoined
10:39:59  * kazuponquit (Read error: Connection reset by peer)
10:45:12  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
10:48:05  <MI6>nodejs-v0.10: #1536 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) linux-x64 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1536/
10:57:12  <MI6>joyent/node: Ben Noordhuis v0.10 * 5bc5210 : doc: http: reword IncomingMessage 'close' event (+1 more commits) - http://git.io/CQFUxw
11:01:50  * AvianFluquit (Remote host closed the connection)
11:02:32  * AvianFlujoined
11:07:17  <MI6>nodejs-v0.10: #1537 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) linux-x64 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1537/
11:11:37  <MI6>nodejs-v0.10-windows: #263 UNSTABLE windows-ia32 (9/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/263/
11:33:03  * mcavagejoined
11:37:30  * mcavagequit (Ping timeout: 252 seconds)
11:48:10  * dominictarrjoined
12:33:24  * mcavagejoined
12:35:53  * inolenquit (Quit: Leaving.)
12:38:05  * mcavagequit (Ping timeout: 272 seconds)
12:50:27  * c4milojoined
12:53:44  * piscisaureus_joined
12:54:10  <piscisaureus_>bnoordhuis: why was skpac reverted?
12:54:16  <piscisaureus_>*spkac
13:00:41  <bnoordhuis>apparently the test failed on os x
13:00:51  <bnoordhuis>piscisaureus_: ^
13:01:00  <piscisaureus_>bnoordhuis: ic. thnx
13:08:26  * c4miloquit (Remote host closed the connection)
13:08:59  * c4milojoined
13:13:31  * c4miloquit (Ping timeout: 248 seconds)
13:33:45  * mcavagejoined
13:37:42  * mcavagequit (Ping timeout: 241 seconds)
13:44:32  <bnoordhuis>https://github.com/joyent/node/pull/6362 <- so much goodness!
13:47:21  <mmalecki>bnoordhuis: the <title> tag made me laugh
13:47:56  <mmalecki>'debugger: make busy loops SIGUSR1-interruptible by bnoordhuis'
13:54:04  * dominictarrquit (Quit: dominictarr)
13:55:35  <piscisaureus_>bnoordhuis: the patch lgtm, I'm waiting for jenkins to tell me whether I was right
13:56:06  <piscisaureus_>bnoordhuis: in other (good) news for the humanity: http://www.nu.nl/economie/3603063/voorraad-bier-bij-grolsch-raakt-op.html
14:04:25  * pachetjoined
14:05:13  * bnoordhuisquit (Ping timeout: 272 seconds)
14:06:20  * dominictarrjoined
14:08:40  <piscisaureus_>isaacs: why are dns.resolveXYZ functions not implicitly added to a domain?
14:10:05  * AvianFluquit (Remote host closed the connection)
14:10:34  * AvianFlujoined
14:10:35  * indexzerojoined
14:14:49  * AvianFluquit (Ping timeout: 246 seconds)
14:17:17  * c4milojoined
14:21:47  * c4miloquit (Ping timeout: 248 seconds)
14:28:10  * bajtosjoined
14:34:05  * mcavagejoined
14:35:09  * indexzeroquit (Quit: indexzero)
14:38:08  * mcavagequit (Ping timeout: 240 seconds)
14:46:37  * inolenjoined
15:02:35  * bajtosquit (Quit: bajtos)
15:03:11  <indutny>finally
15:03:19  * mikealquit (Quit: Leaving.)
15:07:40  * mcavagejoined
15:08:17  * mcavage_joined
15:08:17  * mcavagequit (Read error: Connection reset by peer)
15:10:23  * bnoordhuisjoined
15:10:24  * bajtosjoined
15:11:08  * AvianFlujoined
15:13:09  * mcavage_quit (Remote host closed the connection)
15:13:36  * mcavagejoined
15:14:48  * bnoordhuisquit (Ping timeout: 240 seconds)
15:17:55  * mcavagequit (Ping timeout: 245 seconds)
15:20:26  <MI6>nodejs-master: #619 UNSTABLE osx-x64 (1/645) smartos-ia32 (5/645) linux-x64 (1/645) smartos-x64 (9/645) osx-ia32 (1/645) http://jenkins.nodejs.org/job/nodejs-master/619/
15:21:31  * bajtosquit (Quit: bajtos)
15:21:36  * bnoordhuisjoined
15:24:33  * defunctzombie_zzchanged nick to defunctzombie
15:24:49  * bradleymeckjoined
15:30:30  * mikealjoined
15:35:13  <isaacs>tjfontaine, trevnorris: Actually, the test passing in linux was just luck. The test fails about 1/10 times for me
15:40:25  * mcavagejoined
15:42:59  * mcavagequit (Remote host closed the connection)
15:43:26  * mcavagejoined
15:46:13  * paddybyersquit (Quit: paddybyers)
15:48:11  * mcavagequit (Ping timeout: 272 seconds)
16:01:32  * `3Echanged nick to `3E|DINNER
16:07:52  * dshaw_joined
16:11:31  * TooTallNatejoined
16:20:43  * dapjoined
16:23:55  <trevnorris>morning all
16:24:44  <trevnorris>isaacs: only thing I can think is possibly it's not null terminating the string?
16:26:47  <indutny>bnoordhuis: please expect cpplint PR in a 20-30 minutes ;)
16:29:15  * bajtosjoined
16:35:57  <trevnorris>i'm remerging the SPKAC pr. there's a fix and all tests pass. any objections?
16:36:36  <bnoordhuis>indutny: i'll put the return statement on a separate line, just for you
16:36:43  <bnoordhuis>trevnorris: not from me
16:36:44  <indutny>thanks :)
16:37:18  <MI6>joyent/node: Jason Gerfen master * 7669c4c : doc: crypto SPKAC (+1 more commits) - http://git.io/RPShgQ
16:39:37  <bnoordhuis>trevnorris: ^ not the original commit log, is it?
16:39:53  <trevnorris>bnoordhuis: nope. he referenced a commit that was then incorrect
16:40:03  <trevnorris>also, i'm about to fix the fact I missed the commit has jas-
16:40:20  <bnoordhuis>trevnorris: can you restore the commit logs that i originally landed the commits with?
16:40:45  <trevnorris>bnoordhuis: even with the old SHA?
16:40:50  * mikealquit (Quit: Leaving.)
16:41:05  <bnoordhuis>trevnorris: you get a pony if you manage to pull that off
16:41:13  <trevnorris>bnoordhuis: you mean aa94450?
16:41:31  <bnoordhuis>trevnorris: yeah, and 7f66e44dc1e90e7abda2a9ed02d7e8163e1f6358
16:41:56  <trevnorris>bnoordhuis: can do. give me 2
16:42:22  <bnoordhuis>okay. i'm getting dinner first then :) biab
16:45:22  <MI6>joyent/node: Jason Gerfen master * 9901415 : doc: crypto: document SPKAC additions (+1 more commits) - http://git.io/vamOKw
16:45:55  * dominictarrquit (Quit: dominictarr)
16:46:42  * octetcloudjoined
16:46:50  <tjfontaine>Please, really, can we just not force push to the public repo
16:49:50  <MI6>nodejs-master: #620 UNSTABLE smartos-ia32 (5/646) smartos-x64 (9/646) osx-ia32 (1/646) http://jenkins.nodejs.org/job/nodejs-master/620/
16:51:55  <piscisaureus_>isaacs: is there any reason that dns.resolve* are not captured by a domain?
16:52:12  <isaacs>piscisaureus_: hm. not that i can think of.
16:52:16  <isaacs>piscisaureus_: seems like they ought to be.
16:52:22  <isaacs>piscisaureus_: probably a bug?
16:52:42  <isaacs>piscisaureus_: does it throw after the current tick? if so, then that's probably terrible.
16:53:12  <trevnorris>piscisaureus_: have some example code? I test that domains are captured in my 6011 patch, and they are.
16:53:23  <trevnorris>so I'd like to test it against that
16:53:25  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:53:35  <tjfontaine>what cases does it throw vs pass an error?
16:57:22  <piscisaureus_>isaacs: https://gist.github.com/25a215c9ae9df68d754c
16:57:29  <piscisaureus_>trevnorris: ^
16:58:26  <isaacs>piscisaureus_: that is pretty clearly a bug
16:58:29  <indutny>bnoordhuis: https://github.com/joyent/node/pull/6363
16:58:31  <indutny>piscisaureus_: ^
16:58:32  <isaacs>piscisaureus_: patch welcome
16:58:35  <indutny>lets make it happen
16:58:42  * bnoordhuisquit (Ping timeout: 252 seconds)
16:58:59  <trevnorris>piscisaureus_: yup. my 6011 fixes that
16:59:14  <trevnorris>isaacs: i have one, it's 6011 ;)
17:02:20  <isaacs>trevnorris: well, also, in v0.10 it's a bug
17:02:41  <trevnorris>isaacs: then we can find an inferior patch for v0.10. :P
17:03:26  * st_lukejoined
17:03:28  <tjfontaine>oh snap :)
17:05:36  <MI6>nodejs-master-windows: #413 UNSTABLE windows-x64 (21/646) windows-ia32 (21/646) http://jenkins.nodejs.org/job/nodejs-master-windows/413/
17:06:01  <MI6>nodejs-master: #621 UNSTABLE smartos-ia32 (7/646) smartos-x64 (8/646) http://jenkins.nodejs.org/job/nodejs-master/621/
17:09:37  * brsonjoined
17:15:16  * dshaw_quit (Quit: Leaving.)
17:15:28  <trevnorris>othiym23, groundwater_: double ping
17:15:39  <groundwater_>trevnorris: pong
17:15:46  <trevnorris>wow, fast.
17:16:00  * dominictarrjoined
17:16:13  <groundwater_>latency kills!
17:17:07  <trevnorris>groundwater_: so, I was thinking. should I automatically remove the asyncListener key just before the before/after/error callbacks run?
17:17:07  <trevnorris>because right now you can't just console.log from inside. you have to removeAsync..() console.log() addAsync...()
17:17:19  <trevnorris>then add it back after all the callbacks are done running?
17:17:32  * TooTallNatejoined
17:17:39  <trevnorris>or just leave it up to the user to do the lifting if they want to log from those callbacks?
17:18:17  <groundwater_>trevnorris: interesting idea
17:18:44  <trevnorris>it'll add quite the performance hit, and change the way error handling occurs from inside the callbacks.
17:18:55  <groundwater_>i would keep performance as the #1 criteria
17:18:59  <trevnorris>ok
17:19:00  <trevnorris>done
17:19:07  <groundwater_>i've been using _rawDebug for checking my code
17:19:31  <tjfontaine>the function that shall not be named
17:20:14  <groundwater_>i think before using _rawDebug you should have to email tjfontaine and explain why you want to use it
17:20:22  <tjfontaine>:)
17:20:29  <groundwater_>then he generates a one-time key that lets you use it for 5 minutes only
17:20:47  <tjfontaine>that would be fun, it's like FLEX for apis
17:21:02  <groundwater_>actually, it's easy enough to stub using fs.writeSync you could leave it out
17:22:07  <groundwater_>but seriously, i think if there are async-listener docs there should be a big banner "you cannot use console.log"
17:22:39  * julianduquejoined
17:22:54  * pachetquit (Ping timeout: 252 seconds)
17:24:40  * bnoordhuisjoined
17:25:58  <trevnorris>isaacs: on a totally unrelated note, I managed to get pipe_wrap throughput up to 42Gb/s
17:27:29  * inolenquit (Quit: Leaving.)
17:29:18  <indutny>whoa
17:29:26  <indutny>that sounds like a big achievement
17:29:27  <indutny>congrats
17:31:16  <piscisaureus_>why the change where require('events') === EventEmitter...
17:31:24  <trevnorris>indutny: heh, thanks. it's mainly because I wrote a custom handler directly on top of pipe_wrap that does nothing except count the bytes that come through.
17:31:52  <trevnorris>piscisaureus_: community request I believe it was. there's a pr about it somewhere.
17:32:43  <isaacs>trevnorris: rad
17:32:58  <isaacs>piscisaureus_: acceptance of common node.js style
17:33:06  * bnoordhuisquit (Ping timeout: 245 seconds)
17:33:15  <isaacs>piscisaureus_: and it was just easier to relent and accept the patch rather than keep saying no
17:33:19  <isaacs>piscisaureus_: since it does no harm
17:33:37  <isaacs>ok, landing the 6214 patches
17:33:42  <MI6>nodejs-master-windows: #414 UNSTABLE windows-x64 (22/646) windows-ia32 (19/646) http://jenkins.nodejs.org/job/nodejs-master-windows/414/
17:33:46  <isaacs>if you wanan review them, come to the secret room
17:34:24  <piscisaureus_>the even more secret room
17:39:27  * bnoordhuisjoined
17:40:57  * pachetjoined
17:40:58  * pachetquit (Changing host)
17:40:58  * pachetjoined
17:44:04  * st_lukequit (Read error: Connection reset by peer)
17:44:26  * st_lukejoined
17:45:16  * amartensjoined
17:46:17  * AvianFluquit (Remote host closed the connection)
17:53:15  <MI6>libuv-master: #287 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/287/
17:54:05  * paulfryzeljoined
17:54:48  <trevnorris>groundwater_: well, there seems to be a bug in 6011 that if the first thing you do is addAsync then setTimeout, the net module fails. still figuring out why.
17:55:18  <trevnorris>groundwater_: oh, I meant to add, if you're trying to console.log inside the asyncListener
17:55:33  <trevnorris>seems the timer module hasn't finished loading or something...
17:57:17  <groundwater_>trevnorris: i should also mention, i discovered a bug in one of the tests i sent you
17:57:23  <trevnorris>ok
17:57:50  * bnoordhuisquit (Ping timeout: 240 seconds)
17:59:52  * st_lukequit (Remote host closed the connection)
18:00:11  * dshaw_joined
18:00:23  <MI6>libuv-node-integration: #272 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/272/
18:00:57  <groundwater_>trevnorris: i'll send you the fix at some point
18:00:57  * `3E|DINNERchanged nick to `3E
18:01:02  <groundwater_>i assume it's not an urgent issue
18:01:08  <trevnorris>groundwater_: thanks. and no
18:01:14  <trevnorris>i'm still finishing up the docs.
18:01:29  * mikealjoined
18:02:01  <MI6>joyent/node: isaacs master * 085dd30 : http: provide backpressure for pipeline flood (+1 more commits) - http://git.io/UXPNWw
18:02:29  <piscisaureus_>trevnorris: so asyncListener handles are also fired when a handleWrap is created?
18:02:36  * mcavagejoined
18:03:01  <trevnorris>piscisaureus_: yeah, and reqwrap, and pretty much any c++ class that will result in calling MakeCallback()
18:03:24  <piscisaureus_>trevnorris: so the "after" functions of handles run around the close callback
18:03:32  <piscisaureus_>?
18:03:58  <trevnorris>no, the after function runs immediately after the callback that was passed to MakeCallback().
18:04:39  <trevnorris>so there are cases where async listener will be called for handles that don't result in a MakeCallback(), but if for some reason one of them errors, the error function will still catch that.
18:05:08  <piscisaureus_>trevnorris: so is there a way to intercept handle.close()
18:05:22  <piscisaureus_>trevnorris: I think that should be called with MakeCallback
18:05:43  <trevnorris>piscisaureus_: yeah, it'll intercept that I believe. let me double check.
18:07:21  <trevnorris>piscisaureus_: but I was playing with the idea of somehow running a callback just before the class destructor was called. and adding a "done" field
18:07:59  <trevnorris>it was out of scope, but definitely within reason.
18:11:00  <piscisaureus_>HandleWrap.addAsyncListener is also a secret api
18:11:00  <trevnorris>piscisaureus_: here's an example: https://gist.github.com/trevnorris/7012225
18:11:04  <trevnorris>yeah
18:11:44  <trevnorris>so, server._handle.addAsyncListener() is there, but since it lives on the _handle, figured it shouldn't be exposed.
18:11:57  <trevnorris>or else people might start doing server._handle.addAsyncListener()
18:14:30  <MI6>nodejs-master: #622 UNSTABLE osx-x64 (1/647) smartos-ia32 (6/647) smartos-x64 (9/647) osx-ia32 (1/647) http://jenkins.nodejs.org/job/nodejs-master/622/
18:15:37  * kenperkinsjoined
18:16:40  * AvianFlujoined
18:20:38  * AvianFluquit (Ping timeout: 240 seconds)
18:23:11  * bnoordhuisjoined
18:25:18  <MI6>joyent/node: Ben Noordhuis master * 4234bcc : debugger: fix SIGUSR1 bootstrap race condition (+1 more commits) - http://git.io/3eHIcw
18:26:50  <othiym23>why would people do that
18:26:56  <othiym23>(not saying they won't, I just wish I knew why)
18:27:10  <othiym23>why do people do the things they do
18:27:20  <MI6>nodejs-master-windows: #415 UNSTABLE windows-x64 (25/647) windows-ia32 (23/647) http://jenkins.nodejs.org/job/nodejs-master-windows/415/
18:30:03  <trevnorris>othiym23: why do you hijack uncaughtException? ;)
18:30:58  * qardjoined
18:31:07  * qardpart
18:34:13  * paddybyersjoined
18:34:54  * bajtosquit (Quit: bajtos)
18:38:18  * mikealquit (Quit: Leaving.)
18:38:31  * mikealjoined
18:43:35  <MI6>nodejs-master: #623 UNSTABLE smartos-ia32 (9/647) smartos-x64 (10/647) linux-ia32 (1/647) http://jenkins.nodejs.org/job/nodejs-master/623/
18:48:57  * AvianFlujoined
18:49:54  * dshaw_quit (Quit: Leaving.)
18:51:00  * defunctzombiechanged nick to defunctzombie_zz
18:51:35  <MI6>nodejs-master-windows: #416 UNSTABLE windows-x64 (22/647) windows-ia32 (22/647) http://jenkins.nodejs.org/job/nodejs-master-windows/416/
18:51:43  * bradleymeckquit (Quit: bradleymeck)
18:51:58  * AvianFlu_joined
18:52:14  * AvianFluquit (Read error: Connection reset by peer)
18:52:18  * dshaw_joined
18:53:19  * AvianFlu_changed nick to AvianFlu
18:53:49  <indutny>bnoordhuis: yt?
18:53:52  * bradleymeckjoined
18:54:07  <indutny>what do you think about creating separate uv_loop_t for polling stuff if FSEventStart fails
18:54:20  * vptrjoined
18:56:28  * defunctzombie_zzchanged nick to defunctzombie
18:56:30  <indutny>seems like an overkill
18:56:40  <bnoordhuis>indutny: i was going to ask 'why?'
18:56:43  <indutny>haha
18:56:49  <indutny>because threading is complicated :)
18:57:09  <indutny>FSEventStream starts in CF thread
18:57:17  <indutny>aaaah
18:57:20  <indutny>wait a sec,
18:57:21  <indutny>nvm
18:57:29  <indutny>I just figured out that I've list of all handles
18:57:37  <bnoordhuis>... and?
18:57:43  <indutny>and don't need to pass costful messages between threads
18:58:05  <indutny>ok, I'll do it without second loop
18:58:10  <bnoordhuis>what are you proposing instead?
18:58:26  <bnoordhuis>anything that does O(n) scans is out, you know that, right?
18:58:50  * bradleymeckquit (Quit: bradleymeck)
18:58:56  <indutny>oh, really?
18:59:04  <indutny>we're doing it now
18:59:05  <indutny>anyway
18:59:08  <indutny>:D
18:59:18  <indutny>haven't you seen that while reviewing FSEvents code?
19:00:13  <bnoordhuis>oh, i thought you were talking about loop->active_handles
19:04:19  * EhevuTovjoined
19:08:38  * paulfryzelquit (Remote host closed the connection)
19:09:13  * paulfryzeljoined
19:13:01  * piscisaureus_quit (Ping timeout: 272 seconds)
19:13:13  <trevnorris>bnoordhuis: thank you for changing "domain" to "hostnames" in 6355.
19:13:47  * paulfryzelquit (Ping timeout: 268 seconds)
19:16:24  <bnoordhuis>trevnorris: np, it was getting in my way too :)
19:16:57  <bnoordhuis>you know, i kind of wonder how we ever settled on 'domain' as the property name...
19:17:58  <trevnorris>bnoordhuis: oh, on <insert PR here> about removing err.domain. that's totally doable with my 6011 patch, but othiym23 said he knows devs that are using it.
19:18:17  <trevnorris>I don't mind breaking their code, but that decision isn't up to me. :)
19:19:05  <bnoordhuis>what are people using it for?
19:19:19  <trevnorris>no idea
19:19:28  <bnoordhuis>othiym23: ^ ?
19:19:39  <trevnorris>groundwater_: maybe you also have an idea?
19:19:59  * mikealquit (Quit: Leaving.)
19:21:10  * EhevuTovquit (Quit: This computer has gone to sleep)
19:22:13  * EhevuTovjoined
19:30:44  <trevnorris>why w/ fs don't we return some type of handle for asynchronous events?
19:31:07  <trevnorris>well, guess it never made sense before.
19:31:18  <trevnorris>don't mind me, just having a conversation with myself.
19:33:34  * kenperkinsquit (Quit: Computer has gone to sleep.)
19:35:16  <trevnorris>bnoordhuis: if you wouldn't mind doing an initial review of 6011 at your leisure, i'm trying to pound through the issue tracker. :)
19:38:14  <bnoordhuis>trevnorris: oh, right. i'll try to do that tonight. grappling with some v8 issue atm
19:38:28  <trevnorris>bnoordhuis: anything interesting?
19:40:07  <bnoordhuis>trevnorris: not really. investigating why d8 sometimes segfaults when you feed linux-tick-processor big v8.log files
19:40:18  <bnoordhuis>probably an out of memory issue or something
19:40:26  <trevnorris>bnoordhuis: hm, strange. how big, and what v8 version?
19:41:29  <bnoordhuis>trevnorris: v8 HEAD and - /me checks - on the order of 7-8 MB
19:42:17  <trevnorris>that's all? I've been pumping 100MB files through that the last few days, but that's on latest v3.21
19:44:58  <trevnorris>bnoordhuis: you know how to build that sucker w/o needing the massive icu dep? haven't been able to figure out the right flag.
19:49:11  <bnoordhuis>trevnorris: make x64.debug extrachecks=on i18nsupport=off
19:49:21  <bnoordhuis>that's what i use anyway
19:49:53  * paulfryzeljoined
19:50:04  <trevnorris>thanks
19:50:29  * dominictarrquit (Quit: dominictarr)
19:59:01  * dapchanged nick to Guest84659
19:59:45  <MI6>joyent/node: Ben Noordhuis master * a2d1cbe : dns: set hostname property on error object (+1 more commits) - http://git.io/fkKpig
20:01:32  * brsonquit (Quit: leaving)
20:01:50  * brsonjoined
20:04:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:11:28  <MI6>nodejs-master: #624 UNSTABLE smartos-ia32 (6/647) smartos-x64 (7/647) http://jenkins.nodejs.org/job/nodejs-master/624/
20:13:51  * brsonquit (Quit: leaving)
20:14:06  * brsonjoined
20:15:40  * dominictarrjoined
20:16:41  * dshaw_quit (Quit: Leaving.)
20:20:30  <MI6>nodejs-master-windows: #417 UNSTABLE windows-x64 (22/647) windows-ia32 (21/647) http://jenkins.nodejs.org/job/nodejs-master-windows/417/
20:21:02  * TooTallNatejoined
20:29:44  * paulfryzelquit (Remote host closed the connection)
20:34:37  <MI6>joyent/node: Fedor Indutny master * 2bc30f2 : cpplint: disallow if one-liners (+1 more commits) - http://git.io/pycTaw
20:35:17  <indutny>tadam
20:36:26  * mikealjoined
20:39:28  * wwickspart
20:41:01  * paulfryzeljoined
20:42:07  * paulfryzelquit (Read error: Connection reset by peer)
20:42:26  * paulfryzeljoined
20:43:01  * `3Echanged nick to `3E|GONE
20:46:48  <MI6>nodejs-master: #625 UNSTABLE smartos-ia32 (7/647) smartos-x64 (7/647) linux-ia32 (1/647) http://jenkins.nodejs.org/job/nodejs-master/625/
20:47:27  * Guest84659quit (Quit: Leaving.)
20:47:41  * dshaw_joined
20:49:04  * dshaw_quit (Read error: Connection reset by peer)
20:49:21  * dshaw_joined
20:52:13  * paulfryz_joined
20:52:41  * brsonquit (Ping timeout: 245 seconds)
20:53:46  * brsonjoined
20:55:22  <MI6>nodejs-master-windows: #418 UNSTABLE windows-x64 (21/647) windows-ia32 (22/647) http://jenkins.nodejs.org/job/nodejs-master-windows/418/
20:55:26  * paulfryzelquit (Ping timeout: 240 seconds)
20:58:38  * dshaw_quit (Ping timeout: 240 seconds)
21:06:49  <trevnorris>bnoordhuis: fwiw using the same build options and generating a 76MB v8.log file I was able to parse it just fine. took 3 mins, but it worked.
21:08:31  <bnoordhuis>trevnorris: yeah, i haven't seen it anymore after a clean rebuild
21:08:41  <trevnorris>hm. strange.
21:09:12  <bnoordhuis>probably cosmic rays, always flipping my bits
21:09:51  <trevnorris>hah, yeah.
21:23:28  * mikealquit (Quit: Leaving.)
21:25:44  * austoquit (Quit: Leaving)
21:27:38  <octetcloud>Is it helpful to keep PRs rebased against their target branch? Or just annoying because it breaks comments, and you all would rather squash during merge?
21:29:38  <tjfontaine>rebasing usually isn't a big deal for our work flow, unless what you're working on has also changed
21:31:21  * vptrquit (Ping timeout: 272 seconds)
21:32:23  <tjfontaine>but squashing into logical commits we'd prefer if you do
21:33:54  * julianduquequit (Quit: leaving)
21:33:56  <octetcloud>tjfontaine: yes, I don't want to push burden of history cleanup on merger
21:34:47  <octetcloud>For #5914 in particular, should I squash the commits on cluster.markdown into a single, and rebase whole thing onto v0.10 HEAD. sound reasonable?
21:35:53  <tjfontaine>yes, that's what I would do
21:38:26  * mikealjoined
21:46:43  <trevnorris>indutny: well, here we go rebasing on your lint commit :P
21:56:34  * vptrjoined
22:01:41  * vptrquit (Ping timeout: 245 seconds)
22:02:30  * rendarquit
22:07:39  <trevnorris>tjfontaine: you had some unresponded comments on https://github.com/joyent/node/pull/5914, have any issues w/ it?
22:08:11  <trevnorris>bnoordhuis: also all your notes were taken care of on https://github.com/joyent/node/pull/5914. I gave it a quick look over and lgtm. if you're ok then i'll merge.
22:08:26  <bnoordhuis>trevnorris: yep, okay by me
22:08:44  <trevnorris>coolio. and this time I'll remember to double check his real name is used :P
22:08:56  <bnoordhuis>:)
22:09:42  <tjfontaine>well, ya it would be nice if "it" was actually "node" since the antecedent is some what ambiguous to me
22:10:03  <tjfontaine>the phrasing is less than ideal I guess for what it's trying to achieve
22:10:34  <tjfontaine>I still agree with my comment abotu not deduplicating documentation like that
22:11:06  * rjequit (Excess Flood)
22:11:09  <MI6>joyent/node: Sam Roberts v0.10 * 2e16037 : doc: cluster documentation cleanup and corrections (+1 more commits) - http://git.io/5ApA2w
22:11:18  * rjejoined
22:11:54  <trevnorris>well, it's better than it was. and imho i love having the community write out docs.
22:11:58  * Raltquit (Quit: Bye)
22:12:06  <trevnorris>tjfontaine: almost makes me wish we had like wiki.nodejs.org
22:12:18  <trevnorris>where the community could contribute more in depth docs.
22:12:29  * Raltjoined
22:15:57  <trevnorris>isaacs: thoughts on creating wiki.nodejs.org. I feel like the github wiki is more full of misc things, and this would be geared towards in depth API documentation, usage, etc.
22:16:39  <tjfontaine>wiki's are not really all that good
22:16:42  <tjfontaine>but we have one
22:17:25  <trevnorris>well, forget the wiki part. more just a place for users to contribute docs. the github wiki sucks.
22:17:30  <trevnorris>tjfontaine: where's our current one?
22:17:44  <tjfontaine>trevnorris: also, why did you ask about my opinions on my unanswered comments if you were just going to commit it?
22:17:48  <tjfontaine>trevnorris: github wiki
22:19:32  <trevnorris>tjfontaine: wasn't planning on committing it that quickly (i.e. giving you time to respond) but since it'd been 3 months and you hadn't responded to the comments and bnoordhuis gave me the ok figured I'd throw it in.
22:20:44  <tjfontaine>it's just kind of frustrating to context switch into it, only to see it get committed
22:20:54  * AvianFluquit (Remote host closed the connection)
22:22:49  <trevnorris>sorry, next time I ask your opinion I'll wait for it. :)
22:22:49  <trevnorris>just took too much adderall this morning and my mind's going way too fast
22:23:12  <MI6>nodejs-v0.10: #1538 UNSTABLE smartos-x64 (5/601) smartos-ia32 (5/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1538/
22:23:39  <tjfontaine>right, it helps if we just slow down a little on that commit process, that should also alleviate some of the desire to force push to handle commit messages we wish were slightly better
22:23:47  * paulfryz_quit (Remote host closed the connection)
22:24:04  <tjfontaine>there's rarely a scenario where it really/truly needs to be LGTM ZOMG COMMIT
22:24:24  * paulfryzeljoined
22:25:05  <trevnorris>yeah, but we also have pr's and issues coming out the yin yang and, myself definitely included, can side track responding to them.
22:25:56  <trevnorris>so usually after 2 maintainers +1 minor commits, I'd give it a go. and the force push mainly was because i forgot to change the committer's name from his github handle to his real name.
22:27:13  <tjfontaine>the realname isn't necessarily a crucial feature, but we can probably work out a simple script to do that part for you
22:28:06  * paddybyersquit (Quit: paddybyers)
22:28:35  <MI6>nodejs-v0.10-windows: #264 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/264/
22:28:38  * paulfryzelquit (Ping timeout: 240 seconds)
22:29:17  <bnoordhuis>joyent wants signed CLAs, right? having commits land with the author's real name + email makes checks after the fact a lot easier
22:32:30  * hzquit
22:35:16  * paddybyersjoined
22:35:17  <tjfontaine>it's certainly a nice to have, and a pre-commit script would certainly make it easier, in fact it could automatically add to the AUTHORS list for a new person -- it woud make all our lives easier, if others start doing release builds
22:35:34  <tjfontaine>I just find it a quite poor reason to do a force push on a public repository
22:38:09  <bnoordhuis>why? force-pushing away the last 20 commits, okay. but a commit that landed 30 seconds ago? i don't have an issue with that
22:39:20  <isaacs>tjfontaine: just out of curiousity, what problems does force pushing cause for jenkins/jankins?
22:40:02  <tjfontaine>isaacs: depending on the timing of the force pushes it means I have to manually intervene to clear out the workspace so it can recover because pulls may fail
22:40:12  <isaacs>i see.
22:40:38  <isaacs>tjfontaine: how dependent on timing is it? ie, is it better if it's faster, or if it's slower?
22:41:04  <tjfontaine>it's better to be slower, but worse for someone external to us
22:41:10  <isaacs>tjfontaine: right
22:41:25  <isaacs>tjfontaine: can that be solved by handling the error better in jankins?
22:41:46  <tjfontaine>we can solve it by continuing the transition away from jenkins
22:41:49  <isaacs>tjfontaine: or is it simply always a thing that's going to require some manual intervention?
22:41:52  <isaacs>i see
22:41:57  <isaacs>so it's jenkins that's the problem, not jankins?
22:41:59  <tjfontaine>but there's nothing wrong with taking a breath before pushing
22:42:03  <tjfontaine>yes, it's jenkins
22:42:21  <isaacs>i'd be fine with a "no force pushes to master, period" rule.
22:42:24  <isaacs>if it was really necessary
22:42:32  <isaacs>but if not, i mean, it's kind of convenient sometimes
22:42:44  <tjfontaine>or we could have a pre-commit that handles the AUTHORS check, which would also solve the CLA match issue
22:43:01  <tjfontaine>so if this is a PR from someone new we can't commit if the author doesn't exist
22:43:36  <isaacs>hm. ok
22:43:40  <tjfontaine>but that doesn't solve the "but I wanted this other log message" part
22:43:51  <isaacs>well, that part is not a real problem.
22:44:05  <isaacs>suck it up, and live with your eternal shame, captured forever in a million forks.
22:44:09  <bnoordhuis>is too. good commit logs are important
22:44:19  <bnoordhuis>also, sometimes patches land that shouldn't have landed
22:44:27  <isaacs>bnoordhuis: yes, that's you should edit them before pushing to master.
22:44:36  <isaacs>bnoordhuis: and we can revert patches that shouldn't have landed.
22:44:50  <isaacs>of course, whatever reasoning we come up with will have some excuses or other workarounds
22:45:03  <isaacs>people made due without force pushign and commit editing for decades before git existed.
22:45:05  <bnoordhuis>yes, but that's just plain annoying when you're digging through the history later on
22:45:30  <bnoordhuis>i worked on a project once that had tons of commit/revert cycles going on
22:45:36  <bnoordhuis>intractable
22:45:49  <isaacs>bnoordhuis: one could argue that the solution to commit/revert cycles is not forced pushing, but slower commits.
22:46:07  <isaacs>more testing, more "reverting forward" to fix the bug rather than simply un-do the previous commit
22:46:09  <bnoordhuis>one could argue a lot of things but the point still stands
22:46:17  <tjfontaine>v8 would have far fewer reverts if they hooked their review process into their CI
22:46:17  <isaacs>bnoordhuis: i am arguing it now :)
22:46:39  <isaacs>we don't have many reverts, and we dont' have many forced pushes to master, either.
22:46:45  <isaacs>actually, we're pretty good at this, as projects go
22:47:01  <bnoordhuis>yeah. so the occassional force-push is okay in my book
22:47:04  <tjfontaine>I agree, I'm perhaps too sensitive to it, I just have a very visceral reaction to it
22:47:08  <bnoordhuis>preferable over a cluttered history
22:47:11  <isaacs>we could give up forced pushing, and it wouldn't be too onerous, and jenkins would be less work for tjfontaine to do manually to clean up
22:47:19  <isaacs>i'm definitely not ideologically anti-rebase.
22:47:25  <isaacs>wrote a whole big freaking blog post about how great it is :)
22:47:54  <isaacs>but editing history of an upstream is inconvenient for many reasons.
22:48:14  <isaacs>branches other than master and stable are free for alls, and that's fine.
22:49:04  <isaacs>what if jenkins had a 1m timeout or something?
22:49:14  <isaacs>tjfontaine: the github api is actually alerting jankins, not jenkins directly, right?
22:49:24  <tjfontaine>that's right
22:49:46  <isaacs>the downside would be a usually-unnecessary wwait for CI feedback, of course.
22:50:24  <trevnorris>well, when this conversation is done I have an fs API question. :)
22:50:30  <tjfontaine>we can make the reporting time from CI faster, by spinning up more zones potentially, at least for windows responsives
22:50:55  <isaacs>tjfontaine: sure, but waiting for a minute befor pulling the new code won't make it faster, that's for sure :)
22:51:31  <tjfontaine>right
22:51:36  <bnoordhuis>trevnorris: shoot
22:52:34  * mcavagequit (Remote host closed the connection)
22:53:07  * mcavagejoined
22:53:57  <trevnorris>bnoordhuis: currently fs async function return undefined. I'm assuming that's because no instance object needed to be created. but in 6011 it will be creating an async event instance object.
22:53:57  <trevnorris>so wondering if we could return that. see. for tcp and pipe there's a hidden addAsyncListeners API that allows you to add it to the handle after the fact.
22:53:58  <isaacs>tjfontaine: but, ok, let's say we make jankins do a setTimeout(.., 30000), and have a hard-and-fast rule that forced pushing is allowed for no more than 15 seconds after the initial push. bnoordhuis would that seem reasonable to you, at least until we have a CI system that won't fall over?
22:54:15  <trevnorris>bnoordhuis: but it's hidden because it's only accessible via the ._handle property
22:54:33  <isaacs>trevnorris: hmmm.... i have much foreboding regarding this idea.
22:54:44  <trevnorris>ok
22:55:06  <bnoordhuis>trevnorris: there are probably jokers out there that have code that does -> if (fs.open(...)) throw "fs.open failed"
22:55:12  <trevnorris>what's your forebode?
22:55:21  <bnoordhuis>iow, it's probably going to break something somewhere
22:55:33  <tjfontaine>isaacs: I'm fine with that, presuming we can agree with a timeframe for it
22:55:38  <isaacs>trevnorris: what would be pretty awesome (wishful blue-sky thinking here) is if fs.open() returned anything, it shoudl besome kind of monad or promise or something
22:55:43  <trevnorris>bnoordhuis: wait, so it can return an error code?
22:55:48  <isaacs>trevnorris: today? no
22:55:57  <trevnorris>thought if you pass a callback it always returned undefined
22:56:03  <bnoordhuis>trevnorris: no, but i have seen several snippets of code that assume it does
22:56:13  <bnoordhuis>isaacs: re force-pushing, yeah, seems reasonable
22:57:02  * mcavagequit (Ping timeout: 240 seconds)
22:57:15  <bnoordhuis>btw, you guys know v8 is going to implement promises natively, right?
22:57:43  <trevnorris>imho it seems inconsistent that for other api's we return some type of async instance object when an async call is made, but once you fire off an fs operation then there's nothing you can do.
22:57:48  <trevnorris>it's gone into oblivion.
22:58:03  <isaacs>bnoordhuis: right, and when it does, using those promises would be rad
22:58:20  <bnoordhuis>trevnorris: i guess. fs operations are one-shot events though
22:58:25  <isaacs>trevnorris: where do we return the async instance object?
22:58:30  <isaacs>trevnorris: you mean like net.connect and such?
22:58:43  <trevnorris>bnoordhuis: well, i'll consider them acceptable after i've done considerable performance testing.
22:59:03  <isaacs>i'm not considering promises for anything sooner than node 2.0, btw.
22:59:04  <bnoordhuis>trevnorris: don't worry, i'm not saying we should switch right away :)
22:59:19  <isaacs>but, it would be nice to support as another native alternative to callbacks.
22:59:21  <trevnorris>isaacs: well, sort of there. but that's technically a sugar object of the EventEmitter. but internally TCPWrap/PipeWrap/etc all do
22:59:31  <trevnorris>so it's seems that FSEventWrap should as well.
22:59:36  <isaacs>trevnorris: right, because those aren't one-off events.
22:59:48  <isaacs>trevnorris: and you do get a evenwrap watcher thingie from fs.watch()
22:59:58  <isaacs>s/one-off events/one-off requests/
23:01:07  <trevnorris>the point is more that with 6011 FSEventWatch will have an instance object, and it could be useful.
23:01:18  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:01:38  <isaacs>Purely hypothetical question for everyone in this room: Do you know (or are you) someone who would be working on node-core full time if not for a day-job?
23:02:03  <isaacs>ie, if a company where to hire a new node-core engineer who isn't already working on node-core full time, who would it be?
23:02:06  * defunctzombiechanged nick to defunctzombie_zz
23:02:38  <trevnorris>like, say you've called fs to open up an file, but somewhere an error is thrown, you could cancel the request to open the file.
23:02:44  <trevnorris>i'm just spit balling.
23:02:54  <isaacs>trevnorris: yeah, ryah and i talked abotu that way back in the day
23:03:03  <isaacs>never went past spit balls, though
23:03:07  <trevnorris>heh
23:03:14  <isaacs>i know piscisaureus has some ideas about that.
23:03:19  <bnoordhuis>libuv on unix actually supports it up to a point
23:03:44  <bnoordhuis>once the fs request is actually executing it's no longer cancellable
23:03:44  <trevnorris>yeah, i only bring it up because in 6011 it pretty much exposes this ability
23:03:47  <isaacs>srsly, about the recruiting thing.
23:04:03  <isaacs>they'll probably hire a rubyist or something if we don't get them to spend their money on node :)
23:04:13  <isaacs>think about it, lmk if you have any ideas
23:04:15  <bnoordhuis>isaacs: i don't know. no one really comes to mind
23:04:18  <trevnorris>bnoordhuis: so that's an platform dependent thing?
23:04:20  <bnoordhuis>but i'll think about it :)
23:04:27  <isaacs>bnoordhuis: and i'm sure you'd've tried to get strongloop to hire them by now if you did :)
23:04:33  <bnoordhuis>trevnorris: well, it's mostly a matter of bertje not having implemented it on windows
23:04:34  <isaacs>bnoordhuis: i'm in pretty much the same boat.
23:04:41  <bnoordhuis>yeah, indeed :)
23:05:00  <trevnorris>bnoordhuis: ah, cool. well w/ his latest obsession of wrappers/handlers or whatever he calls them, think I might be able to convince him to at some point. :)
23:05:19  <isaacs>it's not joyent or strongloop, so maybe if someone just doesn't like those companies, or us personally, but they do like node and want to work on core, it could be a good opportunity,
23:05:54  * mikealquit (Quit: Leaving.)
23:06:05  * c4milojoined
23:06:28  <mmalecki>isaacs: hey, I'm looking for a job! ;)
23:06:35  <trevnorris>isaacs: heh, i'm checking w/ a couple of my programming friends. we'll see what they say.
23:06:50  <mmalecki>tjfontaine: isaacs out of curiosity, why did you move away from Travis?
23:07:12  <isaacs>mmalecki: node takes too long to build, and we need more OS'es and tasks than travis supports
23:07:13  <tjfontaine>I can find you the github issue comment I made on it, if youd' like
23:07:23  <tjfontaine>but in short their matrix will never support all of our configurations
23:07:24  <bnoordhuis>1 am... okay, signing off. goodnight everyone
23:07:29  <isaacs>g'nite bnoordhuis
23:07:31  <trevnorris>night
23:07:52  <mmalecki>isaacs: ah, got it
23:08:06  <octetcloud>trevnorris: Is there any way to see what emails I've signed the CLA with? And make sure that the couple I use regularly are all in it, to avoid the CLA nagging, and commit troubles?
23:08:20  <trevnorris>tjfontaine: ^
23:08:41  <isaacs>octetcloud: it's a private google doc, so... no
23:08:48  <isaacs>octetcloud: but if you ask, i can search by your name, and tell you :)
23:09:05  <tjfontaine>I can tell you what jankins checks on :)
23:09:36  <isaacs>man, since i registered izs.me, and have been using [email protected] everywhere, my life has been so easy.
23:09:37  <isaacs>one short public email address.
23:09:42  <octetcloud>Sam Roberts, I do most o/s work with [email protected], but am using [email protected] more now.
23:10:22  <isaacs>damn near impossible to tell someone over the phone, though. the most fun one i got was [email protected]
23:10:51  <tjfontaine>do you own that domain?
23:10:53  <octetcloud>isaacs: I was meaning to move to [email protected], but that just seems to cause problems, and I have to do it everywhere, and SL's CI really likes it if I use [email protected], because jenkins is a bit sucky.
23:10:56  <isaacs>[email protected]
23:11:04  <isaacs>tjfontaine: yeah
23:11:04  * Kakeraquit (Ping timeout: 265 seconds)
23:11:13  <isaacs>tjfontaine: not me.com, no :)
23:11:16  <tjfontaine>well :P
23:11:17  <isaacs>tjfontaine: that's $APPL's
23:11:24  <tjfontaine>do you have that $email :P
23:11:38  <tjfontaine>octetcloud: jankins checks on your commit email address and then your github user information to do the checks
23:11:38  <isaacs>oh, no
23:11:50  <isaacs>i don't have a me.com email i don't think, unless one just got made for me somehow
23:12:17  <isaacs>octetcloud: so you wnat to make sure that [email protected] is also [email protected]?
23:12:17  <mmalecki>isaacs: seriously tho, is Joyent looking for people for node work?
23:12:22  <isaacs>mmalecki: not joyent.
23:12:23  <tjfontaine>actually, no it just checks on your cla email address
23:12:26  * bnoordhuisquit (Ping timeout: 268 seconds)
23:12:27  <isaacs>mmalecki: but yes, seriously
23:12:41  <mmalecki>isaacs: ah. then, yes, I'd seriously apply :)
23:12:56  * pachetquit (Quit: leaving)
23:13:11  <octetcloud>isaacs: [email protected] === [email protected] === [email protected], if that is possible. sorry for the trouble.
23:13:15  <mmalecki>(today was my last day)
23:14:20  <tjfontaine>octetcloud: which one will you be using for your future PRs?
23:14:21  <tjfontaine>:)
23:16:06  <trevnorris>isaacs: what's your thoughts on adding response.statusMessage, like response.statusCode?
23:16:15  <octetcloud>If I have to choose one, I will use [email protected] The setting is kindof a pain to setup specific to each repo, and I use vieuxtech on my own-time projects, like libnet, so it would be convenient for all three to work. But I can always rewrite history, if I know it has to be the one.
23:16:38  * julianduquejoined
23:16:42  <isaacs>trevnorris: hm.. i think i'd actually done it, but then rolled back that refactor, and forgot it.
23:16:45  <isaacs>trevnorris: so, +1
23:16:50  <trevnorris>coolio
23:17:17  <isaacs>tjfontaine: if there's three separate CLA entries for octetcloud with three separate email addresses it should Just Work, right?
23:17:25  <tjfontaine>yes, if there's 3 it's no problem
23:18:35  <octetcloud>thank you. I'll try to be consistent.
23:19:52  <tjfontaine>consistency helps everyone :)
23:20:30  <isaacs>octetcloud: there were to for [email protected], one fore [email protected] I added [email protected][
23:20:36  <isaacs>octetcloud: should be all set now
23:21:39  * hzjoined
23:25:03  * TooTallNatejoined
23:25:43  * paulfryzeljoined
23:25:47  * paulfryzelquit (Remote host closed the connection)
23:29:32  * Benvie_quit
23:31:32  * AvianFlujoined
23:35:55  * mcavagejoined
23:36:15  * mcavagequit (Read error: Connection reset by peer)
23:36:29  * AvianFluquit (Ping timeout: 268 seconds)
23:36:30  * mcavagejoined
23:56:04  * AvianFlujoined
23:56:16  * julianduquequit (Ping timeout: 245 seconds)
23:56:41  * paddybyersquit (Quit: paddybyers)
23:58:55  <MI6>libuv-master-gyp: #227 FAILURE windows-x64 (4/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/227/