19:33:11  <trevnorris>Domenic_: also, as a side note, I think it's a design flaw to open a TCPSocket w/o first being able to setup your callback handlers. because it necessitates the ability to buffer data in the background until the callbacks are setup.
19:33:15  <piscisaureus>Now I missed everything
19:33:20  <trevnorris>heh
19:33:58  <trevnorris>piscisaureus: i'm just showing Domenic_ how being able to pass v8::External's as callback handlers will be a big win for Node: https://gist.github.com/trevnorris/9077794
19:34:36  <piscisaureus>ah, ok :)
19:34:50  <piscisaureus>I didn't miss any standards decision making phew
19:34:57  * kazuponjoined
19:35:11  <trevnorris>heh, no. when i'm around it's hard to make any decisions. ;-P
19:36:56  * thlorenzquit (Remote host closed the connection)
19:37:58  * kpdeckerquit (Read error: Connection reset by peer)
19:38:19  * kpdeckerjoined
19:43:39  * paulfryz_joined
19:44:48  * eugenewarequit (Remote host closed the connection)
19:46:10  <trevnorris>Domenic_: also on the side, there are, imo, features missing necessary for stability (also currently missing from Node).
19:46:10  <trevnorris>like, say I notice that memory is filling up. so I could do a TCP.pause(); which pauses _all_ TCP. Then do TCP.transverse(fn); which allows me to step through each connection and check its state (e.g. how much data is waiting to be written, time of last write, etc.)
19:46:49  <trevnorris>then if I find a "bad" connection (e.g. data not being written) I can simply close that connection then TCP.resume(); to keep things going normally.
19:47:59  * paulfryz_quit (Ping timeout: 252 seconds)
19:50:20  * bajtosjoined
19:54:10  * thlorenzjoined
19:54:59  * bajtosquit (Ping timeout: 260 seconds)
19:58:38  <Domenic_>trevnorris: ok, so this is basically saying that on('data', ...) gives you possible perf wins because then you can process the data in C++ by passing a C++ callback?
20:00:42  <Domenic_>and it wouldn't work to do cppOndata(server.read()) ?
20:07:22  <trevnorris>Domenic_: data comes in through then native layer, right? so what this does is allow the native layer to hand off the data directly to another native method, bypassing the need to interface w/ JS.
20:08:24  <trevnorris>cppOndata(server.read()) would require transversing from C++ to JS and creating as Object/ArrayBuffer/etc. then passing that back down to C++ where it then has to be parsed and the data extracted.
20:08:38  * kazuponquit (Ping timeout: 264 seconds)
20:09:26  <Domenic_>oh i see that's where the void* comes in
20:09:30  <trevnorris>yeah
20:10:21  <trevnorris>in the native layer, it would detect there's a native method waiting for the data then do a static_cast<FreeCallback>(cb_info->cb)(char*, length);
20:10:32  <Domenic_>well i mean ideally the C++ could just reach into the stream directly, but in this case you are trying to mediate it via a setup in JS---i.e. via server.ondata(cppOndata). Hmmm...
20:10:56  <Domenic_>you could mediate via pipe I guess :-S
20:11:13  <trevnorris>the advantage here is i can start to chain c++ methods together and create complex data paths, but never have the data reach JS.
20:11:19  <Domenic_>server.pipeTo(cppWritableStream), where pipeTo detects C++ streams and does some nice stuff.
20:11:27  <Domenic_>pipeTo in this case being implemented in C++ as well
20:11:59  <trevnorris>i'm not sure what you mean by c++ stream. under the hood it's all a c++ stream.
20:12:34  <Domenic_>well, you can also create streams purely in JS
20:12:54  <trevnorris>in my version server.ondata() is also implemented in C++, because you can create a Persistent reference to the callback and call it more quickly. instead, like how we now do it, and query out the callback from a new Object on every event.
20:13:02  <trevnorris>it's a pain, and very slow.
20:13:30  <trevnorris>Domenic_: sure. but that's an abstraction. in this case, i only care about the C++ to JS binding layer.
20:13:46  <trevnorris>then people can use that to implement whatever fluffy JS based streams interface they want
20:14:29  <indutny>tjfontaine: heya
20:14:46  <indutny>tjfontaine: what do you think about doing js API and feature freeze?
20:14:47  <indutny>in node
20:15:04  <indutny>I mean like
20:15:04  <indutny>today
20:15:05  <indutny>:P
20:15:10  * eugenewarejoined
20:15:13  <indutny>trevnorris: piscisaureus: any objections?
20:15:15  <indutny>AlexisMocha: ?
20:15:30  <trevnorris>Domenic_: basically, node core has Streams and EventEmitters. Both abstractions that make it difficult for people to implement their own interfaces w/o a lot of overhead.
20:16:00  <trevnorris>Domenic_: by focusing on the JS/C++ binding layer users can then implement whatever interface they want at practically zero unnecessary overhead.
20:16:07  <trevnorris>indutny: what? and when?
20:16:10  <MI6>joyent/libuv: Fedor Indutny v0.10 * 703a9e6 : sunos: handle rearm errors - http://git.io/yEiEiQ
20:17:18  <trevnorris>Domenic_: this is why I hate the idea of forcing promises in these types of APIs. Something like a TCPSocket should be very low level and allow users to implement a Promise based abstraction on top of that.
20:17:55  <trevnorris>it definitely shouldn't be defined in a standard. because then writing any sort of uber-performant code becomes much harder.
20:18:03  * Domenic_eyerolls
20:19:26  <trevnorris>Domenic_: what is hard to grasp here? the only way for C++ and JS to interface is via basic callbacks. how is it difficult to understand that it would be good to define the "standard" where there is as little abstraction as possible?
20:19:53  <indutny>trevnorris: node.js
20:19:54  <indutny>v0.11
20:20:05  <Domenic_>promises are a fine JS <-> C++ interface as well. you are thinking that the way you have always done things is the only way.
20:20:08  <trevnorris>indutny: um. not until I am able to finish my last AL patch.
20:20:13  <indutny>oh, ok
20:20:17  <indutny>is it happening soon?
20:20:18  <indutny>:)
20:20:31  <trevnorris>indutny: yeah. hopefully i'll have it ready for review by the end of the day.
20:21:08  <trevnorris>Domenic_: seriously? so you're telling me there's a C++ API that allows Promise::Call(), like the v8 Function::Call()?
20:21:44  <trevnorris>Domenic_: i'm doing things the way that are the only possible way based on how the v8 api exists.
20:21:44  <Domenic_>trevnorris: of course there is. You think promises are implemented in JS when they're in V8?
20:22:24  <trevnorris>Domenic_: i'd love for you to show me where that API is.
20:23:04  <Domenic_>V8PromiseCustom::call
20:23:15  * mikolalysenkoquit (Ping timeout: 272 seconds)
20:23:41  * kenperkins_quit (Remote host closed the connection)
20:23:50  <indutny>trevnorris: good :)
20:24:10  <trevnorris>Domenic_: file please?
20:24:17  * kenperkinsjoined
20:24:29  <Domenic_>http://src.chromium.org/viewvc/blink/trunk/Source/bindings/v8/custom/V8PromiseCustom.cpp?pathrev=153560#1284
20:24:42  <Domenic_>this is an old version, not sure about newer ones
20:24:48  <Domenic_>but it was in my awesomebar
20:24:56  <trevnorris>Domenic_: really? do you look at the v8 API itself?
20:25:07  <trevnorris>that's all implemented for the browser, not in v8 proper
20:25:08  * sblomquit (Read error: Connection reset by peer)
20:25:21  <Domenic_>yes, they are working in blink first, then porting to v8
20:25:32  * sblomjoined
20:27:39  * eugenewarequit (Ping timeout: 260 seconds)
20:29:27  * rmgquit (Remote host closed the connection)
20:30:52  * rmgjoined
20:31:20  <trevnorris>Domenic_: well, if you've read my latest blog post responding to that asinine tweet taking what I said way out of context, it says I'll legitimately give alternative APIs a try once they actually exist in v8.
20:31:26  * mikolalysenkojoined
20:31:44  <trevnorris>Domenic_: regardless, have a link for v8 team saying they'll implement that into v8 after blink?
20:32:09  <Domenic_>https://groups.google.com/forum/#!topic/v8-users/A2ODAZ6kKaE
20:35:17  * rmgquit (Ping timeout: 252 seconds)
20:38:39  <MI6>joyent/libuv: Fedor Indutny master * fc40836 : Merge branch 'v0.10' (+1 more commits) - http://git.io/zQKkkw
20:38:52  <indutny>ok, one less thing
20:42:12  <trevnorris>sorry. was tending to the infant. :)
20:44:26  <trevnorris>Domenic_: your comment of "you are thinking that the way you have always done things is the only way" is a bit obtuse. my api decisions are based on how things can be improved now, not on api designs that aren't implemented.
20:44:30  * paulfryz_joined
20:44:44  <trevnorris>if a Promises based C++ api existed right now, then i'd add it to my implementation benchmarks
20:46:22  <trevnorris>Domenic_: and you're also missing the point that the key part of Node is that it basically makes libuv calls accessible from JS. this also only uses basic callbacks. so, again, using promises in between is a layer of abstraction.
20:48:27  * dshaw_joined
20:49:26  * paulfryz_quit (Ping timeout: 264 seconds)
20:52:30  * mikolalysenkoquit (Ping timeout: 265 seconds)
20:57:58  <tjfontaine>indutny: I can release libuv v0.10 then?
20:58:02  <indutny>yep
20:58:06  <indutny>definitely
20:58:16  <tjfontaine>ok, anything else due for v0.10?
20:58:36  <indutny>hm...
20:58:41  <indutny>well there was one bug fix
20:58:42  <indutny>in libuv
20:58:51  <indutny>but the guy hasn't signed CLA yet
20:59:00  <tjfontaine>oh right the epoll stuff
20:59:05  <prettyrobots>How do I do a debug build of Bud?
20:59:14  <indutny>so, I guess it should be fine for now
20:59:18  <indutny>unless saghul has something to say
20:59:23  <indutny>tjfontaine: https://github.com/joyent/libuv/pull/1100
20:59:43  <indutny>prettyrobots: are you building with `make`? If yes - `BUILDTYPE=Debug make -C out/`
20:59:50  <prettyrobots>Yes.
20:59:52  <prettyrobots>Thank you.
20:59:57  * rmgjoined
21:00:09  <tjfontaine>indutny: nod
21:00:26  <indutny>prettyrobots: you are welcome :)
21:00:46  * mikealquit (Quit: Leaving.)
21:02:08  <MI6>joyent/libuv: tjfontaine created tag v0.10.25 - http://git.io/dr2g-w
21:02:10  <MI6>joyent/libuv: Timothy J Fontaine v0.10 * 714bec1 : Now working on v0.10.26 (+1 more commits) - http://git.io/DN5Uvg
21:02:35  * AvianFlu_joined
21:02:42  <indutny>yay! :)
21:04:35  * AvianFluquit (Disconnected by services)
21:04:42  * AvianFlu_changed nick to AvianFlu
21:04:57  * kazuponjoined
21:05:52  * abraxasjoined
21:10:29  <WalrusPony>oh boy
21:10:33  <WalrusPony>new stable version of libuv!
21:10:46  * abraxasquit (Ping timeout: 260 seconds)
21:12:46  * txdvquit (Ping timeout: 245 seconds)
21:13:18  <tjfontaine>isaacs: hey you around?
21:14:37  * txdvjoined
21:20:54  <MI6>joyent/node: Timothy J Fontaine v0.10 * 3e6e634 : test: make test-net-error-twice less racey (+1 more commits) - http://git.io/yCZBDA
21:24:15  * sh1mmerquit (Quit: sh1mmer)
21:28:14  * rmgquit (Remote host closed the connection)
21:28:55  * sh1mmerjoined
21:31:18  <trevnorris>tjfontaine: it's taking my muscle memory a while to get out of the habit of typing process.*AsyncListener() :P
21:31:40  <prettyrobots>indutny: Can I target for an XCode build/project with this gyp configuration?
21:31:43  <prettyrobots>For Bud?
21:36:04  * rmg_joined
21:36:21  <MI6>joyent/node: Pedro Ballesteros v0.10 * 1d734a7 : doc: stdout blocking or non-blocking behaviour - http://git.io/_huOTw
21:38:32  * kazuponquit (Ping timeout: 252 seconds)
21:40:45  <prettyrobots>What if I made a libuv TLS library.
21:40:53  <prettyrobots>?
21:41:07  <prettyrobots>Would that be interesting? Or is that not that interesting.
21:41:33  <prettyrobots>I need a TLS client socket. I'm seeing how I could extract it from Bud. I might be able to do it as an open source project.
21:46:35  <mmalecki>prettyrobots: that's be freaking awesome
21:46:47  <prettyrobots>Okay. So, no one else has done it.
21:46:50  <prettyrobots>Wow.
21:47:08  <prettyrobots>Cool. Maybe I can. I'd rip apart Bud to get it done.
21:47:18  <mmalecki>prettyrobots: if that library did work in uv_queue, I'll write a node binding for it
21:51:57  * mikealjoined
21:52:03  * mikealquit (Client Quit)
21:52:30  * m76quit (Read error: Connection reset by peer)
21:53:52  <MI6>joyent/node: Anton Khlynovskiy v0.10 * 1fa5cff : docs: clarify process.stdin and old mode - http://git.io/2YFAsA
21:54:41  <trevnorris>ah yes. for the love of... finally got it working. now, to just write up a massive number of tests and update all the docs to match the new functionality. :P
21:55:29  <trevnorris>damn you setImmediate()....
21:56:23  * mikealjoined
21:59:48  <trevnorris>groundwater: you around?
21:59:55  <groundwater>trevnorris ahoy!
22:00:14  <trevnorris>groundwater: hey dude. so AL just got a lot more complex... (didn't think that was possible)
22:01:08  <trevnorris>groundwater: here you can see there are a set number of providers that can be filtered: https://github.com/trevnorris/node/blob/al-pass-provider/lib/tracing.js#L119-L137
22:01:35  <trevnorris>groundwater: and the name of that provider is now passed as the second argument to the create() callback. so you can know where the call is coming from.
22:01:43  <groundwater>right
22:02:07  <groundwater>trevnorris so this is changing the user-facing api, right?
22:02:36  <trevnorris>groundwater: extending it. don't think there's anything that will break backwards compatibility.
22:03:12  <trevnorris>but there is one strange quirk. process.nextTick() doesn't have its own provider type, since it's more of an "extension" of where it's being called. so it inherits the provider type of the caller.
22:03:39  <tjfontaine>to make nextTick be viable I think you can't filter any messages
22:03:56  <trevnorris>groundwater: also, the error() callback will pass the context of the originating context of the callstack. _not_ the context of the object that actually threw.
22:04:02  <trevnorris>tjfontaine: come again?
22:04:20  <isaacs>tjfontaine: whassup?
22:04:30  <tjfontaine>trevnorris: so I filter only TCP, the only next ticks I get notified for are those that are cleared through a makecallback out of the tcp wrap?
22:04:30  <groundwater>trevnorris okay i understand
22:04:46  <tjfontaine>isaacs: LeftWing had some shasum mismatches, he's in #npm
22:05:33  <trevnorris>tjfontaine: well, whose callstack originates from TCP. so you can be several calls deep, but it all depends on where the call originated from.
22:06:11  <tjfontaine>where the original cb was enqueued, or who called MakeCallback?
22:07:28  <trevnorris>where the cb was enqueued. because, for example, StreamWrap makes calls to MakeCallback for a lot of different things.
22:07:40  <trevnorris>but StreamWrap doesn't have a provider type itself.
22:07:51  <tjfontaine>no the cb is enqueued in process.nextTick, so that's where you store it's provider?
22:09:31  <trevnorris>code will help. tracing.addAL(TCP, { create: fn(stor, provider) { log(provider); }});
22:09:31  <trevnorris>net.createServer(fn() { process.nextTick(fn() { });
22:09:31  <trevnorris>output: TCP\nTCP
22:10:01  <trevnorris>the nextTick will have the TCP provider because it was called within the callback of another TCP
22:10:23  <tjfontaine>no, the fn will be called by whomever happens to transition through makecallback
22:10:33  <prettyrobots>rendar: It is a bit complicated.
22:10:41  <rendar>prettyrobots: ? why?
22:10:47  <prettyrobots>rendar: But, it looks like Bud has done most of the work.
22:10:49  <tjfontaine>we may not actually be in tcp's stack when that happens
22:11:09  <prettyrobots>rendar: More complicated than nothing.
22:11:26  <tjfontaine>bah, indutny ping
22:11:30  <trevnorris>tjfontaine: when fn() is called, that is the beginning of another callstack. and it was queued in the creation context of TCP. still with me?
22:11:37  <rendar>prettyrobots: i see
22:11:42  <trevnorris>so the provider of fn() will be TCP
22:11:59  <tjfontaine>trevnorris: so you're storing the provider from when nextTick was enqueued, and what if I'm at the start of the node process?
22:12:11  <prettyrobots>rendar: This could be extracted to create a TLS wrapper for a stream.
22:12:12  <prettyrobots>https://github.com/indutny/bud/blob/master/src/client.c
22:12:12  <trevnorris>then it will be NONE
22:12:37  <rendar>prettyrobots: got it, but why then one couldn't use Bud directly, at that point?
22:12:41  <prettyrobots>The wrapper could expose the same interface as any other `libuv` stream.
22:12:52  <prettyrobots>What does Bud do?
22:13:22  <trevnorris>well, at least it should be. right now that test is failing.
22:13:23  <rendar>a terminator, isn't it?
22:13:40  <trevnorris>tjfontaine: have any qualms w/ how this operates?
22:14:09  <trevnorris>haha, wait. it is passing. wasn't passing because I had set a provider. :P
22:14:48  <tjfontaine>I am reading the code, because I'm not explaining myself well enough over irc for you to understand what I'm trying to get across
22:15:17  <trevnorris>tjfontaine: there is still some issues with the code. allow me to get the tests up and that should make a lot more sense.
22:15:26  <tjfontaine>no that's not the problem
22:15:35  * rmg_quit (Remote host closed the connection)
22:15:38  <prettyrobots>rendar: Yes. I'd like to extract a TLS wrapper from Bud.
22:15:48  <tjfontaine>I'm trying to rationalize the logic of when the provider is to be stored
22:15:48  <prettyrobots>A TLS socket wrapper.
22:17:46  <groundwater>tjfontaine trevnorris i'm listening/following, i just don't have anything to add yet
22:17:53  <trevnorris>groundwater: thanks :)
22:18:09  <tjfontaine>trevnorris: I'm in a tcp cb, say on connection, and I call an fs operation that immediately nextTick's, the nextTick will be registered to TCP and not to FS
22:18:43  <tjfontaine>or it could be anythign that does a dns.lookup and uses an ip that gets immediately deferred
22:19:04  <trevnorris>net.connect(..., fn0() { fs.stat(..., fn1() { p.nextTick(); }); }); <- the nextTick will be FS
22:19:32  <tjfontaine>it's not about the result of fs.stat, it's if fs.<foo> called nextTick implicitly
22:20:31  <trevnorris>tjfontaine: ah, you're taking about if inside node core code we call a nextTick() ?
22:20:55  <tjfontaine>yes, that's where the peril is most obvious
22:21:04  <rendar>prettyrobots: i see
22:21:24  <prettyrobots>rendar: He's using `ringbuffer`.
22:21:27  <rendar>prettyrobots: well i need some sleep now, we'll talk about this tomorrow if you want, where are you from?
22:21:33  <trevnorris>ahhhhhhh. yeah. because we screw w/ some stuff and make the call look async even though it's in another... got you.
22:21:51  <prettyrobots>rendar: A `ringbuffer` that is a wrapper around SSL BIO.
22:21:51  <trevnorris>tjfontaine: thanks for thinking of this case. so, have an idea to mitigate the issue?
22:22:15  <prettyrobots>New Orleans. I'm currently in California.
22:22:26  <tjfontaine>well, I'm just kinda worried about trying to shoe horn AL in for nextTick/timers beyond the first transition, that is AW doing its thing saying "Hey, I moved from C++ to JS"
22:22:43  <tjfontaine>that's where ALs bread and butter is
22:22:57  <tjfontaine>more often than not it's where the majority of the logic is handled as well
22:23:51  <trevnorris>i think I got timers working well. because of the screwy way setImmediate is handled it did require some finagling. but nextTick does worry me.
22:24:19  <trevnorris>we can't just blindly call AL for every nextTick. that's where a large amount of perf hit is coming from. nextTick is used all over the place.
22:25:04  <trevnorris>and if we don't handle nextTick at all, then that's a lot of callstacks that will be lost in the process.
22:25:35  <tjfontaine>I know, I'm mostly worried about lost call stacks if we say we are trying to handle it, and then the bug reports and the question about how we fix that in stables
22:25:51  <tjfontaine>I worry that the fallback here *would* be just to always fire next ticks regardless of provider
22:26:52  <trevnorris>ok... i'm not a fan, but for the time being it's a viable fallback.
22:27:23  * kenperkinsquit (Ping timeout: 272 seconds)
22:27:36  * austoquit (Quit: austo)
22:27:47  <tjfontaine>groundwater: I presume you're tracing call stacks when something is enqueued, and binding, and on call checking the latency at that point?
22:27:56  <trevnorris>oh wait... son of a bitch. this means keeping a simple list of async callstacks would also be affected by this.
22:28:21  * daviddiasquit (Ping timeout: 248 seconds)
22:28:41  <trevnorris>it's so sad. the C++ side is so simple. working this around all the JS fluff is where almost all my pain has come.
22:28:59  <tjfontaine>which is why I vote for a different solution, because AW is pretty clear cut
22:29:18  * austojoined
22:29:35  <trevnorris>tjfontaine: I am totally for probes. in my mind these always just had a different use case.
22:29:41  <tjfontaine>nod
22:31:08  <trevnorris>hm. well, at the least I have the mechanics to pass in the provider type of the call. that should help with probe filtering.
22:31:45  <trevnorris>tjfontaine: on the side.didn't you say that dtrace or the like will replace bits of assembly with its own execution stuff?
22:32:18  <tjfontaine>trevnorris: yes it replaces 3 noop instructions with it's own jump when the probe is enabled
22:33:25  <trevnorris>tjfontaine: think I already brought this up, but calling an empty v8::Function from JS is < 10ns. sprinkling those around core and allowing dtrace to hook into those functions would come at almost no performance cost.
22:33:40  <tjfontaine>trevnorris: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill_html/
22:33:47  <tjfontaine>trevnorris: that's what we already do
22:34:05  <trevnorris>tjfontaine: yeah, but it's not a cross platform solution right?
22:34:27  <tjfontaine>that's part of what my 5940 is for
22:34:51  <tjfontaine>on platforms where dtrace works (sunos, freebsd, darwin) use that, where you have etw (windows) you're fine
22:35:00  <tjfontaine>on linux you get our static probes with systemtap
22:35:04  <trevnorris>and, um. linux?
22:35:05  * kazuponjoined
22:35:07  <trevnorris>ok
22:35:14  <tjfontaine>for user defined you'll only get our probes in process (like with NR)
22:37:02  <trevnorris>tjfontaine: fyi, this type of thing is going to eat your face: https://github.com/joyent/node/pull/5940/files#diff-e3bc37430eb078ccbafe3aa3b570c91aR157
22:37:07  <groundwater>tjfontaine everything we do around async-listeners is encapsulated in continuation-local-storage
22:37:14  <trevnorris>that's the type of thing i'm trying to mitigate against.
22:37:53  <tjfontaine>trevnorris: the style of the javascript can be massaged, you can pass variables to the function so they can be hoisted out, stop freaking out about that part, substance over style
22:39:00  <trevnorris>what i'm getting at is that noop JS calls that have to make a context jump are more expensive than a noop C++ call.
22:39:02  <tjfontaine>https://github.com/joyent/node/pull/5940/files#diff-e6ef024c3775d787c38487a6309e491dR414
22:39:08  <tjfontaine>that's where I already do what you're worrying about
22:39:23  * hzjoined
22:40:27  <trevnorris>sorry, I didn't mean the call style in general. i meant more of calling the function at all.
22:40:53  <tjfontaine>ya, if I stop calling all functions, the cpu can idle very quickly ;)
22:41:04  <trevnorris>;-P
22:41:22  <trevnorris>i mean, going with noop C++ calls that dtrace can hook into would be far more efficient.
22:41:52  <tjfontaine>but not in a way that's cross platform
22:42:16  * morganhelockerquit (Quit: morganhelocker)
22:42:16  <tjfontaine>the point of the user definable api is such that we can let NR and others consume the same static probe points
22:43:10  <tjfontaine>I ask this probably knowing the answer, but I presume you don't want us to ever call .emit() as well?
22:43:53  * rendarquit
22:46:01  * paulfryz_joined
22:47:08  <trevnorris>tjfontaine: my first concern is how this will affect performance when probes aren't being used. i'll manage from there.
22:47:43  <trevnorris>but in terms of perf, never touch Function#bind() or declare a function within another function. but emit() I could probably live with.
22:47:52  <tjfontaine>it's roughly the same concern as calling emit when there are no listeners, in the event you're on a system with dtrace/etw/systemtap you'll get one extra call to a noop c++ function
22:48:15  <trevnorris>ok. i'll think about it. bbiab
22:48:16  * trevnorris&
22:50:28  * paulfryz_quit (Ping timeout: 265 seconds)
22:55:35  * kazuponquit (Ping timeout: 260 seconds)
22:56:10  <MI6>joyent/node: tjfontaine created branch v0.10.26-release - http://git.io/zmsrvQ
22:57:03  * austoquit (Quit: austo)
23:00:52  * thlorenzquit (Remote host closed the connection)
23:01:38  * thlorenzjoined
23:02:27  * thlorenzquit (Remote host closed the connection)
23:06:46  * abraxasjoined
23:09:09  * rmgjoined
23:11:29  * mikolalysenkojoined
23:11:29  * abraxasquit (Ping timeout: 252 seconds)
23:15:09  * AvianFluquit (Remote host closed the connection)
23:16:50  * kpdeckerquit (*.net *.split)
23:16:50  * piscisaureusquit (*.net *.split)
23:16:52  * octetcloudquit (*.net *.split)
23:16:55  * seldoquit (*.net *.split)
23:16:58  * trevnorrisquit (*.net *.split)
23:18:36  * kpdeckerjoined
23:18:36  * piscisaureusjoined
23:18:36  * octetcloudjoined
23:18:36  * seldojoined
23:18:36  * trevnorrisjoined
23:18:49  * bradleymeckquit (Quit: bradleymeck)
23:26:51  * morganhelockerjoined
23:27:51  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:32:16  * mikealquit (Quit: Leaving.)
23:35:14  <MI6>joyent/node: Timothy J Fontaine v0.10.26-release * cc56c62 : build: readd missing installer resources - http://git.io/hYKvjQ
23:39:40  * kpdeckerquit (Quit: Leaving.)
23:42:43  * piscisaureusquit (Ping timeout: 260 seconds)
23:46:26  * jmar777_joined
23:46:32  * jmar777quit (Read error: Connection reset by peer)
23:46:49  * paulfryz_joined
23:50:59  * mikolalysenkoquit (Ping timeout: 272 seconds)
23:51:07  * paulfryz_quit (Ping timeout: 252 seconds)
23:55:48  * mikealjoined
23:57:39  <Ralith>indutny: woops, trivial mistake; will push a fix tonight
23:57:54  * eugenewarejoined
23:57:58  <Ralith>shame the buildbot doesn't do windows
23:58:26  * inolenquit (Read error: Connection reset by peer)
23:58:45  * inolenjoined
23:58:46  * dqminhquit (Ping timeout: 260 seconds)
23:59:36  * paulfryzelquit (Remote host closed the connection)
23:59:42  * indutnyquit (Ping timeout: 260 seconds)