00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:05:08  * rosskquit
00:10:03  * cjihrigjoined
00:12:09  * mrvisserjoined
00:14:58  * cjihrigquit (Ping timeout: 264 seconds)
00:21:39  * mrvisserquit (Remote host closed the connection)
00:22:14  * mrvisserjoined
00:25:52  * AlexisMochaquit (Ping timeout: 250 seconds)
00:26:44  * mrvisserquit (Ping timeout: 260 seconds)
00:27:47  * AlexisMochajoined
00:29:31  * zz_karupachanged nick to karupa
00:48:17  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:49:08  * cjihrigjoined
00:52:05  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:52:40  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:53:59  * a_lequit (Remote host closed the connection)
00:57:24  * a_lejoined
01:02:21  * a_lequit (Remote host closed the connection)
01:02:53  * dap_1quit (Quit: Leaving.)
01:09:02  * kazuponjoined
01:10:51  * avalanche123quit (Remote host closed the connection)
01:12:34  * jgiquit (Quit: jgi)
01:18:46  * rmgquit (Remote host closed the connection)
01:20:06  * seldoquit (Remote host closed the connection)
01:21:00  * c4milojoined
01:21:55  * nickleeflyjoined
01:22:42  * mrvisserjoined
01:27:17  * mrvisserquit (Ping timeout: 245 seconds)
01:29:41  * sh1mmerjoined
01:30:37  * c4miloquit (Remote host closed the connection)
01:56:07  * c4milojoined
01:58:41  * Left_Turnquit (Remote host closed the connection)
02:09:01  * wolfeidauquit (Remote host closed the connection)
02:21:57  * wolfeidaujoined
02:23:29  * mrvisserjoined
02:28:04  * mrvisserquit (Ping timeout: 250 seconds)
02:33:59  * wolfeidauquit (Remote host closed the connection)
02:34:48  * rmgjoined
02:34:57  * wolfeidaujoined
02:36:31  * wolfeidauquit (Remote host closed the connection)
03:08:51  * c4miloquit (Remote host closed the connection)
03:12:33  * cjihrigquit (Quit: Leaving.)
03:14:35  * mrvisserjoined
03:15:11  * c4milojoined
03:15:25  * mikealjoined
03:16:38  * c4miloquit (Read error: Connection reset by peer)
03:16:47  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
03:17:52  * c4milojoined
03:18:24  * sh1mmerjoined
03:19:32  * mrvisserquit (Ping timeout: 272 seconds)
03:22:03  * c4miloquit (Ping timeout: 240 seconds)
03:24:33  * a_lejoined
03:25:34  * Wraithanquit (Read error: Connection reset by peer)
03:28:45  * kazuponquit (Remote host closed the connection)
03:29:12  * kazuponjoined
03:33:33  * kazuponquit (Ping timeout: 246 seconds)
03:37:02  * mikealquit (Quit: Leaving.)
04:09:35  * kazuponjoined
04:14:14  * kazuponquit (Ping timeout: 255 seconds)
04:15:24  * mrvisserjoined
04:16:22  * kellabytequit (Quit: Connection closed for inactivity)
04:17:43  * kazuponjoined
04:19:37  * mrvisserquit (Ping timeout: 244 seconds)
04:28:45  * rphillips_joined
04:30:18  * isaacsquit (Disconnected by services)
04:30:18  * isaacs_joined
04:30:30  * acrichto_joined
04:34:04  * trevnorr1sjoined
04:34:30  * mitsuhiko_joined
04:34:32  * Damn3d_joined
04:35:33  * Damn3dquit (*.net *.split)
04:35:33  * trevnorrisquit (*.net *.split)
04:35:33  * rphillipsquit (*.net *.split)
04:35:33  * othiym23quit (*.net *.split)
04:35:34  * acrichtoquit (*.net *.split)
04:35:34  * mitsuhikoquit (*.net *.split)
04:35:34  * blissdevquit (*.net *.split)
04:41:34  * othiym23joined
04:42:03  * cjihrigjoined
04:43:09  * blissdevjoined
04:49:35  * cjihrigquit (Ping timeout: 244 seconds)
05:05:58  * c4milojoined
05:07:02  * mikealjoined
05:09:46  * nickleeflyquit (Quit: Connection closed for inactivity)
05:10:34  * c4miloquit (Ping timeout: 250 seconds)
05:16:07  * mrvisserjoined
05:20:26  * mrvisserquit (Ping timeout: 250 seconds)
05:46:13  * cjihrigjoined
05:50:50  * cjihrigquit (Ping timeout: 260 seconds)
06:02:22  * a_lequit (Remote host closed the connection)
06:14:26  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
06:15:12  * janjongboomjoined
06:16:56  * mrvisserjoined
06:21:33  * mrvisserquit (Ping timeout: 244 seconds)
06:39:28  * avalanche123joined
06:39:56  * rendarjoined
06:46:31  * cjihrigjoined
06:51:04  * cjihrigquit (Ping timeout: 272 seconds)
06:56:57  * avalanch_joined
06:56:58  * avalanche123quit (Read error: Connection reset by peer)
06:58:47  * avalanche123joined
06:58:47  * avalanch_quit (Read error: Connection reset by peer)
07:00:49  * Soarez|afkchanged nick to Soarez
07:01:21  * nickleeflyjoined
07:03:21  * a_lejoined
07:03:40  <txdv>saghul: ill try to sit down this evening on the patches
07:03:48  <txdv>been a tight week weekend and all
07:08:22  * a_lequit (Ping timeout: 264 seconds)
07:13:16  <saghul>txdv: awesome, thanks!
07:16:40  * Soarezchanged nick to Soarez|afk
07:17:39  * mrvisserjoined
07:22:06  * mrvisserquit (Ping timeout: 246 seconds)
07:23:21  * avalanche123quit (Remote host closed the connection)
07:26:36  * Soarez|afkchanged nick to Soarez
07:35:24  * dignifiedquirejoined
07:46:53  * cjihrigjoined
07:51:14  * cjihrigquit (Ping timeout: 250 seconds)
07:57:39  * Left_Turnjoined
07:58:54  * rmgquit (Remote host closed the connection)
07:59:28  * rmgjoined
08:04:10  * rmgquit (Ping timeout: 264 seconds)
08:11:00  * rmgjoined
08:18:23  * mrvisserjoined
08:22:44  * mrvisserquit (Ping timeout: 240 seconds)
08:31:37  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:37:35  * inolenquit (Quit: Leaving.)
08:42:42  * c4milojoined
08:47:03  * Soarezchanged nick to Soarez|afk
08:47:09  * c4miloquit (Ping timeout: 246 seconds)
08:47:10  * janjongboomjoined
08:47:14  * cjihrigjoined
08:51:34  * cjihrigquit (Ping timeout: 250 seconds)
08:54:53  * rmgquit (Remote host closed the connection)
08:56:09  * rmgjoined
09:00:34  * rmgquit (Ping timeout: 255 seconds)
09:09:46  * nickleeflyquit (Quit: Connection closed for inactivity)
09:19:09  * mrvisserjoined
09:20:23  <mmalecki>saghul: alive yet?
09:21:46  * Soarez|afkchanged nick to Soarez
09:23:58  * mrvisserquit (Ping timeout: 264 seconds)
09:24:10  <saghul>mmalecki: pong!
09:24:24  <saghul>I was on Windows
09:32:11  <mmalecki>saghul: oh, word. so tonight 18:00 at my place?
09:32:36  <mmalecki>saghul: do you know if Bert is still in Amsterdam btw?
09:35:22  <saghul>mmalecki: 18:30? also, msg me your address, I think I had it but I lost it
09:35:39  <mmalecki>18:30 sounds good
09:35:51  <saghul>not sure if bert is around, send an email just in case, he responded to some libuv issues 2 days ago
09:37:14  <MI6>joyent/node: Fedor Indutny master * aa3b4b4 : deps: update openssl to v1.0.1i - http://git.io/pC8WnA
09:37:29  <indutny>I guess it is the fastest way to trigger CI :)
09:37:59  <saghul>you can open a PR and trigger a build with parameters, but that's 2 more steps :-P
09:41:25  <indutny>haha
09:41:27  <indutny>yes
09:41:33  <indutny>well, I just pushed out bud with that update
09:41:41  <indutny>and it was building just fine
09:41:47  <indutny>also I have double-checked all changes manually
09:44:11  <mmalecki>hey, this builds on ARM! \o/
09:44:55  <mmalecki>or wait, that was 0.10 that was broken
09:45:37  <mmalecki>indutny: are you planning to backport v1.0.1i?
09:45:49  <indutny>haha
09:45:52  <indutny>to v0.10?
09:45:52  <indutny>yes
09:54:22  * stagasjoined
10:07:53  * euoia_joined
10:11:48  <indutny>saghul: gosh, template argument
10:12:00  <indutny>saghul: could you please do a libuv v0.11 release?
10:12:06  <indutny>with that `template` argument fix?
10:12:27  <saghul>I've never done one, but let me do it as practice for 0.12 :-)
10:14:17  <saghul>indutny: "node release.js should do, right"?
10:14:21  <indutny>aaah
10:14:26  <indutny>yes, it'll do it
10:14:36  <saghul>ok, lets see
10:14:50  <indutny>please check that libuv.org has your public key
10:15:19  <saghul>indutny: yes, it does
10:15:23  <indutny>ok, great
10:15:26  <indutny>then you are good to go
10:15:29  <saghul>hum: no tag with patch level 0 found
10:15:29  <saghul>?
10:16:01  <saghul>indutny: I did node release.js --dir ../libuv
10:16:19  <indutny>try absolute path
10:16:22  <indutny>may be it will work
10:16:50  <saghul>do we need to raise the version manually?
10:17:16  <saghul>because: Tag for patch level 27 already exists
10:18:35  <saghul>ah, version was not properly bumped
10:18:43  <saghul>on the previous release
10:24:25  <MI6>joyent/libuv: saghul created tag v0.11.28 - http://git.io/kbTxMA
10:24:27  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * a9a4872 : Now working on v0.11.29 (+2 more commits) - http://git.io/Fb7w2A
10:26:04  <saghul>indutny: ^^
10:29:54  * seishunjoined
10:30:54  * c4milojoined
10:35:50  * c4miloquit (Ping timeout: 255 seconds)
10:47:42  * petka_joined
10:52:07  * a_lejoined
10:54:13  <indutny>thanks!
10:56:17  * piscisaureusjoined
10:56:25  * a_lequit (Ping timeout: 244 seconds)
11:10:15  <MI6>joyent/node: Saúl Ibarra Corretgé master * 28eee0a : src: handle UV_EAGAIN in TryWrite (+2 more commits) - http://git.io/bH-1Aw
11:10:32  <indutny>yay
11:10:33  <indutny>all good
11:13:18  * euoia_quit (Ping timeout: 260 seconds)
11:15:29  <saghul>\o/
11:23:06  * Soarezchanged nick to Soarez|afk
11:23:34  * Alex7Komjoined
11:26:50  * c4milojoined
11:31:07  * c4miloquit (Ping timeout: 245 seconds)
11:36:01  * kazuponquit (Remote host closed the connection)
11:36:28  * kazuponjoined
11:41:00  * kazuponquit (Ping timeout: 250 seconds)
11:56:37  * c4milojoined
12:14:53  * Soarez|afkchanged nick to Soarez
12:18:36  * stagasquit (Ping timeout: 250 seconds)
13:04:28  * Alex7Komquit (Read error: Connection reset by peer)
13:04:58  * Alex7Komjoined
13:07:39  * guybrushquit (Excess Flood)
13:08:18  * guybrushjoined
13:09:20  <indutny>saghul: :D
13:25:45  * nickleeflyjoined
13:31:06  * mitsuhiko_changed nick to mitsuhiko
13:31:06  * mitsuhikoquit (Changing host)
13:31:06  * mitsuhikojoined
13:31:20  * piscisaureusquit (Ping timeout: 272 seconds)
13:40:47  * kazuponjoined
13:47:01  * c4miloquit (Remote host closed the connection)
13:47:33  * c4milojoined
13:52:02  * c4miloquit (Ping timeout: 255 seconds)
13:56:05  * a_lejoined
14:00:32  * a_lequit (Ping timeout: 250 seconds)
14:02:20  * wolfeidaujoined
14:18:54  * piscisaureusjoined
14:19:10  * dignifiedquirequit (Quit: dignifiedquire)
14:30:50  * stagasjoined
14:31:27  * rmgjoined
14:31:30  * sinclair|workquit (Read error: Connection reset by peer)
14:36:09  * rmgquit (Ping timeout: 260 seconds)
14:39:53  * dignifiedquirejoined
14:40:50  * dignifiedquirequit (Client Quit)
14:53:55  * c4milojoined
15:00:10  * dignifiedquirejoined
15:09:08  <AlexisMocha>@indutny: thanks for recommitting the cluster fix!
15:24:59  <piscisaureus>Hello libuv
15:31:47  * dignifiedquirequit (Quit: dignifiedquire)
15:35:24  <indutny>AlexisMocha: thank *you*!
15:39:46  * nickleeflyquit (Quit: Connection closed for inactivity)
15:40:49  * c4miloquit (Remote host closed the connection)
15:41:25  * c4milojoined
15:45:26  * rmgjoined
15:46:25  * c4miloquit (Ping timeout: 272 seconds)
15:47:25  * rphillips_changed nick to rphillips
15:48:01  * kazuponquit (Remote host closed the connection)
15:48:30  * kazuponjoined
15:48:35  * AvianFluquit (Ping timeout: 264 seconds)
15:48:41  * a_lejoined
15:52:59  * kazuponquit (Ping timeout: 244 seconds)
15:55:08  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:56:38  * bradleymeckjoined
16:01:33  <roxlu>indutny: sorry, saw your reply very late, after I fixed the issue... I was having issues with an ICE implementation and found out the issue wasn't related to ssl
16:01:41  <indutny>ah
16:01:41  <indutny>ok
16:01:42  <indutny>kewl!
16:02:27  <chrisdickinson>morning!
16:04:08  <indutny>morn
16:04:10  * AlexisMocha_joined
16:04:11  * AlexisMochaquit (Ping timeout: 264 seconds)
16:04:31  <roxlu>indutny: do you have experience with DTLS? (or key extraction)
16:04:43  <indutny>key extraction?
16:04:48  <indutny>no experience with DTLS, sorry
16:05:52  <roxlu>np, I've created this example https://gist.github.com/roxlu/f72e5fbe5badcf9daa4b not 100% sure if its correct ^.^
16:07:44  * octetcloudjoined
16:11:33  * jgijoined
16:11:41  <indutny>ah
16:12:46  <indutny>I have no idea what's happening there
16:12:48  <indutny>sorry
16:13:53  <roxlu>hehe np :) I'm writing the server part for WebRTC so I can receive video/audio from the browser in my app
16:16:29  * dignifiedquirejoined
16:20:42  * jgiquit (Quit: jgi)
16:22:01  * jgijoined
16:25:35  <tjfontaine>indutny: have you seen this before? http://jenkins.nodejs.org/job/nodejs-msi/DESTCPU=x64,label=windows-jpc/428/console
16:25:53  <indutny>omg
16:25:55  <indutny>it is in russian
16:26:06  <indutny>hm...
16:26:08  <indutny>haven't seen it before
16:26:17  * mikealquit (Quit: Leaving.)
16:26:20  * dap_joined
16:26:31  <indutny>which branch is it?
16:26:41  <tjfontaine>it's what I'm seeing when trying to do an msi build on windows for master
16:26:49  <tjfontaine>wanted to get a nightly build for people to test with
16:26:51  <indutny>master
16:28:43  * kazuponjoined
16:30:53  * avalanche123joined
16:32:20  * dignifiedquirequit (Quit: dignifiedquire)
16:33:44  * kazuponquit (Ping timeout: 272 seconds)
16:35:57  * AlexisMocha_quit (Read error: Connection reset by peer)
16:36:20  * AlexisMochajoined
16:37:01  * mikealjoined
16:38:12  * rmgquit (Remote host closed the connection)
16:38:39  * c4milojoined
16:39:39  * mikealquit (Client Quit)
16:39:50  * dignifiedquirejoined
16:42:20  <tjfontaine>ok, kicking off another nightly build for the master branch so we can get some folks to help test on tip of that
16:44:13  * nickleeflyjoined
16:45:04  <mmalecki>hello!
16:45:18  <tjfontaine>ohi mmalecki
16:45:28  <mmalecki>tjfontaine: getting to making that error issue now, passed out yesterday
16:45:43  <tjfontaine>mmalecki: understandable, there may be others you want toa ttach it to?
16:46:06  <mmalecki>tjfontaine: yeah, I'll look into it
16:46:26  <tjfontaine>there are a few "improve error" tickets
16:50:38  * rmgjoined
16:50:43  * TooTallNatejoined
16:51:08  * Ralithjoined
16:51:30  * inolenjoined
16:53:20  * dignifiedquirequit (Quit: dignifiedquire)
16:56:22  * petka_quit (Quit: Connection closed for inactivity)
16:59:46  * kellabytejoined
17:00:17  * piscisaureusjoined
17:05:48  * a_lequit
17:06:22  * mikealjoined
17:09:51  * rosskjoined
17:11:22  * a_lejoined
17:11:39  * dignifiedquirejoined
17:12:09  <tjfontaine>http://nodejs.org/dist/nightlies/sprint/v0.11.14/
17:13:22  <tjfontaine>though windows still doesn't build in that environment, and I'm not sure what's changed there
17:19:00  <tjfontaine>indutny: do you have ideas on that windows build?
17:23:53  <tjfontaine>or AlexisMocha
17:23:55  * stagasquit (Ping timeout: 244 seconds)
17:32:19  * bradleymeckquit (Quit: bradleymeck)
17:33:26  * mikealquit (Quit: Leaving.)
17:34:50  * seldojoined
17:35:34  * brsonjoined
17:37:39  * dignifiedquirequit (Quit: dignifiedquire)
17:40:47  * dignifiedquirejoined
17:45:20  * dignifiedquirequit (Client Quit)
17:53:00  * avalanch_joined
17:53:01  * avalanche123quit (Read error: Connection reset by peer)
17:53:53  <MI6>joyent/node: Timothy J Fontaine merge-review * afcc4be : Revert "net: don't prefer IPv4 addresses during resolution" (+2 more commits) - http://git.io/LbJeyw
17:55:10  * Soarezchanged nick to Soarez|afk
17:59:22  <MI6>joyent/node: Kevin Simper v0.10 * 70cc996 : doc: clarify factory methods for net.Socket (+2 more commits) - http://git.io/v99z_w
17:59:48  * piscisaureusquit (Ping timeout: 246 seconds)
18:02:19  * avalanch_quit (Remote host closed the connection)
18:02:47  * avalanche123joined
18:03:31  * AvianFlujoined
18:05:15  * sh1mmerjoined
18:07:04  * brsonquit (Quit: leaving)
18:07:08  * avalanche123quit (Ping timeout: 240 seconds)
18:07:12  * brsonjoined
18:08:37  * a_lequit (Remote host closed the connection)
18:09:15  * a_lejoined
18:18:03  * jgiquit (Quit: jgi)
18:20:10  * avalanche123joined
18:31:50  * bradleymeckjoined
18:32:37  <mmalecki>tjfontaine: while looking for other error issues, I found a bunch of outdated, okay to close issues
18:32:45  <tjfontaine>ok hit me
18:32:48  <mmalecki>tjfontaine: should I make a gist of them?
18:32:53  <tjfontaine>yes please
18:32:59  <tjfontaine>mmalecki: or comment on them
18:33:10  <tjfontaine>mmalecki: actually comment on them, and reference when they were fixed perhaps?
18:34:33  <tjfontaine>AlexisMocha, indutny, trevnorr1s: https://github.com/joyent/node/compare/master...merge-review this reverts the api change for net.connect, since it's not yet ready and causes too much instability, ok with this?
18:35:17  * rendarquit (Ping timeout: 245 seconds)
18:35:31  * jgijoined
18:35:39  <octetcloud>I'm investigating what may be a dgram with cluster on Windows bug, causing supervisor to error out with `Error: write ENOTSUP - cannot write to IPC channel.`
18:36:04  <trevnorr1s>tjfontaine: you mean the change in lib/net.js?
18:36:09  <tjfontaine>trevnorr1s: yes
18:36:15  * trevnorr1schanged nick to trevnorris
18:36:22  <octetcloud>I have vague memories that there might be some windows specific caveats with dgram and cluster, does anybody know about this?
18:36:41  <tjfontaine>octetcloud: in so far as you can't pass udp sockets, I thought that's what the comment was
18:36:43  * mikealjoined
18:36:54  <trevnorris>tjfontaine: that's a change I merged in, then merged a fix for. what are the instabilities you're seeing?
18:37:11  <tjfontaine>octetcloud: though in practice dgram sockets are meant to not need anything special to be shared (unless we do the reuseaddr stuff)
18:37:30  <octetcloud>@tjfontaine: udp sockets cannot be sent to workers via IPC?
18:37:48  <tjfontaine>trevnorris: yes, AlexisMocha pointed out it's a breaking change, and then that your fix broke backwards compatibility
18:38:06  <tjfontaine>trevnorris: alexis is concerned that since we're trying to get 0.12 out, we shouldn't be changing apis this late
18:38:26  <trevnorris>tjfontaine: what's the API change? and is it windows only?
18:38:34  <trevnorris>just wondering why it wasn't covered by the tests.
18:39:32  <tjfontaine>the api change is an api addition, what happened was that your follow up fix dropped the ability to pass an integer family to connect
18:40:14  <tjfontaine>trevnorris: AlexisMocha commented on the relevant commits
18:40:46  <octetcloud>@tjfontaine: if udp sockets can't be passed over IPC, then since ALL uses of the dgram library in a cluster worker cause the socket to be bound, causing a queryServer to be sent to the master, causing the master to asert and die: https://gist.github.com/sam-github/15b261e71d7833564cd7
18:42:03  * rendarjoined
18:43:15  <tjfontaine>octetcloud: sorry I'm still consuming my coffee, hit me again
18:45:33  <octetcloud>node's cluster requires all dgram sockets to be allocated by cluster master, and passed using IPC to the worker
18:45:57  <octetcloud>if udp can't be passed via IPC on windows, then the cluster module can't be used at all. i'm in process of writing a confirmation, but this is pretty bad
18:46:02  <trevnorris>AlexisMocha: that was my bad: https://github.com/joyent/node/commit/e643fe4c4b79f2683914c6435f7166fc6be9f1a7#commitcomment-7308284
18:46:23  <tjfontaine>octetcloud: no I would assume looking at the code it should work, my assumption was on another part
18:46:27  * yunongjoined
18:46:29  <mmalecki>tjfontaine: sure, I'll comment and mention you
18:46:46  <trevnorris>tjfontaine: check the above link. that logic shouldn't have been removed.
18:47:02  <trevnorris>my mistake. if added, then that shouldn't break backwards compatibility.
18:47:30  <tjfontaine>trevnorris: right, but the question we should address is what our tolerance is currently for adding new api
18:47:43  <tjfontaine>trevnorris: if we're trying to get 0.12 out that is
18:48:32  <trevnorris>tjfontaine: except for my screw up, the API seemed only slightly additive, and contained plenty of tests. so I figured it on the minor side, and nothing problematic.
18:49:38  <trevnorris>tjfontaine: i'm more worried about getting the new icu build support in, and finishing up my asyncwrap patch (should have it by friday)
18:49:41  <tjfontaine>trevnorris: sure, I tend to agree, but ideally as a team we make sure everyones concerns about the changes we've integrated are addressed
18:50:14  <trevnorris>tjfontaine: totally, and the main issue seemed more to be w/ my screw up and breaking backwards compatibility.
18:50:33  <octetcloud>@tjfontaine: doesn't work: https://github.com/joyent/node/issues/5587
18:51:04  <tjfontaine>octetcloud: right ok
18:51:45  <tjfontaine>octetcloud: we should probably throw sooner with a clearer message I think
18:52:25  <tjfontaine>octetcloud: doesn't seem like we'll be able to fix that any time soon
18:52:52  <tjfontaine>that should probably land on 0.10 and master
18:53:28  <tjfontaine>trevnorris: lets see if we can get indutny, AlexisMocha, and TooTallNate to chime in with their thoughts
18:53:50  * trevnorriscalls all committers
18:54:20  * trevnorrisget's back to work on AsyncWrap while waiting for a response
18:54:22  <mmalecki>doc changes applicable to both 0.10 and 0.12 belong to 0.10 branch?
18:54:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:54:29  <tjfontaine>mmalecki: yes please
18:55:45  <trevnorris>tjfontaine: for AsyncWrap, just removing the JS is easy enough. but you also want me to remove stuff like the PROVIDER types from the AsyncWrap class?
18:56:52  <tjfontaine>trevnorris: just looking at how I had prototyped it before
18:56:53  <octetcloud>@tjfontaine: note that unlike tcp, where client sockets don't involve the master, ALL dgram socket usage currently goes through master, even though it doesn't have to. I think there are two bugs here, I'll see if I can get time to fix them. One is unprotected by try-catch use of send() in cluster master, the other is that when a worker calls dgram.send(), it involves the cluster master at all: see
18:56:56  <octetcloud>https://github.com/joyent/node/pull/8027#issuecomment-51358854
18:57:51  <tjfontaine>trevnorris: looks like I kept all the cc hte same and added an AL module that could be used for initialization https://github.com/tjfontaine/node/commit/91a934fc1429f4029d80377fa48681019c7cf068
18:58:08  <trevnorris>ok
18:58:54  <tjfontaine>octetcloud: ya, I had read that comment, we should try and make this work as sanely as we can for now, but the automagic nature of cluster's behavior is continuing to bite us and there should be a conversation about what it means to change that
18:59:24  <txdv>saghul: how is that cygwin alternative called
18:59:29  <tjfontaine>msys
18:59:56  <tjfontaine>sometimes coupled with mingw, mingw is the compiler, msys is the shell iirc
19:00:03  <txdv>ja thank thanks
19:01:39  * Alex7Komquit
19:01:44  <txdv>the colros of putty and msys burn my eyes
19:01:51  <txdv>why did they have to take terminal emulation so literally
19:03:16  <txdv>wow
19:03:33  <txdv>it is actually the bright screen which burns my eyes
19:03:42  * sh1mmerquit (Ping timeout: 260 seconds)
19:03:44  <txdv>f.lux and redshifht for the win
19:05:58  * sh1mmerjoined
19:08:14  <indutny>heya
19:08:15  <indutny>sup?
19:08:16  <indutny>tjfontaine: ^
19:09:38  <tjfontaine>indutny: there's a concern with one of our recent changes, which is that we're too late in the window to change api, even if it's purely additive, and I want to make sure we're all on the same page about it, in particular alexis is concerned about the net.connect change that brings in the options object
19:09:54  <indutny>oh
19:09:56  <indutny>I see
19:10:42  <tjfontaine>trevor ultimately can fix the part that introduced backwards compatibility problems, but the question is if it's too controversial right now to keep for 0.12
19:10:52  <indutny>I don't remember the change itself
19:10:53  <tjfontaine>and then what's our line for these changes as we work to get 0.12 out
19:10:56  <indutny>where is it?
19:11:28  <tjfontaine>indutny: original is 4306786
19:11:39  <indutny>aaah
19:11:41  <indutny>ipv6 thing
19:11:41  <tjfontaine>with a follow up fix at e643fe4
19:11:43  <tjfontaine>yes
19:11:46  <tjfontaine>well
19:11:49  <indutny>if we won't do it in v0.12
19:11:52  <tjfontaine>don't explicitly set ipv4
19:11:53  <indutny>we probably won't do it in v0.14 :)
19:12:08  <tjfontaine>no alexis is concerned that it's just too late to add for 0.12
19:12:10  * mikealquit (Quit: Leaving.)
19:12:11  <tjfontaine>not that the change is wrong
19:12:11  <indutny>this is something that I was trying to advocate for a long time
19:12:21  <indutny>tjfontaine: why?
19:12:29  <indutny>tjfontaine: we haven't released v0.12 RC
19:12:39  <indutny>anyway
19:12:44  <indutny>it is hard to tell without API diff
19:12:45  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:12:46  <indutny>you know
19:12:51  <indutny>something that we did for v0.8 -> v0.10
19:13:07  <tjfontaine>you mean the wiki api changelog?
19:13:13  <txdv>'dont explicitly set ipv5'?
19:13:15  <indutny>yes
19:13:29  <txdv>ipv6 is a thing i tried to get into libuv one year ago and it was ignored
19:13:34  <tjfontaine>indutny: https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12 some of that
19:13:56  <indutny>it contains only buffer changes :P
19:14:06  <indutny>and some stream changes
19:14:10  <tjfontaine>it's because trevor did it :)
19:14:15  <tjfontaine>everyone who changed something could add to it :)
19:14:16  <indutny>I guess net.connect should give us drastic problems
19:14:18  <indutny>hahaha
19:14:31  <indutny>we have lots of features
19:14:36  <indutny>some breaking TLS changes
19:14:42  <indutny>well
19:14:46  <indutny>probably not that much, but anyway
19:14:50  <tjfontaine>we have hte legacy stuff
19:14:56  <indutny>tons of v8 addons problems
19:14:58  <txdv>hte?
19:15:02  <tjfontaine>*the
19:15:15  <indutny>hell tons of eternal
19:15:18  <indutny>hte
19:15:19  <txdv>you said it a second time i thought it was short term for something
19:15:44  <tjfontaine>indutny: so, the question at hand is, as we're working for 0.12 right now what tolerance level do we have for integrating things that change external api
19:15:46  * sh1mmerjoined
19:16:24  <indutny>this depends only on amount of breaking changes
19:16:28  <indutny>we should break
19:16:31  <indutny>stuff
19:16:34  <MI6>joyent/node: Jackson Tian v0.10 * cc08106 : fs: fix fs.readFileSync fd leak when get RangeError - http://git.io/rX1oKQ
19:16:34  <indutny>but not that much
19:17:00  <txdv>when is node 0.12 due?
19:17:21  * sh1mmerquit (Client Quit)
19:17:23  <tjfontaine>foss doesn't have due dates, but we're working on that currently
19:17:47  <tjfontaine>jenkins -- I fucking hate you, learn to reconnect your slaves.
19:18:00  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:19:46  * nickleeflyquit (Quit: Connection closed for inactivity)
19:20:31  <MI6>joyent/node: Maciej Małecki v0.10 * d6b4766 : doc: document arguments for 'error' event on a stream - http://git.io/4U6J6g
19:22:31  <tjfontaine>if we do another of these sprints on saturday will others join?
19:24:20  * sh1mmerjoined
19:25:28  <indutny>I'm fine with it
19:26:01  * saghul_joined
19:26:16  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 02e1ebd : include: remove unneeded EADDRINFO errno - http://git.io/qxu2bw
19:26:25  * dignifiedquirejoined
19:29:20  * octetcloudquit (Ping timeout: 250 seconds)
19:30:37  <AlexisMocha>tjfontaine, indutny, trevnorris, TooTallNate: I was raising a concern about the process in general. If we want to get a stable release out, at some point we need to postpone changes that have too high a chance of having a tail of new bugs. On some projects I've worked before, at a certain point you don't allow any more API changes. Then you don't allow any more design changes. Then you only take high-priority bugs. Maybe there is
19:30:38  <AlexisMocha>another strategy in place here and I am not aware of :) How is 0.11 supposed to turn into 0.12, and so to go from "free churn" to "stable"?
19:31:00  <indutny>well
19:31:05  <indutny>we should get out of blockers
19:31:06  <indutny>:)
19:31:13  <indutny>and just do a release
19:31:20  <indutny>the bug fixes are fine in consequent v0.12 releases
19:31:30  <indutny>as we will do a RC first anyway
19:31:35  <tjfontaine>depends on how egregious that bug is
19:31:41  <indutny>well, yeah
19:31:51  <indutny>but minor bugs are usually just fine
19:31:51  <tjfontaine>if the bug comes from something we landed the day before doing the rc
19:32:03  <indutny>AlexisMocha: we have no rules, in general
19:32:03  <indutny>:D
19:32:08  <AlexisMocha>I see :)
19:32:24  <AlexisMocha>ok, so we could call it 0.12 anyday, and it won't be stable from day 1 ever
19:32:27  <tjfontaine>I think AlexisMocha is advocating it's time to do feature freeze, so the only thing that can happen from now are removals and not additions
19:32:40  <tjfontaine>along with bug fixes
19:32:47  <tjfontaine>and performance enhancements
19:32:50  <indutny>ok
19:32:53  <indutny>so here is a problem
19:33:00  <indutny>to do a feature freeze
19:33:02  <indutny>we need to branch
19:33:08  <indutny>and if we branch
19:33:26  <indutny>we will need to backport stuff to 3 branches after that
19:33:31  <indutny>v0.12, v0.10, v0.8
19:33:34  <indutny>instead of 2
19:34:07  <tjfontaine>but those changes shouldn't be too hard, I think we can manage that part, and eventually 0.10 will quickly fall into maint once we release 0.12
19:34:14  <tjfontaine>but
19:34:26  <tjfontaine>branching 0.12 isn't license to start landing things that break master either
19:36:11  * txdvquit (Read error: Connection reset by peer)
19:36:21  * txdvjoined
19:36:24  <AlexisMocha>well at some point we'll need a branch to start stabilizing
19:37:23  <tjfontaine>yes, I would advocate we branch 0.12
19:37:25  <AlexisMocha>since we have been talking about 0.12 for 9 months now, we should probably have a branch already
19:37:32  <tjfontaine>AlexisMocha, indutny, trevnorris?
19:37:45  <indutny>+1
19:37:59  * mikealjoined
19:38:04  <AlexisMocha>and start raising the bar for changes there
19:38:21  <tjfontaine>yes that's not a license to start landing things of any less quality in master or 0.12
19:38:46  <indutny>tjfontaine: btw, is your AL-removal PR ready?
19:38:50  <indutny>what are waiting for right now?
19:38:54  <txdv>O that will be candy, breaking changes in a not statically enforced type system
19:39:06  <tjfontaine>indutny: trevor wants to do that himself, so I am deferring to him since it's his code
19:39:32  <indutny>ooook
19:39:39  <indutny>trevnorris: ?? :)
19:39:55  <tjfontaine>so, branching 0.12 I would leave our version number 0.11 for now, but change master to 0.13
19:40:52  <AlexisMocha>sounds good to me
19:41:05  * a_lequit
19:41:18  <indutny>yay!
19:43:10  <MI6>joyent/node: tjfontaine created branch v0.12 - http://git.io/WGAeOg
19:43:24  <tjfontaine>ok, branch created, I will now update master to be 0.13
19:44:02  * a_lejoined
19:44:17  * mikealquit (Quit: Leaving.)
19:44:37  <AlexisMocha>so is AL the last API change left?
19:45:02  <tjfontaine>the removal of the public api for al
19:45:22  <MI6>joyent/node: Timothy J Fontaine master * 92598e8 : node: Now working on v0.13.0 - http://git.io/OocTkQ
19:49:07  <AlexisMocha>cool! so how do we triage what goes in 0.12 and what doesn't make the bar? I think we could use a little bit of more rigorous process...
19:49:16  <AlexisMocha>Happy to chat about it more later
19:49:21  <AlexisMocha>now dinner time :)
19:49:59  <AlexisMocha>btw, branching needs to happen for libuv as well
19:50:26  <tjfontaine>indutny, saghul_: do you guys want to do that branch?
19:50:46  <indutny>it won't be just branch then
19:50:55  <indutny>it will be a release
19:51:00  <saghul_>we'll do a release
19:51:01  <indutny>saghul_: are you ready for it?
19:51:02  <saghul_>exactly
19:51:05  <saghul_>almost
19:51:08  <saghul_>3 PRs to go
19:51:25  <indutny>great
19:51:29  <saghul_>I know there are failing tests, but nothing fatal it's mostly failures on the tests themselves
19:51:45  <saghul_>I think we should be able to release next week
19:51:50  <AlexisMocha>but then if we need a new fix in libuv, what will we do? an entire libuv update? there seems to be quite a lot of churn in libuv too
19:52:19  <saghul_>libuv was updated today, so there won't be a lot to update
19:53:04  <AlexisMocha>yes, but many bug fixes in node require a fix in libuv. I don't see that percentage going down
19:53:41  <saghul_>can you point to specific issues? I haven't seen a fix coming in that direction for a while now
19:53:54  <saghul_>also, fixes that don't need API changes are ok
19:53:56  <tjfontaine>AlexisMocha: we always do a libuv release before we update libuv in node, but normally patch releases
19:53:56  <AlexisMocha>we'll need to make fixes in node that require a libuv update, and if libuv is churning at full speed, it will reduce the stability of node
19:54:19  * a_lequit
19:54:37  <tjfontaine>jenkins 0.12 jobs are there for node
19:54:47  <AlexisMocha>I saw that DNS is somewhat broken on windows
19:55:11  <AlexisMocha>and at first glance it appeared due to a refactoring that happened with the thread pool changes
19:55:13  <tjfontaine>AlexisMocha: does that require an api change to fix, or is it implementation specific?
19:55:27  <AlexisMocha>no, it's just a bug fix
19:55:34  <tjfontaine>ok
19:55:56  <AlexisMocha>but the regression happened because of a design change, which may not have met the bar of a stabilizing branch
19:56:32  <AlexisMocha>so now to keep accepting high priority bug fixes from libuv, we need to bring in all the changes from master?
19:57:17  <tjfontaine>you mean until libuv branches to 0.11?
19:57:20  <tjfontaine>er 0.12
19:58:25  <AlexisMocha>yes, i mean lib uv should branch also, and node 0.12 should to libuv updates from libuv 0.12
19:59:19  <saghul_>AlexisMochathat's the plan, we are just releasing earlier this time because, well, the line needs to be drawn somewhere
19:59:21  <tjfontaine>well presuming that libuv is not integrating any more api changes, saghul_ can you describe what the last 3 PRs you want to land do?
19:59:41  <saghul_>1) 2 new api functions to modify send and recv buffers
20:00:02  <saghul_>2) return errors in some places we currently assert
20:00:25  <saghul_>3) a fix for a weird case with pipes on windows
20:01:01  <saghul_>generally the threadpool change only brought benefits, the tests on libuv pass nicely, I (hope) there are no big fixes to be done there
20:01:08  <saghul_>(famous last words)
20:01:28  * a_lejoined
20:01:39  <tjfontaine>saghul_: and is there any particular reason you can't branch off 0.12 now as well?
20:05:07  <saghul_>tjfontaine I'd rather land API changes first :-)
20:05:21  * a_lequit (Client Quit)
20:05:46  <tjfontaine>ok, I'm going to grab some food and brb
20:05:55  <AlexisMocha>makes sense to me to branch after api changes
20:06:13  * jgiquit (Quit: jgi)
20:07:02  * a_lejoined
20:12:10  <saghul_>I'll let you folks know once they land
20:12:40  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:15:09  <txdv>saghul: one can only specify the buffer size for named piped servers on windows on creation
20:15:35  <txdv>the pipes which connect to the server, you can't specify the size for them
20:15:44  <txdv>so a getter seems unlikely to return anything
20:16:45  <txdv>windows is weird
20:16:47  <trevnorris>back
20:18:42  <trevnorris>tjfontaine: there's more I need to add to the v0.10-v0.12 changes, but there's a lot more that I'm probably not even aware of.
20:18:42  <trevnorris>should we have that done before v0.12 is released?
20:19:26  <trevnorris>for the docs we might just put, "for any native modules, migrate to nan"
20:21:15  <trevnorris>indutny: i'm working on removing AL now. removing the JS is easy, but there are some small things in the C++ that should also be cleaned up.
20:22:01  <trevnorris>tjfontaine, indutny, AlexisMocha: Are we going to land the icu build feature? there are bigger players (e.g. yahoo) that really want that in for v0.12.
20:24:47  * a_lequit (Remote host closed the connection)
20:27:57  * seldoquit (Remote host closed the connection)
20:28:34  * a_lejoined
20:28:35  <trevnorris>tjfontaine: so remove all possible hooks into C++? or just all the propagation logic I put into place?
20:30:01  <trevnorris>or can I leave process._setupAsyncListener() (maybe put it under a different name or something)
20:33:00  * a_lequit (Ping timeout: 255 seconds)
20:33:41  * a_lejoined
20:34:33  * avalanche123quit (Ping timeout: 240 seconds)
20:35:23  * jgijoined
20:37:39  * janjongboomjoined
20:37:47  * octetcloudjoined
20:37:49  * jgiquit (Client Quit)
20:40:51  * Soarez|afkchanged nick to Soarez
20:41:48  * janjongboomquit (Ping timeout: 250 seconds)
20:49:19  * TooTallNatejoined
20:49:21  * janjongboomjoined
20:51:10  * jgijoined
20:52:05  * janjongboomquit (Client Quit)
20:54:41  * bradleymeckquit (Quit: bradleymeck)
20:56:22  * qard-appnetajoined
20:56:38  * qardjoined
20:56:49  * qardquit (Client Quit)
21:03:49  * mikealjoined
21:08:38  * bradleymeckjoined
21:12:52  * avalanche123joined
21:28:28  * c4miloquit (Remote host closed the connection)
21:29:02  * c4milojoined
21:33:16  * c4miloquit (Ping timeout: 250 seconds)
21:46:12  * nickleeflyjoined
21:51:22  <trevnorris>tjfontaine: i'm also making one of the same changes you had. that is to remove MakeDomainCallback.
21:51:38  <trevnorris>cleaned up the logic a lot, and found at least one inconsistency between the implementations.
21:53:12  <chrisdickinson>based on a request from rockbot and maxogden, took a stab at putting together an error section for the api docs: http://neversaw.us/nodejs-api/errors.html
21:55:04  <trevnorris>chrisdickinson: nice work.
21:55:54  <trevnorris>chrisdickinson: one thing I might request be worded _very_ explicitly is that "throwing a _value_ (e.g. anything) is called an exception"
21:56:19  <trevnorris>like, a user can: throw 42; and that's an exception.
21:56:59  <trevnorris>the {Syntax,Range,Type,*}Error are just JS objects that automatically generate a stack trace when constructed.
21:57:31  * chrisdickinsonnods
21:57:57  <chrisdickinson>I'll update that!
21:58:01  <trevnorris>but they are not an exception by themselves. I realize this probably seems trivial, but you'd be surprised how many JS devs are confused by the nomenclature.
21:58:25  <chrisdickinson>getting the wording right and keeping it consistent is key
21:59:15  <trevnorris>One thing I like about the error docs is that it'll force us to standardize what types of additional information we attach to errors, what those attributes are, etc.
21:59:17  <trevnorris>nice work.
21:59:22  <chrisdickinson>thanks!
21:59:28  <chrisdickinson>& thanks for taking a look
21:59:33  <trevnorris>np
21:59:58  <chrisdickinson>is there anything that would prevent backporting this to v0.10 as well?
22:00:20  <trevnorris>the basics? probably not.
22:00:28  <chrisdickinson>rad
22:01:04  <trevnorris>here's an example that could help out JS devs:
22:01:04  <trevnorris>"When an operation is not permitted due to language-syntax or language-runtime-level reasons, a JavaScript error is generated [and thrown as a runtime **exception]"
22:01:24  <trevnorris>erm. forgot the ending **
22:01:43  <chrisdickinson>ah, good catch
22:02:21  * rendarquit
22:02:27  <trevnorris>also, might be helpful to link to relevant docs like https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error for specifics.
22:02:55  * mikealquit (Quit: Leaving.)
22:03:03  <trevnorris>I forget who, but someone asked where Node's Error object implementation was. They didn't realize that Errors are built into V8.
22:03:49  * mikealjoined
22:04:11  <mmalecki>tjfontaine: https://github.com/joyent/node/issues/8103
22:04:24  * saghul_joined
22:05:51  <trevnorris>chrisdickinson: also, there's an important change between v0.10 and v0.11. V8 decided that it would no longer lazy load the message into the stack trace.
22:06:57  <trevnorris>> var e = new Error('hi');
22:06:57  <trevnorris>e.message = 'bye';e.stack.split('\n')[0] === 'Error: hi';
22:07:19  <trevnorris>but in v0.10 it's different.
22:08:19  <chrisdickinson>trevnorris: yep, there's a link to that mdn doc
22:08:38  <trevnorris>> var e = new Error('hi');
22:08:39  <trevnorris>> e.message = 'bye';
22:08:39  <trevnorris>> e.stack.split('\n')[0];
22:08:39  <trevnorris>'Error: bye'
22:09:00  <trevnorris>so in v0.11 the message in the stack trace can't be changed after it's been initially set.
22:09:08  <chrisdickinson>ah interesting
22:09:11  <trevnorris>unless you do some serious splicing on the stack itself.
22:09:49  <trevnorris>chrisdickinson: nice on the mdn docs
22:10:01  <chrisdickinson>i pointed at the v8 stack trace api docs, which will hopefully be helpful
22:10:28  <chrisdickinson>(the super-secret-but-maybe-not-so-super-secret "you can inform how v8 renders the stack trace" api)
22:10:39  <trevnorris>heh
22:10:46  * chrisdickinsonbrbs!
22:11:38  <trevnorris>chrisdickinson: also, in v0.11 the stack trace strings are lazily generated. so if a user wants to generate a long stack trace it's faster to store the error object itself, then ask for the .stack when it's needed.
22:13:21  <trevnorris>ah, nm. you already have a note about the lazy loading
22:13:36  * trevnorrisactually start reading the docs before giving feedback. :P
22:14:56  * kazuponjoined
22:15:29  <trevnorris>chrisdickinson: might want to mention the full API of rror.captureStackTrace(error[, constructorOpt]). It is in the link, but might be nice to at least add the full syntax into the header.
22:17:50  <trevnorris>"ReferenceError [...] only V8 may generate and propagate these errors." Not technically true. It's still a global, and users _could_ use it if they wanted (though there's no good reason to do so)
22:18:32  <trevnorris>(unless they're doing something freaking insane like using esprima to parse JS code and detect that crap.
22:23:59  * c4milojoined
22:25:00  * kazuponquit (Remote host closed the connection)
22:25:29  * kazuponjoined
22:25:48  * c4milo_joined
22:26:01  <tjfontaine>ok back
22:26:06  <tjfontaine>reading backlog
22:27:26  <tjfontaine>trevnorris: I think ICU can go in, it doesn't really change the api of node itself, and is more about how we build and distribute node
22:27:32  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:27:37  <trevnorris>coolio
22:27:48  <tjfontaine>trevnorris: also, yes please to be unifying MakeDomainCallback
22:28:00  <trevnorris>already done. :)
22:28:03  <jgi>AlexisMocha: I’m running test/internet/test-dns.js and here’s what I get: https://gist.github.com/misterdjules/eb984bf0728b61cc8f28
22:28:33  <jgi>AlexisMocha: Is it expected? I mean, has it been failing for some time or is there a problem with my windows dev setup?
22:29:06  <tjfontaine>trevnorris: when I was working in that code I was so sad to see how much was duplicated :/
22:29:25  * saghul_joined
22:29:27  * c4miloquit (Ping timeout: 245 seconds)
22:29:29  <jgi>AlexisMocha: seems like jenkins agent has the same issue: http://jenkins.nodejs.org/job/nodejs-master-windows/DESTCPU=x64,label=windows/lastCompletedBuild/tapTestReport/internet.tap-2/
22:29:53  * a_lequit (Remote host closed the connection)
22:30:05  <tjfontaine>chrisdickinson: thanks for doing this work on the error handling, especially on common errors, now we can start (some time) going through and documenting when things emit what kinds of errors and link into the error document
22:30:07  * kazuponquit (Ping timeout: 255 seconds)
22:30:28  * a_lejoined
22:30:44  <trevnorris>tjfontaine: that duplication is cruft left over from before it was made easier to detect whether domains were in use from the C++ side.
22:30:54  <tjfontaine>indeed
22:31:18  <tjfontaine>mmalecki: thanks for the ticket, chrisdickinson can you mention your work/branch on issue #8103?
22:35:03  * mikealquit (Quit: Leaving.)
22:43:10  * dignifiedquirequit (Quit: dignifiedquire)
22:44:28  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:52:53  * Soarezchanged nick to Soarez|afk
22:56:49  * AlexisMochaquit (Read error: Connection reset by peer)
22:57:17  * AlexisMochajoined
22:58:41  * seldojoined
23:01:38  <AlexisMocha>jgi: yes I started investigating today and it's a legitimate issue with DNS on windows. There were at least 2 regressions affecting that test. I am working on it.
23:01:49  <jgi>AlexisMocha: ok
23:03:55  * saghul_joined
23:04:37  <jgi>tjfontaine: actually if you could do a code review for this one, that would be great: https://github.com/joyent/node/issues/8046
23:05:15  <tjfontaine>jgi: you mean 8045 right?
23:05:30  <jgi>tjfontaine: sorry yes
23:05:33  <tjfontaine>k
23:06:20  <tjfontaine>jgi: right ok, I think I may apply this to 0.10 then merge 0.10 into 0.12 and then 0.12 into master ...
23:07:54  <jgi>tjfontaine: yes, awesome!
23:08:56  <tjfontaine>jgi: do we know more discretely what the libuv change was that changed the behavior such that this test fails more regularly?
23:09:26  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:09:37  <jgi>tjfontaine: no, but do they actually fail more regularly?
23:09:49  <jgi>tjfontaine: did they use to work?
23:09:57  <tjfontaine>jgi: dunno, I guess I'm just not used to seeing them fail on 0.10
23:10:13  <tjfontaine>I agree that this test as written is more correct for what it was meant to be testing
23:11:08  <tjfontaine>but I see that it does currently in 0.10
23:11:20  <jgi>tjfontaine: is there a way we could determine when they started to fail more regularly? The fact that they fail inconsistently prevents us to use tools like git bisect. And IIRC Jenkins doesn’t have a “this test fails since” feature right?
23:11:40  <tjfontaine>jgi: no, but that's what we can use manta for
23:11:48  <tjfontaine>but anyway, neither here nor there at the moment
23:11:58  <jgi>tjfontaine: ok, but yeah using manta sounds like a good idea
23:12:24  <MI6>joyent/node: Julien Gilli v0.10 * b0277f3 : tests: fix child-process-fork-dgram on SmartOS. - http://git.io/doRAUQ
23:15:34  * rmgquit (Remote host closed the connection)
23:16:04  * seldoquit (Ping timeout: 250 seconds)
23:16:09  * rmgjoined
23:17:14  * mikealjoined
23:20:25  * rmgquit (Ping timeout: 244 seconds)
23:23:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:26:54  * mikealquit (Quit: Leaving.)
23:27:58  * mikealjoined
23:33:55  <MI6>joyent/node: Timothy J Fontaine v0.12 * a5778cd : Merge remote-tracking branch 'upstream/v0.10' into v0.12 (+19 more commits) - http://git.io/ZNR-9w
23:34:36  <MI6>joyent/node: Timothy J Fontaine master * 912b5e0 : Merge remote-tracking branch 'upstream/v0.12' (+20 more commits) - http://git.io/fpTrqA
23:35:41  * mikealquit (Quit: Leaving.)
23:36:02  * saghul_joined
23:36:36  * mikealjoined
23:37:10  <trevnorris>anyone have the url to the debugger work ben has been working on for 3.27?
23:37:40  <tjfontaine>how's the AW/AL stuff coming?
23:38:51  * mikealquit (Client Quit)
23:39:50  <trevnorris>still working on it.
23:39:53  * saghul_quit (Client Quit)
23:39:55  * mikealjoined
23:40:09  * saghul_joined
23:40:27  <trevnorris>tjfontaine: should I remove the process._setupAsyncListener, or leave it in?
23:41:14  <tjfontaine>trevnorris: that's why I moved it the AL module, so you could process.binding('async_listener')
23:42:01  <tjfontaine>trevnorris: so in short -- yes, anything in js that's related to AL should be gone
23:42:48  <trevnorris>where's your AL repo?
23:43:21  * saghul_quit (Client Quit)
23:43:53  <tjfontaine>the removal of the node bits, or the public module portion?
23:43:54  <tjfontaine>https://github.com/tjfontaine/node/commits/al-external
23:44:00  <tjfontaine>that's the removal of the AL bits
23:44:17  <tjfontaine>https://github.com/joyent/node-tracing is the migration of those bits to the public module
23:45:54  * mikealquit (Quit: Leaving.)
23:53:03  * dshaw_joined
23:54:20  <trevnorris>tjfontaine: there's one bit of JS that wasn't removed: https://github.com/tjfontaine/node/blob/6a74d6c817c5315bff41cd228205e7f3afc30d24/src/async-wrap-inl.h#L99-L102
23:54:38  <trevnorris>that sets a _removeAsyncQueue on the _handle object for all streams.
23:58:36  <tjfontaine>trevnorris: it's on a private member though, it's mostly about it not taking place by default in the public
23:58:58  <trevnorris>coolio.
23:59:45  <tjfontaine>trevnorris: remember the idea was to be able to iterate on the public api in a module