00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:24  * dshaw_joined
00:10:43  * `3rdEdenchanged nick to `3E|ZZ
00:20:10  * paulfryzeljoined
00:24:25  * paulfryzelquit (Ping timeout: 252 seconds)
00:27:35  * daviddiasquit (Read error: Connection reset by peer)
00:31:01  * hueniversequit (Excess Flood)
00:31:14  * hueniversejoined
00:31:43  * mikealquit (Quit: Leaving.)
00:35:08  * thlorenzquit (Remote host closed the connection)
00:35:40  * thlorenzjoined
00:40:23  * thlorenzquit (Ping timeout: 272 seconds)
00:41:37  * inolenjoined
00:48:26  * mikolalysenkoquit (Ping timeout: 252 seconds)
00:49:19  * kazuponjoined
00:51:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:53:43  * mikolalysenkojoined
01:07:07  * abraxasjoined
01:11:16  * abraxasquit (Ping timeout: 246 seconds)
01:14:38  * dshaw_quit (Quit: Leaving.)
01:19:31  <trevnorris>suck a duck.
01:19:36  <trevnorris>othiym23: ping
01:19:46  <trevnorris>groundwater: or you
01:19:48  * rmgquit (Remote host closed the connection)
01:20:20  <trevnorris>tjfontaine: fyi, make test-debug fails w/ some strange stuff in crypto.
01:21:01  * paulfryzeljoined
01:25:17  * paulfryzelquit (Ping timeout: 252 seconds)
01:26:10  * trevnorris_joined
01:26:12  * trevnorris_changed nick to Guest11281
01:26:22  <othiym23>trevnorris: pong
01:27:02  <trevnorris>othiym23: crap. on sec. znc bouncer issues
01:27:03  * trevnorrisquit (Quit: Leaving)
01:35:44  * Guest11281quit (Quit: ZNC - http://znc.in)
01:36:04  * trevnorrisjoined
01:37:34  * trevnorrispart
01:46:27  * rmgjoined
01:57:55  * mcavagequit
02:01:39  * c4milojoined
02:04:00  * thlorenzjoined
02:05:19  * mikolalysenkoquit (Ping timeout: 260 seconds)
02:06:46  * mikolalysenkojoined
02:10:49  * hzquit
02:21:45  * paulfryzeljoined
02:26:09  * paulfryzelquit (Ping timeout: 252 seconds)
02:26:19  * mikealjoined
02:33:18  * mikealquit (Quit: Leaving.)
02:34:17  * mikealjoined
02:42:26  * thlorenzquit (Remote host closed the connection)
03:11:53  * kazuponquit (Remote host closed the connection)
03:13:22  * mikealquit (Quit: Leaving.)
03:14:12  * kazupon_joined
03:22:38  * paulfryzeljoined
03:27:01  * paulfryzelquit (Ping timeout: 252 seconds)
03:29:55  * rmgquit (Remote host closed the connection)
03:32:43  * inolenquit (Quit: Leaving.)
03:36:05  * kazupon_quit (Remote host closed the connection)
03:37:37  * paulfryzeljoined
03:40:22  * mikolalysenkoquit (Ping timeout: 246 seconds)
03:41:23  * mikolalysenkojoined
03:42:03  * paulfryzelquit (Ping timeout: 252 seconds)
03:48:41  * jmar777joined
03:57:40  * mikealjoined
04:00:37  * rmgjoined
04:06:59  * kazuponjoined
04:07:06  * jmar777quit (Remote host closed the connection)
04:09:04  * rmgquit (Ping timeout: 246 seconds)
04:09:55  * trevnorrisjoined
04:10:45  <trevnorris>ok. think I finally got this working.
04:11:51  * kazuponquit (Ping timeout: 260 seconds)
04:13:45  * thlorenzjoined
04:13:52  <octetcloud>indutny: you there?
04:19:31  * mikealquit (Quit: Leaving.)
04:22:35  * thlorenzquit (Ping timeout: 272 seconds)
04:25:19  * mikealjoined
04:29:01  * mikealquit (Client Quit)
04:36:09  * kazuponjoined
04:36:41  * mikealjoined
04:38:21  * paulfryzeljoined
04:40:51  * mikealquit (Client Quit)
04:41:03  * mikealjoined
04:42:55  * paulfryzelquit (Ping timeout: 252 seconds)
04:43:27  * indexzeroquit (Read error: Connection reset by peer)
04:48:36  * mikealquit (Quit: Leaving.)
04:58:19  * inolenjoined
05:07:10  * c4miloquit (Remote host closed the connection)
05:12:14  * dshaw_joined
05:15:32  * dshaw_quit (Client Quit)
05:23:53  * dshaw_joined
05:24:39  * mikolalysenkoquit (Ping timeout: 272 seconds)
05:35:22  * defunctzombiechanged nick to defunctzombie_zz
05:36:23  * brsonjoined
05:39:12  * paulfryzeljoined
05:43:25  * paulfryzelquit (Ping timeout: 252 seconds)
05:43:29  * mikolalysenkojoined
05:51:21  * dshaw_quit (Read error: Connection reset by peer)
05:53:43  * dshaw_joined
06:03:40  * rmgjoined
06:07:31  <trevnorris>great. think my irc is setup back the way it was.
06:08:04  * rmgquit (Ping timeout: 246 seconds)
06:10:39  * mikealjoined
06:11:08  * bajtosjoined
06:18:43  <trevnorris>othiym23: don't suppose you'd happen to still be here?
06:19:02  <othiym23>trevnorris: lol
06:19:07  <othiym23>trevnorris: hacking on my implementation of Domenic's WHATWG Streams spec
06:19:11  <othiym23>took you long enough
06:19:41  <trevnorris>yeah. got delayed. and found an issue in AL.
06:20:09  <trevnorris>right now if you try to add an AL to the same asyncQueue twice it'll just reject it.
06:20:17  <trevnorris>only allow it to be added once.
06:20:59  <trevnorris>but... if the AL is then attached to the instance, and you add the AL again from one step into the stack, it'll then run multiple times.
06:21:20  * AvianFluquit (Remote host closed the connection)
06:21:50  <trevnorris>othiym23: is your al polyfill sort-of up to date?
06:22:17  <othiym23>trevnorris: nope, been waiting for you to get things straightened out with your before updating it
06:22:23  <trevnorris>ok
06:22:29  <othiym23>I have time set aside this week to work on it
06:22:31  * brsonquit (Quit: leaving)
06:22:48  <trevnorris>cool
06:23:27  <trevnorris>othiym23: in your opinion, should a given AL instance be allowed to run more than once within a given execution context?
06:23:44  <trevnorris>imho, it shouldn't
06:23:47  <othiym23>no
06:23:54  <trevnorris>ok. so bug.
06:23:56  * trevnorrisoff to go fix
06:26:07  <trevnorris>othiym23: so if I add an AL and it gets attached to the context, then before that callback runs the previous asyncQueue is pushed up the stack. in that moment I can add the same AL again, but instead it will be on the new asyncQueue.
06:26:18  <trevnorris>not on the ._asyncQueue on the context
06:27:05  <trevnorris>but if i'm only allowing one to run, then I guess I should run the one attached to the context first, then jump any matching AL instances in the asyncQueue
06:27:15  <trevnorris>because then the storage value could be overwritten.
06:27:24  <trevnorris>oy, so abstract.
06:28:22  <othiym23>so there's two consistent ways to apply ALs
06:29:04  <othiym23>one is to do away with uids and allow the same AL to be added as many times as possible, and just be really careful about binding a given run of an AL to a given piece of AL storage
06:29:49  <othiym23>the other is to ensure that a given AL uid is only run once per execution context
06:30:04  <othiym23>you've designed for the latter, so you should stick with that
06:30:15  <othiym23>is there any way to bind the storage to the uid per context?
06:30:26  <othiym23>perhaps with a flag indicating whether it's been run for that context?
06:30:41  <othiym23>efficiently, I mean
06:30:50  <othiym23>there's no question in my mind that it can be done inefficiently
06:31:04  <trevnorris>not sure. let me simply what i've got then we'll revisit that later if necessary.
06:32:21  <othiym23>kk
06:32:37  <othiym23>in this case, I care less about simplicity than consistency
06:32:58  <othiym23>because people are going to have enough trouble understanding how all this works, so this could turn into some kind of subtle footgunsaw
06:33:23  <trevnorris>heh yeah. hence why i'm trying to simply what's going on. so it's easier to make it consistent. :)
06:34:45  <MI6>nodejs-v0.10-windows: #452 UNSTABLE windows-ia32 (7/610) windows-x64 (13/610) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/452/
06:39:53  * paulfryzeljoined
06:40:01  * octetcloudquit (Ping timeout: 272 seconds)
06:44:17  * paulfryzelquit (Ping timeout: 252 seconds)
06:59:58  * indexzerojoined
07:22:54  * `3E|ZZchanged nick to `3E
07:29:25  * m76joined
07:33:51  * mikolalysenkoquit (Ping timeout: 260 seconds)
07:40:46  * paulfryzeljoined
07:45:09  * paulfryzelquit (Ping timeout: 252 seconds)
07:53:05  * rendarjoined
08:05:55  * dshaw_quit (Quit: Leaving.)
08:07:35  * calvinfojoined
08:13:40  * TooTallNatejoined
08:13:53  * TooTallNatequit (Client Quit)
08:21:11  <trevnorris>tjfontaine: have a few things I need to merge for AL regardless of the tracing module, that will require a rebase.
08:21:30  <trevnorris>tjfontaine: almost finished those tonight, but still needs to be refined slightly before merging.
08:21:35  * trevnorris&
08:21:35  <LOUDBOT>AAAAH WHAT IS THIS
08:29:52  * mikolalysenkojoined
08:35:01  * mikolalysenkoquit (Ping timeout: 252 seconds)
08:36:53  * calvinfoquit (Quit: Leaving.)
08:39:15  * calvinfojoined
08:41:31  * paulfryzeljoined
08:45:15  * calvinfoquit (Quit: Leaving.)
08:45:39  * paulfryzelquit (Ping timeout: 252 seconds)
08:58:14  * kazuponquit (Remote host closed the connection)
08:58:42  * kazuponjoined
09:02:44  * dshaw_joined
09:02:59  * kazuponquit (Ping timeout: 260 seconds)
09:10:13  * dshaw_quit (Ping timeout: 272 seconds)
09:20:42  * indexzeroquit (Quit: indexzero)
09:21:11  * indexzerojoined
09:24:14  * janjongboomjoined
09:30:39  * mikolalysenkojoined
09:35:33  * mikolalysenkoquit (Ping timeout: 252 seconds)
09:39:50  * hueniversequit (Quit: Leaving.)
09:40:03  * hueniversejoined
09:41:27  <mmalecki>morning
09:42:10  * paulfryzeljoined
09:46:31  * paulfryzelquit (Ping timeout: 252 seconds)
09:47:49  * janjongboomquit (Ping timeout: 248 seconds)
09:48:45  * janjongboomjoined
10:06:45  * abraxasjoined
10:07:21  * daviddiasjoined
10:08:31  * mikolalysenkojoined
10:09:21  <indutny>morning
10:11:55  * abraxasquit (Ping timeout: 272 seconds)
10:13:25  * mikolalysenkoquit (Ping timeout: 248 seconds)
10:22:57  * daviddiasquit
10:27:55  * bajtosquit (Quit: bajtos)
10:30:01  * hzjoined
10:47:11  <MI6>nodejs-v0.10: #1731 FAILURE osx-x64 (4/610) linux-ia32 (2/610) smartos-x64 (8/610) smartos-ia32 (8/610) linux-x64 (2/610) osx-ia32 (3/610) http://jenkins.nodejs.org/job/nodejs-v0.10/1731/
11:06:55  <MI6>joyent/libuv: Fedor Indutny v0.10 * 8bc29b6 : openbsd: fix obvious bug in uv_cpu_info - http://git.io/Yqk7xw
11:06:56  <indutny>tjfontaine: yt?
11:07:31  <MI6>libuv-v0.10-windows: #14 FAILURE http://jenkins.nodejs.org/job/libuv-v0.10-windows/14/
11:09:13  * mikolalysenkojoined
11:10:31  <MI6>libuv-v0.10: #151 UNSTABLE smartos (3/191) http://jenkins.nodejs.org/job/libuv-v0.10/151/
11:11:08  <MI6>libuv-v0.10-gyp: #119 UNSTABLE smartos-ia32 (2/191) smartos-x64 (4/191) osx-x64 (1/192) linux-x64 (1/191) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/119/
11:14:39  * mikolalysenkoquit (Ping timeout: 260 seconds)
11:29:04  * inolenquit (Read error: Connection reset by peer)
11:29:22  * inolenjoined
11:59:25  * bajtosjoined
12:08:03  * dshaw_joined
12:08:43  * inolenquit (Ping timeout: 260 seconds)
12:09:45  * inolenjoined
12:09:59  * mikolalysenkojoined
12:12:37  * dshaw_quit (Ping timeout: 272 seconds)
12:15:23  * mikolalysenkoquit (Ping timeout: 252 seconds)
12:33:12  * inolenquit (Read error: Connection reset by peer)
12:33:47  * inolenjoined
12:35:44  * c4milojoined
12:44:36  * paulfryzeljoined
12:48:45  * paulfryzelquit (Ping timeout: 252 seconds)
12:55:52  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:10:47  * mikolalysenkojoined
13:12:30  * indexzeroquit (Quit: indexzero)
13:14:40  * kazuponjoined
13:15:55  * mikolalysenkoquit (Ping timeout: 260 seconds)
13:22:23  * indexzerojoined
13:25:56  * janjongboomjoined
13:29:21  * daviddiasjoined
13:45:20  * paulfryzeljoined
13:49:37  * paulfryzelquit (Ping timeout: 252 seconds)
14:02:05  * thlorenzjoined
14:05:51  * kazuponquit (Remote host closed the connection)
14:06:14  * daviddiasquit (Ping timeout: 264 seconds)
14:06:18  * kazuponjoined
14:09:33  * dshaw_joined
14:10:31  * kazuponquit (Ping timeout: 252 seconds)
14:11:30  * mikolalysenkojoined
14:11:32  * daviddiasjoined
14:11:59  * inolenquit (Ping timeout: 252 seconds)
14:13:17  * piscisaureus_joined
14:13:17  * piscisaureus_changed nick to piscisaureus
14:14:12  * inolenjoined
14:14:13  * dshaw_quit (Ping timeout: 272 seconds)
14:16:37  * mikolalysenkoquit (Ping timeout: 248 seconds)
14:21:54  * kazuponjoined
14:22:31  * kazuponquit (Read error: Connection reset by peer)
14:22:46  * kazuponjoined
14:26:15  * janjongboomquit (Ping timeout: 272 seconds)
14:27:27  * daviddiasquit (Remote host closed the connection)
14:27:58  * janjongboomjoined
14:39:07  * m76quit (Read error: Connection reset by peer)
14:42:10  * daviddiasjoined
14:45:54  * paulfryzeljoined
14:46:20  * daviddiasquit (Remote host closed the connection)
14:50:29  * paulfryzelquit (Ping timeout: 252 seconds)
14:51:59  * jmar777joined
14:52:05  * daviddiasjoined
14:52:29  * hzquit (Ping timeout: 272 seconds)
14:54:18  * mikolalysenkojoined
15:04:25  * hzjoined
15:20:31  <MI6>nodejs-master: #868 FAILURE linux-x64 (2/695) osx-x64 (2/695) linux-ia32 (2/695) osx-ia32 (2/695) smartos-x64 (3/695) http://jenkins.nodejs.org/job/nodejs-master/868/
15:25:30  * defunctzombie_zzchanged nick to defunctzombie
15:28:38  * paulfryzeljoined
15:28:58  * AvianFlujoined
15:31:31  * kazuponquit (Remote host closed the connection)
15:35:11  * daviddiasquit (Remote host closed the connection)
15:35:50  * daviddiasjoined
15:38:56  * daviddia_joined
15:40:26  * daviddiasquit (Ping timeout: 264 seconds)
15:50:38  * pachetjoined
15:55:54  * kenperkinsjoined
16:07:38  * hzquit
16:09:47  * abraxasjoined
16:11:15  * dshaw_joined
16:14:27  * abraxasquit (Ping timeout: 272 seconds)
16:16:27  * dshaw_quit (Ping timeout: 272 seconds)
16:19:53  <trevnorris>morning
16:39:30  * m76joined
16:42:25  * kazuponjoined
16:42:26  * rmgjoined
16:45:04  * piscisaureusquit (Ping timeout: 246 seconds)
16:46:18  * bajtosquit (Quit: bajtos)
16:47:02  * kazuponquit (Ping timeout: 264 seconds)
16:53:21  * `3Echanged nick to `3E|DINNER
17:03:13  <tjfontaine>indutny: here
17:03:17  <tjfontaine>trevnorris: morn
17:06:08  * pachet_joined
17:08:19  * c4milo_joined
17:09:05  * c4milo_quit (Excess Flood)
17:09:10  * tellnesquit (Ping timeout: 260 seconds)
17:09:10  * pachetquit (Read error: Connection reset by peer)
17:09:10  * niskaquit (Ping timeout: 260 seconds)
17:09:12  * hij1nxquit (Ping timeout: 260 seconds)
17:09:20  * c4miloquit (Ping timeout: 260 seconds)
17:09:30  <tjfontaine>indutny: thanks for closing the bot issues
17:09:38  * c4milojoined
17:09:39  * niskajoined
17:10:17  * tellnesjoined
17:10:32  * hij1nxjoined
17:14:37  <groundwater>trevnorris ahoy
17:14:58  <trevnorris>hello all
17:15:42  <trevnorris>tjfontaine: have a couple bug fixes I'm about to push. doing my usual cleanup and double checking what not.
17:16:38  <tjfontaine>let me know when you want a review
17:22:48  * calvinfojoined
17:23:01  <trevnorris>tjfontaine: https://github.com/joyent/node/pull/6925
17:24:10  <trevnorris>also, I had a dream last night on a useful implementation detail for checking probes.
17:24:48  <trevnorris>the provider code is almost complete. and after that i'm going to try the probe trick I drempt up
17:24:50  * Benvie_quit (Ping timeout: 252 seconds)
17:25:36  * dap_joined
17:26:42  * janjongboomquit (Ping timeout: 265 seconds)
17:26:48  * mikealquit (Quit: Leaving.)
17:28:23  * dshaw_joined
17:28:31  * janjongboomjoined
17:29:22  * Benviejoined
17:32:43  * piscisaureusjoined
17:33:58  * paulfryzelquit (Read error: Connection reset by peer)
17:34:33  * paulfryzeljoined
17:37:27  <piscisaureus>Hello
17:37:39  <piscisaureus>What do you guys think about nodejx ?
17:38:05  <piscisaureus>(nodejx.com)
17:38:22  <piscisaureus>also, trevnorris, you heard back from aapl yet?
17:40:05  <trevnorris>piscisaureus: yeah. so it's a kernel bug that won't be fixed. it's a complicated matter in how they've layered their bsd posix standard on top of mach.
17:40:31  <mmalecki>piscisaureus: let me phrase it that way
17:40:33  <rendar>piscisaureus, it seems interesting, nodejx i mean
17:40:43  <trevnorris>piscisaureus: so they recommend using their new "dispatch" API: https://developer.apple.com/library/mac/documentation/performance/reference/gcd_libdispatch_ref/Reference/reference.html
17:40:46  <piscisaureus>trevnorris: hmm, sad ...
17:41:09  <mmalecki>piscisaureus: if I was in an elevator with Hitler, author of Nodejx and a gun with one bullet in it, I'd shoot Hitler and teach author of Nodejx how to write benchmarks
17:41:19  <trevnorris>the dispatch api is supported on 10.7+
17:41:29  <trevnorris>but I don't care enough to take the time to do it. :)
17:41:41  <piscisaureus>trevnorris: so we'd have to move away from epoll ?
17:41:47  <piscisaureus>:-/
17:41:50  <tjfontaine>itym kqueue
17:41:52  <piscisaureus>er, kqueu heh
17:41:54  <tjfontaine>and they work together
17:42:00  <tjfontaine>it's just a lot of lift, but doable
17:42:12  <tjfontaine>the question is if there are people on darwin, with FS in their hotpath
17:42:21  <piscisaureus>likely not I guess
17:42:27  <piscisaureus>no servers on os x
17:42:35  <piscisaureus>I was just looking forward to fixing this wart
17:42:53  <piscisaureus>but apparently there's a lot (too much) to it
17:43:02  <tjfontaine>othiym23 said there are some
17:43:12  <trevnorris>my friend did mention there is an implementation detail that if you force open the file with append mode, then it will take a different logic path in the kernel that will do the right thing.
17:43:38  <trevnorris>piscisaureus: but the problem is that linux has a bug that if you open in append mode it will ignore any offset you pass to pwrite and alway write to the end of the file.
17:43:43  <piscisaureus>mmalecki: rendar: of course I've seen no code
17:43:56  <rendar>piscisaureus, is that closed source?
17:44:06  <piscisaureus>mmalecki: rendar: but I like the addition of a message queue and a kv store
17:44:21  <tjfontaine>trevnorris: iti could be done only on darwin
17:44:50  <trevnorris>sure
17:44:51  <piscisaureus>trevnorris: append mode is possible. but our problem is also with pwrite,so always writing to the end of the file is not all that
17:45:09  <piscisaureus>and I suppose that if you don't write to the end of the file it doesnt solve the issue?
17:45:35  <trevnorris>no, if you always open the file in append mode, but still give an offset then pwrite should work as expected.
17:45:49  <piscisaureus>ah, ok. I suppose we should do that then
17:45:51  <piscisaureus>on os x
17:45:54  <trevnorris>yeah
17:45:55  <piscisaureus>sounds like a simple fix
17:46:06  <trevnorris>worth testing anyways.
17:46:17  <tjfontaine>generally a reasonable fix, presuming it yields benefits by removing the lock
17:46:30  <rendar>but is that nodejx a v8 link to another lib different than libuv?!
17:46:54  * c4miloquit (Remote host closed the connection)
17:46:56  <piscisaureus>rendar: I don't know, and it's not released, it
17:47:01  <piscisaureus>'s only announced
17:47:06  <trevnorris>tjfontaine: any issues w/ 6925?
17:47:06  <rendar>hmm
17:47:15  <tjfontaine>still reviewing, moment
17:47:19  <piscisaureus>so I presume it's not all that different
17:47:25  <tjfontaine>bert trolled me with nodejx
17:47:35  <piscisaureus>tjfontaine: trolled? how?
17:47:48  <tjfontaine>heh, by making me look at that site :)
17:47:52  <tjfontaine>when I wasn't expecting it
17:47:53  <piscisaureus>oh right
17:47:57  <piscisaureus>haha
17:48:01  <rendar>eheh
17:48:21  <tjfontaine>mBaaS though, seems in your arena, aside from some questionable naming concerns I have
17:49:36  <trevnorris>is nodejx a joke?
17:49:55  <tjfontaine>as in, implementation or in reality?
17:49:59  <tjfontaine>it's a real thing
17:50:17  <piscisaureus>tjfontaine: yeah much like it indeed
17:50:20  <trevnorris>....
17:50:26  <piscisaureus>tjfontaine: I only just heard of it yesterday though
17:50:34  <tjfontaine>first I heard of it as well
17:50:52  <piscisaureus>http://nodejx.com/?p=953 <-- that is a pretty ridiculous post
17:51:28  <piscisaureus>but still worth looking at, overall there seem to be some interesting ideas
17:52:52  * c4milojoined
17:53:11  <MI6>libuv-master: #440 FAILURE http://jenkins.nodejs.org/job/libuv-master/440/
17:53:55  * hzjoined
17:53:58  <rendar>piscisaureus, hmmm but isn't v8 an enemy of multithreading?
17:53:59  <tjfontaine>ya, I'm always interested to see tweaks on our ideas
17:53:59  <rendar>:)
17:54:30  <piscisaureus>rendar: I think they uses the threads-a-gogo approach
17:54:45  <piscisaureus>rendar: not very useful for real stuff imo
17:56:25  <rendar>hmmm
17:56:44  <rendar>they assert that vert.x is comparable to node.js?! really? it is running over a JVM...
17:57:13  * brsonjoined
17:57:40  <rendar>"But considering the recent popularity of Vert.x and some of the published benchmarking results indicating a superior performance over Node.js, .." ... ?
17:58:11  <rendar>something running over a JVM has a superior performance over node.js? i guess this is just BS :-)
17:58:25  * janjongboomquit (Ping timeout: 272 seconds)
17:59:12  * bajtosjoined
17:59:32  * janjongboomjoined
17:59:33  * c4miloquit (Remote host closed the connection)
18:01:09  * Ralithquit (Ping timeout: 252 seconds)
18:01:40  * iamstefquit (Ping timeout: 245 seconds)
18:01:40  * petka_quit (Ping timeout: 245 seconds)
18:02:52  * thlorenzquit (Remote host closed the connection)
18:03:01  * iamstefjoined
18:03:25  * thlorenzjoined
18:03:33  * petka_joined
18:05:21  <trevnorris>indutny: ping
18:06:08  <tjfontaine>I tried that debug test and osx last night, and it didn't didn't get any crypto errors, were you on the latest master?
18:07:45  * thlorenzquit (Ping timeout: 252 seconds)
18:08:39  <trevnorris>tjfontaine: what do you get if you run: ./node_g test/simple/test-crypto-binary-default.js
18:08:42  <trevnorris>on latest master?
18:10:39  * abraxasjoined
18:11:09  * AvianFluquit (Remote host closed the connection)
18:11:12  <tjfontaine>trevnorris: wfm
18:11:35  <trevnorris>strange. I get:
18:11:36  <trevnorris>FATAL ERROR: v8::String::Cast() Could not convert to string
18:11:37  <trevnorris>Aborted
18:11:49  <trevnorris>tjfontaine: you building w/ gcc or clang?
18:11:53  <tjfontaine>that's not ideal, I'll try on smartos
18:11:55  <tjfontaine>trevnorris: clang
18:11:58  * octetcloudjoined
18:12:03  <trevnorris>hm. strange.
18:12:22  * octetcloudquit (Client Quit)
18:12:24  * `3E|DINNERchanged nick to `3rdEden
18:13:01  <trevnorris>tjfontaine: it dies here: ../src/string_bytes.cc:290
18:13:13  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:13:21  <tjfontaine>piscisaureus: working on slurp?
18:13:32  <piscisaureus>tjfontaine: just added 2 channels, that's all
18:13:42  <piscisaureus>svcadm restart slurp is what you saw
18:14:47  * abraxasquit (Read error: Operation timed out)
18:15:33  <tjfontaine>trevnorris: that's not ideal
18:15:48  <tjfontaine>trevnorris: probably means in some path it's not actually getting a string down there, scary.
18:16:11  <trevnorris>tjfontaine: yeah. just wonder why only debug mode is catching it.
18:16:30  <tjfontaine>it adds extra checks generally, in the v8 macros
18:17:03  * hueniversequit (Ping timeout: 272 seconds)
18:17:17  <trevnorris>but usually if that's hit then v8 will dump a bunch of information, or that's what i'd expect. but that's not happening.
18:18:32  <trevnorris>tjfontaine: this line is causing the failure: crypto.createCredentials({pfx:certPfx, passphrase:'sample'});
18:18:41  <trevnorris>but eh, put that on the long list.
18:18:45  <trevnorris>have al to work on right now.
18:18:55  <trevnorris>tjfontaine: and thanks for the review
18:19:02  <tjfontaine>right, working for feature freeze so we can get to testing and perf
18:20:57  <MI6>joyent/node: Trevor Norris master * bf08ac4 : node: compare AsyncListener instances, not uid's (+2 more commits) - http://git.io/yuslaA
18:22:02  <indutny>pong
18:22:04  <MI6>joyent/node: Alexis Campailla master * 22879e7 : test: give test-net-GH-5504 more time to run - http://git.io/j0626g
18:22:06  <indutny>trevnorris: pong
18:22:21  * TooTallNatejoined
18:22:50  <trevnorris>indutny: > ./node_g test/simple/test-crypto-binary-default.js
18:22:50  <trevnorris>FATAL ERROR: v8::String::Cast() Could not convert to string
18:23:11  <trevnorris>something to to with crypto.createCredentials({pfx:certPfx, passphrase:'sample'});
18:23:20  <trevnorris>though doesn't seem to fail on osx.
18:23:21  <trevnorris>just linux
18:23:50  * AvianFlujoined
18:24:10  * hueniversejoined
18:24:34  * octetcloudjoined
18:25:58  <indutny>odd
18:26:08  * bajtosquit (Quit: bajtos)
18:26:45  * hueniversequit (Client Quit)
18:27:21  <indutny>trevnorris: do you have a stack trace?
18:28:35  <MI6>joyent/node: Alexis Campailla master * 2a0b619 : text: give more time to test-next-tick-error-spin - http://git.io/5Btvjw
18:29:29  <trevnorris>indutny: yeah. here's some info: https://gist.github.com/trevnorris/8545430
18:31:16  <trevnorris>oh, heh. possible that .As<String>() is being run on an Buffer Object. But since if it's external it doesn't try to access it like a string it never failed.
18:31:36  <trevnorris>ok. so probably just some logic ordering issues.
18:37:12  <MI6>nodejs-master: #869 FAILURE linux-x64 (4/693) osx-x64 (1/693) linux-ia32 (2/693) osx-ia32 (2/693) http://jenkins.nodejs.org/job/nodejs-master/869/
18:39:27  <MI6>nodejs-master-windows: #656 UNSTABLE windows-x64 (14/693) windows-ia32 (13/693) http://jenkins.nodejs.org/job/nodejs-master-windows/656/
18:39:58  * m76quit (Read error: Connection reset by peer)
18:41:45  * daviddia_quit (Remote host closed the connection)
18:42:17  * daviddiasjoined
18:46:47  * daviddiasquit (Ping timeout: 260 seconds)
18:51:46  * piscisaureusquit (Ping timeout: 265 seconds)
18:52:23  * calvinfopart
18:53:24  * thlorenzjoined
18:56:29  * jmar777quit (Read error: Connection reset by peer)
18:57:00  * jmar777joined
19:02:45  <MI6>nodejs-master: #870 FAILURE linux-x64 (1/693) osx-x64 (1/693) linux-ia32 (4/693) osx-ia32 (1/693) smartos-x64 (4/693) http://jenkins.nodejs.org/job/nodejs-master/870/
19:03:02  * piscisaureusjoined
19:03:23  * jmar777quit (Read error: Connection reset by peer)
19:03:53  * jmar777joined
19:08:40  <piscisaureus>indutny: https://github.com/indutny/libuv/blob/a2bc3fd912b9cb076cb0c914c9a8d08fbcb3ff86/src/unix/process.c#L319-L320 <-- I'm sure you didn't mean that
19:10:19  <trevnorris>tjfontaine: ready for another one of my insane ideas? ;)
19:10:36  <tjfontaine>I guess?
19:10:57  <piscisaureus>trevnorris: go!
19:12:24  <trevnorris>behold, my insanity: https://github.com/trevnorris/node/commit/97e6ac6
19:13:28  <tjfontaine>I'm wary of abusing the object like that
19:13:40  <trevnorris>heh :)
19:13:44  <tjfontaine>it is an interesting pattern
19:13:55  <trevnorris>well, I could create another object and attach it like I have with ._asyncQueue
19:14:15  <trevnorris>but this way we have immediate access to the provider and flag in MakeCallback
19:14:34  <trevnorris>*provider and probe
19:14:44  <tjfontaine>you mean from the js side of the event path?
19:15:29  <trevnorris>yeah. basically. a user sets they want to check provider X and Y. so from js you set it on another object tied to memory the same way
19:16:24  <trevnorris>then you can do comparisons in c++ or js at practically zero cost of whether the provider/probe have been requested
19:16:25  * thlorenzquit (Remote host closed the connection)
19:16:34  <tjfontaine>I would like to benchmark the differences in attaching it that way vs adding inline array definition that includes it
19:16:59  * thlorenzjoined
19:17:14  <trevnorris>sorry, what do you mean inline array. you mean just adding another object property?
19:17:23  <trevnorris>like ._asyncQueue?
19:17:43  <tjfontaine>no, instead of doing &val, it would be Local<Value> argv[] = { obj, provider_, probe_ }
19:18:07  <trevnorris>where would that code occur?
19:18:19  <trevnorris>actually, this might not be necessary at all.
19:18:23  <tjfontaine>L73
19:18:38  <trevnorris>have another idea. moment please.
19:20:45  <trevnorris>and actually.... provider isn't a bitwise flag like probes will be. since an AsyncWrap can only be a single provider.
19:20:49  * dshaw_quit (Read error: Connection reset by peer)
19:20:50  <trevnorris>don't know why I didn't think of that before.
19:21:08  * dshaw_joined
19:21:34  <tjfontaine>the only reason I kept it bitwise (both probes and providers) is because it was nice to express it all with the same values
19:21:38  * thlorenzquit (Ping timeout: 252 seconds)
19:21:40  <tjfontaine>from who is watching what and why
19:22:09  <tjfontaine>so provider doesn't need to be bitwise, but unless we outgrow the javascript precision on it, it's convenient for the expression to stay the same
19:22:14  <trevnorris>but it's not possible an AsyncWrap instance has more than one provider type, correct?
19:22:57  <tjfontaine>that's correct, I'm just trying to say "I want to watch c-ares, timers, net" which is conveniently described as CARES|TIMERS|NET
19:23:26  <trevnorris>ah.... I see what you're saying. ok. got it.
19:23:34  * bradleymeckjoined
19:23:47  <tjfontaine>so, they dont' *have* to be bitwise, but if we can keep them bitwise we can reuse values and logic
19:23:57  <trevnorris>yeah. see what you're saying now.
19:27:14  * Ralithjoined
19:32:21  * mikolalysenkoquit (Ping timeout: 248 seconds)
19:33:52  * c4milojoined
19:34:44  <trevnorris>tjfontaine: here, much saner: https://github.com/trevnorris/node/commit/a9a8ae4eda09f8724a03d4cec573f9367a5b6291
19:34:54  * mikolalysenkojoined
19:35:33  <trevnorris>tjfontaine: now, all you have to do is asyncFlags[kWatchedProviders] |= PROVIDER_TCPWRAP; and that can be a quick check in MakeCallback against provider_type()
19:37:13  <trevnorris>tjfontaine: yeah. so in MakeCallback, just have to do an if ((provider_type() & env()->watched_providers()) > 0) {}
19:37:30  <trevnorris>and you'll know if the user has requested to listen to that provider.
19:38:03  <trevnorris>now, there's currently no API to actually set that. but that's what I figured your tracing module would do. :)
19:39:14  * c4miloquit (Ping timeout: 264 seconds)
19:45:44  <MI6>nodejs-master-windows: #657 UNSTABLE windows-x64 (14/693) windows-ia32 (11/693) http://jenkins.nodejs.org/job/nodejs-master-windows/657/
19:49:00  * c4milojoined
19:50:16  <trevnorris>tjfontaine: now, once the provider has been listened for, the exact probes on the provider are unique to the AsyncWrap instance.
19:50:46  <trevnorris>so that's where we'd use a technique like the one before.
19:54:49  * thlorenzjoined
19:55:24  <trevnorris>othiym23: ooh, massive pipe-dream.
19:55:37  <trevnorris>man I love thinking of things that are dang near impossible to implement. :P
19:56:05  <trevnorris>tracing('<module>', '<provider>', '<probe>')
19:56:31  <trevnorris>like: tracking('express', 'tcp', 'read|write');
19:56:45  <trevnorris>so, module as in user-land module
19:57:10  <trevnorris>so totally not possible. but hey. it's what makes life interesting.
19:58:29  * rmgquit (Remote host closed the connection)
20:00:17  * piscisaureusquit (Ping timeout: 272 seconds)
20:00:47  * daviddiasjoined
20:01:15  * daviddiasquit (Read error: Connection reset by peer)
20:02:26  * brsonquit (Quit: leaving)
20:03:02  <trevnorris>indutny: did you already have a PR for removing all the node_isolate's, or can I take care of that real quick?
20:03:08  * wolfeidauquit (Remote host closed the connection)
20:03:24  <indutny>trevnorris: haha :)
20:03:27  <indutny>trevnorris: I tried to do that
20:03:39  <indutny>trevnorris: but it was just too broad
20:03:48  <indutny>I decided to think about it for a couple of days
20:03:50  <indutny>basically
20:03:55  <indutny>the main problem is Throw()
20:03:59  <indutny>ThrowCryptoError()
20:04:01  <indutny>and friends
20:04:11  <trevnorris>oh, come on. there's only 652 of them in src/ :P
20:06:10  * piscisaureusjoined
20:07:02  <indutny>haha
20:07:03  <indutny>well
20:07:17  <indutny>it is actually much bigger
20:07:28  <indutny>because you'll need to propagate it to some of those 652 places
20:07:36  <indutny>as it isn't available in it
20:07:36  <trevnorris>yeah....
20:07:41  <indutny>look at node_file.cc for starters
20:07:47  <indutny>and then at node_crypto.cc
20:07:56  <indutny>trevnorris: if you want - I can push my stuff to github
20:08:00  <indutny>so you could start from there
20:08:24  <trevnorris>hehe. no. I have plenty else on my plate right now. :P
20:08:35  <trevnorris>was just trolling you since I had seen you had started doing that. :)
20:09:15  <trevnorris>plenty could be gotten rid of.
20:09:27  <trevnorris>like, all the env()->isolate() and args.GetIsolate() locations are easy.
20:09:41  <trevnorris>but yeah, there are some places that will require rearchitecting
20:11:33  * abraxasjoined
20:15:56  * abraxasquit (Ping timeout: 252 seconds)
20:17:06  * rmgjoined
20:18:17  * mikolalysenkoquit (Ping timeout: 265 seconds)
20:22:23  <tjfontaine>trevnorris: why was that a pipe dream? that's what my thing did?
20:23:50  <trevnorris>tjfontaine: you're telling me you can be so specific as to say, I only want to intercept incoming tcp connections made by X user-land module?
20:24:14  <trevnorris>the "user-land module" part seems pretty far fetched imho.
20:24:51  <bradleymeck>are we talking about interposed hooks? (missed earlier conversation)
20:24:53  <tjfontaine>oh I see, no, that wouldn't be done with async listeners anyway, it's with the actual user defined instrumentation that I've been doing
20:25:30  * trevnorrisgoes to look up what interposed means
20:26:39  <trevnorris>tjfontaine: well, here's the simple part for watching for providers: https://github.com/trevnorris/node/commit/8d241ab4ebaaca895e41a654f5d4bb618a916b87
20:28:52  <tjfontaine>I'm torn on the idea of keeping extra state on the AsyncWrap for this vs global tracking state
20:29:24  <trevnorris>tjfontaine: please elaborate
20:29:41  <tjfontaine>the need to have in both Environment and AsyncWrap
20:29:55  <trevnorris>they're not the same.
20:29:56  <tjfontaine>s/and/or/
20:30:11  <tjfontaine>I know they behave differently, I'm torn on the need for it
20:30:17  * dshaw_quit (Quit: Leaving.)
20:30:23  <trevnorris>i'm confused how we get around not needing it
20:30:50  <trevnorris>it's not they behave differently, it's that they complement each other
20:31:33  <trevnorris>so I can check env()->wached_providers() in AsyncWrap::Init() and see if there's extra work we need to do
20:32:31  <tjfontaine>but there's context state for this and global state?
20:32:51  <trevnorris>sorry, how do you mean?
20:32:56  <tjfontaine> return const_cast<Environment*>(this)->async_listener()->watched_providers(); is grabbing the current active async listener?
20:33:34  <trevnorris>that's just telling us what we're listening for globally
20:33:47  <tjfontaine>right, global state, and per context state
20:34:02  <trevnorris>so if AsyncWRap::provider_type() doesn't match that then there's no extra work to do
20:34:23  <tjfontaine>so what's the storage on AsyncWrap for?
20:34:42  <tjfontaine>oh this AsyncListener
20:37:51  <indutny>trevnorris: yep
20:38:13  <trevnorris>indutny: bummer. well, that's definitely down the road.
20:38:22  <indutny>you have looked at it? :)
20:38:39  <trevnorris>briefly. just enough to know that it's non-trivial
20:39:29  <indutny>well, it is simple
20:39:41  <indutny>but I don't like that we need to propagate ThrowException stuff
20:39:47  <indutny>I mean it's isolate argument
20:39:58  <indutny>perhaps we could move them to the Environment
20:40:02  <indutny>hmm...
20:40:37  <trevnorris>tjfontaine: so, if you look at the currentContext object in src/node.js you'll see I keep flags for each AsyncListenerInst for what callbacks are available. but also a cumulative flag on currentContext that let's me know all the possible flags for all object on the context.
20:42:07  <trevnorris>tjfontaine: so you can keep track of _all_ listened for providers on the asyncFlags[kWatchedProviders], then iterate through each one and check if it's listening for that provider or not.
20:44:07  <trevnorris>tjfontaine: unfortunately timers and nextTick are going to be one strange ass exception, but shouldn't be too bad to work around.
20:45:03  <tjfontaine>trevnorris: from a tracing api I'm not sure it's all that interesting to make them work different from ALs perspective
20:45:29  <tjfontaine>trevnorris: AL should work like AL works, that means timeouts and intervals are represented in their real constructs
20:45:40  * paulfryzelquit (Read error: Connection reset by peer)
20:45:59  * paulfryzeljoined
20:46:11  <trevnorris>tjfontaine: i mean more of, needing to check if the "timers" provider is being listened for in MakeCallback. since setImmediate takes the slow path anyways because of that linked list thing.
20:46:19  <trevnorris>so it's not attached to an AsyncWrap
20:46:23  <trevnorris>same w/ nextTick
20:46:59  <tjfontaine>right, since they're not implemented in that semantic I'm not sure it makes sense to work harder around them, instead we could expose static probes
20:47:09  <trevnorris>ah, I see.
20:47:11  <trevnorris>ok cool
20:47:30  <tjfontaine>so we keep ALs logic straight forward and simple, and tracing the things it can trace
20:47:51  <tjfontaine>for the cases where that differs, we make sure that our static probes fit the inbetween land
20:47:52  <trevnorris>tjfontaine: well, tracing providers is simple in AL. I just implemented that.
20:48:09  <trevnorris>well, the guts
20:48:17  <trevnorris>not the api, since that'll be up to the tracing module
20:48:19  <tjfontaine>yes yes, I'm not talking about that
20:48:25  <indutny>hm...
20:48:32  <indutny>what do you guys think about some sort of context? :)
20:48:42  <indutny>https://github.com/joyent/node/issues?milestone=17&state=open
20:48:42  <tjfontaine>for you?
20:49:02  <tjfontaine>surprisingly fewer than i anticipated
20:49:22  <MI6>joyent/node: Fedor Indutny master * e57ab7b : node: `EmitExit` should not call `exit()` (+1 more commits) - http://git.io/oIh5gg
20:49:23  <indutny>haha
20:49:33  <indutny>tjfontaine: so this commit has introduced one test failure
20:49:44  <indutny>I haven't really dug into it
20:49:45  <tjfontaine>emiexit?
20:49:48  <tjfontaine>*emitexit
20:49:50  <indutny>nope
20:49:55  <indutny>I fixed it
20:50:09  <tjfontaine>which test failure?
20:50:11  <indutny>./node test/addons/async-hello-world/test.js
20:50:16  <tjfontaine>oh
20:50:18  <indutny>yeah
20:50:27  <tjfontaine>that's fine
20:50:37  <indutny>sometimes 'exit' is emitted before nextTick
20:51:03  <indutny>that's quite surpising
20:51:05  * tjfontainelooks at implementation
20:51:08  <indutny>trevnorris: perhaps, you want to look into it?
20:51:14  <trevnorris>indutny: um, Isolate::GetCurrent() is, or at least will be, deprecated.
20:51:21  <indutny>trevnorris: ok
20:52:03  <indutny>trevnorris: you could open a Pull Request that is fixing this :)
20:52:06  <trevnorris>indutny: i think the "context" you're talking about, and why this discussion has been taking priority is because it's the last bit api change before code freeze, afaik. tjfontaine ?
20:52:19  <indutny>wut?
20:52:19  <trevnorris>indutny: i'll just replace it w/ node_isolate. :P
20:52:22  <indutny>aaah
20:52:39  <indutny>env()->Throw() ?
20:52:48  <indutny>I don't think that it is an API change
20:53:05  <trevnorris>seems we're on different pages now. :)
20:53:15  <trevnorris>i was talking about all our discussion around AL
20:53:21  <tjfontaine>trevnorris: tracing is our last external api, as well as execSync -- they're the last pieces to add, not that we can tweak that after feature freeze
20:53:30  <trevnorris>env()->ThrowRangeError() seems cool w/ me.
20:53:55  <trevnorris>tjfontaine: yeah. that's what I thought. so hammering this out is priority.
20:54:02  <trevnorris>env()->ThrowTypeError()
20:54:05  <indutny>trevnorris: ah, sorry
20:54:07  <indutny>I missed it
20:54:26  <tjfontaine>can't we abuse macros to assume env?
20:54:27  <indutny>tjfontaine: will I still be able to make `process.send()` async after that?
20:54:35  <indutny>tjfontaine: probably
20:54:37  <trevnorris>indutny: yeah. I like that API. and honestly how it should've been from the beginning
20:55:23  <tjfontaine>indutny: I'm not sure about async send, how soon can you have a PR?
20:55:25  * daviddiasjoined
20:55:35  <indutny>haha
20:55:39  <indutny>ok
20:55:41  <indutny>let's move it to 0.14
20:55:47  <indutny>seems like a minor behavior change
20:55:51  <indutny>ok?
20:55:52  * daviddiasquit (Read error: Connection reset by peer)
20:55:54  <tjfontaine>yes
20:55:59  <trevnorris>tjfontaine: side note. the reason for attaching data directly to _handle is because it's already a Persistent. Attaching data to a normal object leads to some strange failures. well. let me check that.
20:56:11  <tjfontaine>indutny: I also want to revisit the cluster api for distribtued
20:56:25  * paulfryzelquit (Remote host closed the connection)
20:56:25  <indutny>in v0.14?
20:56:32  <trevnorris>tjfontaine: actually. dare I actually say this, it might be prudent to use the ArrayBuffer API in this case since the values are small and the GC is hyper opimized for them.
20:56:37  <tjfontaine>indutny: in 0.13 :)
20:56:41  <indutny>yeah
20:57:01  <trevnorris>tjfontaine: i'm going to try that instead. so _handle._asyncFlags will be a Uint32Array
20:57:09  <tjfontaine>trevnorris: ok
20:57:44  * AWinterm_joined
20:57:59  <tjfontaine>indutny: seems like we're going to get more people wanting to distribute their load and get node out of the way of making that decision
20:58:07  <trevnorris>tjfontaine: ok. i'm feeling good about this so far. do you have like a general tracing.js? I'd like to migrate as much of the code from node.js over as possible.
20:58:18  * AWintermanquit (Read error: Connection reset by peer)
20:58:20  <trevnorris>if nothing else, just a skeleton
20:59:01  <tjfontaine>trevnorris: I would be happy to land https://github.com/tjfontaine/node/commit/1363052e853d369f7f546131021026a1bc00b897 (after some restyling)
20:59:09  <MI6>nodejs-master: #871 FAILURE linux-x64 (1/693) osx-x64 (2/693) linux-ia32 (3/693) osx-ia32 (1/693) smartos-x64 (3/693) http://jenkins.nodejs.org/job/nodejs-master/871/
20:59:12  <indutny>tjfontaine: great
20:59:55  <octetcloud>@tjfontaine: cluster for distributed, you mean across multiple machines/virtual machines?
21:00:11  <trevnorris>tjfontaine: have you done any perf testing w/ that? v8 still hasn't well optimized for inline functions.
21:00:12  <tjfontaine>trevnorris: there's still some bikeshedding areas around .on() and .create that need to be had
21:00:18  <trevnorris>ok
21:00:28  * piscisaureusquit (Read error: Operation timed out)
21:00:30  * mikealjoined
21:00:44  <tjfontaine>octetcloud: no, specifically how load in a single cluster is managed, shunting handles across logical machines seems out of scope for node
21:00:46  <trevnorris>overall i'm cool w/ it. i'll do most the benchmarking and whatnot
21:01:11  <trevnorris>tjfontaine / octetcloud: and wouldn't that be at the libuv level to boot?
21:01:15  <tjfontaine>trevnorris: I want to be able to have namespacing be a first class feature I think
21:01:47  <tjfontaine>trevnorris: such that we don't pollute the potential space for others
21:01:54  <trevnorris>tjfontaine: sorry, you'll have to elaborate on that one. you mean get around the butt hole of a performance issue I bitch about all the time?
21:02:01  <trevnorris>ah, ok
21:02:38  <octetcloud>@tjfontaine: I'd like suicide to go, maybe as a concept, definitely as the name. I had to explain yesterday on a conf call how if the master calls worker.kill(), its suicide, but if a worker calls process.exit(), it is NOT suicide :-(
21:02:44  * dshaw_joined
21:03:02  <trevnorris>tjfontaine: ok. i'll put a pause on 6923 and take a look at your current tracing module.
21:04:38  <trevnorris>tjfontaine: what I don't like is that because of how our module system works v8 can't make assumptions about other-module methods. so even if it's a noop, v8 still has to do the context switch/check and all that.
21:04:42  <tjfontaine>octetcloud: sigh, ya...
21:04:49  <octetcloud>And the worker events should either be all emitted on cluster, as sugar, or none of them should be: right now its like a node trivia contest "of the six events <...> that a worker can emit, guess which ones are emitted on the cluster module, too?"
21:04:59  <othiym23>tjfontaine: if I get some time (hint: no time soon) I'll see if I can put together a report showing how many people are actually serving off OS X in production
21:05:15  <tjfontaine>othiym23: that'd be great, we just had this conversation at lunch :)
21:05:44  <tjfontaine>othiym23: I believe we're already under MNDA, so aggregate results in general around platform usage would be ... ya know ... invaluable :P
21:05:56  <trevnorris>othiym23: either indutny or tjfontaine said we could try the append flag hack and get the pwrite mutex fixed in libuv. fwiw
21:06:17  <tjfontaine>octetcloud: ya, when's the next time you'll be in the bay area?
21:06:29  <othiym23>trevnorris: rad
21:06:39  <tjfontaine>no reason not to try it
21:07:08  <trevnorris>tjfontaine: wtf. you authored that 6 months ago? ok. well since the remainder of AL work depends on the tracing module being in place i'll get started getting this working.
21:07:20  <octetcloud>specific suggestions would be: 1: emit message on cluster, for consistency, 2: completely remove .kill(), or make it === child_process.kill, 3: rename suicide to 'expected'
21:07:33  <octetcloud>I can PR, but don't want to waste time if you all don't want
21:07:35  <tjfontaine>trevnorris: I started working on it 6 months ago, the rest is an artifact of git rebase timers
21:07:37  <MI6>nodejs-master-windows: #658 UNSTABLE windows-x64 (17/693) windows-ia32 (15/693) http://jenkins.nodejs.org/job/nodejs-master-windows/658/
21:07:55  <trevnorris>tjfontaine: ah, of course.
21:08:09  <tjfontaine>octetcloud: I don't want to waste your time either, I would like the PR as a mechanism to discuss the problems and ideas
21:08:49  <octetcloud>@tjfontaine: not for a while, next scheduled is May-ish
21:09:15  <tjfontaine>ok, it would be nice to get a roundtable of people using cluster in production
21:09:18  <octetcloud>@tjfontaine: I could PR just a doc change, or something, so people could comment, and I could link to some of the bug-reports caused by current API
21:09:32  <tjfontaine>as this is our last chance to fix some of the problematic things (i.e. 0.13)
21:09:42  <tjfontaine>octetcloud: yes, please do that
21:10:20  <octetcloud>ok. will add to my list. which is growing, but not as fast as Node's ;-)
21:10:39  <tjfontaine>growth in issues doesn't scare me
21:10:51  <tjfontaine>it's better to *know* about them then for people to be toiling in quiet disdain
21:11:03  <tjfontaine>we can't fix the ones we don't know about
21:11:15  <tjfontaine>when we do know about them, we can prioritize appropriately
21:11:22  <tjfontaine>at the moment we're just in brace for impact mode of 0.12
21:11:50  <trevnorris>othiym23: api question
21:12:21  <trevnorris>othiym23: so, since multiple AL can run, and each handle the error, would it be useful to pass in another argument that let's the called error handler know if the error has already been handled?
21:14:06  <octetcloud>that's one way to look at it. the other is that as issue count gets larger people might stop reporting, and issues that are open but in won't fix can contribute to that. also, the sheer number makes triage and cleaning time consumeing. and dev time is precious resource. but that's just IMHO
21:14:54  <trevnorris>groundwater: or you too. :)
21:15:22  <othiym23>trevnorris: it *could* be useful, but I don't have a concrete use case off the top of my head
21:15:30  <othiym23>trevnorris: so my suggestion is to leave it out
21:15:32  <tjfontaine>octetcloud: what's important is that when a user submits an issue they have a good interaction with the community and team around it, if they feel like their request is heard and other people see it they will feel encouraged to participate
21:15:43  <trevnorris>othiym23: yup. ok.
21:15:51  <tjfontaine>octetcloud: but we can't be obsessed with closing issues for sake of burn down rate, or the sheer number
21:16:22  <tjfontaine>octetcloud: often that leads to users feeling their requests weren't apropriately considered, and leads to members feeling the need to spend all day working through and triaging them
21:16:38  <tjfontaine>fwiw daviddias has been working on tooling that will help some of us keep better track of our responses
21:19:22  * mcavagejoined
21:21:47  * mikealquit (Quit: Leaving.)
21:27:25  * paulfryzeljoined
21:36:45  * paulfryzelquit (Ping timeout: 252 seconds)
21:37:55  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:38:07  <MI6>libuv-master-windows: #20 UNSTABLE windows-ia32 (4/202) windows-x64 (4/202) http://jenkins.nodejs.org/job/libuv-master-windows/20/
21:43:17  <trevnorris>tjfontaine: are we going to merge in the work that ben did into tracing after AL is hammered out?
21:43:56  * hzquit
21:44:30  <trevnorris>tjfontaine: also, from that commit: ../src/node_dtrace.cc:110:21: error: unknown type name 'node_isolate'
21:45:15  <trevnorris>tjfontaine: wait... why is node_dtrace being compiled on my linux box?
21:50:10  * daviddiasjoined
21:50:41  * daviddiasquit (Read error: Connection reset by peer)
21:51:09  <MI6>libuv-v0.10-windows: #15 FAILURE http://jenkins.nodejs.org/job/libuv-v0.10-windows/15/
21:58:13  <trevnorris>tjfontaine: you'll need to step me though what's going on in that commit, and why node_dtrace is trying to build, and why the build is broken.
21:58:32  * daviddiasjoined
21:59:00  * daviddiasquit (Remote host closed the connection)
21:59:29  * daviddiasjoined
22:00:35  * CoverSlidequit (Ping timeout: 252 seconds)
22:07:37  <tjfontaine>trevnorris: I can fix the build, but the idea is it should always be compiled, but when systemtap/etw/dtrace is not enabled it's not a runtime issue
22:08:01  <tjfontaine>trevnorris: and yes, as I've said multiple times, exposing the v8 tracing mechanisms will be integrated in the form of the work that ben started
22:08:12  <tjfontaine>but with big big caveats that this is an interface we do not control
22:09:01  <trevnorris>tjfontaine: i know you said we would. was just wondering on some timeline. but doesn't really matter I guess.
22:09:08  <trevnorris>i'm working on adding more tests for AL
22:09:38  <tjfontaine>that part is pretty trivial, I could od that right now if you care, by introducing tracing.js and hanging v8 off it and rebase ben's work on that
22:10:00  * dshaw_quit (Quit: Leaving.)
22:10:12  <trevnorris>whatever's easiest.
22:13:52  * AWinterm_quit (Remote host closed the connection)
22:15:57  * AWintermanjoined
22:17:22  <indutny>tjfontaine: please rereview https://github.com/joyent/node/pull/6913
22:17:41  <tjfontaine>on it
22:18:10  * AWinterm_joined
22:18:42  <indutny>thank you
22:20:38  * AWintermanquit (Ping timeout: 264 seconds)
22:21:07  * rmgquit (Remote host closed the connection)
22:22:21  <tjfontaine>indutny: looks pretty good, I'm glad we only have the one implementation now :)
22:22:26  <indutny>haha
22:22:28  <indutny>yeah
22:22:31  * c4miloquit (Remote host closed the connection)
22:22:34  <indutny>tjfontaine: I could go even further
22:22:38  <indutny>and merge Sign and Verify together
22:22:41  <indutny>but this is another thing
22:22:47  <indutny>and I have a lot of other stuff to do before v0.12
22:22:49  <tjfontaine>ya
22:23:07  <tjfontaine>that's nto necessary, we should explore a general code cleanup of src/ anyway
22:23:12  <tjfontaine>post 0.12
22:23:27  <tjfontaine>along with somewhat of an internal documentation effort
22:23:53  <indutny>yep
22:23:56  <indutny>so should I land that PR?
22:24:13  <tjfontaine>ya, it seems like a fine refactoring for now
22:24:19  <tjfontaine>thanks for catching it
22:24:23  <indutny>you're welcome
22:24:51  * c4milojoined
22:25:34  <MI6>joyent/node: Fedor Indutny master * 661190a : crypto: throw only in direct C++ methods - http://git.io/sl3BeQ
22:26:33  <indutny>yay
22:26:35  <indutny>40 issues left
22:26:37  <indutny>59 closed
22:26:41  <tjfontaine>heh
22:27:11  <indutny>tjfontaine: one more, please https://github.com/joyent/node/pull/6914 ?
22:27:13  <indutny>pretty simple
22:27:45  * thepumpkinjoined
22:28:28  * rendarquit (Quit: Leaving)
22:28:53  <tjfontaine>indutny: previously, if we sent an invalid type to the crypto layer for this, how owuld it die by raising an exception?
22:29:13  <indutny>how?
22:29:15  <indutny>it would die
22:29:18  <indutny>as usual
22:29:18  <tjfontaine>like if I passed 12345
22:29:25  <indutny>hm...
22:29:29  <tjfontaine>was that a ThrowException from crypto layer?
22:29:30  <indutny>you mean that exception will not be informative?
22:29:37  <indutny>no
22:29:39  <indutny>ah
22:29:40  <tjfontaine>or is it delivered to on('error')
22:29:43  <indutny>before patch?
22:29:46  <tjfontaine>yes before
22:29:49  <indutny>let me see
22:30:02  <tjfontaine>I'm trying to decide if we are just making a more clear exception
22:31:43  <indutny>tjfontaine:
22:31:45  <indutny>Error: error:0906D066:PEM routines:PEM_read_bio:bad end line
22:31:45  <indutny> at Object.exports.createCredentials (crypto.js:95:17)
22:31:51  <indutny>oh
22:31:55  <indutny>not exactly this
22:31:56  <indutny>one sec
22:32:23  <indutny>haha
22:32:26  <indutny>actually it is ok
22:32:26  <indutny>:)
22:32:29  <indutny>it accepts it
22:32:43  <tjfontaine>right ... it just ignores it or tries to apply some internal ordering list from openssl?
22:33:24  * paulfryzeljoined
22:34:30  * bradleymeckquit (Quit: bradleymeck)
22:35:22  <indutny>tjfontaine: I have no idea, honestly
22:35:47  <indutny>I think it'll fail
22:35:55  <indutny>on new connection
22:36:01  <indutny>one sec
22:36:02  <indutny>testing it
22:36:03  <tjfontaine>the ssl connection will fail likely with econnreset
22:36:14  <tjfontaine>because there's no cert for openssl to handhsake with
22:36:23  <tjfontaine>if it's like any other previous bug I've hit
22:36:35  <indutny>SSL connection error
22:36:37  <indutny>got in chrome
22:36:37  <tjfontaine>right
22:36:47  <indutny>so
22:36:51  <indutny>now it'll be an exception
22:36:54  <indutny>and it is fine, I think
22:36:59  <tjfontaine>right, I think we can keep the exception
22:37:02  <indutny>perhaps I should add proper message
22:37:05  <tjfontaine>but I would like to do it: if (!isBuf || !util.isString(buf)) throw new Error("Certificate should be of type Buffer or string");
22:37:06  <indutny>as a second assert argument
22:37:08  <tjfontaine>something like that
22:37:15  <indutny>sure
22:37:19  <indutny>otherwise LGTY?
22:37:22  <tjfontaine>yup
22:37:59  * paulfryzelquit (Ping timeout: 252 seconds)
22:38:01  <indutny>let's run some tests
22:38:19  <indutny>just to make sure
22:38:29  <tjfontaine>always a good idea ;)
22:39:52  * bradleymeckjoined
22:42:24  <MI6>joyent/node: Fedor Indutny master * cdde9a3 : crypto: add newline to cert and key if not present - http://git.io/h0unFA
22:42:34  * c4milo_joined
22:43:09  <indutny>done!
22:43:14  <tjfontaine>thanks fedor
22:43:33  <indutny>you're welcome
22:43:37  <indutny>and thank you
22:43:38  <indutny>for reviewing
22:43:45  <tjfontaine>no problem, I have plenty more to do :)
22:45:02  * rmgjoined
22:45:23  * kenperkinsjoined
22:45:47  * c4miloquit (Ping timeout: 260 seconds)
22:46:40  <MI6>nodejs-master-windows: #659 UNSTABLE windows-x64 (17/693) windows-ia32 (13/693) http://jenkins.nodejs.org/job/nodejs-master-windows/659/
22:48:49  <tjfontaine>really need to figure out the gyp flock issue
22:50:31  * bradleymeckquit (Quit: bradleymeck)
22:55:27  <MI6>nodejs-master: #872 UNSTABLE linux-x64 (1/693) osx-x64 (1/693) linux-ia32 (5/693) osx-ia32 (1/693) smartos-ia32 (2/693) smartos-x64 (5/693) http://jenkins.nodejs.org/job/nodejs-master/872/
22:56:33  <trevnorris>wow. strange freakin.
22:57:02  <trevnorris>back to the issue where net.createServer is propagating the same error twice through the fatal error handler.
23:08:01  * dshaw_joined
23:10:26  * daviddiasquit (Ping timeout: 264 seconds)
23:11:56  <trevnorris>othiym23 or groundwater: have a moment?
23:13:22  * jmar777quit (Remote host closed the connection)
23:17:21  * piscisaureusjoined
23:17:31  <MI6>nodejs-master-windows: #660 UNSTABLE windows-x64 (14/694) windows-ia32 (15/694) http://jenkins.nodejs.org/job/nodejs-master-windows/660/
23:17:32  * thlorenzquit (Remote host closed the connection)
23:18:06  * thlorenzjoined
23:22:21  * thlorenzquit (Ping timeout: 252 seconds)
23:22:52  <othiym23>trevnorris: sure, we're hanging out with dshaw_ here in the New Relic podcast studio
23:23:03  * mikolalysenkojoined
23:23:11  <trevnorris>othiym23: coolio. actually. think I might have just figured it out. thanks for the vibes. :)
23:24:00  * dshaw_waves
23:24:51  <trevnorris>hey hey. \o/
23:28:37  * Ralithquit (Ping timeout: 248 seconds)
23:30:52  <MI6>nodejs-master: #873 UNSTABLE linux-x64 (1/694) osx-x64 (2/694) linux-ia32 (2/694) osx-ia32 (2/694) smartos-ia32 (2/694) smartos-x64 (4/694) http://jenkins.nodejs.org/job/nodejs-master/873/
23:33:04  * kenperkinsquit (Quit: Computer has gone to sleep.)
23:33:10  * thlorenzjoined
23:34:18  * paulfryzeljoined
23:38:29  * paulfryzelquit (Ping timeout: 252 seconds)
23:41:47  * mikolalysenkoquit (Ping timeout: 252 seconds)
23:42:08  * kenperkinsjoined
23:48:14  <trevnorris>tjfontaine: need quick review on https://github.com/joyent/node/pull/6930
23:49:27  * thlorenzquit (Remote host closed the connection)
23:50:01  * thlorenzjoined
23:50:16  * Ralithjoined
23:53:07  <trevnorris>or anyone really... review. anyone?
23:54:37  * thlorenzquit (Ping timeout: 272 seconds)
23:58:53  <MI6>libuv-master-gyp: #398 UNSTABLE smartos-ia32 (3/203) smartos-x64 (3/203) http://jenkins.nodejs.org/job/libuv-master-gyp/398/