00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:09  * brsonquit (Ping timeout: 248 seconds)
00:02:12  * jmar777joined
00:07:28  <trevnorris>tjfontaine: ping
00:07:37  <tjfontaine>pong
00:08:44  <trevnorris>tjfontaine: two things. can we make console.error = proccess._rawDebug? and, I want to add some simple logic so if console.{log,error,etc.} is called from inside an asynclistener callback it'll automatically bypass the callbacks.
00:08:54  <trevnorris>honestly i'm not sure why we need to create a ReqWrap for those calls anyways.
00:09:03  * brsonjoined
00:09:25  <tjfontaine>rawDebug calls a flush on each call?
00:09:36  <trevnorris>yeah
00:09:46  <tjfontaine>how does rawDebug help .log?
00:10:19  <trevnorris>rawDebug just does fprint(stderr,... but I don't see why .log can't do the same but with stdout
00:10:55  <tjfontaine>that's a pretty significant change, I'm sure that we'd get bit by this in one way or another
00:11:09  <tjfontaine>at the very least it makes printing much slower triggering a flush every call
00:11:33  <trevnorris>is logging asynchronous?
00:11:35  <tjfontaine>no
00:11:38  <tjfontaine>but
00:11:39  <tjfontaine>well
00:11:43  <tjfontaine>actually "sometimes"
00:12:30  * dshaw_quit (Read error: Connection reset by peer)
00:12:31  <trevnorris>strange. well, i'm going to add in the logic to make console.* an exception when inside an asynclisteners. it's a simple check, and would make other edge cases easier.
00:14:25  <trevnorris>my docs:
00:14:25  <trevnorris>> "allows developers to be notified about key events"
00:14:25  <trevnorris>"key events"? wtf does that mean. man, I'm really glad I get to revisit this before the v0.12 release
00:16:17  <trevnorris>othiym23: a post v0.12 API addition is the "complete" callback. the implementation is simple enough, and I think it'd be useful.
00:17:50  * dshaw_joined
00:18:22  * timoxleyjoined
00:18:55  <tjfontaine>what's "complete" mean in this context?
00:19:25  * dap_quit (Quit: Leaving.)
00:20:09  * mikealquit (Quit: Leaving.)
00:20:29  * mikealjoined
00:20:57  * dap_joined
00:21:26  <trevnorris>a callback that will run when all possible asynchronous events have been run from the level at which the asynclistener was added.
00:22:21  <trevnorris>so: addAsync(); nextTick(fn() { setImmediate(fn() { }); }); removeAsync(); would run "complete" after the fn in the setImmediate has run
00:22:57  <trevnorris>because it'd be impossible for any other asynchronous callbacks to be added to its asynchronous callstack
00:24:28  * abraxasjoined
00:25:06  <othiym23>trevnorris: I like the idea of the "complete" callback, as long as everybody involved understands that it's not guaranteed to fire 100% of the time
00:25:38  <othiym23>the discussion of done on thenables for DOM Promises was exhausting enough to go through the first time
00:25:53  * mikealquit (Quit: Leaving.)
00:25:58  <trevnorris>othiym23: why wouldn't it be? i mean, i'm fine w/ that but don't see why it wouldn't. hahaha. yeah, not getting into something that complex.
00:26:37  <othiym23>trevnorris: I'll put it this way: the obverse of having a done() function is considering how to make async ops cancelable
00:26:52  <othiym23>they share a lot of the same concerns (and infringe on the halting problem in similar ways)
00:27:03  <trevnorris>this implementation is as simple as a ref counter. I have a central location for all async callbacks to be created and run, so that'll be easy.
00:27:19  <trevnorris>oh, freak. yeah. adding something like .pause() to a single async callback stack is ridiculous.
00:28:53  * abraxasquit (Ping timeout: 248 seconds)
00:30:41  <trevnorris>othiym23: so, is your concern that this functionality would make people ask for the other APIs?
00:30:45  * mikealjoined
00:31:29  <othiym23>trevnorris: nah, I just don't want to make promises we can't keep
00:31:46  <othiym23>also my main concern is how much latency these APIs add when listeners are in use
00:31:53  <othiym23>which is sorta the opposite of your concern ;)
00:32:21  <trevnorris>haha. no. I want this API to be fast enough that anyone using it won't feel the need to use anything else.
00:32:24  * mikealquit (Client Quit)
00:32:27  * zz_karupanerurachanged nick to karupanerura
00:33:08  <trevnorris>cheaply keeping counters is easy.
00:38:14  * c4miloquit (Remote host closed the connection)
00:38:54  * felixge_joined
00:38:54  * kuplatup1ujoined
00:38:56  * felixgequit (Ping timeout: 250 seconds)
00:38:56  * felixge_changed nick to felixge
00:38:58  * kuplatupsuquit (Ping timeout: 250 seconds)
00:39:59  * stagasquit (Ping timeout: 260 seconds)
00:41:29  <trevnorris>tjfontaine: on https://github.com/joyent/node/issues/6664 should we just zero fill the stupid things?
00:41:59  * AvianFlujoined
00:42:34  * dap_quit (Quit: Leaving.)
00:42:52  * saghul_joined
00:44:26  * hueniverse1joined
00:46:05  * saghulquit (Ping timeout: 250 seconds)
00:46:05  * saghul_changed nick to saghul
00:46:07  * hueniversequit (Ping timeout: 250 seconds)
00:46:13  * mmalecki_joined
00:46:14  * mmaleckiquit (Ping timeout: 250 seconds)
00:49:51  * jamesmhowejoined
00:52:49  * kazuponjoined
00:56:28  <trevnorris>othiym23: ping
00:57:03  <othiym23>trevnorris: pong
00:57:13  * jameshowequit (*.net *.split)
00:57:37  <trevnorris>othiym23: do you think that the after async-callback should fire even if the event callback itself errored, but was handled?
00:58:01  <trevnorris>currently it doesn't, and don't know if that's something I want to bother with.
00:58:36  * dap_joined
00:59:07  <othiym23>trevnorris: I went to considerable shenanigans to ensure that worked for the polyfill, so right now it's a difference in behavior that's not exposed via the tests we share
00:59:38  <trevnorris>othiym23: ok. so sounds like you think I should implement the same. sounds fine.
00:59:57  <othiym23>trevnorris: personally, I think that it's important for consistency's sake, but if you don't think it's worth the hassle, I'd double-check with piscesaureus and ensure it won't nerf tasks if it's not there
01:00:14  <tjfontaine>trevnorris: typed arrays should absolutely behave like their ignorant browser brethren, but with a memset not a .fill
01:00:26  <trevnorris>eh, implementation is simple enough. it's just one extra fn call
01:00:34  <trevnorris>tjfontaine: ok. i'll throw that on. it's a super trivial fix
01:00:37  <tjfontaine>nod
01:00:40  <trevnorris>but yeah, very ignorant, and slow
01:01:29  <tjfontaine>it's should absolutely be opt-in
01:01:36  <tjfontaine>but whatever.
01:01:38  * kazuponquit
01:01:53  <tjfontaine>FINE ES PLAY TO THE LOWEST COMMON DENOMINATOR
01:01:53  <LOUDBOT>I RAISE MY MIDDLE FINGER AT YOU
01:01:57  <tjfontaine>exactly.
01:02:07  <trevnorris>i understand it for the browser. you don't want any webpage poking around your memory at random.
01:02:14  <tjfontaine>"random"
01:02:24  <tjfontaine>it's not really like that, because of things like ASLR
01:02:38  * kazuponjoined
01:03:06  <tjfontaine>it's mostly a concern about data leakage, and about if you know what's going on wrt language and features
01:03:25  <trevnorris>why doesn't ./configure auto-run anymore when you run make?
01:04:19  <tjfontaine>a chicken and an egg problem, you could make a change to your config.gypi and then it would get blown away because make decided it was time to rerun
01:04:36  <tjfontaine>also having make run configure is super automagical
01:04:44  <tjfontaine>./configure && make && make install
01:04:46  <trevnorris>okie dokie
01:04:56  <tjfontaine>that's the tried and true pattern for decades :)
01:05:06  * dap_quit (Quit: Leaving.)
01:05:25  <trevnorris>haven't you noticed? we're writing JAVASCRIPT!
01:05:32  <tjfontaine>we're running on unix.
01:05:35  <tjfontaine>:)
01:05:54  <trevnorris>WE LAUGH IN THE FACE OF PROVEN TECHNIQUES!!!
01:05:55  <LOUDBOT>GOING HOEM
01:06:27  <trevnorris>yes. and it hurts me a little every time I see a module written like it was for the browser...
01:07:01  * kazuponquit (Remote host closed the connection)
01:07:05  <othiym23>I still think my favorite was the rethinkdb team shipping a minified / Closure Compiler-munged module for Node
01:07:07  * dshaw_quit (Quit: Leaving.)
01:07:21  <othiym23>it took a surprisingly long time to convince them that was a really really really really really really really really really bad idea
01:07:44  <tjfontaine>people love the tiny codes
01:08:20  <groundwater>cuz less letters = faster! duhh
01:09:08  <othiym23>well, the tricky part was that they were using protobufs, which required Closure Compiler to do its thing
01:09:28  <othiym23>but still, trying to debug with that thing in the mix was a giant pile of ugh
01:09:49  <othiym23>what Node really needs is sourcemap support, othiym23 deadpanned
01:14:01  <MI6>joyent/node: Trevor Norris master * 7222539 : node: follow specification, zero-fill ArrayBuffers - http://git.io/kLikvg
01:14:59  <tjfontaine>trevnorris: fwiw, do you remember me asking you about this very specific issue? :)
01:15:37  <trevnorris>tjfontaine: not really, but my memory retention isn't that great :P
01:16:39  <tjfontaine>I did a v8 upgrade, and the allocator pattern changed, introducing the secondary function for unitialized functions
01:16:57  <tjfontaine>asked if you wanted me to add the memset, and you demurred
01:18:01  <trevnorris>BECAUSE PERFORMANCE!
01:18:01  <LOUDBOT>OH SHIT CALIFORNIA CALLED FOR BOB BARR
01:18:55  <trevnorris>well, i'm out.
01:18:56  * trevnorris&
01:18:57  <LOUDBOT>OMG ESCH LET'S GO TO THE RENAISSANCE FAIR
01:20:58  * dshaw_joined
01:22:03  * AvianFluquit (Read error: Connection reset by peer)
01:22:44  * AvianFlujoined
01:34:57  * octetcloudquit (Ping timeout: 272 seconds)
01:38:33  <hueniverse1>trevnorris: any chance of getting a core domains API that allows running a function within the domain but existing the domain on a callback?
01:39:43  * abraxasjoined
01:44:23  * otwojoined
01:46:55  * mikealjoined
01:47:38  * kenperkinsquit (Quit: Computer has gone to sleep.)
01:53:04  * c4milojoined
01:53:55  * skebcioquit (Read error: Connection reset by peer)
01:54:09  <MI6>nodejs-master: #762 UNSTABLE smartos-x64 (9/683) osx-x64 (2/683) centos-ia32 (8/683) ubuntu-ia32 (1/683) smartos-ia32 (9/683) osx-ia32 (1/683) centos-x64 (6/683) ubuntu-x64 (2/683) http://jenkins.nodejs.org/job/nodejs-master/762/
01:54:13  * skebciojoined
01:54:30  * dshaw_quit (Quit: Leaving.)
01:54:55  * mikolalysenkoquit (Ping timeout: 240 seconds)
01:55:46  * mikealquit (Quit: Leaving.)
01:57:55  * c4miloquit (Ping timeout: 260 seconds)
01:59:50  * paulfryzelquit (Remote host closed the connection)
02:08:25  * AvianFluquit (Read error: Connection reset by peer)
02:09:01  * AvianFlujoined
02:14:40  * jmar777_joined
02:15:41  * dlmanningquit (Ping timeout: 252 seconds)
02:16:37  * jmar777quit (Ping timeout: 248 seconds)
02:19:20  * kazupon_joined
02:20:03  * dlmanningjoined
02:22:07  * mikolalysenkojoined
02:27:00  * inolenquit (Quit: Leaving.)
02:29:03  * octetcloudjoined
02:37:34  * rmgquit (Remote host closed the connection)
02:38:09  * rmgjoined
02:41:52  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:42:45  * rmgquit (Ping timeout: 248 seconds)
02:56:46  * paulfryzeljoined
03:03:14  * paulfryzelquit (Remote host closed the connection)
03:06:03  * rmgjoined
03:06:15  * AvianFluquit (Read error: Connection reset by peer)
03:07:02  * AvianFlujoined
03:22:30  * inolenjoined
03:31:53  * c4milojoined
03:36:18  * AvianFluquit (Read error: Connection reset by peer)
03:36:56  * c4miloquit (Remote host closed the connection)
03:37:48  * AvianFlujoined
03:40:08  <othiym23>hueniverse1: expand, that's an interesting idea that I'm not sure I understand
03:46:11  * mikolalysenkoquit (Ping timeout: 260 seconds)
03:53:18  <hueniverse1>othiym23: I want this: https://github.com/spumko/hapi/blob/master/lib/ext.js#L110
03:59:41  * mcavage_joined
03:59:42  * mcavagequit (Read error: Connection reset by peer)
04:01:22  * jmar777_quit (Remote host closed the connection)
04:01:32  * mikolalysenkojoined
04:08:47  <othiym23>hueniverse1: so something in core that provides functionality analgous to setup(enter, exit)?
04:09:28  <othiym23>hueniverse1: you could probalby do that with asyncListeners instead; the implementation of domains on top of asyncListener should be pretty simple / dumb after the new rewrite
04:17:00  * rmgquit (Remote host closed the connection)
04:17:35  * rmgjoined
04:20:22  * abraxasquit (Remote host closed the connection)
04:20:53  * brsonquit (Ping timeout: 272 seconds)
04:22:31  * rmgquit (Ping timeout: 272 seconds)
04:34:57  * paulfryzeljoined
04:37:23  * abraxasjoined
04:48:04  * rmgjoined
05:02:41  * rmgquit (Ping timeout: 272 seconds)
05:03:10  * kazuponjoined
05:04:07  * kazupon_quit (Read error: Connection reset by peer)
05:14:37  * toothrotquit (Ping timeout: 252 seconds)
05:16:56  * defunctzombiechanged nick to defunctzombie_zz
05:17:00  * abraxasquit (Remote host closed the connection)
05:21:38  * c4milo_joined
05:24:05  * toothrjoined
05:24:22  * dshaw_joined
05:26:20  * kazuponquit (Read error: Connection reset by peer)
05:26:29  * c4milo_quit (Ping timeout: 248 seconds)
05:26:39  * kazuponjoined
05:28:56  * mikealjoined
05:34:26  * mikealquit (Quit: Leaving.)
05:34:47  * kenperkinsjoined
05:35:13  * rmgjoined
05:47:35  * mikealjoined
05:49:44  * mikealquit (Client Quit)
06:17:36  * mikealjoined
06:18:47  * paddybyersjoined
06:24:28  * abraxasjoined
06:24:51  * m76joined
06:28:36  * octetcloudquit (Quit: WeeChat 0.4.2)
06:29:03  * octetcloudjoined
06:31:59  * mikolalysenkoquit (Ping timeout: 272 seconds)
06:38:19  * mikolalysenkojoined
06:38:38  <hueniverse1>othiym23: is there a doc for the new asyncListener thingie?
06:39:24  <groundwater>hueniverse1: i think here is the only place so far https://github.com/joyent/node/pull/6665
06:40:40  <hueniverse1>"dramatic performance impact"
06:40:43  <hueniverse1>thats bad right?
06:41:13  <MI6>nodejs-v0.10-windows: #369 UNSTABLE windows-ia32 (11/605) windows-x64 (12/605) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/369/
06:41:27  <trevnorris>hueniverse1: that's just a general warning to make sure people don't over use it.
06:42:04  <othiym23>I read that as "don't ever use it" first, and that seemed somewhat counterproductive
06:42:20  <trevnorris>that's being reworded.
06:42:29  <hueniverse1>trevnorris: I hate the current domain.run() option. I really want something better that doesn't wrap the entire execution flow.
06:42:57  <trevnorris>hueniverse1: hence my api design with async listeners. so you don't have any function wraps.
06:42:58  <hueniverse1>we really need an enter-exit wrapper
06:43:00  <othiym23>hueniverse1: it seems like it should be pretty easy to write yourself, no?
06:43:18  <hueniverse1>well, I did
06:43:20  <hueniverse1>and it's ugly
06:43:22  <hueniverse1>:-)
06:43:54  <hueniverse1>joking aside, I think that people will benefit from it. I wouldn't suggest it but since you are messing with the apis anyway...
06:43:59  <trevnorris>othiym23: for reference, here's the PR that will be accumulating the changes: https://github.com/joyent/node/pull/6665
06:44:02  <hueniverse1>I am happy publishing a tiny module to do this
06:44:08  * paulfryzelquit (Remote host closed the connection)
06:44:11  <othiym23>I would do it, but I'm in the middle of removing the default context from CLS, which breaks like half my tests and I have to look at each one and make sure I'm fixing the test the right way
06:44:20  <othiym23>trevnorris: on it already ;)
06:44:24  <trevnorris>othiym23: right now there are no actual code changes. just made changes to the tests for reference as I do the rewrite
06:44:24  <othiym23>trevnorris: thank you!
06:44:28  <trevnorris>heh, of course :)
06:45:27  <othiym23>hueniverse1: I need to understand your API better, but in general I'm fine with adding new stuff to the domains API, but I don't want to do anything that breaks backwards compatibility
06:45:30  <othiym23>for what it's worth
06:45:47  <othiym23>I don't get a vote, though ;)
06:46:41  <trevnorris>hueniverse1: i must be oversimplifying your use case, but it seems like since you can add/remove an async listener at any point in the execution flow, that should take care of your needs.
06:47:46  <trevnorris>othiym23: also, i'm adding an exception to console.* so if any of those are run inside an async listener they won't be caught.
06:47:48  <hueniverse1>trevnorris: it is going to be in the hottest code in my application, still a good idea?
06:49:15  <trevnorris>hueniverse1: after my rewrite, I'll say probably. my performance benchmarks are basically running perfectly tight loops on async code and measuring impact.
06:49:15  <trevnorris>so unless you're doing that much traffic on that machine you'll be fine.
06:49:28  <trevnorris>hueniverse1: i mean, is your CPU usage anywhere near 100% on your servers?
06:51:23  <hueniverse1>trevnorris: is 2% near 100%? I didn't go to CS school.
06:51:43  <trevnorris>hahah
06:52:20  <trevnorris>hueniverse1: so, CPU _might_ jump to 3%. but your performance numbers won't change in the least.
06:52:44  <groundwater>how about latency
06:52:59  <groundwater>just being THAT GUY
06:53:19  <trevnorris>single digit microseconds per req at worst.
06:54:10  <trevnorris>you'll only notice performance impact if CPU is maxing out. but latency won't change much.
06:55:07  <trevnorris>groundwater: i mean, to see performance impact I had to hammer kraken on my loopback.
06:55:40  <trevnorris>and don't worry about being "that guy" ;)
06:56:41  * otwoquit (Ping timeout: 272 seconds)
06:57:28  <trevnorris>hueniverse1: like othiym23 said, the API is going to change slightly before the v0.12 release. that's so it'll be more extendable in the future.
06:58:22  <othiym23>man, these changes to CLS are dramatic enough that I might have to bump the version up to 3.0
06:58:43  <othiym23>so maybe I'll wait to release this until I've rebuilt the asyncListener polyfill to match the new API
06:58:57  * octetcloudquit (Ping timeout: 272 seconds)
07:10:06  * c4milojoined
07:11:13  * dshaw_quit (Read error: Connection reset by peer)
07:12:07  * dshaw_joined
07:14:47  * c4miloquit (Ping timeout: 272 seconds)
07:15:35  * calvinfoquit (Quit: Leaving.)
07:20:16  * stagasjoined
07:21:46  * rmgquit (Remote host closed the connection)
07:31:26  * `3E|ZZchanged nick to `3rdEden
07:37:07  * otwojoined
07:42:26  * dshaw_quit (Quit: Leaving.)
07:43:49  * dshaw_joined
07:55:12  * paulfryzeljoined
07:56:21  <roxlu>good morning!
07:57:50  <roxlu>I've got something silly with c/c++ ... when I do: uint64_t delay = 3 * 1000 * 1000 * 1000; the value overflows ?
07:59:45  * paulfryzelquit (Ping timeout: 272 seconds)
08:05:28  <roxlu>ahh.. 3LLU * 1000 * 1000 * 1000 does the trick
08:06:14  * mraleph1quit (Ping timeout: 240 seconds)
08:06:27  * mralephjoined
08:10:12  * bajtosjoined
08:16:15  * rmgjoined
08:19:47  * toxedvirusjoined
08:21:33  * rmgquit (Ping timeout: 272 seconds)
08:22:33  * mikolalysenkoquit (Ping timeout: 272 seconds)
08:25:15  * otwoquit (Ping timeout: 260 seconds)
08:45:58  * mmalecki_changed nick to mmalecki
08:48:38  * mikolalysenkojoined
08:52:52  * rendarjoined
08:53:37  * mikolalysenkoquit (Ping timeout: 246 seconds)
08:58:21  * c4milojoined
09:02:30  * AvianFluquit (Remote host closed the connection)
09:02:48  * c4miloquit (Ping timeout: 240 seconds)
09:04:06  * janjongboomjoined
09:04:58  * mcavagejoined
09:04:59  * mcavage_quit (Read error: Connection reset by peer)
09:07:17  * mcavage_joined
09:07:18  * mcavagequit (Read error: Connection reset by peer)
09:09:07  * mcavagejoined
09:09:07  * mcavage_quit (Read error: Connection reset by peer)
09:32:16  * karupanerurachanged nick to zz_karupanerura
09:35:39  * hzjoined
09:52:18  * dshaw_quit (Quit: Leaving.)
09:54:49  * dshaw_joined
09:55:12  * dshaw_quit (Client Quit)
09:55:17  * toothrquit (Ping timeout: 272 seconds)
09:55:47  * stagasquit (Ping timeout: 260 seconds)
10:02:25  * inolenquit (Quit: Leaving.)
10:02:40  * inolenjoined
10:25:05  * toothrjoined
10:30:32  * abraxasquit (Remote host closed the connection)
10:39:11  * toothrquit (Ping timeout: 260 seconds)
10:46:53  * c4milojoined
10:49:26  <MI6>nodejs-v0.10: #1651 UNSTABLE smartos-ia32 (5/605) osx-ia32 (2/605) linux-ia32 (2/605) osx-x64 (1/605) linux-x64 (2/605) smartos-x64 (7/605) http://jenkins.nodejs.org/job/nodejs-v0.10/1651/
10:50:18  * mikolalysenkojoined
10:51:39  * c4miloquit (Ping timeout: 272 seconds)
10:53:35  * toothrjoined
10:54:30  * kazuponquit (Remote host closed the connection)
10:55:11  * mikolalysenkoquit (Ping timeout: 240 seconds)
10:55:33  * abraxasjoined
11:04:23  * inolenquit (Read error: No route to host)
11:04:34  * inolenjoined
11:15:32  * toothrquit (Ping timeout: 240 seconds)
11:19:05  * toothrjoined
11:20:17  * bajtosquit (Quit: bajtos)
11:28:09  * abraxasquit (Remote host closed the connection)
11:38:57  * LeftWing__joined
11:42:14  * LeftWingquit (Remote host closed the connection)
11:43:02  * Brett19quit (Ping timeout: 240 seconds)
11:45:03  * Brett19joined
11:51:06  * mikolalysenkojoined
11:53:36  * bajtosjoined
11:55:53  * mikolalysenkoquit (Ping timeout: 240 seconds)
11:56:01  * kellabytequit (Remote host closed the connection)
12:11:35  * Kakerajoined
12:26:23  <indutny>morning
12:28:43  <mmalecki>morning Fedor
12:30:06  <indutny>how are you?
12:30:33  <mmalecki>good, hating my life just a little bit. been doing frontend whole morning. you?
12:35:02  * c4milojoined
12:35:35  <mmalecki>actually, let me test that weird connect stuff we talked about yesterday
12:37:59  <mmalecki>got it to repro
12:38:04  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:39:18  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 15af49a : unix, windows: always update loop time - http://git.io/OeGjHQ
12:39:22  * c4miloquit (Ping timeout: 246 seconds)
12:41:17  <mmalecki>indutny: the same error happens when I change ephemeral port range
12:41:28  <indutny>Ж)
12:41:41  <mmalecki>that's a nice emoticon :)
12:42:22  <MI6>libuv-master: #380 UNSTABLE smartos (3/199) windows (6/198) http://jenkins.nodejs.org/job/libuv-master/380/
12:48:24  <MI6>libuv-master-gyp: #332 UNSTABLE windows-x64 (5/198) smartos-ia32 (6/199) smartos-x64 (3/199) windows-ia32 (5/198) http://jenkins.nodejs.org/job/libuv-master-gyp/332/
12:51:52  * mikolalysenkojoined
12:53:08  * janjongboomjoined
12:55:41  * jmar777joined
12:56:52  * mikolalysenkoquit (Ping timeout: 246 seconds)
13:00:21  * jmar777quit (Ping timeout: 248 seconds)
13:02:18  <MI6>libuv-node-integration: #340 UNSTABLE linux-ia32 (2/683) smartos-x64 (7/683) smartos-ia32 (5/683) osx-x64 (1/683) osx-ia32 (2/683) linux-x64 (3/683) http://jenkins.nodejs.org/job/libuv-node-integration/340/
13:18:32  * kazuponjoined
13:27:49  * toothrquit (Ping timeout: 272 seconds)
13:33:01  <jamesmhowe>indutny: ping
13:40:16  * AlexisMocha_part
13:40:42  * kevinswiberjoined
13:40:50  * AlexisMochajoined
13:52:48  * mikolalysenkojoined
13:56:41  * kellabytejoined
13:56:53  * kellabytequit (Changing host)
13:56:53  * kellabytejoined
13:56:53  * kellabytequit (Changing host)
13:56:53  * kellabytejoined
13:57:37  * mikolalysenkoquit (Ping timeout: 240 seconds)
14:04:55  * [m76]joined
14:06:11  * Brett19quit (Ping timeout: 246 seconds)
14:06:38  * mikeal1joined
14:06:41  * Brett19joined
14:06:53  * mikealquit (Ping timeout: 246 seconds)
14:07:36  * m76quit (Ping timeout: 246 seconds)
14:10:45  * julianduquequit (Ping timeout: 246 seconds)
14:11:15  * julianduquejoined
14:12:04  * toothrjoined
14:13:10  * wolfeidauquit (Ping timeout: 246 seconds)
14:14:40  * wolfeidaujoined
14:14:56  * inolenquit (Ping timeout: 246 seconds)
14:15:16  * inolenjoined
14:18:16  * hzquit
14:18:46  * timoxleyquit (Ping timeout: 246 seconds)
14:19:55  * timoxleyjoined
14:20:10  * tjfontainequit (Ping timeout: 246 seconds)
14:20:12  * kevinswiberquit (Remote host closed the connection)
14:20:25  * tjfontainejoined
14:20:47  * [m76]quit (Read error: Connection reset by peer)
14:20:50  * tjfontainechanged nick to Guest44648
14:23:11  * c4milojoined
14:27:49  * c4miloquit (Ping timeout: 248 seconds)
14:33:06  * kevinswiberjoined
14:52:20  * defunctzombie_zzchanged nick to defunctzombie
14:53:31  * mikolalysenkojoined
14:58:19  * mikolalysenkoquit (Ping timeout: 246 seconds)
15:11:29  * hzjoined
15:21:10  * m76joined
15:21:27  <MI6>nodejs-master: #763 UNSTABLE smartos-x64 (8/683) osx-x64 (1/683) centos-ia32 (6/683) ubuntu-ia32 (3/683) smartos-ia32 (6/683) osx-ia32 (1/683) centos-x64 (6/683) http://jenkins.nodejs.org/job/nodejs-master/763/
15:23:49  * pachetjoined
15:23:49  * pachetquit (Changing host)
15:23:49  * pachetjoined
15:27:28  * paulfryzeljoined
15:30:06  * kevinswiberquit (Remote host closed the connection)
15:30:14  * abraxasjoined
15:30:23  * paulfryzelquit (Remote host closed the connection)
15:31:25  * kevinswiberjoined
15:33:07  * mikolalysenkojoined
15:34:29  * abraxasquit (Ping timeout: 248 seconds)
15:37:16  * m76quit (Read error: Connection reset by peer)
15:41:23  * felixgequit (Quit: felixge)
15:45:27  * paulfryzeljoined
15:47:09  * mikeal1quit (Quit: Leaving.)
16:03:20  * c4milojoined
16:09:20  <MI6>joyent/node: Alexis Campailla master * f9e3364 : test: fix create-file test fixture - http://git.io/qm6B_A
16:09:22  * AvianFlujoined
16:10:21  * AvianFlu_joined
16:12:07  <indutny>jamesmhowe: sorry, I got into very important stuff at my job
16:12:15  * octetcloudjoined
16:12:29  <indutny>I don't think that I'll be able to spend time on your issue
16:12:34  <indutny>at least soon
16:13:01  * mikolalysenkoquit (Ping timeout: 241 seconds)
16:13:14  * AvianFluquit (Disconnected by services)
16:13:18  * AvianFlu_changed nick to AvianFlu
16:18:12  * wolfeida_joined
16:19:34  * pachetquit (Quit: leaving)
16:19:43  * wolfeidauquit (Ping timeout: 272 seconds)
16:19:58  * pachetjoined
16:21:15  <indutny>trevnorris: hey there
16:21:16  <indutny>how are you?
16:22:42  <indutny>trevnorris: do you have a minute to help me land some PRs https://github.com/joyent/node/pull/6560 ?
16:30:33  * bajtosquit (Quit: bajtos)
16:32:59  * inolenquit (Read error: No route to host)
16:33:12  * inolenjoined
16:34:02  <MI6>nodejs-master: #764 UNSTABLE smartos-x64 (11/683) osx-x64 (2/683) centos-ia32 (7/683) ubuntu-ia32 (2/683) smartos-ia32 (7/683) osx-ia32 (1/683) centos-x64 (8/683) ubuntu-x64 (1/683) http://jenkins.nodejs.org/job/nodejs-master/764/
16:35:05  <mmalecki>janjongboom: I'm on my way
16:35:45  <jamesmhowe>indutny that's ok
16:35:47  * jamesmhowequit (Quit: Leaving)
16:35:54  <indutny>janjongboom: really sorry
16:36:13  <indutny>oops
16:36:23  <indutny>jan, that was not for you
16:37:38  * mikealjoined
16:37:42  <janjongboom>lol
16:37:54  <janjongboom>@mmalecki: take it easy, I'm not on my way yet :p
16:38:56  * mikolalysenkojoined
16:43:40  * mikolalysenkoquit (Ping timeout: 246 seconds)
16:45:03  * dap_joined
16:47:06  * timoxleyquit (Remote host closed the connection)
16:48:18  * timoxleyjoined
16:48:40  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:50:21  * rmgjoined
16:51:17  * m76joined
16:51:20  <Guest44648>g'day
16:52:03  * Guest44648changed nick to tjfontaine
16:52:07  * tjfontainequit (Changing host)
16:52:07  * tjfontainejoined
16:52:55  * timoxleyquit (Ping timeout: 260 seconds)
16:54:46  * titojoined
16:55:40  <tito>hey guys, i got a question on pyuv.util.hrtime(), is this time would be the same accross the system, or does it depend on the boot time?
16:58:12  <tjfontaine>you mean across processes on the system?
16:58:21  <tito>accross different system
17:00:09  <tjfontaine>they won't work across systems no, they are implementation specific to the kernel and may indeed be related to time since boot
17:01:30  * inolenquit (Quit: Leaving.)
17:01:59  <rendar>tjfontaine, i guess its the rdstc instruction on intel, right?
17:03:07  <tjfontaine>impelementation dependent, they're free to do so as they desire :)
17:04:06  <rendar>:)
17:04:07  <tito>tjfontaine: ok, thanks :)
17:06:10  * mikealquit (Quit: Leaving.)
17:06:19  * mikealjoined
17:09:38  * mikolalysenkojoined
17:12:25  <indutny>tjfontaine: TJ!
17:12:44  <indutny>tjfontaine: hello
17:12:55  <tjfontaine>hi, I'm going through my emails fedor, I'll land the stuff we need :)
17:13:20  * mikealquit (Quit: Leaving.)
17:27:39  <indutny>tjfontaine: :)
17:27:41  <indutny>great
17:27:42  <indutny>thank you
17:28:24  <indutny>tjfontaine: btw, chrome extension still doesn't work for me :(
17:29:09  <tjfontaine>I know, I haven't spent time to find out why, I may just tweak MI6 to let us say things like: MI6: build joyent/node#6666
17:29:18  <indutny>oh, ok
17:29:23  <tjfontaine>easier, right?
17:29:40  <tjfontaine>I mean it's still putting the results on the PR via the github api
17:31:00  * abraxasjoined
17:31:29  * bajtosjoined
17:34:42  <MI6>joyent/node: Vladimir Kurchatkin master * 259d449 : src: only access stack of defined errors - http://git.io/1Mqt_Q
17:35:52  <rendar>indutny, is that a chrome extension to have these notifications ^ directly on chrome?
17:36:05  * abraxasquit (Ping timeout: 272 seconds)
17:37:06  <indutny>rendar: well, not notifications
17:37:07  <tjfontaine>rendar: no, it's an extension that would let us trigger builds for PRs and see if users had signed the CLA and which tests exactly were failing for a build
17:37:15  <tjfontaine>it could have done notifications, but that's less interesting
17:37:18  * dshaw_joined
17:37:21  <rendar>i see
17:48:05  * joshthecoderquit (Quit: IRCRelay - http://ircrelay.com)
17:48:43  * joshthecoderjoined
17:48:50  * joshthecoderquit (Client Quit)
17:49:07  * joshthecoderjoined
17:50:14  <MI6>nodejs-master: #765 UNSTABLE smartos-x64 (9/684) osx-x64 (1/684) centos-ia32 (5/684) ubuntu-ia32 (1/684) smartos-ia32 (7/684) centos-x64 (5/684) http://jenkins.nodejs.org/job/nodejs-master/765/
17:50:44  <indutny>tjfontaine: could it be printing it to another channel?
17:50:50  <indutny>tjfontaine: like #libuv-ci
17:50:51  <tjfontaine>yes
17:51:43  * stagasjoined
17:54:02  * kevinswiberquit (Remote host closed the connection)
17:54:03  <MI6>libuv-master: #381 UNSTABLE smartos (4/199) windows (5/198) http://jenkins.nodejs.org/job/libuv-master/381/
17:55:18  * inolenjoined
18:00:10  * brsonjoined
18:00:38  <tjfontaine>indutny: I'm still getting the test failure with your fix 6560
18:00:48  <indutny>6560?
18:00:51  <indutny>fs watch?
18:00:54  <tjfontaine>yse
18:00:56  * dap_quit (Read error: Connection reset by peer)
18:01:02  <indutny>hm...
18:01:10  <indutny>one sec
18:01:10  * dap_joined
18:02:11  * LeftWing__changed nick to LeftWing
18:02:21  <indutny>oh
18:02:23  <indutny>I know why
18:02:43  * brsonquit (Client Quit)
18:02:56  * brsonjoined
18:03:02  <tjfontaine>testsubdir /Users/tjfontaine/Development/node/test/tmp/testsubdir
18:04:14  <indutny>yeah, I got it
18:04:18  <indutny>also
18:04:24  <indutny>it gets event for change right before it
18:04:46  <indutny>gosh
18:05:19  <indutny>tjfontaine: may I ask you to try https://gist.github.com/indutny/b372a6b219a9d70e8981 ?
18:05:35  <indutny>if it works - I'll just push it to master
18:06:50  * kevinswiberjoined
18:07:51  <tjfontaine>indutny: lgtm
18:07:57  <indutny>ok, good
18:07:59  <indutny>thank you
18:08:21  * m76quit (Read error: Connection reset by peer)
18:08:48  <MI6>joyent/node: Fedor Indutny master * 78cd453 : test: make fs-watch-recursive less racy - http://git.io/Tcw3CQ
18:09:51  * kazuponquit (Remote host closed the connection)
18:10:29  * m76joined
18:10:40  * TooTallNatejoined
18:11:40  <indutny>so
18:11:46  <indutny>tjfontaine: I think only close-notify thing left
18:11:49  <indutny>from my stuff
18:11:54  <MI6>joyent/node: Timothy J Fontaine v0.10 * 92bbd60 : build: only whole archive on static v8 builds - http://git.io/lj_5YQ
18:12:13  <tjfontaine>indutny: ok, can you also look into the read(1) read(N) issue on tls?
18:12:21  <indutny>sure, where is it?
18:12:26  <indutny>aaah
18:12:31  <indutny>you mean first byte thing
18:12:43  <indutny>sure
18:12:50  <tjfontaine>yes
18:13:40  <indutny>hm...
18:13:49  * indutnyopens wireshark
18:15:17  <indutny>tjfontaine: can't confirm it
18:15:25  <indutny>tjfontaine: are you sure this isn't an npm thing?
18:15:45  <tjfontaine>yes, I was seeing it in normal https.get()'s
18:16:36  <indutny>ok
18:16:38  <indutny>one sec
18:17:47  <indutny>I'm quite sure that npm does it
18:17:52  <indutny>I see two application data coming out of it
18:17:54  <indutny>one small
18:17:56  <indutny>and one big
18:18:11  * mikolalysenkoquit (Ping timeout: 252 seconds)
18:18:12  <indutny>will try with localhost server
18:19:26  <indutny>yeah
18:19:30  <indutny>can't reproduce it with local server
18:20:37  <indutny>tjfontaine: which other servers should I try?
18:21:05  <indutny>also
18:21:34  <indutny>tjfontaine: in confirmation of my words https://gist.github.com/indutny/c278db6ac875527bc913
18:21:40  <indutny>https://gist.github.com/indutny/c278db6ac875527bc913#file-gistfile1-txt-L231
18:21:46  <indutny>https://gist.github.com/indutny/c278db6ac875527bc913#file-gistfile1-txt-L222
18:21:51  <indutny>"H" comes before "TTP"
18:21:56  <indutny>when requesting it with s_client
18:22:05  <indutny>I think npm should just try using bud :)
18:22:06  <indutny>and spdy
18:22:48  <MI6>libuv-node-integration: #341 UNSTABLE smartos-x64 (10/684) smartos-ia32 (5/684) osx-x64 (1/684) osx-ia32 (1/684) linux-x64 (4/684) http://jenkins.nodejs.org/job/libuv-node-integration/341/
18:25:20  <tjfontaine>heh
18:25:43  <tjfontaine>that's kinda crazy, but ok
18:25:59  <tjfontaine>I'll defer until now, can you bump kClearOut or whatever it is anyway to 4k?
18:26:05  <tjfontaine>no test necessary
18:26:13  <tjfontaine>just that it needs to be > mtu :)
18:27:27  <indutny>tjfontaine: :)
18:28:00  <indutny>tjfontaine: sur
18:28:02  <indutny>tjfontaine: 16 kb
18:28:12  <indutny>I think it should be ok
18:28:34  <tjfontaine>:)
18:28:42  <indutny>let it be it
18:28:45  <MI6>joyent/node: Fedor Indutny master * c17449d : tls_wrap: bump kClearOutChunkSize to 16kb - http://git.io/O11UiQ
18:29:43  <tjfontaine>thanks
18:29:59  <MI6>nodejs-v0.10-windows: #370 UNSTABLE windows-ia32 (12/605) windows-x64 (11/605) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/370/
18:31:13  <indutny>tjfontaine: you're welcome
18:31:17  <MI6>nodejs-v0.10: #1652 UNSTABLE smartos-ia32 (8/605) osx-ia32 (1/605) linux-ia32 (3/605) osx-x64 (1/605) linux-x64 (2/605) smartos-x64 (9/605) http://jenkins.nodejs.org/job/nodejs-v0.10/1652/
18:31:25  <indutny>tjfontaine: btw, what do you think about backporting openssl updates to v0.10?
18:31:31  <indutny>I mean assembly patches
18:31:42  <MI6>nodejs-master: #766 UNSTABLE smartos-x64 (9/684) osx-x64 (2/684) centos-ia32 (8/684) ubuntu-ia32 (2/684) smartos-ia32 (8/684) osx-ia32 (1/684) centos-x64 (7/684) ubuntu-x64 (2/684) http://jenkins.nodejs.org/job/nodejs-master/766/
18:31:56  <indutny>I'd suggest doing it after next 0.11 release
18:32:07  <indutny>which, at least, some people will try to build on different platforms
18:32:16  <indutny>and we'll be sure that it works for them
18:32:27  <tjfontaine>we can consider it, I'm not opposed
18:39:42  <indutny>:)
18:39:43  <indutny>great
18:39:49  <indutny>on another hand
18:39:56  <indutny>we're much faster than 0.10 right now
18:39:57  <indutny>:)
18:40:01  <indutny>in benchmarks
18:40:05  <indutny>haha
18:40:30  <indutny>it may be a good incentive for people to move to 0.12
18:40:36  * kazuponjoined
18:41:25  <tjfontaine>:P
18:41:33  <inolen>(I thought this may be an appropriate place to ask) is it possible to override the functionality of the subscript operator for v8 objects?
18:41:42  <tjfontaine>I'm hoping that after I get execSync landed we'll have real benchmarks to report
18:42:11  <tjfontaine>indutny: you mean handling the getters and setters?
18:42:32  <indutny>I think it was addressed not to me, right?
18:42:50  <tjfontaine>sorry
18:42:52  <tjfontaine>inolen
18:42:53  <trevnorris>indutny: just got in. still need help?
18:42:58  <indutny>trevnorris: well
18:43:04  <indutny>let's see
18:43:15  <indutny>if you want to - https://github.com/joyent/node/pull/6530
18:44:02  <inolen>tjfontaine: I mean, I'd like to override the [] operator functionality when used in JS, for a v8 object.
18:44:14  <inolen>(as the buffer object does here http://nodejs.org/api/buffer.html#buffer_buf_index)
18:44:23  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:44:38  <inolen>I was fumbling around in the buffer source trying to see how exactly that was exposed but didn't find anything obvious
18:45:19  * kazuponquit (Ping timeout: 252 seconds)
18:45:20  <tjfontaine>buffer does something else
18:45:29  <tjfontaine>it uses SetIndexedProperties
18:45:36  * mikealjoined
18:45:37  <tjfontaine>but there are other mechanisms for dispatch in js itself
18:47:03  <tjfontaine>https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
18:49:41  <tjfontaine>indutny: is removing receivedShutdown function an API change for the stable branch?
18:49:58  <indutny>tjfontaine: not really, it was internal
18:50:01  <inolen>(looking) I was hoping there was a way to set this up on the FunctionTemplate
18:50:12  <indutny>tjfontaine: and undocumented http://nodejs.org/api/tls.html
18:50:15  <tjfontaine>inolen: you can yes
18:50:19  <indutny>tjfontaine: also it was useless
18:50:22  <tjfontaine>inolen: see contextify
18:50:28  <indutny>tjfontaine: we are setting .receivedShutdown property to true
18:50:30  <indutny>tjfontaine: on shutdown
18:50:36  <inolen>tjfontaine: thanks
18:50:39  <indutny>tjfontaine: so using it as function was rather complicated
18:50:42  <tjfontaine>inolen: right overwriting a function with a bool?
18:50:46  <indutny>tjfontaine: yes
18:50:50  <tjfontaine>evil.
18:50:50  <indutny>that was a bug
18:50:55  <indutny>yeah, inded
18:50:57  <indutny>indeed*
18:51:02  <indutny>I think it lived here for years
18:51:09  <indutny>but no one was using it
18:51:09  <tjfontaine>indeed
18:51:33  * mikolalysenkojoined
18:52:12  <tjfontaine>indutny: squash and land, but let me do the merge for v0.10 -> master before you land the master piece
18:52:36  * mralephquit (Read error: Connection reset by peer)
18:52:40  <tjfontaine>well
18:52:40  <indutny>tjfontaine: well
18:52:44  <indutny>tjfontaine: better do it now
18:52:50  <tjfontaine>the master stuff?
18:52:54  <indutny>yep
18:52:54  <indutny>merge
18:52:55  <tjfontaine>I'mg ogin to do a merge right away
18:53:03  <indutny>ok, I'll wait for ya
18:53:14  <tjfontaine>I just don't want both commits to land, because it will be harder for me to merge
18:54:25  <indutny>I understand
18:54:27  <indutny>:)
18:54:30  <indutny>but please hurry up
18:54:44  * calvinfojoined
18:54:49  <tjfontaine>I'm ready, so just squash and land
18:55:38  <indutny>well
18:55:44  <indutny>why not merge v0.10 in master?
18:55:45  <indutny>first
18:55:54  <indutny>I'll do second merge after it
18:55:55  <tjfontaine>why there's not much changed there
18:56:30  <tjfontaine>I mean, squash your commits and land your tls fixes in v0.10, then I'll merge v0.10 in master, and then you can do the tlswrap
18:56:51  <indutny>tjfontaine: it'd be a pain for you
18:56:54  <indutny>believe me
18:57:04  <indutny>I'd rather do my fixes for tlswrap
18:57:06  <indutny>as a part of merge
18:57:09  <indutny>hrm
18:57:13  <indutny>as a part of conflict resolution
18:57:32  <indutny>so it won't appear separately in the log
18:57:49  <tjfontaine>ok
18:58:04  <tjfontaine>well then you do the v0.10 merge, because there's only a node.gyp change
18:58:09  <indutny>ah
18:58:10  <indutny>ok
18:58:26  <tjfontaine>I mean, there's no conflicts atm
18:58:28  <indutny>here we go :)
18:58:31  <MI6>joyent/node: Fedor Indutny v0.10 * 4a2792c : tls: emit 'end' on .receivedShutdown - http://git.io/56r9IQ
18:58:40  * TooTallNatejoined
18:59:06  * st_lukejoined
18:59:35  <indutny>ok, building master merge
18:59:37  <indutny>and pushing it
18:59:40  <indutny>after running tests
18:59:43  <indutny>should take a couple of minutes
18:59:44  <tjfontaine>nod
18:59:46  <MI6>nodejs-master: #767 UNSTABLE smartos-x64 (10/684) centos-ia32 (5/684) ubuntu-ia32 (1/684) smartos-ia32 (8/684) centos-x64 (4/684) ubuntu-x64 (1/684) http://jenkins.nodejs.org/job/nodejs-master/767/
18:59:49  <indutny>everyone: please avoid pushing to master
18:59:57  <indutny>the window is closed for a couple of minutes
19:00:10  <tjfontaine><@indutny> lock(master);
19:00:15  <indutny>haha
19:00:36  * brsonquit (Ping timeout: 265 seconds)
19:02:37  <indutny>build=done
19:02:38  <indutny>running tests
19:05:04  * mikolalysenkoquit (Ping timeout: 246 seconds)
19:06:47  <indutny>here we go
19:07:22  <MI6>joyent/node: Fedor Indutny master * 1e066e4 : Merge branch 'v0.10' (+2 more commits) - http://git.io/IfXwlw
19:07:38  <indutny>tadam!
19:08:30  <tjfontaine>:)
19:08:53  <trevnorris>indutny: re 6530: done :)
19:08:57  <indutny>haha
19:09:01  <indutny>trevnorris: thank you
19:09:12  <indutny>does it mean LGTM
19:09:15  <indutny>except nits?
19:09:18  <indutny>ah
19:09:20  <indutny>I see your comment
19:09:21  <indutny>great
19:10:17  <indutny>if we'll continue doing it that fast :)
19:10:19  <indutny>I'll be out of PRs soon
19:11:41  <indutny>that scaries me very much
19:16:47  <tjfontaine>:)
19:16:59  <tjfontaine>dont' get too used to it :P
19:17:31  <MI6>nodejs-v0.10-windows: #371 UNSTABLE windows-ia32 (11/606) windows-x64 (12/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/371/
19:18:11  <MI6>joyent/node: Fedor Indutny v0.10 * f16edd2 : fs: report correct path when EEXIST - http://git.io/j5j_9Q
19:18:29  <indutny>tjfontaine: haha
19:18:32  <indutny>tjfontaine: I'll try
19:18:41  <indutny>tjfontaine: I think it may be a good idea to do another merge
19:18:58  <indutny>since I've just introduced conflicts
19:19:11  <tjfontaine>do you want to handle it then?
19:20:10  <MI6>nodejs-v0.10: #1653 UNSTABLE smartos-ia32 (7/606) osx-ia32 (1/606) linux-ia32 (3/606) osx-x64 (1/606) linux-x64 (4/606) smartos-x64 (9/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1653/
19:20:15  <indutny>tjfontaine: yes
19:20:38  <tjfontaine>thanks
19:21:13  * dshaw_quit (Quit: Leaving.)
19:22:37  <trevnorris>tjfontaine: re my comment on test macros. it would definitely be for non-standard builds. but the thought was to spew info about internal operations to stderr and compare that output to what we'd expect. like fixtures, but from debugging output.
19:22:50  <tjfontaine>that doesn't really work for tests though
19:22:55  <tjfontaine>tests need to work for release builds
19:23:25  <tjfontaine>and generally we're testing what the user expects, not verifying our internal assumptions :)
19:24:28  <tjfontaine>oh interesting
19:24:37  <tjfontaine>trevnorris: this is the failure you were seeing before? http://jenkins.nodejs.org/job/nodejs-v0.10/1653/DESTCPU=ia32,label=osx/tapTestReport/test.tap-559/
19:24:45  <trevnorris>tjfontaine: also, thanks for responding on 6664
19:25:04  <trevnorris>YES!!!!
19:25:06  * m76quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
19:25:37  <tjfontaine>indutny: can you look into that please, that's failing on all our build slaves atm
19:25:45  <trevnorris>that's the failure I'm seeing.
19:25:58  <indutny>tjfontaine: wut?
19:26:06  <tjfontaine>indutny: see that jenkins link above
19:26:06  <indutny>oh right
19:26:08  <indutny>I seen it too
19:26:13  <tjfontaine>I'm not seeing that failure locally
19:26:20  <octetcloud>If you've installed node from nodejs.org installer, how do you get the d8 tick processor? do you have to download src, and build? if you build, won't the addresses be different, so an existing v8.log won't be processable?
19:26:22  <indutny>indeed, I'm not seeing it failing now too
19:26:29  <indutny>octetcloud: npm install -g tick-processor
19:26:33  <tjfontaine>octetcloud: what indutny said
19:26:39  <indutny>octetcloud: btw, try #nodejs channel for this ;)
19:26:42  <trevnorris>octetcloud: you can build from deps/v8
19:26:53  <tjfontaine>indutny: I've never seen it locally, but all the build slaves hate it
19:26:55  <trevnorris>tick-processor module will fail if running stuff on master
19:27:04  <indutny>tjfontaine: master is not on nodejs.org
19:27:11  <trevnorris>octetcloud: here are some steps: https://gist.github.com/trevnorris/7712539
19:27:23  <indutny>almost finished merge
19:27:24  <octetcloud>thanks you all
19:27:26  <indutny>building master
19:27:28  <trevnorris>ah, missed that context
19:27:28  <tjfontaine>octetcloud: alternatively you could use dtrace ;)
19:28:25  <tjfontaine>anyway, if there's nothign else I'm needed for at the moment, I'm going back to execSync
19:28:30  <tjfontaine>yay, tests and docs
19:28:50  * m76joined
19:31:47  * abraxasjoined
19:32:40  <groundwater>@tjfontaine: yay execSync
19:32:48  <tjfontaine>hey do you have a moment?
19:33:02  <indutny>merge done
19:33:04  <indutny>running tests
19:33:08  <tjfontaine>indutny: excellent
19:33:08  <groundwater>tjfontaine: me?
19:33:10  <tjfontaine>groundwater: yes
19:33:13  <groundwater>SURE
19:33:25  * paulfryzelquit (Read error: Connection reset by peer)
19:33:34  <indutny>tjfontaine: about that CI failure
19:33:36  * paulfryzeljoined
19:33:41  <indutny>tjfontaine: I think connection is closing too eraly
19:33:43  <indutny>early*
19:33:46  <indutny>somehow
19:34:45  <indutny>or something terrible happens with s_client :)
19:35:24  <tjfontaine>this is another reason why I'd like to build s_client from our deps/openssl
19:35:33  <tjfontaine>so we can specify the cert locker and everythong
19:35:35  <tjfontaine>*everything
19:35:57  <indutny>tjfontaine: I'll figure it out
19:36:02  <indutny>tjfontaine: that's next on my list
19:36:06  <tjfontaine>nod
19:36:06  * brsonjoined
19:36:13  * abraxasquit (Ping timeout: 246 seconds)
19:36:49  <indutny>yikes!
19:36:51  <MI6>joyent/node: Fedor Indutny master * ba706ba : Merge branch 'v0.10' (+1 more commits) - http://git.io/ePqOQA
19:37:26  <MI6>nodejs-v0.10-windows: #372 UNSTABLE windows-ia32 (11/606) windows-x64 (13/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/372/
19:37:44  <MI6>nodejs-master: #768 UNSTABLE smartos-x64 (10/685) centos-ia32 (7/685) ubuntu-ia32 (3/685) smartos-ia32 (9/685) centos-x64 (7/685) ubuntu-x64 (1/685) http://jenkins.nodejs.org/job/nodejs-master/768/
19:38:57  * bajtosquit (Quit: bajtos)
19:41:19  * kazuponjoined
19:45:05  <octetcloud>tjfontaine: yes, that'd be an option for me, I'll get on that soon. I spent an hour working through a customer's prof data with ben this morning, and it was all on my machine, I build and run node from src, of course, and built d8 from src, but it made me wonder what someone who doesn't run node from src should do
19:45:21  <tjfontaine>nod
19:45:29  <octetcloud>indutny: thanks, I'll try the npm install, just to see what it looks like for people who don't run from src
19:45:48  * kazuponquit (Ping timeout: 246 seconds)
19:47:06  <inolen>octetcloud: once spawnSync makes it into node we can easily shim the environment and make the tick processor run in node with proper symbol resolution, etc.
19:47:22  <tjfontaine>hmm?
19:47:28  <tjfontaine>what does spawnSync have to do with that?
19:47:44  <inolen>tjfontaine: the tick processor script calls some d8-specific functions to spawn nm
19:47:53  <tjfontaine>oh that sort of stuff
19:54:23  * dshaw_joined
19:56:17  <inolen>tjfontaine: thanks for pointing me earlier, SetIndexedPropertyHandler worked out great. Do you know if there is a similar sort of method for providing custom iterator functionality?
19:56:36  <inolen>to handle when a user does say, for (var foobar in myobject)
19:56:57  <tjfontaine>hmm I am not sure if that's overridable or not
19:57:11  <MI6>nodejs-v0.10: #1654 UNSTABLE smartos-ia32 (8/606) osx-ia32 (1/606) linux-ia32 (2/606) osx-x64 (2/606) linux-x64 (1/606) smartos-x64 (9/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1654/
19:58:45  * dshaw_quit (Ping timeout: 245 seconds)
20:01:25  <indutny>tjfontaine: so I got it build `openssl` binary
20:01:28  <indutny>but building node fails :)
20:01:32  * indutnyhates build systems
20:01:43  <tjfontaine>hahah
20:01:44  <indutny>it suddenly started using system's openssl
20:01:45  <tjfontaine>indutny: <3
20:01:54  <tjfontaine>that's not good
20:01:55  <tjfontaine>or at least not ideal
20:02:01  <indutny>I think `direct_dependent_settings` applied to only one target
20:02:18  <MI6>nodejs-master: #769 UNSTABLE smartos-x64 (10/685) osx-x64 (2/685) centos-ia32 (8/685) smartos-ia32 (7/685) centos-x64 (10/685) ubuntu-x64 (1/685) http://jenkins.nodejs.org/job/nodejs-master/769/
20:05:09  <tjfontaine>mikeal: "GH is suppose to have a new feature soon that should let us kill the mailing list while maintaining a forum for the positive (and without doubt some of the negative) uses of the mailing list. I've got no love for Google Groups." -- I can only imagine it will leave me unenthused and wishing for yet more features
20:05:46  <mikeal>hahahahah
20:06:02  <mikeal>being that we can't kill ML threads anyway, shouldn't be much worse :)
20:06:07  <tjfontaine>....
20:06:13  <tjfontaine>mikeal: demerit
20:06:21  <tjfontaine>if you worked here ...
20:06:59  <mikeal>FYI, the features is apparently called "discussions"
20:07:05  <mikeal>and is basically issues w/o being an "issue"
20:07:17  <mikeal>bascically what a bunch of people already use issues for
20:08:10  <tjfontaine>hmm ok
20:09:18  <indutny>oh, I think
20:09:43  <indutny>it's happening just because openssl dependency is added only to apps
20:12:22  <indutny>goooosh
20:12:26  <indutny>ok, I'll figure it out
20:12:28  <indutny>in a hacky way
20:15:36  <trevnorris>othiym23: ping
20:15:47  <trevnorris>tjfontaine: you too
20:16:07  <trevnorris>what's better: EventEmitter#addObserver() or EventEmitter#addEventListener() ?
20:16:16  <tjfontaine>omg so meta
20:16:34  <tjfontaine>not the latter
20:16:44  <tjfontaine>addEventListener is too close to people fuckign up
20:17:22  <trevnorris>heh, yup.
20:17:46  <tjfontaine>not that I'm sure Observer is better, but at least it's separate enough that I'm ok
20:17:51  <tjfontaine>tell me what this does in practice
20:18:16  <trevnorris>same thing as asynclisteners. except have the option to be alerted when an EE is instantiated, etc.
20:18:24  <tjfontaine>no no
20:18:29  <tjfontaine>hmm
20:18:54  <tjfontaine>when *any* object EE.call()'s?
20:19:12  <trevnorris>right now we have to inject domain code into ee's for domains. this api will allow us to finally get rid of that.
20:19:27  <tjfontaine>is this in a branch somewhere I can see?
20:19:30  <trevnorris>you add a listener to EE and it'll tell you when it's instantiated. exact same as asynclistener.
20:19:33  <trevnorris>sure, one sec.
20:20:28  <trevnorris>tjfontaine: this is sort of it: https://github.com/joyent/node/pull/6502
20:20:32  <trevnorris>still needs work.
20:21:06  <trevnorris>whoops. merge issues.
20:21:50  <tjfontaine>I don't think you want to remove the ._events = undefined;
20:21:57  <tjfontaine>or ._maxListeners
20:22:09  * dshaw_joined
20:22:21  <trevnorris>tjfontaine: since they're always defined in the constructor, v8 treats it the same.
20:22:36  * calvinfo1joined
20:22:46  * calvinfoquit (Read error: Connection reset by peer)
20:22:55  <trevnorris>i'll check the IR output though and double check that.
20:22:59  <tjfontaine>hmm there was a reason OnceUponATime(tm) for that, this is why micro benchmarks need to come with a fucking test.
20:23:02  <tjfontaine>anyway
20:24:26  <trevnorris>tjfontaine: it's a performance gain in the least because constantly checking process.domain is a PITA.
20:24:53  <indutny>tjfontaine: you still there?
20:24:56  * skypjackjoined
20:25:02  <indutny>tjfontaine: do we have any custom gyp patches applied?
20:25:06  <tjfontaine>sure I have no doubt about that change trevnorris, just want to do only effect one thing at a time
20:25:09  <tjfontaine>indutny: no
20:25:17  <indutny>heh
20:25:23  <indutny>ok, I'll try updating it then
20:25:55  <trevnorris>tjfontaine: imo this api is the best way to work around the edge cases i'm running into trying to get asynclisteners working with event emitters.
20:26:48  <tjfontaine>trevnorris: I want to be careful with how we describe this, so this allows you to actually observe arbitrary events regardless of who the invoker actually is, the instantiation doesn't matter per se
20:27:36  * kevinswiberquit (Remote host closed the connection)
20:27:39  <tjfontaine>trevnorris: also any reason why you're not passing type to the after cb?
20:27:56  <tjfontaine>and why not also include args?
20:28:58  <trevnorris>i threw this together quickly. so the api isn't flushed out.
20:29:14  <tjfontaine>I mean obviously create is happening here as well, it's just that the pwoer is that for people to avoid having to monkey patch the hell out of EE
20:29:14  <trevnorris>i'll be looking for feedback like that once i'm serious about getting it merged.
20:29:44  <trevnorris>yeah. I think the api is enough that the othiym23's of the world won't feel the need to monkeypatch everything. ;P
20:29:57  <tjfontaine>othiym23, groundwater: won't you still have to monkey patch the people who actually just implement the EE pattern and not actually inherit? is this really that beneficial to you?
20:30:11  <tjfontaine>trevnorris: I want the domains/ee nonsense to be fixed either way
20:30:35  <trevnorris>tjfontaine: part of the API not implemented is you'll be able to also pass an EE to the functions and it'll add the create/etc. callback to an existing EE.
20:30:48  <tjfontaine>sorry, what?
20:30:50  <trevnorris>that's the part othiym23/groundwater are looking for.
20:31:12  <trevnorris>so, listeners on an EE are just some object properties. any user could set them manually.
20:31:22  <trevnorris>*object properties of the EE instance
20:32:18  <tjfontaine>sure, I'm just curious about the scenarios (which happen all the time) where people mock up EE's and NewRelic's left having to sniff validity anyway, it's still going to be lift for them
20:33:33  <trevnorris>yeah. we'll see how this goes. hopefully as we're working out the api we'll be able to foresee those scenarios.
20:33:38  <trevnorris>anyways. have to run for a bit.
20:33:39  * trevnorris&
20:33:40  <LOUDBOT>MATTHEW BRODERICK IS AN AIRFORCE SCIENTIST GUY
20:38:38  * kazuponjoined
20:39:05  * mikealquit (Quit: Leaving.)
20:43:04  * kazuponquit (Ping timeout: 246 seconds)
20:52:51  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:52:55  * kevinswiberjoined
20:54:20  * mikolalysenkojoined
21:02:03  * dshaw_quit (Read error: Connection reset by peer)
21:02:16  * kuplatup1uchanged nick to kuplatupsu
21:07:19  * dshaw_joined
21:15:42  <indutny>gosh
21:15:48  <indutny>just fought not existent gyp bug :D
21:15:50  <tjfontaine>hi fedor
21:15:53  <indutny>that was in my head
21:16:22  <tjfontaine>heh
21:16:31  <indutny>yeah!
21:16:32  <indutny>it builds
21:16:36  <tjfontaine>woo fucking hoo
21:16:40  <tjfontaine>indutny++
21:16:43  <indutny>great
21:16:49  <indutny>will open PR in 15 minutes
21:16:51  <indutny>time to eat
21:17:47  <tjfontaine>enjoy
21:22:12  * m76quit (Read error: Connection reset by peer)
21:28:02  * dshaw_quit (Ping timeout: 246 seconds)
21:30:44  * dshaw_joined
21:37:38  * mikealjoined
21:38:26  * jmar777joined
21:39:21  * kazuponjoined
21:39:28  * dshaw_quit (Read error: Connection reset by peer)
21:41:00  * kazuponquit (Read error: Connection reset by peer)
21:41:01  * dshaw_joined
21:41:07  * kazupon_joined
21:45:51  * kazupon_quit (Ping timeout: 250 seconds)
21:54:22  <othiym23>man, chose the wrong day to go to Yank Sing for lunch
21:55:36  <othiym23>trevnorris: tjfontaine is correct, we'll still have to monkeypatch until people like TJ Holowaychuk decide to opt into whatever API you use (something something snowball's chance in Hell)
21:55:56  <othiym23>tjfontaine: you have to set --harmony to use Proxy in Node now, no?
21:56:43  * dshaw_quit (Quit: Leaving.)
21:56:53  <tjfontaine>othiym23: likely yes
21:59:07  <othiym23>booooooooo
22:00:26  * dshaw_joined
22:10:06  * TooTallNatejoined
22:17:38  <indutny>tjfontaine: you still there?
22:21:11  <tjfontaine>semi, sup?
22:24:10  * mikolalysenkoquit (Ping timeout: 245 seconds)
22:26:23  <indutny>tjfontaine: https://github.com/joyent/node/pull/6675
22:26:39  <indutny>tjfontaine: may I ask you to give it a try on windows?
22:26:43  <indutny>seems to be working fine on osx
22:27:17  * mikealquit (Quit: Leaving.)
22:33:37  * st_lukequit (Remote host closed the connection)
22:34:50  <tjfontaine>indutny: push to a feature branch and node-review will run it on windows
22:34:58  <indutny>ok
22:34:59  <indutny>one sec
22:35:09  <indutny>like this? ^
22:35:11  <MI6>joyent/node: indutny created branch fix/gh-6663 - http://git.io/ETPN1w
22:35:14  <indutny>^
22:37:20  * mitsuhikoquit (Ping timeout: 246 seconds)
22:39:12  <tjfontaine>yup
22:40:10  <tjfontaine>hmm
22:40:14  * skypjackquit (Quit: Sto andando via)
22:41:52  * kazuponjoined
22:42:49  * timoxleyjoined
22:44:51  * wolfeida_changed nick to wolfeidau
22:46:48  * kazuponquit (Ping timeout: 265 seconds)
22:51:44  * dshaw_quit (Read error: Connection reset by peer)
22:52:41  * hzquit
22:54:37  <indutny>tjfontaine: sup?
22:56:57  * dshaw_joined
22:58:49  * st_lukejoined
22:59:38  * hzjoined
22:59:48  <indutny>going to sleep
22:59:48  <indutny>ttyl
23:03:33  * kevinswiberquit (Remote host closed the connection)
23:06:42  * rendarquit (Quit: Leaving)
23:31:57  * dshaw_quit (Read error: Connection reset by peer)
23:32:13  * st_lukequit (Remote host closed the connection)
23:33:07  * skebcioquit (Quit: No Ping reply in 180 seconds.)
23:33:13  * abraxasjoined
23:33:30  * pachetquit (Quit: leaving)
23:34:11  * c4miloquit (Remote host closed the connection)
23:36:50  * skebciojoined
23:37:14  * dshaw_joined
23:38:27  * abraxasquit (Ping timeout: 260 seconds)
23:42:11  * skebcioquit (Ping timeout: 260 seconds)
23:42:26  * stagasquit (Ping timeout: 250 seconds)
23:42:36  * kazuponjoined
23:47:38  * kazuponquit (Ping timeout: 264 seconds)
23:57:14  * kazuponjoined
23:58:43  * Kakeraquit (Ping timeout: 246 seconds)
23:59:37  <MI6>libuv-master-gyp: #333 UNSTABLE windows-x64 (5/198) linux-ia32 (1/199) smartos-ia32 (3/199) smartos-x64 (3/199) windows-ia32 (5/198) http://jenkins.nodejs.org/job/libuv-master-gyp/333/