00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:02  <petka_>it is currently capped at 15000 op/s
00:00:08  * ircretaryjoined
00:00:22  <petka_>that's like, really, really slow
00:00:24  <tjfontaine>and since it's not a critical imperative at the moment, it does us all a benefit for it to grow and mature in the npm space on its own, and as adoption of it increases the inclusion can be reevaluated
00:00:57  <petka_>you cannot get 100 000 rps if parsing the url already is taking you down to 15k rps
00:01:14  <groundwater>trevnorris: ahoy!
00:02:31  <tjfontaine>petka_: there are a lot of large and complex deployments out there, they have complaints about node, so far as I know, you're the first to raise the url parser as an issue -- and lucky for you and everyone else in the short term that might experience the pain -- it's really easy to replace the parser by using your module
00:02:38  <petka_>I don't understand why it would need to grow and mature, it's the same module but faster. e.g. .resolve code is mostly the same
00:02:57  <trevnorris>groundwater: hey dude. one sec and i'd like you to take a quick look at something.
00:03:25  <tjfontaine>petka_: it's *not* the same module, it's a ground up rewrite of the parser as you indicate
00:03:29  <groundwater>trevnorris: sure
00:03:37  <petka_>in terms of api and semantics
00:03:41  <tjfontaine>petka_: the API is not the question
00:04:13  <tjfontaine>petka_: and semantics are for now undetermined, you know as much of the coverage that our current tests have and any that you've done, that isn't necessarily indicative of all the existing semantics of node's existing parser
00:04:25  * mikealjoined
00:04:47  <tjfontaine>petka_: there may yet be unknown corner cases in your implementation, and for that staying out in the community for a while can do it quite well
00:05:01  <petka_>sure, but a few minors? doesn't that mean years?
00:05:02  <tjfontaine>petka_: again, feel free to file the PR and keep it up to date on the master branch
00:05:11  <tjfontaine>petka_: no not really
00:05:13  <petka_>again I don't want to rush it but if it takes years
00:05:20  <tjfontaine>but that's why npm exists
00:05:27  * spionjoined
00:05:37  <tjfontaine>this would be a different conversation if url itself were used heavily within node core itself
00:06:12  <petka_>afaik url.parse(request.url) is what is done in every web server
00:06:25  <tjfontaine>what users decide to do, is not the same as what node itself does
00:06:51  <petka_>but the users don't know that url.parse is a heavy bottleneck and wouldn't know to look for another module
00:07:00  <petka_>I mean you kinda dismissed it yourself at the beginning as well
00:07:51  <tjfontaine>users who are doing heavy amounts of url.parse and do profiling will certainly see it popping up in their results, and then begin searching for solutions
00:08:16  <petka_>no, just once per request is already a huge slow down
00:08:31  <Domenic_>I am surprised you are dismissing this just because it's not used in core code. It feels like dismissing HTTP performance because of all the users who use Node primarily for Grunt and never run servers.
00:09:11  <MI6>libuv-master-gyp: #363 UNSTABLE windows-x64 (5/202) smartos-ia32 (4/203) smartos-x64 (7/203) windows-ia32 (5/202) linux-ia32 (2/203) osx-ia32 (2/204) http://jenkins.nodejs.org/job/libuv-master-gyp/363/
00:09:17  <tjfontaine>node needs to continue to focus on being correct, and not introducing new performance regressions -- but I'm unconvinced it's worth our time in the short term to focus on introducing a rewrite now for something that is generally solvable from npm
00:09:22  <tjfontaine>Domenic_: it's not about that
00:10:01  <petka_>but it wouldn't be as accessible from npm, I mean I don't really have time to market it
00:10:03  <tjfontaine>Domenic_: it's not dimissing it because it's not used in core, it's not dismissing it at all -- it's a question of priorities
00:10:16  <petka_>(or skill :P)
00:10:22  * thlorenzquit (Remote host closed the connection)
00:10:56  * thlorenzjoined
00:11:29  <tjfontaine>if url.parse were somethign that node itself was forcing on users in a hot path it would be crucial and critical to be evaluating all solutions, if there's another core comitter that wants to take this on as their pet project that's fine -- but url parsing is an important part to get *right*
00:14:37  <mmalecki>ideally, the tests cover all the semantic catches :P
00:14:48  <tjfontaine>mmalecki: in a perfect world, yes
00:15:05  <tjfontaine>and of our coverage, url is some of our best
00:15:08  * thlorenzquit (Ping timeout: 245 seconds)
00:15:14  <tjfontaine>mostly because the rfc covers a lot of it
00:15:25  <tjfontaine>that doesn't mean we haven't gotten it wrong in the past
00:15:32  <tjfontaine>in subtle ways
00:15:46  <mmalecki>yeah, I saw those, they are pretty impressive really
00:16:02  <tjfontaine>and there are people using node and url.parse in important ways that do require stability in the behavior
00:16:45  <MI6>nodejs-v0.10: #1683 UNSTABLE linux-x64 (5/606) osx-x64 (1/606) linux-ia32 (6/606) smartos-x64 (8/606) smartos-ia32 (7/606) osx-ia32 (1/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1683/
00:16:51  <MI6>nodejs-v0.10-windows: #407 UNSTABLE windows-x64 (11/606) windows-ia32 (12/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/407/
00:17:50  <trevnorris>tjfontaine: ping
00:17:58  <othiym23>TIL that Marak is apparently a "Node.js sensei"
00:17:58  <tjfontaine>trevnorris: pong
00:18:08  <othiym23>I like to think of myself more as an advanced Node.js padawan
00:18:19  <othiym23>or maybe, you know, somebody who uses Node to get his job done
00:18:42  <tjfontaine>that's how I view myself
00:19:14  <trevnorris>tjfontaine: forgot whether I talked to you about this, but I noticed that node is cheating the event loop.
00:19:21  <tjfontaine>define "cheat"
00:19:32  <tjfontaine>I hope you mean "nextTick" :P
00:19:35  <trevnorris>tjfontaine: for example. when we run Server#close() the callback should be run in the uv__run_closing_handles() phase of the eloop.
00:19:57  <trevnorris>but instead it's queued. and even if the callback were queued via setImmediate, it would still fire in the "technical" wrong order
00:19:57  <tjfontaine>trevnorris: node should not be calling anything with two _'s in it
00:20:13  <tjfontaine>heh
00:20:18  <trevnorris>what are you talking about? everything runs in a phase that has two __ in it.
00:20:31  <tjfontaine>it was a silly joke, anyway
00:21:01  <MI6>nodejs-master: #810 UNSTABLE smartos-x64 (10/687) smartos-ia32 (7/687) osx-ia32 (2/687) centos-ia32 (2/687) ubuntu-ia32 (1/687) centos-x64 (3/687) http://jenkins.nodejs.org/job/nodejs-master/810/
00:21:15  <tjfontaine>trevnorris: can you be more explicit about what you're talking about?
00:21:50  <trevnorris>when you run Server#close() it then queues up an emit() in nextTick (but that's implementation detail)
00:22:10  <trevnorris>when the emit should happen until the run_closing_handles() has finished running
00:22:23  <tjfontaine>should it?
00:22:36  <trevnorris>so right now we "close" the handle and remove the js reference, but it still exists until the eloop ends.
00:23:38  <trevnorris>tjfontaine: the kicker is, even if we setImmediate the callback, those calbacks run _before_ run_closing_handles(), so it still wouldn't be closed at that point.
00:23:40  <tjfontaine>define: 'it', the libuv uv_handle_t?
00:24:08  <trevnorris>yeah. the uv_handle_t
00:24:09  <tjfontaine>I'm not sure where the cheating is happening, and where that might be causing problems
00:24:55  <tjfontaine>indutny: if you give me the high sign on libuv v0.11 I will do a release of it and therefore node tonight
00:25:22  * rmgjoined
00:25:42  <trevnorris>Server#close() basically just does server._handle.close(), then server._handle = null;
00:26:27  <trevnorris> server._handle.close() accepts a callback, but instead we're emitting the "close" event sooner than uv's had time to properly close the uv_handle_t
00:26:32  <tjfontaine>trevnorris: yes, we've signalled our intent, the event emission in this case is ours and not something to be delivered from libuv
00:27:06  <trevnorris>that doesn't make sense to me. imo we shouldn't emit "close" until uv has signaled back that the uv_handle_t has in fact been closed.
00:27:07  <tjfontaine>trevnorris: so yes, since we know the intent at this point we can emit the event sooner than when libuv has closed it
00:28:24  <tjfontaine>trevnorris: both are valid to me, it is not unreasonable to simplify the code paths, but it also makes sense to signal as soon as we know it's ok to do so
00:28:50  <trevnorris>and for me it's only ok to do so when the layer under us has given the ok.
00:29:43  * rmgquit (Ping timeout: 245 seconds)
00:30:11  <trevnorris>thought experiment. i create a Server instance, then close it in the nextTick, then create a new one in the close callback. since the callback is nextTick and we create a new one then memory is going to fill up with a bunch of uv_handle_t's hanging around.
00:30:23  <trevnorris>though, again, just a thought experiment.
00:31:00  <tjfontaine>create a bunch of things and there will be a bunch of a lot of things hanging around :)
00:31:32  <trevnorris>unless the callback was called when uv gave the all clear, then there'd only be one created at a time.
00:31:55  <trevnorris>sorry, just don't like implicit order of operations. like it more when things run when the code makes it look like it should run.
00:32:16  <tjfontaine>anyway, if changing the code to be more simple is a bonus, and if that's not changing ordering semantics for consumers and/or adding performance overhead because now they're waiting a more indefinite amount of time for that event -- we should explore it
00:32:25  <tjfontaine>it's not implicit, in fact it's very explicit :)
00:33:02  <trevnorris>when I read the code in uv_run and saw run_closing_handles() I first thought, oh, that's when all the Server#close() callbacks are called.
00:33:07  <trevnorris>but that isn't the case.
00:33:27  <tjfontaine>that's the case when something externally may have closed the socket
00:33:40  <tjfontaine>if it supplied the callback
00:33:53  <trevnorris>how do you mean?
00:34:45  <tjfontaine>I just mean, someone/thing using libuv may decide to operate with that mechanism
00:34:57  * spionpart ("Leaving")
00:35:28  <tjfontaine>I'm not sure it's necessary for node to do it, as .close in this case has been called by user code
00:35:51  <tjfontaine>there's no reason to necessarily wait for notification from the platform that the socket has indeed been closed
00:36:31  <octetcloud>@tjfontaine: if I address the small format nits on #6727, and remove the incomplete change ("a normal disconnect should not error"), can I get this in tonight? if so, I'll do it tomorrow
00:36:59  * wolfeidauquit (Ping timeout: 240 seconds)
00:37:02  <tjfontaine>octetcloud: yup, I think that's doable
00:37:15  <tjfontaine>octetcloud: I absolutely want to get the fixes and the new tests in
00:37:36  <octetcloud>ok. will do right away, it means rebasing away one commit, so some comments kindof dissappear, that's ok?
00:37:50  <tjfontaine>yup, I can recover them from email
00:40:38  * wolfeidaujoined
00:42:09  <octetcloud>ok, and will libuv get updated? or has it? I don't see the uv version that fixes node #6749 (an assert) in v0.10 of node, or is it only 0.11 going out?
00:42:27  <tjfontaine>libuv will be updated, I do a release of libuv and upgrade before every node release
00:43:57  <octetcloud>great, thanks.
00:44:31  * kazuponjoined
00:44:39  <tjfontaine>octetcloud: fwiw that fix went in v0.10 of libuv, and then bert merged v0.10 into master
00:44:55  <tjfontaine>octetcloud: https://github.com/joyent/libuv/commit/140c863ff096a7998fb5528480fc7eccfd837165
00:45:23  <tjfontaine>or rather it should have ...
00:45:51  <tjfontaine>ah it was https://github.com/joyent/libuv/commit/46a06021415009e0e2918966b926d20bc6f0422c
00:45:54  <tjfontaine>anyway
00:49:45  * kazuponquit (Ping timeout: 272 seconds)
00:54:31  * stagasjoined
00:57:54  <groundwater>any gurus here know how to grab a stack trace out of a "RangeError: Maximum call stack size exceeded"
01:03:18  <tjfontaine>--abort-on-uncaught-exception
01:06:50  <groundwater>tjfontaine: thanks!
01:10:27  * indexzeroquit (Quit: indexzero)
01:21:46  <groundwater>tjfontaine: looks like something is catching the exception
01:22:03  <groundwater>i'm at maximum levels of inception here, i don't even wanna describe it
01:22:45  * mikealquit (Quit: Leaving.)
01:23:47  * thlorenzjoined
01:25:24  <trevnorris>groundwater: have a script that replicates this?
01:25:43  <tjfontaine>I think ...
01:26:13  <tjfontaine>isn't RangeError supposed to be a FatalError? a fixed node should handle that
01:26:38  <othiym23>Phusion Passenger may or may not be in the mix here, and may or may not have its own ideas about how Node things want to be done
01:26:39  <othiym23>allegedly
01:26:41  <othiym23>perhaps
01:26:42  <tjfontaine>hmm no I guess not
01:26:45  <groundwater>i'm trying to figure out why an app being run through Passenger throws a fit combined with a certain express body parser, and the NR agent
01:27:00  <tjfontaine>you poor fucking souls
01:27:23  <groundwater>ruby, c, and node are all in the mix here
01:27:30  <othiym23>we're not using it, we're just trying to keep it from fuckin' up the program for our users
01:27:36  <tjfontaine>are you able to do this on smartos such that we can play dtrace fun games?
01:27:48  <tjfontaine>othiym23: ya, I know -- that's why I feel for you
01:27:59  * hzquit
01:28:14  <groundwater>passenger needs to be compiled, and i'm trying to avoid that rabbit hole
01:28:24  <tjfontaine>I see
01:28:25  <groundwater>but it may be the path of least resistance at htis point
01:28:58  <tjfontaine>because you may be able to use the pid provider to grab the Error creation and jstack()
01:29:26  <groundwater>i'm gonna try a few more hacks, then jump to that
01:32:26  * stagasquit (Read error: Connection reset by peer)
01:33:08  * stagasjoined
01:40:21  <octetcloud>@tjfontaine: #6727 isn't going to happen tonight, test-debug-signal-cluster.js is intermittently failing, I'll need to bisect back to see what I did. it'll have to be next round. sorry.
01:41:27  * st_lukejoined
01:45:17  * kazuponjoined
01:50:47  <tjfontaine>octetcloud: that's ok, no worries
01:54:24  <isaacs>tjfontaine: wb!
01:55:52  <tjfontaine>thanks!
01:59:29  * mikealjoined
02:18:12  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:19:03  * kazuponquit (Ping timeout: 272 seconds)
02:19:22  * inolenquit (Quit: Leaving.)
02:20:23  * sdeathjoined
02:27:34  * mikealquit (Quit: Leaving.)
02:28:49  * TooTallNatejoined
02:29:01  * sdeathquit (Remote host closed the connection)
02:41:37  * st_lukequit (Remote host closed the connection)
02:43:13  * st_lukejoined
02:57:34  * st_lukequit (Remote host closed the connection)
02:59:53  * ladymurrjoined
03:00:23  * st_lukejoined
03:03:01  * stagasquit (Ping timeout: 248 seconds)
03:04:00  * st_luke_joined
03:04:38  * st_lukequit (Ping timeout: 240 seconds)
03:06:21  * inolenjoined
03:08:14  * st_luke_quit (Ping timeout: 240 seconds)
03:15:19  * calvinfoquit (Quit: Leaving.)
03:15:22  * kazuponjoined
03:20:04  * kazuponquit (Ping timeout: 246 seconds)
03:32:29  * felicityquit (Quit: ircII EPIC5-1.1.5 -- Accept specific limitations on /who.)
03:35:55  * felicityjoined
03:36:47  * st_lukejoined
03:42:23  * st_lukequit (Ping timeout: 272 seconds)
03:48:03  * AlexisMochaquit (Ping timeout: 260 seconds)
04:06:08  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:10:43  * mikealjoined
04:16:06  * calvinfojoined
04:16:23  * kazuponjoined
04:20:33  * calvinfoquit (Ping timeout: 245 seconds)
04:20:56  * ladymurrquit (Remote host closed the connection)
04:20:58  * kazuponquit (Ping timeout: 246 seconds)
04:23:19  * AlexisMochajoined
04:24:27  * mikeal1joined
04:27:37  * mikealquit (Ping timeout: 272 seconds)
04:28:58  * abraxasjoined
04:33:26  * abraxasquit (Ping timeout: 240 seconds)
04:34:13  * rnowak_quit (Ping timeout: 272 seconds)
04:34:41  * rnowakjoined
04:45:53  * calvinfojoined
04:55:55  * mikeal1quit (Quit: Leaving.)
05:00:04  * st_lukejoined
05:02:19  <thlorenz>got like 70% of the libuv book examples adapted to the latest API I think its only about 5 more to go https://github.com/thlorenz/libuv-dox/tree/master/examples
05:07:23  * AlexisMochaquit (Ping timeout: 252 seconds)
05:09:35  * rmgjoined
05:11:22  * defunctzombiechanged nick to defunctzombie_zz
05:14:15  * rmgquit (Ping timeout: 252 seconds)
05:16:16  * calvinfoquit (Quit: Leaving.)
05:17:17  * kazuponjoined
05:23:49  * kazuponquit (Ping timeout: 248 seconds)
05:23:53  * calvinfojoined
05:29:49  * st_lukequit (Remote host closed the connection)
05:32:02  * thlorenzquit (Remote host closed the connection)
05:36:51  * calvinfopart
05:43:21  * m76joined
05:46:55  * stagasjoined
06:17:13  * octetcloudquit (Ping timeout: 245 seconds)
06:19:46  * kazuponjoined
06:22:56  * mikealjoined
06:24:37  * kazuponquit (Ping timeout: 248 seconds)
06:41:14  <MI6>nodejs-v0.10-windows: #408 UNSTABLE windows-x64 (11/606) windows-ia32 (11/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/408/
06:48:27  * zz_karupanerurachanged nick to karupanerura
07:03:20  * M28quit (Read error: Connection reset by peer)
07:03:25  * M28_joined
07:21:12  * kazuponjoined
07:21:19  * vptrquit (Ping timeout: 260 seconds)
07:25:57  * kazuponquit (Ping timeout: 246 seconds)
07:43:07  * hallsyjoined
07:45:17  * AvianFluquit (Remote host closed the connection)
07:45:23  * hallsyquit (Client Quit)
07:45:53  * hallsyjoined
07:45:58  <hallsy>Hi. Am I right in thinking uv__inotify_read won't pass on IN_Q_OVERFLOW ?
07:55:43  * brsonquit (Quit: leaving)
07:58:51  * M28_changed nick to M28
08:16:16  * m76quit (Read error: Connection reset by peer)
08:16:44  * m76joined
08:19:06  * rendarjoined
08:22:14  * `3E|GONEchanged nick to `3rdEden
08:22:17  * kazuponjoined
08:27:18  * kazuponquit (Ping timeout: 252 seconds)
08:35:20  * calvinfojoined
08:47:11  * hallsyquit (Quit: Page closed)
08:59:53  * AlexisMochajoined
09:08:13  * calvinfoquit (Quit: Leaving.)
09:18:27  * stagasquit (Ping timeout: 260 seconds)
09:23:24  * kazuponjoined
09:28:21  * kazuponquit (Ping timeout: 252 seconds)
09:43:51  <indutny>heya
09:44:40  <mmalecki>ahoy!
09:46:46  <indutny>ohai
09:46:47  <MI6>joyent/node: Benjamin Waters master * 58d6ca3 : doc: Fix doc heading for 'response' event - http://git.io/RmVlTg
09:46:48  <indutny>how are you?
09:51:27  * rmgjoined
09:52:15  * hzjoined
09:56:21  * rmgquit (Ping timeout: 248 seconds)
09:58:03  <mmalecki>I'm good! writing monitoring tool for haproxy
09:58:09  <mmalecki>how are you Fedor?
10:00:51  <MI6>nodejs-master: #811 UNSTABLE smartos-x64 (8/687) smartos-ia32 (6/687) centos-ia32 (2/687) ubuntu-x64 (2/687) ubuntu-ia32 (1/687) centos-x64 (1/687) http://jenkins.nodejs.org/job/nodejs-master/811/
10:11:29  * timoxleyjoined
10:17:47  <indutny>mmalecki: nice :)
10:17:51  <indutny>I'm good too
10:17:57  <indutny>preparing for a new year celebrations
10:18:01  <indutny>and triaging some git issues
10:18:06  <indutny>s/git/githu
10:18:17  <mmalecki>same! I'm making chocolate truffles for the party
10:20:53  <indutny>haha
10:20:54  <indutny>cool
10:24:17  * kazuponjoined
10:29:08  * kazuponquit (Ping timeout: 252 seconds)
10:32:09  * inolenquit (Ping timeout: 246 seconds)
10:32:25  * insertcoffeejoined
10:36:08  * inolenjoined
10:43:17  * insertcoffeequit (Ping timeout: 240 seconds)
10:51:11  <MI6>nodejs-v0.10: #1684 UNSTABLE linux-x64 (2/606) osx-x64 (2/606) linux-ia32 (2/606) smartos-x64 (6/606) smartos-ia32 (6/606) osx-ia32 (2/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1684/
11:08:04  * insertcoffeejoined
11:09:52  * insertcoffeequit (Max SendQ exceeded)
11:11:02  * insertcoffeejoined
11:11:13  * insertcoffeequit (Read error: Connection reset by peer)
11:19:16  * inolenquit (Quit: Leaving.)
11:19:38  * inolenjoined
11:20:10  * inolen1joined
11:20:11  * inolenquit (Read error: Connection reset by peer)
11:25:15  * inolen1quit (Ping timeout: 272 seconds)
11:25:19  * kazuponjoined
11:29:59  * kazuponquit (Ping timeout: 240 seconds)
11:46:19  * Chip_Zeroquit (Changing host)
11:46:20  * Chip_Zerojoined
11:58:00  * timoxleyquit (Ping timeout: 240 seconds)
11:58:14  * timoxleyjoined
12:03:52  * karupanerurachanged nick to zz_karupanerura
12:14:23  * timoxleyquit (Remote host closed the connection)
12:26:22  * kazuponjoined
12:28:44  * bajtosjoined
12:30:57  * kazuponquit (Ping timeout: 252 seconds)
12:51:59  * bajtosquit (Quit: bajtos)
13:04:34  * timoxleyjoined
13:08:01  * daviddiasjoined
13:20:46  * m76quit (Read error: Connection reset by peer)
13:27:21  * kazuponjoined
13:32:17  * kazuponquit (Ping timeout: 252 seconds)
14:06:30  * timoxley_joined
14:07:38  * kazuponjoined
14:09:23  * timoxleyquit (Ping timeout: 272 seconds)
14:14:08  * timoxley_quit (Remote host closed the connection)
14:14:44  * timoxleyjoined
14:17:21  * bajtosjoined
14:19:18  * timoxleyquit (Ping timeout: 245 seconds)
14:21:49  * kazuponquit (Remote host closed the connection)
14:29:32  * mikealquit (*.net *.split)
14:29:32  * petka_quit (*.net *.split)
14:35:09  * mikealjoined
14:35:09  * petka_joined
14:40:54  * pachetjoined
14:40:54  * pachetquit (Changing host)
14:40:54  * pachetjoined
14:44:18  * thlorenzjoined
14:54:03  * hueniversequit (Ping timeout: 252 seconds)
15:11:59  * piscisaureusjoined
15:12:38  * m76joined
15:15:35  * defunctzombie_zzchanged nick to defunctzombie
15:21:36  <MI6>nodejs-master: #812 UNSTABLE smartos-x64 (7/687) smartos-ia32 (6/687) centos-ia32 (3/687) ubuntu-x64 (2/687) ubuntu-ia32 (2/687) centos-x64 (2/687) http://jenkins.nodejs.org/job/nodejs-master/812/
15:22:38  * kazuponjoined
15:22:56  * thlorenzquit (Remote host closed the connection)
15:26:09  * vptrjoined
15:29:09  * kazuponquit (Ping timeout: 248 seconds)
15:30:00  * bajtosquit (Quit: bajtos)
15:31:20  * bajtosjoined
15:34:38  * timoxleyjoined
15:45:44  * bajtosquit (Read error: Connection reset by peer)
15:46:40  * potaninjoined
15:48:51  * piscisaureusquit (Read error: Connection reset by peer)
15:49:38  * piscisaureusjoined
15:50:08  * thlorenzjoined
16:01:42  * potaninquit (K-Lined)
16:11:27  * swajrjoined
16:12:27  * M28_joined
16:13:32  * [m76]joined
16:13:34  * AvianFlujoined
16:20:03  * [m76]quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
16:20:27  * [m76]joined
16:20:56  * [m76]quit (Client Quit)
16:21:16  * [m76]joined
16:21:27  * [m76]quit (Client Quit)
16:21:50  * [m76]joined
16:22:16  * hueniversejoined
16:23:06  * swajquit (Ping timeout: 240 seconds)
16:23:06  * m76quit (Ping timeout: 240 seconds)
16:23:47  * M28quit (Quit: No Ping reply in 180 seconds.)
16:25:09  * kazuponjoined
16:25:14  * [m76]quit (Client Quit)
16:30:07  * kazuponquit (Ping timeout: 260 seconds)
16:53:30  * timoxleyquit (Remote host closed the connection)
17:08:18  * kazuponjoined
17:09:29  <tjfontaine>good morning node folk
17:13:19  * kazuponquit (Ping timeout: 272 seconds)
17:14:16  <tjfontaine>indutny: all good for me to do libuv v0.11 release?
17:18:15  * M28_changed nick to M28
17:29:53  * mikealquit (Quit: Leaving.)
17:32:18  * octetcloudjoined
17:36:30  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:38:55  * calvinfojoined
17:42:26  <tjfontaine>octetcloud: morning
17:43:19  <octetcloud>morning, tj
17:43:24  <tjfontaine>how's things?
17:44:13  <octetcloud>ok, just cleaning my email. saw your comments. haven't had time to look yet. are you waiting?
17:44:23  <tjfontaine>not on you, no
17:44:39  <octetcloud>good, I hate being on critical paths!
17:44:48  <tjfontaine>I'll let you know if you ever are :)
17:53:51  <MI6>libuv-master: #411 UNSTABLE windows (4/202) osx (1/204) smartos (3/203) http://jenkins.nodejs.org/job/libuv-master/411/
17:53:56  <octetcloud>Do unstable releases always get cut at same time as stable? Just wondering, seems like they do, but its not clear to me what release criteria isfor the master.
17:54:49  <tjfontaine>we dont' have one, I'm not planning on doing another stable until next week
17:54:53  <tjfontaine>though
17:55:11  <tjfontaine>generally if I'm in the sequence of doing a release it's just as easy to do both
17:55:52  <octetcloud>ok, and I guess goal for master is to be bug-free (hopefully), though feature IN-complete?
17:56:48  <tjfontaine>the release criteria for unstables is generally "how long since the last? (HOLY SHIT IT'S BEEN A WHILE)" or "oh wow that was a big feature that landed we should get people testing it ASAP"
17:57:02  <tjfontaine>but my overall goal is to be much more predictable in releases
17:57:13  <tjfontaine>of both stables and unstables
17:57:37  <tjfontaine>like make every Monday a release day, and then alternate between stable and unstable
17:57:49  <tjfontaine>if there are commits in a branch that warrant a release
18:07:55  * calvinfoquit (Quit: Leaving.)
18:09:11  * kazuponjoined
18:11:11  * TooTallNatejoined
18:14:16  * mikealjoined
18:14:18  * kazuponquit (Ping timeout: 245 seconds)
18:14:27  <MI6>libuv-node-integration: #366 UNSTABLE linux-x64 (2/687) smartos-ia32 (5/687) linux-ia32 (2/687) smartos-x64 (7/687) http://jenkins.nodejs.org/job/libuv-node-integration/366/
18:18:02  <indutny>tjfontaine: hm...
18:18:03  <indutny>tjfontaine: heya
18:18:11  <tjfontaine>hey
18:18:15  <indutny>I think I have few prs to land
18:18:19  <tjfontaine>for libuv?
18:18:21  <indutny>oh
18:18:23  <indutny>actually
18:18:25  <indutny>they all landed, I think
18:18:27  <indutny>let me check
18:18:29  <tjfontaine>ok
18:18:40  <tjfontaine>I'm goign to land this EACCESS cluster fix I think
18:18:52  <tjfontaine>squashed and reworded the commit to:
18:18:57  <tjfontaine> cluster: report more errors to workers
18:18:57  <tjfontaine> Some errors for listening and binding to a socket were not properly
18:18:57  <tjfontaine> delivered to workers.
18:19:57  <indutny>ok
18:19:58  <indutny>great
18:20:11  <indutny>ok, I think everything has landed in libuv
18:20:13  <indutny>let's do a release
18:20:17  <tjfontaine>sounds good
18:21:56  <indutny>yeah :P
18:22:07  <indutny>I'll open a uv_try_write PR for node
18:22:43  <MI6>joyent/node: Fedor Indutny v0.10 * 3e9f2e6 : cluster: report more errors to workers - http://git.io/015mAA
18:22:48  <indutny>yay!
18:22:52  <indutny>tjfontaine: thank you
18:23:29  <tjfontaine>thank you!
18:24:10  * mikealquit (Quit: Leaving.)
18:27:59  <MI6>joyent/libuv: tjfontaine created tag v0.11.17 - http://git.io/lVGVdQ
18:28:01  <MI6>joyent/libuv: Timothy J Fontaine master * 4ce9c39 : Now working on v0.11.18 (+1 more commits) - http://git.io/pBTimQ
18:28:25  * mikealjoined
18:31:07  * AvianFluquit (Remote host closed the connection)
18:31:28  <MI6>libuv-review: #109 FAILURE http://jenkins.nodejs.org/job/libuv-review/109/
18:32:28  <octetcloud>@indutny: test-cluster-eaccess.js, not supported on windows because bug exists? or because listen fails differently? on windows, .listen('some-socket') will fail, too, but with error EACCES
18:33:17  <tjfontaine>well, it is technically EADDRINUSE, but I will log in and see what the actual failure will be, but I have a feeling it'll be reported on the master not the worker
18:33:18  <octetcloud>so I think minor tweak to assert will make test work on windows, but I don't have windows node build env to confirm, sorry
18:34:47  <MI6>joyent/node: Timothy J Fontaine master * 8590f81 : uv: Upgrade to v0.11.17 - http://git.io/zLWpiA
18:36:13  <octetcloud>tj: what do you mean? I just checked. Its EACCES for the path that the test is using (because the path doesn't start with //./pipe/)
18:36:47  <tjfontaine>oh, interseting, I mean it's EADDRINUSE in the way he's doing it at the moment for unicies I meant
18:36:53  <MI6>libuv-master: #412 UNSTABLE windows (6/202) smartos (3/203) http://jenkins.nodejs.org/job/libuv-master/412/
18:38:29  * kazuponjoined
18:38:35  <octetcloud>right, yes. if you want to get EADDRINUSE, you can, but have to constuct a valid path, like //./pipe/some-name, and then the second listen on it will cause EADDRINUSE. maybe i'll try. it might be necessary to evade cluster... because its purpose in life is to allow multiple listens on the same "address"
18:38:47  * mikealquit (Quit: Leaving.)
18:39:09  <tjfontaine>well I'm fine with just using a different regex on windows
18:39:40  <tjfontaine>building now on the windows scratch vm just to do the verification of the assumptions
18:40:30  * brsonjoined
18:42:10  <MI6>libuv-master-gyp: #364 UNSTABLE windows-x64 (4/202) osx-x64 (1/204) smartos-ia32 (3/203) smartos-x64 (4/203) windows-ia32 (4/202) linux-ia32 (1/203) osx-ia32 (1/204) http://jenkins.nodejs.org/job/libuv-master-gyp/364/
18:42:33  <MI6>nodejs-v0.10: #1685 UNSTABLE linux-x64 (5/607) osx-x64 (2/607) linux-ia32 (5/607) smartos-x64 (7/607) smartos-ia32 (7/607) osx-ia32 (3/607) http://jenkins.nodejs.org/job/nodejs-v0.10/1685/
18:43:05  <MI6>nodejs-v0.10-windows: #409 UNSTABLE windows-x64 (10/607) windows-ia32 (11/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/409/
18:43:53  * kazuponquit (Ping timeout: 272 seconds)
18:45:06  <trevnorris>morning
18:45:16  <tjfontaine>octetcloud: well, actually it's working fine as is without changing the regex
18:45:31  <tjfontaine>trevnorris: morning
18:45:36  <trevnorris>are calls on thurs now?
18:45:42  * AvianFlujoined
18:46:28  <tjfontaine>trevnorris: lemme do one of those calendar things and get us to coordinate on a time that works for us, since it's a new year and all
18:46:44  <trevnorris>coolio
18:46:46  * calvinfojoined
18:49:04  <tjfontaine>octetcloud: I'm still getting orphaned workers, /Users/tjfontaine/Development/node/out/Release/node --debug=13683 /Users/tjfontaine/Development/node/test/fixtures/clustered-server/app.js
18:49:12  <trevnorris>tjfontaine: so I almost have the close callback thing working, except for the fact that cluster jacks with _handle.close() and overrides it with some other method.
18:50:39  <tjfontaine>trevnorris: ok
18:53:10  * thlorenzquit (Remote host closed the connection)
18:54:45  * stagasjoined
18:54:45  <tjfontaine>man I don't get the test runner
18:55:03  <tjfontaine>oh I see
18:55:09  <tjfontaine>hmm
18:55:51  <tjfontaine>oh right ok ...
18:56:28  <tjfontaine>bad tj
18:56:41  <octetcloud>@tjfontaine: how are you killing the master?
18:57:03  <tjfontaine>octetcloud: in which case?
18:57:40  <octetcloud>you have orphan workers. so workers outlived master. so master died... what made it die? app doesn't exit on its own, it needs to be killed (now)
18:57:57  * mikealjoined
18:58:33  <tjfontaine>octetcloud: I'm just running make test
18:58:53  <tjfontaine>but it was ...
18:59:00  <tjfontaine>Command: out/Release/node /Users/tjfontaine/Development/node/test/simple/test-debug-port-cluster.js
18:59:03  <tjfontaine>that timedout
18:59:06  <tjfontaine>and resulted in orphans
18:59:14  <indutny>oh gosh
18:59:26  <octetcloud>@tjfontaine: oh, sorry, you pasted a command line, i was trying that, I'll try that last one
18:59:40  <tjfontaine>indutny: the test is broken ;)
19:00:56  * thlorenzjoined
19:01:07  <tjfontaine>brb
19:03:31  <octetcloud>@tjfontaine: oh, that, too. right, it never exits. Same change I made to test-debug-cluster.js needs to be made to it. I will do.
19:04:01  * thlorenzquit (Remote host closed the connection)
19:07:57  <MI6>nodejs-master: #813 UNSTABLE smartos-x64 (9/687) smartos-ia32 (5/687) osx-ia32 (1/687) osx-x64 (3/687) centos-ia32 (2/687) ubuntu-x64 (3/687) centos-x64 (6/687) http://jenkins.nodejs.org/job/nodejs-master/813/
19:13:48  <trevnorris>othiym23: ping
19:25:33  <MI6>libuv-node-integration: #367 UNSTABLE linux-x64 (2/687) smartos-ia32 (9/687) osx-x64 (2/687) linux-ia32 (3/687) smartos-x64 (9/687) http://jenkins.nodejs.org/job/libuv-node-integration/367/
19:27:47  * calvinfopart
19:28:20  * mikealquit (Quit: Leaving.)
19:28:39  * daviddiasquit (Remote host closed the connection)
19:30:32  <othiym23>trevnorris: pong
19:33:48  <trevnorris>othiym23: say I create an EE observer with "create" callbacks (i.e. callbacks that are run when the EE is instantiated). and say I "attach" (i.e. add an observer after the EE was instantiated). you think the "create" callbacks should be run at that time against the EE instance?
19:35:46  <trevnorris>othiym23: basically, the EE was already instantiated, but since the observer is being attached after the fact, should the create callback be run against the instance regardless?
19:38:30  <othiym23>trevnorris: I'm having a tough time imagining a use case for the create callback for an EE
19:38:56  <trevnorris>othiym23: domains need them. it sets the "domain" object property on the EE instance when created.
19:38:58  <othiym23>trevnorris: whereas all my use cases revolve around observing on / addListener and emit
19:39:02  <othiym23>aha
19:39:28  * kazuponjoined
19:39:43  <groundwater>*sigh* domains
19:39:55  <trevnorris>yeah. no kidding. :P
19:39:55  <groundwater>othiym23: you're the domain guy! you should have known that :p
19:40:31  <othiym23>trevnorris: so if you're supporting implicit binding of EEs to domains (i.e. the current state of play), you don't need to retroactively fire the create observer, I don't think
19:40:50  <trevnorris>othiym23: cool. thanks
19:40:57  <othiym23>trevnorris: at best you get slightly DRYer code, but at worst you're conflating two different stages of the EE lifecycle unnecessarily
19:44:18  * kazuponquit (Ping timeout: 245 seconds)
19:53:07  <trevnorris>othiym23: should I assume that if I have an api to attach an observer to and EE instance then I should also allow to "detach" it as well?
19:53:46  <othiym23>trevnorris: probably
19:53:57  <tjfontaine>indutny, octetcloud: new and improved (and working) test case for EACCES :)
19:54:05  <othiym23>trevnorris: domains only allow an EE to be attached to a single domain
19:54:13  <othiym23>trevnorris: CLS supports binding EEs to multiple CLS contexts
19:54:26  <trevnorris>yeah
19:54:43  <othiym23>trevnorris: so the general way to support that is to support both add and remove
19:54:54  <trevnorris>i'm focusing on the ee observer thing right now because it's case is much simpler than async listeners. so it's helping me figure out a few bugs.
19:57:56  <trevnorris>othiym23: last one. should I allow users to attach the same observer twice to the same ee instance? or instead just not add it if already found on the instance?
19:58:33  * mikealjoined
20:01:07  <MI6>joyent/node: Timothy J Fontaine v0.10 * 6f8aa24 : test: fix test-cluster-eaccess to work on windows - http://git.io/Def-jQ
20:02:24  <tjfontaine>octetcloud: things look good with your PR, but I need to go around and clean up the orphans on the jenkins slaves, once I get a green light from there I'll land it, YAY
20:05:29  <othiym23>trevnorris: I think generality dictates that you should allow the same observer be added multiple times, as long as it's possible for the caller to verify ahead of time whether or not a given observer has been added (i.e. something like .listeners() for EE observers)
20:07:18  * AvianFluquit (Remote host closed the connection)
20:10:12  <trevnorris>othiym23: two options, either I allow each set of the same callbacks to be run multiple times, or I keep a ref counter and still only execute the callbacks once.
20:10:13  * thlorenzjoined
20:11:06  * inolenjoined
20:13:10  <othiym23>trevnorris: KISS -- each set of the same callbacks can be run multiple times
20:13:12  <othiym23>IMHO
20:15:17  <trevnorris>othiym23: currently I am storing the "storage" value in a separate sparse array that is accessed by the observers uid (it's shown the best performance yet), so currently it's easy to just remove the observer and it's associated storage cell.
20:15:49  <trevnorris>othiym23: but if multiple of the same observer can be added then I'll have to run through the queue and see if that cell needs to be repopulated.
20:17:08  <trevnorris>wait, nm.
20:17:23  <MI6>nodejs-v0.10: #1686 UNSTABLE linux-x64 (4/607) osx-x64 (1/607) linux-ia32 (2/607) smartos-x64 (7/607) smartos-ia32 (8/607) osx-ia32 (1/607) http://jenkins.nodejs.org/job/nodejs-v0.10/1686/
20:17:38  <trevnorris>ok, and i'll just make the note that the run order of observers is always non-deterministic.
20:17:43  <MI6>nodejs-v0.10-windows: #410 UNSTABLE windows-x64 (11/607) windows-ia32 (11/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/410/
20:19:25  * daviddiasjoined
20:22:18  <trevnorris>groundwater: whenever you have time, mind looking over https://github.com/joyent/node/pull/6502 ?
20:23:35  * daviddiasquit (Ping timeout: 240 seconds)
20:25:12  <groundwater>trevnorris: sure thing
20:25:18  <trevnorris>thanks
20:25:19  <groundwater>which PR again?
20:33:51  <trevnorris>groundwater: https://github.com/joyent/node/pull/6502
20:34:21  * AlexisMochaquit (Ping timeout: 272 seconds)
20:40:30  * kazuponjoined
20:41:50  * bajtosjoined
20:43:27  * mikealquit (Quit: Leaving.)
20:46:08  * kazuponquit (Ping timeout: 265 seconds)
20:47:14  <trevnorris>othiym23: fwiw, currently the API is adding < 30ns per instantiation and emit.
20:47:16  * AvianFlujoined
20:47:28  <trevnorris>when in use, and nothing when not used.
20:50:57  <trevnorris>othiym23/ groundwater: what info do you want on add? like, the event name, the callback, context, anything else?
20:51:24  <groundwater>i'm gonna try it out, i just built the branch
20:51:31  <groundwater>trevnorris: give me a bit
20:51:43  <trevnorris>groundwater: ok, the add/remove aren't implemented yet. working on that now.
20:51:55  <groundwater>ahah okay
20:52:00  <trevnorris>tjfontaine: I vote we get rid of the EE leak warning. it's just annoying.
20:52:27  <trevnorris>groundwater: but the before/after do work, and there's the events.attachObserver() so you can attach to an existing ee instance.
20:52:44  <groundwater>wow, i'm sitting at a cafe, and someone just opened the fridge to get a drink, then just walked away. made no effort to even try closing the door...
20:55:04  * bajtosquit (Quit: bajtos)
20:57:01  <trevnorris>groundwater: just added the add observer support. working on remove now.
21:00:39  <groundwater>trevnorris: i may have missed or overlooked this discussion, but why is there a "createobserver" call?
21:00:49  <groundwater>can't i just pass in an object that implements before/after/error/create
21:01:01  <groundwater>is that an optimization?
21:02:05  <trevnorris>groundwater: you can. the EE.createObserver() creates and returns the observer. EE.addObserver() will create it and add it to the active observers so any EE instantiated during that time will be captured.
21:02:32  <trevnorris>so EE.addObserver() can take the same arguments as EE.createObserver()
21:03:13  <groundwater>what functionality does createObserver give us?
21:03:27  <groundwater>it looks like a hidden-class optimization
21:03:58  <groundwater>trevnorris: ^
21:04:14  <trevnorris>it's not an optimization. its for the times you want to create on observer, but not actually make it active until some later time.
21:04:28  <groundwater>also appologies if my brain just isn't working, i'm still adjusting from a 16 hour time change
21:04:34  <trevnorris>no worries.
21:04:51  <trevnorris>this whole thing just makes my head hurt.
21:05:09  <groundwater>what's the advantage of using createObserver vs. just creating my own object that implements before/after/error/create ?
21:06:32  <trevnorris>groundwater: there's a hidden instantiator called ObserverInst() that does a lot of stuff necessary for tracking.
21:07:17  <trevnorris>so the return from createObserver doesn't return the object you passed in. it's an instance of a hidden object.
21:07:35  <groundwater>okay i'm looking at ObserverInst now
21:07:39  * AlexisMochajoined
21:07:55  <trevnorris>i can then use those for more reliable checks, and avoid some collision problems that I'm having w/ async listeners.
21:08:10  <groundwater>so, if i pass in an object to createObserver, the methods are plucked off the object right?
21:08:16  <trevnorris>yeah
21:08:19  <groundwater>but the object itself is discarded?
21:08:37  <trevnorris>it's not used internally if that's what you mean.
21:08:42  <groundwater>yah
21:09:22  <groundwater>so if i call this.xxx from my before method, it will not see the .xxx property on the object i passed in
21:09:38  <groundwater>because the method is attached to ObserverInst instead, right?
21:09:54  <groundwater>i suppose that's what .storage is for instead, correct?
21:10:00  <trevnorris>yeah
21:10:33  <trevnorris>and i'm doing storage in a new way that really simplifies all the pain I was going through.
21:10:46  <trevnorris>think of this as all my lessons learned from doing async listeners.
21:10:51  <groundwater>haha
21:12:17  <groundwater>so i recognize that there are internal properties we need to keep track of, but what do you think of delegating to the before/after/create object passed in, instead of plucking its methods
21:12:37  <groundwater>did that make sense?
21:13:15  <groundwater>function ObserverInst(obj, storage) {
21:13:15  <groundwater> this.obj = obj
21:13:28  <groundwater>then calling this.obj.before(...) elsewhere
21:14:04  <trevnorris>trust me, that leads to a world of hurt. that's how the current async listeners work and there are still edge cases biting me in the ass.
21:15:25  <trevnorris>also, believe it or not, it's not faster.
21:16:44  <trevnorris>groundwater: what are your concerns with the current implementation?
21:17:23  <groundwater>trevnorris: just principle of least surprise
21:17:50  <groundwater>if i pass in an object, expecting its methods to be called, i'd be surprised to find it not actually using that object
21:18:03  * AlexisMochaquit (Ping timeout: 272 seconds)
21:20:58  <groundwater>trevnorris: https://github.com/jacobgroundwater/node/commit/23d72ac55ca6d710cefda9717ae0d17adc628077
21:21:02  <groundwater>very rough idea
21:22:12  <trevnorris>groundwater: but what if a user decides to change the object they've passed in?
21:22:19  <trevnorris>then the entire application explodes.
21:23:57  <trevnorris>and why are you removing the "storage" argument?
21:24:12  <groundwater>trevnorris: because the object passed in serves as storage
21:24:27  <groundwater>the before/after/create methods resolve 'this' to the object you passed in
21:25:16  <trevnorris>groundwater: no no no no no .... dude. that will kill you. the "create" callback can change the "storage" value if it returns something (making the storage unique to the instance) but that creates a collision.
21:25:46  <trevnorris>so you have the same object with "storage" but every time "create" is run then the "storage" will change, for every instance that has the same object.
21:26:05  <groundwater>so, my understanding of the observer was that it was not instance unique
21:26:18  <trevnorris>it's not. the storage value is
21:26:23  <groundwater>oh..
21:26:26  <groundwater>why's that?
21:26:32  <groundwater>sorry, i missed this discussion i think
21:27:27  <groundwater>oh, i guess it's necessary to attach domains etc to the ee
21:27:29  <tjfontaine>trevnorris: the EE leak warning at the very least needs to be improved to tell us which fucking event was oversubscribed :)
21:27:46  <trevnorris>tjfontaine: ok, i think we can do the best of both. :)
21:28:04  <groundwater>trevnorris: why not attach such information to the EE itself, rather than the listener?
21:28:09  <groundwater>performance i guess
21:28:16  <groundwater>i realize we're in the hottest code path here
21:28:36  <trevnorris>sorry, not following about attaching to the listener.
21:30:04  <groundwater>storage is supposed to be unique per EE instance, is that right?
21:31:00  <groundwater>trevnorris: ^
21:31:11  <trevnorris>groundwater: can be, yes. but doesn't have to be.
21:31:45  <trevnorris>you can do an EE.addObserver(callbacks, storage); and the "storage" there will be the default unless the create callback returns something
21:31:57  <groundwater>trevnorris: and we need a storage object because we need a place to store EE stuff, like which domain its bound to?
21:32:55  <trevnorris>the separation of the callbacks object and associated storage comes from a hard lesson learned. one sec.
21:33:03  * daviddiasjoined
21:33:50  <trevnorris>groundwater: so here: https://github.com/joyent/node/blob/master/src/node.js#L307-L336
21:34:10  <trevnorris>groundwater: see how I have to check if a value was returned, then in that case I have to create a new object pointing to all the callbacks?
21:34:21  <trevnorris>so I can properly store the new storage value along side the callbacks.
21:34:29  <trevnorris>it was really stupid of me to do that.
21:35:05  <trevnorris>so now they're separated and life is much happier.
21:35:57  <MI6>joyent/node: Sam Roberts master * cb1646f : test: fix assumption of worker exit on disconnect (+4 more commits) - http://git.io/VjXl3w
21:37:41  * daviddiasquit (Ping timeout: 272 seconds)
21:38:10  <trevnorris>tjfontaine: do you know why lib/cluster.js overrides the ._handle.close() callback? overriding it like that makes debugging a serious pain.
21:39:29  <tjfontaine>trevnorris: so it can deregister itself?
21:40:37  <trevnorris>tjfontaine: the part that bothers me is that the _handle looks like a normal Server instance, but then finding out later, though lots of debugging, that the normal methods have been jacked w/.
21:40:51  <tjfontaine>trevnorris: welcome to javascript? :)
21:41:55  <trevnorris>tjfontaine: hah, yeah. and this is why I hated working on front-end. had to deal with jackwads that are always dynamically changing the code.
21:42:09  <tjfontaine>well node behaves like this all over the place
21:42:13  <tjfontaine>fwiw
21:42:25  <tjfontaine>especially the more you learn about the streams api :P
21:42:37  <trevnorris>dude. don't get me started.
21:42:42  <tjfontaine>or when people override on/emit
21:42:43  * kazuponjoined
21:42:54  <groundwater>tjfontaine: trevnorris had to deal with this today
21:43:08  <trevnorris>i fee like making those readonly properties and tell them to go sit on their thumbs.
21:43:12  <trevnorris>*feel
21:43:14  <groundwater>passenger and the node agent ended up proxying each other, and causing an infinite recursion
21:43:33  <tjfontaine>right, I mean, it's a balance to deal with this as well as you can from node core, but really it can only ever be a best effort
21:43:38  <tjfontaine>groundwater: blech
21:44:11  <trevnorris>tjfontaine: in core it should be a simple rule. you never override a prototype _method_
21:44:25  <tjfontaine>it's not really always that simple though, is it? :)
21:44:36  <groundwater>tjfontaine: i couldn't use dtrace because passenger wouldn't build on smartos, by which i mean it was more trouble than just doing a lot of "step-by-step" debugging until i noticed i was about 50 frames deep in the stack
21:44:46  <trevnorris>um, yeah. it sort of is when we control all the variables.
21:45:35  <tjfontaine>trevnorris: depends on what we're trying to do frankly, the features of the language exist for a reason though
21:45:43  <tjfontaine>groundwater: what didn't build on smartos ooc
21:45:58  <groundwater>https://github.com/phusion/passenger
21:46:01  * vptrquit (Ping timeout: 272 seconds)
21:46:12  <tjfontaine>groundwater: well, executive summary of why?
21:46:39  <groundwater>i think it hard codes, or doesn't follow conventions for finding build tools
21:46:49  <groundwater>i don't think it's smartos' fault
21:46:56  <tjfontaine>ah ok
21:46:59  <tjfontaine>trevnorris: https://github.com/joyent/node/blob/master/lib/_stream_readable.js#L662-L693
21:47:03  <trevnorris>tjfontaine: first, doesn't mean we should use all the features of the language (i'll kill the first person to submit a PR using es6 array comprehensions)
21:47:15  <tjfontaine>trevnorris: welcome to backwards compatability, we don't really control all the variables anymore
21:47:16  <groundwater>can't find gcc / can't find headers / etc
21:47:39  <tjfontaine>groundwater: ya, ok seems like something we can fix for them SomeDay(tm)
21:47:40  <groundwater>TIL: trevnorris will murder people over PRs
21:48:01  <trevnorris>heh
21:48:11  * kazuponquit (Ping timeout: 272 seconds)
21:48:16  <trevnorris>groundwater: virtually of course. :P
21:48:58  <trevnorris>tjfontaine: needing to do something like that means a lack in proper lower level (in this case the EE's) API support.
21:49:35  <tjfontaine>trevnorris: needing to do something like that is more like the sins of the father visited upon the sons
21:49:54  <trevnorris>tjfontaine: yes, i will give you that.
21:51:08  <groundwater>The Book of TJ
21:52:58  <MI6>nodejs-master: #814 UNSTABLE smartos-x64 (10/690) smartos-ia32 (6/690) osx-ia32 (1/690) centos-ia32 (1/690) ubuntu-ia32 (1/690) centos-x64 (3/690) http://jenkins.nodejs.org/job/nodejs-master/814/
21:54:00  <trevnorris>tjfontaine: but you agree w/ me then, that in a completely controlled environment patching code like that to get desired effects shouldn't be necessary?
21:54:40  <tjfontaine>trevnorris: in a completely controlled environment you probably don't need to be patching things, or at least worried if someone else has already patched something
21:54:51  <tjfontaine>but sadly for us, that's not the world we live in
21:55:39  <trevnorris>i'll concede there.
21:56:27  <MI6>joyent/node: Timothy J Fontaine master * 13de0f1 : Merge remote-tracking branch 'upstream/v0.10' (+2 more commits) - http://git.io/AO5NAg
21:59:13  <trevnorris>groundwater: ok. create/error/before/after/add/remove are all there. have fun.
21:59:22  <trevnorris>i'm going to start working on removing domains completely from EE
21:59:52  <groundwater>trevnorris: okay i'll check it out
21:59:57  <trevnorris>thanks
22:00:14  <trevnorris>tjfontaine: and i'm just assuming you'll be fine w/ this api addition. :P
22:01:09  <tjfontaine>well, I will want to review it before it lands :)
22:01:20  <trevnorris>heh, of course. :)
22:03:12  * mmunpart ("Textual IRC Client: www.textualapp.com")
22:07:10  <trevnorris>groundwater: oh, btw. since EE's are technically synchronous, i'm not doing any error handling magic. async listeners can take care of that crap.
22:07:24  <groundwater>haha
22:07:33  <groundwater>orthogonality ftw!
22:15:06  * AvianFluquit (Remote host closed the connection)
22:27:47  * rendarquit
22:30:56  <MI6>nodejs-master: #815 UNSTABLE smartos-x64 (9/691) smartos-ia32 (7/691) osx-ia32 (2/691) centos-ia32 (3/691) ubuntu-x64 (2/691) centos-x64 (4/691) http://jenkins.nodejs.org/job/nodejs-master/815/
22:31:19  <MI6>joyent/node: Tuğrul Topuz master * bddea03 : dns: add resolveSoa and 'SOA' rrtype - http://git.io/CTUrLg
22:42:24  <trevnorris>ok. now all that's left is to move EE domain error handling out and domains will be completely removed from core.
22:42:26  <trevnorris>what a blessed day.
22:42:43  <trevnorris>then, just have to spend the next 3 months getting all of hueniverse's tests to pass :P
22:42:54  <tjfontaine>well hopefully less than that
22:42:55  <tjfontaine>:)
22:43:44  * kazuponjoined
22:48:37  * kazuponquit (Ping timeout: 248 seconds)
22:49:18  <MI6>joyent/node: Timothy J Fontaine v0.10 * ffb718b : doc: clarify process on exit safe usage (+1 more commits) - http://git.io/DIHplQ
22:54:46  <MI6>joyent/node: Maciej Małecki v0.10 * 5a8de85 : doc: document that `process.send` is synchronous - http://git.io/sj6S-w
22:58:07  <MI6>joyent/node: Timothy J Fontaine master * 08c83bb : Merge remote-tracking branch 'upstream/v0.10' (+3 more commits) - http://git.io/FVWtbg
22:58:11  <tjfontaine>ok
22:58:16  <tjfontaine>oh, v8 upgrade check
23:04:57  <MI6>nodejs-master: #816 UNSTABLE smartos-x64 (8/691) smartos-ia32 (5/691) osx-x64 (1/691) centos-ia32 (3/691) ubuntu-x64 (2/691) ubuntu-ia32 (4/691) centos-x64 (3/691) http://jenkins.nodejs.org/job/nodejs-master/816/
23:05:48  <MI6>nodejs-v0.10-windows: #411 UNSTABLE windows-x64 (10/607) windows-ia32 (17/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/411/
23:14:01  <trevnorris>time for food
23:14:02  * trevnorris&
23:14:15  <trevnorris>DAMN RIGHT LOUTBOT
23:14:59  <MI6>nodejs-v0.10: #1687 UNSTABLE linux-x64 (4/607) osx-x64 (1/607) linux-ia32 (6/607) smartos-x64 (9/607) smartos-ia32 (6/607) osx-ia32 (1/607) http://jenkins.nodejs.org/job/nodejs-v0.10/1687/
23:17:15  <tjfontaine>hah
23:17:46  <tjfontaine>ok
23:17:49  <MI6>joyent/node: Timothy J Fontaine master * 5ce4f3e : v8: Upgrade to - http://git.io/dt_bfQ
23:17:54  <tjfontaine>so time to actually do this 0.11 release
23:23:52  <MI6>nodejs-v0.10-windows: #412 UNSTABLE windows-x64 (11/607) windows-ia32 (14/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/412/
23:27:18  * pachetquit (Quit: leaving)
23:36:10  <trevnorris>tjfontaine: likelihood that we'll upgrade v8 to 3.24 before v0.12?
23:36:21  <tjfontaine>slim, but maybe 3.23
23:36:42  <tjfontaine>3.24 is the active development branch, not the most recent stable
23:37:26  <trevnorris>heh, I figured everything they do is considered unstable :P
23:37:46  <tjfontaine>well, there are some things that are *more* unstable than others :)
23:38:22  <MI6>nodejs-master: #817 UNSTABLE smartos-x64 (11/691) smartos-ia32 (6/691) osx-ia32 (2/691) osx-x64 (1/691) centos-ia32 (2/691) ubuntu-x64 (1/691) ubuntu-ia32 (2/691) centos-x64 (2/691) http://jenkins.nodejs.org/job/nodejs-master/817/
23:38:24  <MI6>joyent/node: tjfontaine created branch v0.11.10-release - http://git.io/7ZhF1g
23:39:18  <trevnorris>tjfontaine: didn't someone report an segfault w/ v8 gc in an issue or something like that?
23:39:34  <tjfontaine>there have been a few
23:40:47  <trevnorris>ok. wonder if it has anything to do w/ https://code.google.com/p/v8/issues/detail?id=3071
23:41:21  <tjfontaine>the trace doesn't look familiar
23:41:48  <tjfontaine>https://github.com/joyent/node/issues/6617
23:44:44  * kazuponjoined
23:47:10  <trevnorris>tjfontaine: this is a new one: v8::ResourceConstraints::void set_max_available_threads(int value)
23:47:36  <trevnorris>guess now that they're moving more out of the main thread, that actually matters.
23:47:46  <trevnorris>tjfontaine: and thanks. that's the issue I was looking for.
23:47:57  <octetcloud>[1;3D/names
23:48:07  <MI6>nodejs-v0.10: #1688 UNSTABLE linux-x64 (5/607) osx-x64 (1/607) linux-ia32 (4/607) smartos-x64 (7/607) smartos-ia32 (9/607) osx-ia32 (1/607) http://jenkins.nodejs.org/job/nodejs-v0.10/1688/
23:49:44  <tjfontaine>trevnorris: ya, they're getting more aggressive with their threaded gc model and reopt pattern
23:49:52  <tjfontaine>trevnorris: we're going to want to keep an eye on it
23:50:09  * kazuponquit (Ping timeout: 272 seconds)
23:50:28  <trevnorris>yeah
23:50:36  <trevnorris>another new one: RequestInterrupt()
23:51:09  <trevnorris>unless it was there before, but by another name.
23:52:12  <tjfontaine>oh god, I'm wary of exposing that functionality directly
23:52:26  <tjfontaine>it does however simplify our vm watchdog
23:53:48  <trevnorris>hehe
23:54:21  <tjfontaine>yaknow?
23:55:35  <trevnorris>wtf. CallOnBackgroundThread() ?
23:55:39  <trevnorris>that's new
23:55:54  <trevnorris>"Schedules a task to be invoked on a background thread"
23:56:36  <tjfontaine>that's an internal though
23:57:36  <trevnorris>don't think so. it's defined in include\v8-platform.h
23:58:02  <trevnorris>and it's initialized on V8::InitializePlatform()
23:58:14  <trevnorris>then you can create v8::Tasks from it
23:58:32  <trevnorris>yeah. namespace v8::Platform
23:59:04  <tjfontaine>it's generally not something an embedder uses, but a porter would
23:59:16  <tjfontaine>at least, what I assume from that
23:59:51  <tjfontaine>ah, it basically abstracts our interfaces
23:59:59  <trevnorris>"V8 Platform abstraction layer. The embedder has to provide an implementation of this interface before initializing the rest of V8."