00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:31  <trevnorris>othiym23: difference between those and my proposals is i'm going to completely re-implement the libuv interface to completely minimize overhead.
00:00:51  <trevnorris>othiym23: oh, i'd never allow that in core. more one of those fun thought experiments of what _could_ be done.
00:00:58  <trevnorris>like also the ability to have mutable strings.
00:01:34  <othiym23>mutable strings are a terrrible idea
00:01:38  * hzquit
00:01:39  <othiym23>terrrrrrrrrrriiiiible
00:01:46  <trevnorris>true, but also possible. ;)
00:01:56  <othiym23>wwwwwrrrryyyyyyyyyyyyyyyy
00:02:14  <trevnorris>wry?
00:02:44  <MI6>libuv-master-gyp: #367 UNSTABLE windows-x64 (5/202) smartos-ia32 (3/203) smartos-x64 (3/203) windows-ia32 (4/202) http://jenkins.nodejs.org/job/libuv-master-gyp/367/
00:05:26  <othiym23>"why"
00:05:31  <trevnorris>ah, ok. :)
00:05:38  <trevnorris>because v8 allows it, that's why. :P
00:08:27  <othiym23>I thought V8 used some mixture of interning and ropes for performance
00:08:47  <othiym23>which could have negative consequences unless you add some kind of copy on write semantics to strings
00:09:05  <trevnorris>for one and two byte strings they allow for a const char* to be passed as an "external string", but you can still change a cons char*. :P
00:09:21  <trevnorris>so basically the string lives outside of the v8 heap.
00:09:28  * petka_joined
00:09:48  <othiym23>glurb
00:09:55  <othiym23>no, sir, I don't like it
00:09:58  <trevnorris>hehe.
00:10:17  <trevnorris>there are so many fun things you can do w/ the v8 api. that's just the start. ;)
00:11:29  <othiym23>I think I've conflated V8 and SpiderMonkey, but I know that V8 does some kind of interning with JS strings, because memory benchmarks tell me so
00:12:07  <trevnorris>they do use "magic" to make things a lot faster and more memory efficient.
00:13:11  * petka_quit (Read error: Connection reset by peer)
00:13:17  * guilleiguaranquit (Read error: Connection reset by peer)
00:14:16  <txdv>v8, so good
00:15:35  * petka_joined
00:15:53  * guilleiguaranjoined
00:19:03  * brunklequit (Ping timeout: 240 seconds)
00:19:34  * brunklejoined
00:19:50  * groundwaterquit (Ping timeout: 240 seconds)
00:21:50  * groundwaterjoined
00:22:49  * brunklequit (Client Quit)
00:23:36  * AvianFluquit (Read error: Connection reset by peer)
00:23:47  * AvianFlu_joined
00:24:04  * AvianFlu_changed nick to AvianFlu
00:26:45  * Raynos_joined
00:28:38  * groundwaterquit (Ping timeout: 240 seconds)
00:29:34  <tjfontaine>trevnorris: pong
00:29:54  <tjfontaine>both v8 and SM intern strings, SM is much more traditional
00:30:21  <trevnorris>tjfontaine: two things. first, I'm almost done with the AL API change. it's not much. i'm going to do the full rewrite as i'm working on the hapi unit tests.
00:30:38  <tjfontaine>excellent.
00:31:14  <trevnorris>tjfontaine: second. had a funny idea. since c++ can capture if an error occurred it'd be possible to capture that in MakeCallback and pass the error object directly to the error handler. Which gives us two things.
00:31:33  <trevnorris>1) the ability to also pass the context (i.e. "this") to the AL error callback
00:31:47  * groundwaterjoined
00:31:49  <tjfontaine>(c++ can capture a throw you mean?)
00:31:49  <trevnorris>2) if the error is handled then we can continue w/ the execution of the c++ function. :P
00:31:52  <trevnorris>yeah
00:32:08  <tjfontaine>yes, that is indeed the power of not doing a .Rethrow()
00:32:21  <tjfontaine>but, you only need to do this when there is an observer watching for it?
00:32:37  <tjfontaine>or I guess you do need it to rethrow eventually to maintain the trace
00:33:00  <trevnorris>not necessarily. you can create the trace whenever you want.
00:33:10  <trevnorris>well, _a_ trace.
00:33:21  <trevnorris>then just make that the trace back to the call site.
00:33:21  <tjfontaine>I mean, technically the C++ execution always completes, unless we're doing an early return beside the rethrow
00:34:11  <tjfontaine>delivery of the error object to the error handler seems like a good idea if there's a listener
00:34:16  <othiym23>trevnorris: one small request: could you split ObserverInst out into a separate file?
00:34:19  <trevnorris>yeah. and we don't technically have to rethrow. just return early.
00:34:26  * brunklejoined
00:34:38  <othiym23>it's a lot easier to debug (and, potentially, to monkeypatch) when all classes are in their own modules
00:34:44  <trevnorris>othiym23: no. because that removes the possibility of inlining. sorry.
00:34:47  <tjfontaine>we only don't have to rethrow if the listener "handles" the error, right?
00:35:08  <tjfontaine>otherwise we do need to rethrow to preserve the existing functionality
00:35:30  <trevnorris>well, MakeCallback doesn't rethrow and the error still propagates.
00:36:20  <tjfontaine>I think it matters how the TryCatch is used, as there are certain circumstances where that's not always true
00:36:32  <tjfontaine>I'm not sure at the moment how that is deliniated
00:36:39  <trevnorris>hm. we should look at that then. because MakeCallback doesn't ReThrow()
00:36:50  * petka_quit (Ping timeout: 264 seconds)
00:36:55  <trevnorris>only node_contexitfy does
00:36:57  <othiym23>trevnorris: can you export ObserverInst as an expando on the EventEmitter constructor, then?
00:37:11  <tjfontaine> * Throws the exception caught by this TryCatch in a way that avoids
00:37:11  * iamstefquit (Ping timeout: 246 seconds)
00:37:12  <tjfontaine> * it being caught again by this same TryCatch.
00:37:13  <tjfontaine>right
00:38:07  <trevnorris>othiym23: sorry. still doesn't work that way. in order to inline the call the function has to be located "close" to the caller.
00:38:23  <trevnorris>othiym23: or else the AST determines it can't make assumptions about the state of the calling function.
00:38:43  * petka_joined
00:38:52  <trevnorris>or maybe i'm not understanding what "expando" means.
00:39:23  <trevnorris>oh wait. you mean something like require('events').ObserverInst?
00:39:25  <othiym23>trevnorris: I'm not asking you to put ObserverInst in a separate file, just something like "EventEmitter.ObserverInst = ObserverInst" so I can get at its proto at runtime
00:40:59  <othiym23>otherwise I have to do EventEmitter.createObserver({}).constructor.prototype (or even better EventEmitter.createObserver({}).__proto__), which is gross and makes me worry about side effects
00:41:18  * iamstefjoined
00:41:58  <trevnorris>i don't think there'd be any side effects of that. let me double check the IR. if not then i'll do it.
00:49:56  * timoxleyquit (Read error: Connection reset by peer)
00:50:36  * timoxleyjoined
00:51:52  * timoxley_joined
00:52:29  <trevnorris>tjfontaine: quick review? https://github.com/joyent/node/pull/6795
00:55:11  * Raynos_changed nick to Raynos
00:55:21  * mikealquit (Quit: Leaving.)
00:55:26  * timoxleyquit (Ping timeout: 264 seconds)
01:07:16  <trevnorris>othiym23: ok, so you want me to expose ObserverInst so you can monkeypatch the prototype?
01:07:44  <othiym23>yuuup
01:07:49  <trevnorris>...
01:07:55  <othiym23>this is a general request, not motivated by a specific use case yet
01:08:46  <othiym23>it is a LOT EASIER for instrumentation writers to write less gross monkeypatching if they have access to the classes used inside whatever it is they're monkeypatching
01:09:30  <trevnorris>you just have to forgive me. i'm wrapping my head around the need to monkeypatch an API that was created to help you to not have to monkeypatch other API's.
01:10:01  <trevnorris>othiym23: fyi, the new API is en route: https://github.com/joyent/node/pull/6795
01:10:25  <trevnorris>othiym23: i'm going to make the guts faster, but at least the basic api is at a stable enough point.
01:10:31  <trevnorris>any changes will be additive.
01:12:15  <othiym23>I'm gonna wait a couple days before I start reworking the polyfill, just to let you work some of the kinks out
01:12:35  <trevnorris>sounds good. i'm analyzing the api tests now.
01:12:51  <trevnorris>hueniverse: i have no idea what black magic your tests are doing, but it's really bugging me.
01:12:54  <othiym23>trevnorris: it is in my nature to look for extension points at all times, and I've gotten a lot of mileage out of monkeypatching thus far, so...
01:13:16  <trevnorris>hueniverse: the error callback is clearly available when the error is thrown.... so not sure how it's being missed.
01:14:14  <hueniverse>trevnorris: heh. I blame you! :-)
01:14:21  <trevnorris>othiym23: ok. you come to me with a case where exposing that is necessary and i'll do it. :)
01:14:39  <trevnorris>hueniverse: and i blame the crazy ass way domains are nested in these tests. :P
01:16:55  <trevnorris>hueniverse: does the test runner suppress output?
01:18:14  * groundwaterquit (Ping timeout: 240 seconds)
01:18:51  <trevnorris>nm... running the wrong executable. :P
01:21:26  * groundwaterjoined
01:26:02  * octetcloudquit (Ping timeout: 264 seconds)
01:33:05  <tjfontaine>trevnorris: before I get too far though this review, I do think we need a separate document for async listeners, like a mention briefly about the methods attached to `process.` but they should just be brief and contain links to a full on page that goes on in depth
01:33:21  <trevnorris>tjfontaine: that's fine.
01:33:25  <tjfontaine>mk
01:33:47  <trevnorris>do you want it part of this pr or can we pop this on now so I can continue working on fixes?
01:34:03  <trevnorris>because the docs may change based on what I find is going on w/ hapi tests
01:34:09  <tjfontaine>I'm still reading, but it can be a separate thing that you just commit
01:34:21  <trevnorris>coolio
01:34:30  <tjfontaine>I'm not too fussed with reviewing docs on the subsystem you maintain :)
01:34:43  <tjfontaine>unless they're accompanying functionality changes of course
01:34:46  <trevnorris>hehe
01:35:12  <trevnorris>i'm trying to step through this test runner for hapi. it's a freakin nightmare.
01:35:22  <trevnorris>i'm like 3 modules deep, to run one freakin test.
01:35:28  <tjfontaine>hehe
01:36:41  <tjfontaine>we're going to need to be more explicit in this documentation in the future
01:37:04  <tjfontaine>"Once attached to an asynchronous event it will persist with the lifetime of the asynchronous call stack."
01:37:22  <tjfontaine>*I* know what that means, but it's not entirely obvious from the information I've read at the moment :P
01:37:43  <trevnorris>i wrote the stupid code and I feel like I don't understand what it means. :P
01:37:46  <tjfontaine>hehe
01:39:52  * groundwaterquit (Ping timeout: 240 seconds)
01:40:55  <tjfontaine>"When multiple error() callbacks have been registered, only one of those callbacks needs to return true for AsyncListener to accept that the error has been handled."
01:41:05  <tjfontaine>trevnorris: but all callbacks that have been registered will be executed?
01:41:09  <trevnorris>yes
01:41:17  <tjfontaine>would like you to add that as a clarification
01:41:24  <trevnorris>ok
01:41:31  <trevnorris>i'll use the online github editor. :P
01:41:53  <tjfontaine>also: "If error returns true" probably better worded as: "If this registered callback returns true"
01:42:06  <trevnorris>yes
01:42:34  * groundwaterjoined
01:43:07  <tjfontaine>I wonder if `storageValue` wouldn't be better called "data"
01:43:38  <tjfontaine>because what we're talking about is "opaque user data that will be passed to each callback"
01:43:48  <tjfontaine>they may or may not use it as storage
01:43:53  <tjfontaine>or userData
01:43:58  <trevnorris>whatevs
01:44:13  <tjfontaine>it's just a bit more of a common naming convention for this pattern
01:44:17  <trevnorris>i'm notorious for being horrible at naming variables.
01:44:27  <tjfontaine>i.e. struct { void* data; };
01:46:23  * CAPSLOCKBOT_quit (Ping timeout: 245 seconds)
01:46:56  <trevnorris>i need to head. tjfontaine just keep spouting off whatever you want changed and i'll take care of it later.
01:46:58  <trevnorris>night all.
01:47:08  <tjfontaine>hahah
01:47:13  <tjfontaine>trevnorris: I'm best at spouting off :P
01:47:21  <trevnorris>heh
01:47:26  * thlorenzjoined
01:47:30  <trevnorris>hueniverse: hate you, or at least your hapi tests.
01:48:21  <tjfontaine>part of me, while not wanting to troll and get too meta with the soon-to-be EEO interface, wonders if AsyncListener objects themselves shouldn't be EEs :)
01:49:01  * thlorenzquit (Client Quit)
01:49:51  * groundwaterquit (Ping timeout: 240 seconds)
01:50:00  * groundwaterjoined
01:50:28  * timoxley_changed nick to timoxley
01:50:36  <othiym23>tjfontaine: the almighty LORD performance demands that AsyncListeners not be EEs
01:50:44  <tjfontaine>:)
01:50:53  <trevnorris>....
01:50:58  <trevnorris>yeah. i'm going to leave now.
01:51:00  * trevnorris&
01:51:14  <tjfontaine>othiym23: it wasn't meant to be trolly (per se) :)
01:52:23  <tjfontaine>othiym23: describe for me the ability to "stop listening for a specific event stack"
01:53:05  <othiym23>tjfontaine: is this for asyncListener or EE observers?
01:53:23  <tjfontaine>AL
01:54:15  * groundwaterquit (Ping timeout: 240 seconds)
01:54:55  <othiym23>"stop this listener from observing asynchronous activity" is probably how I'd put it
01:55:06  <othiym23>maybe I'm stripping context, though
01:55:23  * CAPSLOCKBOTjoined
01:55:57  <tjfontaine>how do I make github not render markdown but leave me with line numbers
01:56:44  <tjfontaine>https://raw.github.com/trevnorris/node/0b67d1cf0f2a81c70b301db1cfae20b12e164c04/doc/api/process.markdown
01:56:49  <tjfontaine>end of file :)
01:57:01  * groundwaterjoined
01:57:02  <tjfontaine>To stop capturing from a specific asynchronous event stack
01:57:02  <tjfontaine>`process.removeAsyncListener()` must be called from within the call
01:57:03  <tjfontaine>stack itself. For example:
01:58:17  <dap_>tjfontaine: curl | cat -n :)
01:58:31  * thlorenzjoined
01:58:45  <tjfontaine>dap_: heh, but I want the clicky clicky link interface :)
01:59:32  * CAPSLOCKBOTquit (Remote host closed the connection)
01:59:38  * CAPSLOCKBOTjoined
02:01:58  * brunklequit (Quit: brunkle)
02:04:15  * groundwaterquit (Ping timeout: 240 seconds)
02:05:33  * groundwaterjoined
02:07:23  * timoxleyquit (Read error: Connection reset by peer)
02:07:56  * timoxleyjoined
02:09:36  * bradleymeckjoined
02:09:51  * groundwaterquit (Ping timeout: 240 seconds)
02:10:09  * groundwaterjoined
02:11:36  * stagasjoined
02:16:32  * timoxley_joined
02:19:00  * timoxleyquit (Ping timeout: 246 seconds)
02:22:32  * nickleeflyjoined
02:26:14  * timoxley_quit (Remote host closed the connection)
02:26:31  * timoxleyjoined
02:27:42  <hueniverse>trevnorris: as soon as I'm out of this insane hapi 2.0 rewrite, I'll isolate the problems into pure node land
02:27:58  <hueniverse>trevnorris: but it is clearly your mess :-)
02:56:14  * groundwaterquit (Ping timeout: 240 seconds)
02:56:42  * groundwaterjoined
03:06:14  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:15:28  * brsonquit (Quit: leaving)
03:18:02  * octetcloudjoined
03:34:38  * groundwaterquit (Ping timeout: 240 seconds)
03:37:18  * groundwaterjoined
03:47:50  * groundwaterquit (Ping timeout: 240 seconds)
03:48:20  * groundwaterjoined
03:55:26  * groundwaterquit (Ping timeout: 240 seconds)
03:58:24  * groundwaterjoined
04:02:38  * groundwaterquit (Ping timeout: 240 seconds)
04:05:53  * groundwaterjoined
04:13:38  * indexzeroquit (Quit: indexzero)
04:16:20  <groundwater>tjfontaine: in many ways, we are emulating the EE interface in async-listeners
04:17:28  <groundwater>and again in EE-observers
04:17:43  <groundwater>the meta surrounding the second one makes my head hurt
04:23:35  <tjfontaine>yes, I know, second one aside I have some ideas
04:24:48  * calvinfoquit (Quit: Leaving.)
04:27:41  <groundwater>tjfontaine: i'm listening
04:32:07  * abraxas_joined
04:35:27  * groundwaterquit (Ping timeout: 240 seconds)
04:36:33  * abraxas_quit (Ping timeout: 246 seconds)
04:36:40  * vptrjoined
04:37:39  * groundwaterjoined
04:38:03  * AvianFluquit (Read error: Connection reset by peer)
04:38:06  <tjfontaine>well
04:38:52  * AvianFlujoined
04:49:14  * timoxleyquit (Remote host closed the connection)
04:49:52  * timoxleyjoined
04:51:49  * timoxleyquit (Read error: Connection reset by peer)
04:55:42  * timoxleyjoined
05:01:03  * groundwaterquit (Ping timeout: 240 seconds)
05:03:44  * AvianFluquit (Read error: Connection reset by peer)
05:03:53  * AvianFlu_joined
05:04:04  * groundwaterjoined
05:04:38  * M28quit (Read error: Connection reset by peer)
05:05:20  * timoxleyquit (Remote host closed the connection)
05:05:57  * M28joined
05:06:09  <tjfontaine>hmm so my domain's test is just wrong for post async listener, I wonder if that will be a problem
05:07:25  * AvianFlu_changed nick to AvianFlu
05:11:49  * thlorenzquit (Remote host closed the connection)
05:14:32  * timoxleyjoined
05:17:57  * octetcloudquit (Ping timeout: 240 seconds)
05:21:03  * groundwaterquit (Ping timeout: 240 seconds)
05:21:37  * groundwaterjoined
05:25:19  * calvinfojoined
05:30:14  * calvinfoquit (Ping timeout: 264 seconds)
05:35:27  * groundwaterquit (Ping timeout: 240 seconds)
05:35:38  * groundwaterjoined
05:39:25  * calvinfojoined
05:40:26  * calvinfo1joined
05:40:26  * calvinfoquit (Read error: Connection reset by peer)
05:41:17  * calvinfojoined
05:41:18  * calvinfo1quit (Read error: Connection reset by peer)
05:42:58  * timoxleyquit (Ping timeout: 240 seconds)
05:45:29  * timoxleyjoined
05:45:50  * calvinfoquit (Ping timeout: 264 seconds)
05:58:38  * groundwaterquit (Ping timeout: 240 seconds)
05:58:45  * groundwaterjoined
06:00:45  * julianduquequit (Ping timeout: 245 seconds)
06:01:47  * julianduquejoined
06:03:02  * groundwaterquit (Ping timeout: 240 seconds)
06:03:13  * groundwaterjoined
06:05:08  * bradleymeckquit (Quit: bradleymeck)
06:07:01  * calvinfojoined
06:08:02  * vptrquit (Ping timeout: 264 seconds)
06:09:51  * groundwaterquit (Ping timeout: 240 seconds)
06:10:26  * julianduquequit (Ping timeout: 264 seconds)
06:10:44  * groundwaterjoined
06:11:00  * julianduquejoined
06:17:38  * julianduquequit (Ping timeout: 264 seconds)
06:18:20  * julianduquejoined
06:18:22  * rvaggquit (Quit: ta ta)
06:20:36  * rvaggjoined
06:22:51  * m76joined
06:29:27  * groundwaterquit (Ping timeout: 240 seconds)
06:30:08  * indexzerojoined
06:30:17  * inolenquit (Quit: Leaving.)
06:30:48  * groundwaterjoined
06:33:08  * inolenjoined
06:34:09  * AvianFluquit (Ping timeout: 246 seconds)
06:40:51  * calvinfoquit (Quit: Leaving.)
06:41:26  <MI6>nodejs-v0.10-windows: #416 UNSTABLE windows-x64 (11/607) windows-ia32 (11/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/416/
06:48:17  * calvinfojoined
06:51:02  * AvianFlujoined
06:57:27  * dsantiagoquit (Ping timeout: 260 seconds)
07:00:29  * dsantiagojoined
07:09:51  * groundwaterquit (Ping timeout: 240 seconds)
07:09:57  * groundwaterjoined
07:49:02  * julianduquequit (Ping timeout: 240 seconds)
07:49:54  * julianduquejoined
07:57:49  * janjongboomjoined
07:58:11  * janjongboomquit (Client Quit)
07:58:45  * janjongboomjoined
07:59:23  * mikealjoined
08:00:51  * janjongboomquit (Client Quit)
08:04:00  * rendarjoined
08:04:19  * AvianFluquit (Read error: Connection reset by peer)
08:05:24  * AvianFlujoined
08:07:16  * AvianFluquit (Remote host closed the connection)
08:10:10  * calvinfoquit (Quit: Leaving.)
08:20:18  * daviddiasjoined
08:25:11  * stagas_joined
08:26:38  * stagasquit (Ping timeout: 240 seconds)
08:26:50  * stagas_changed nick to stagas
08:32:27  * janjongboomjoined
08:37:59  * calvinfojoined
08:43:51  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:51:01  * defunctzombiechanged nick to defunctzombie_zz
08:54:50  * stagasquit (Ping timeout: 264 seconds)
08:58:40  * calvinfoquit (Quit: Leaving.)
09:21:37  * groundwaterquit (Read error: Connection reset by peer)
09:21:59  * groundwaterjoined
09:26:15  * timoxleyquit (Ping timeout: 240 seconds)
09:27:51  * groundwaterquit (Ping timeout: 240 seconds)
09:27:53  * timoxleyjoined
09:29:08  * groundwaterjoined
09:36:50  * hzjoined
09:38:56  * daviddiasquit (Read error: Connection reset by peer)
09:42:49  * janjongboomjoined
09:51:27  * guybrushjoined
09:52:24  * txdvquit (Read error: Operation timed out)
10:01:03  * groundwaterquit (Ping timeout: 240 seconds)
10:03:18  * groundwaterjoined
10:08:03  * daviddiasjoined
10:17:14  * daviddiasquit (Remote host closed the connection)
10:17:43  * daviddiasjoined
10:19:27  * groundwaterquit (Ping timeout: 240 seconds)
10:19:35  * groundwaterjoined
10:22:00  * daviddiasquit (Ping timeout: 246 seconds)
10:26:15  * groundwaterquit (Ping timeout: 240 seconds)
10:27:01  * groundwaterjoined
10:29:14  * txdvjoined
10:36:39  * groundwaterquit (Ping timeout: 240 seconds)
10:37:04  * groundwaterjoined
10:41:27  * groundwaterquit (Ping timeout: 240 seconds)
10:43:34  * groundwaterjoined
10:43:42  * janjongboomquit (Ping timeout: 246 seconds)
10:44:51  * janjongboomjoined
10:47:50  * groundwaterquit (Ping timeout: 240 seconds)
10:50:38  * groundwaterjoined
10:55:03  * groundwaterquit (Ping timeout: 240 seconds)
10:55:12  * groundwaterjoined
11:04:14  * groundwaterquit (Ping timeout: 240 seconds)
11:05:04  * daviddiasjoined
11:06:13  * groundwaterjoined
11:09:15  * daviddiasquit (Ping timeout: 246 seconds)
11:13:26  * janjongboomquit (Ping timeout: 264 seconds)
11:13:51  * groundwaterquit (Ping timeout: 240 seconds)
11:14:09  * groundwaterjoined
11:16:05  * janjongboomjoined
11:22:16  * groundwaterquit (Ping timeout: 240 seconds)
11:22:41  * groundwaterjoined
11:27:03  * groundwaterquit (Ping timeout: 240 seconds)
11:27:44  * groundwaterjoined
11:35:25  * timoxleyquit
11:39:03  * groundwaterquit (Ping timeout: 240 seconds)
11:40:16  * timoxley_joined
11:41:45  * groundwaterjoined
11:46:15  * groundwaterquit (Ping timeout: 240 seconds)
11:46:44  * groundwaterjoined
11:53:06  <txdv>kombaaayaa
11:53:27  * groundwaterquit (Ping timeout: 240 seconds)
11:54:39  * timoxley_quit
11:55:46  * groundwaterjoined
12:01:33  * daviddiasjoined
12:03:40  * inolenquit (Quit: Leaving.)
12:06:39  * daviddiasquit (Ping timeout: 246 seconds)
12:07:26  * groundwaterquit (Ping timeout: 240 seconds)
12:09:18  * groundwaterjoined
12:13:50  * groundwaterquit (Ping timeout: 240 seconds)
12:15:19  * groundwaterjoined
12:19:01  * hzquit
12:23:27  * groundwaterquit (Ping timeout: 240 seconds)
12:23:52  * groundwaterjoined
12:28:15  * groundwaterquit (Ping timeout: 240 seconds)
12:28:23  * groundwaterjoined
12:29:45  * janjongboomquit (Ping timeout: 246 seconds)
12:31:08  * janjongboomjoined
12:32:38  * groundwaterquit (Ping timeout: 240 seconds)
12:35:22  * groundwaterjoined
12:39:52  * groundwaterquit (Ping timeout: 240 seconds)
12:42:54  * groundwaterjoined
12:47:27  * groundwaterquit (Ping timeout: 240 seconds)
12:47:55  * groundwaterjoined
12:52:15  * groundwaterquit (Ping timeout: 240 seconds)
12:52:40  * groundwaterjoined
12:55:24  * dcrostajoined
12:56:32  * daviddiasjoined
12:59:55  * daviddiasquit (Read error: Operation timed out)
13:02:35  * m76quit (Read error: Connection reset by peer)
13:03:51  * groundwaterquit (Ping timeout: 240 seconds)
13:06:28  * groundwaterjoined
13:14:02  * janjongboomquit (Ping timeout: 264 seconds)
13:15:26  * groundwaterquit (Ping timeout: 240 seconds)
13:15:41  * janjongboomjoined
13:18:33  * groundwaterjoined
13:31:51  * groundwaterquit (Ping timeout: 240 seconds)
13:32:15  * groundwaterjoined
13:33:56  * AvianFlujoined
13:40:15  * groundwaterquit (Ping timeout: 240 seconds)
13:41:33  * groundwaterjoined
13:41:58  * thlorenzjoined
13:45:00  * janjongboomquit (Ping timeout: 246 seconds)
13:45:51  * groundwaterquit (Ping timeout: 240 seconds)
13:46:05  * groundwaterjoined
13:46:12  * janjongboomjoined
13:49:01  * janjongboomquit (Client Quit)
13:50:44  * c4milojoined
13:56:46  * daviddiasjoined
13:57:50  * groundwaterquit (Ping timeout: 240 seconds)
13:59:36  * groundwaterjoined
14:00:13  * daviddiasquit (Read error: Connection reset by peer)
14:00:36  * daviddiasjoined
14:06:01  * indexzeroquit (Quit: indexzero)
14:07:53  * AvianFluquit (Remote host closed the connection)
14:09:33  * hueniversequit (Ping timeout: 240 seconds)
14:21:20  * kellabytequit (Remote host closed the connection)
14:24:50  <indutny>haha
14:24:52  <indutny>txdv: hey man
14:24:53  <indutny>how are you/
14:33:40  * pachetjoined
14:33:40  * pachetquit (Changing host)
14:33:40  * pachetjoined
14:34:15  * janjongboomjoined
14:35:14  <txdv>indutny: good
14:35:20  <txdv>what about you?
14:35:40  <txdv>the holidays are comming in russia
14:36:17  <txdv>its been two years and we still dont have iupv6
14:47:51  <indutny>good too
14:47:55  <indutny>haha
14:48:06  <indutny>well, yeah it is a holiday week in russia
14:51:10  * AvianFlujoined
14:57:44  * AvianFlu_joined
14:57:47  * AvianFluquit (Ping timeout: 252 seconds)
15:00:11  <txdv>disco in moscow
15:01:11  * kazuponjoined
15:02:07  * AvianFlu_changed nick to AvianFlu
15:03:28  * hzjoined
15:08:45  * mcavagejoined
15:08:45  * mcavage_quit (Read error: Connection reset by peer)
15:16:07  * hzquit (Ping timeout: 272 seconds)
15:29:15  * m76joined
15:31:21  * AvianFluquit (Read error: Connection reset by peer)
15:31:26  * AvianFlu_joined
15:33:57  * AvianFlu_changed nick to AvianFlu
15:35:42  * vptrjoined
15:46:01  * bhkblhjljbhjoined
15:46:31  <tjfontaine>Log: Revert r18451 "Revert r18449 "Reland r18383: More API cleanup." and r18450 "Unbreak build."" since necessary WebKit changes are rolled in Chromium
15:46:34  <tjfontaine>seriously ...
15:52:47  * bhkblhjljbhquit
15:59:47  * hzjoined
16:16:30  * wavdedjoined
16:30:33  * m76quit (Read error: Connection reset by peer)
16:30:57  * m76joined
16:31:39  * vptrquit (Ping timeout: 252 seconds)
16:32:13  * kellabytejoined
16:32:25  * kellabytequit (Changing host)
16:32:25  * kellabytejoined
16:32:25  * kellabytequit (Changing host)
16:32:25  * kellabytejoined
17:00:07  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:06:38  * AndreasMadsenjoined
17:15:42  * janjongboomjoined
17:15:43  * mikealquit (Quit: Leaving.)
17:15:44  * janjongboomquit (Client Quit)
17:20:24  * brsonjoined
17:26:41  * rendarquit
17:27:10  <groundwater>wat
17:29:13  * kazuponquit (Remote host closed the connection)
17:30:40  * kazuponjoined
17:32:01  * Domenic_joined
17:33:34  * mikealjoined
17:35:49  * kazuponquit (Ping timeout: 272 seconds)
17:36:18  * calvinfojoined
17:37:40  * hzquit (Ping timeout: 260 seconds)
17:39:47  * mikealquit (Quit: Leaving.)
17:42:35  * rendarjoined
17:44:15  * thlorenzquit (Remote host closed the connection)
17:47:32  * hzjoined
17:50:06  * octetcloudjoined
17:50:54  * brunklejoined
17:59:57  * kazuponjoined
18:01:30  <groundwater>trevnorris: ping
18:02:59  * calvinfoquit (Quit: Leaving.)
18:04:28  * AndreasMadsenquit (Remote host closed the connection)
18:05:29  * kazuponquit (Ping timeout: 272 seconds)
18:05:49  * inolenjoined
18:06:19  * stagasjoined
18:10:34  * TooTallNatejoined
18:23:42  <groundwater>trevnorris: https://github.com/jacobgroundwater/node/commit/c2a9c414945d0b031a9b9a9a8e3610a6f9d09313
18:24:28  * wavdedquit (Quit: Nighty night)
18:25:20  <groundwater>whoops, had a stray file in the commit. here: https://github.com/jacobgroundwater/node/commit/869e13e34d951112f1920e3118228b996eac5e34
18:25:26  <groundwater>it's on my ee-hooks branch
18:25:39  <groundwater>still working on it
18:25:54  * janjongboomjoined
18:26:25  * mikealjoined
18:28:16  * mikealquit (Client Quit)
18:30:36  * AndreasMadsenjoined
18:37:09  * calvinfojoined
18:37:14  * stagasquit (Read error: Connection reset by peer)
18:47:47  * thlorenzjoined
18:58:26  * hueniversejoined
18:59:14  * wavdedjoined
19:01:24  * kazuponjoined
19:04:03  * AndreasMadsenquit
19:04:56  * mikealjoined
19:05:57  * mikealquit (Client Quit)
19:06:32  * kazuponquit (Ping timeout: 265 seconds)
19:08:04  * mikealjoined
19:10:57  * mikealquit (Client Quit)
19:12:12  * mikealjoined
19:13:03  * mikealquit (Client Quit)
19:22:37  * thlorenzquit (Remote host closed the connection)
19:23:05  * thlorenzjoined
19:28:10  * hzquit (Read error: No route to host)
19:28:28  * hzjoined
19:39:10  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:02:14  <trevnorris>afternoon all
20:02:24  * kazuponjoined
20:02:57  <trevnorris>hueniverse: problem i'm having is figuring where the actual failure is happening. i'm getting 3 modules deep then suddenly the test exits.
20:04:11  <hueniverse>trevnorris: let me finish up this auth rewrite issue I'm on and I'll work with you in about 2 hours
20:04:40  * defunctzombie_zzchanged nick to defunctzombie
20:04:51  * mikealjoined
20:07:59  * kazuponquit (Ping timeout: 252 seconds)
20:17:02  <trevnorris>groundwater: reviewing now. thanks for your help on this. it's much appreciated. :)
20:17:29  * janjongboomjoined
20:21:21  * c4miloquit (Remote host closed the connection)
20:21:40  * janjongboomquit (Ping timeout: 245 seconds)
20:21:45  * mikealquit (Quit: Leaving.)
20:23:15  <trevnorris>groundwater: seriously dude. I should pay you for all the tests you've written for me.
20:23:22  * mikealjoined
20:26:54  <trevnorris>tjfontaine: just to solidify what I mentioned yesterday. console.* usually works, but i've had to bust out a real debugger to figure out these hapi tests.
20:27:09  <trevnorris>I can do it TheRightWay(tm) when absolutely necessary. :P
20:29:09  <trevnorris>indutny: how you been?
20:31:31  * brunklequit (Quit: brunkle)
20:33:07  * mikealquit (Quit: Leaving.)
20:33:48  <indutny>fine fine
20:33:50  <indutny>how are you?
20:34:32  * mikealjoined
20:34:35  <trevnorris>doing well. finally seeing a light at the end of the tunnel for the patches i've been fixing.
20:35:48  <Raynos>Does anyone have any tips for how to control GC pauses
20:36:02  <Raynos>we noticed a GC pause of 50ms which explains why our 99% latency is 50ms
20:36:11  <Raynos>how does one go about writing low memory / low GC node.js code ?
20:36:57  <Raynos>trevnorris: do you have any experience with low GC node?
20:37:46  * c4milojoined
20:37:50  * mikealquit (Client Quit)
20:38:19  <trevnorris>Raynos: sure, though it can get complex.
20:39:47  * c4miloquit (Client Quit)
20:40:04  <trevnorris>Raynos: try to keep object references local as possible. this will allow them to be cleaned up by simple scavenges.
20:40:35  <trevnorris>Raynos: also, the number of references to an object ~= amount of time it takes to clean up the object
20:40:39  <Raynos>I see.
20:41:03  <trevnorris>and if those references are cross context (especially across the global scope) then it has to wait for a full mark-sweep
20:41:22  <trevnorris>though indutny definitely knows more about this area.
20:41:22  <Raynos>i dont think we do cross context
20:41:36  <trevnorris>Raynos: across modules == cross context.
20:41:50  <indutny>do you have objects with a lot of keys?
20:41:58  * mikealjoined
20:42:04  * mikealquit (Client Quit)
20:42:09  <Raynos>oh, across modules is cross context ?
20:43:13  <Raynos>i'll take a look for objects with lots of keys, I'm not sure
20:43:19  <trevnorris>Raynos: yeah, because each module is ran in its own (function() { }()) to prevent cross contamination. but that means communication across modules requires a context switch.
20:43:57  * c4milojoined
20:44:05  <trevnorris>Raynos: so v8 can't make assumptions about the state of the object in another module, so it has to transverse the context every time.
20:44:19  <trevnorris>hence also one reason why functions from another module cannot be inlined.
20:46:00  <Raynos>Yeah that lack of inlining sucks :(
20:52:58  * indexzerojoined
20:55:24  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:55:57  * TooTallNatejoined
20:56:09  * brunklejoined
20:58:44  <trevnorris>tjfontaine: you want to review the doc changes in https://github.com/joyent/node/pull/6795 ?
20:59:02  * brunklepart
21:03:54  * kazuponjoined
21:05:18  * calvinfoquit (Quit: Leaving.)
21:08:13  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:09:45  <tjfontaine>trevnorris: my point would be that the rightway should save you more time in the long run :)
21:10:22  <tjfontaine>trevnorris: I will review these changes, they're probably fine, but I have a design change I want to make to AL
21:10:32  <tjfontaine>trevnorris: doesn't really change how you've done it, just how it's consumed
21:10:45  * kazuponquit (Ping timeout: 265 seconds)
21:12:43  <tjfontaine>trevnorris: on the one hand I think it will improve the concepts from the consumers, and on the other increase the applicability of AL beyond in-process tracers
21:13:06  * daviddiasquit (Remote host closed the connection)
21:16:20  <trevnorris>tjfontaine: you'll have to excuse my apprehension for any design changes you are thinking of. but i'll reserve that until after you've had time to explain what it is you want to change.
21:16:49  <tjfontaine>I'm going to do a gist
21:17:04  <tjfontaine>at the very least, dear god the names in c++ need to change to their js names :P
21:17:43  <tjfontaine>run/load/unload o0
21:18:10  <trevnorris>tjfontaine: yeah. all that has to do with the active queue. nothing with the before/after/error stuff.
21:18:22  <trevnorris>they are two different things
21:18:37  <tjfontaine>it's just poorly named without internal documentation about what is actually going on
21:18:41  <tjfontaine>not that it's your fault
21:18:49  <tjfontaine>but it's difficult for someone with new eyes to grok it
21:19:02  <tjfontaine>these changes in 6795 seem fine
21:19:32  <trevnorris>cool. i'm going to merge this just to get the new api in place. that'll help me as i'm aggressively tearing out the guts.
21:19:46  <tjfontaine>so let me first start by describing the interface that I think would be nicer for us to export as opposed to `process.addAsyncListener`
21:20:34  <trevnorris>cool
21:20:36  <tjfontaine>ideally I think this is more attractive: require('tracing').on(<module>, <probe>, ...)
21:20:52  <tjfontaine>where module would be something like 'fs' and probe something like 'read'
21:21:02  <tjfontaine>but could accept wild cards
21:21:08  <tjfontaine>so '*', '*' is functionally equivalent
21:21:59  <tjfontaine>I'm torn of if it would make sense to have a tuple of on(<module>, <probe>, <event>, ...)
21:22:00  <trevnorris>the issue is that there is not a 1:1 with the js methods to their c++ counterparts.
21:22:12  <trevnorris>which means we'd have to rape EE in order for AL to work that way
21:22:26  <tjfontaine>I think we can go far enough to make it like that, I know handlewraps sometimes make that difficult
21:22:38  <tjfontaine>but this isn't actually an EE in the proper sense
21:22:44  <hueniverse>trevnorris: where you are? still stuck on the first two errors from yesterday?
21:23:07  <trevnorris>hueniverse: right now working on a couple pr's to make it easier for me to work on those issues.
21:23:14  <trevnorris>about to merge one of them.
21:23:29  <hueniverse>trevnorris: still want me to isolate them from hapi?
21:23:34  <trevnorris>tjfontaine: please elaborate on "make _it_ like _that_"?
21:24:01  <tjfontaine>well, for one, talk to me about why we didn't include arguments for AsyncWrap in the constructor?
21:24:26  <trevnorris>hueniverse: if you want, that'd be helpful. the problem i'm having is seeing when the actual fail point occurs. like, there are two active domains and it seems that one of the domains is hit which causes the test to fail.
21:24:44  <tjfontaine>for instance, why can't we have AsyncWrap::AsyncWrap(char* module, char* probe)
21:25:41  <trevnorris>tjfontaine: because that was beyond scope at the time. i was trying to get out the basics, but what you're talking about is part of the rewrite that i want to do.
21:26:13  <tjfontaine>ok, so the WIP AL PR has this start already on it?
21:27:10  <trevnorris>tjfontaine: sort of, but first I wanted to do the EEO stuff. now that I've nailed that I feel like I have a better grasp on how to deal w/ the AL rewrite.
21:27:50  <tjfontaine>ok, as far as async events in AL handlers, I don't think it's really a big deal, we just document you don't do that, and instead store information in a buffer to be dealt with other places
21:28:26  <tjfontaine>basically I want to move to where we can have require('tracing') be the interface we're exporting for this, and then flesh out AsyncWrap further such that it's firing events for ETW, SystemTap, and DTrace
21:29:02  <trevnorris>ok
21:30:24  <trevnorris>i just don't want you to underestimate how difficult this is to do in a way that is that expansive and doesn't simultaneously screw performance across the board.
21:30:48  <tjfontaine>I don't think anything I would do would change how it operates today as far as calls into JS
21:30:52  <tjfontaine>the number of calls
21:30:54  * calvinfojoined
21:31:10  <tjfontaine>instead we move to a world where we can have fewer and more discrete calls
21:32:08  <trevnorris>that's exactly where I've always wanted it to be, but the bastardization of using EE's to emit when crap happens instead of tying to when the events actually happen in C++ makes that near impossible.
21:32:31  <tjfontaine>so while I'm interested in EEO, I'm not sure we really want to go down that road
21:32:36  <trevnorris>e.g. the net module fucking sucks
21:32:57  <trevnorris>i'm confused.
21:33:06  <trevnorris>EEO is to address a different set of problems.
21:33:15  <tjfontaine>I know, and I'm not sure we should be addressing them right now
21:33:40  <trevnorris>well, the patch is done and it offers better performance across the board.
21:34:21  <tjfontaine>how does adding the observability into EE fix performance across the board for node?
21:35:22  <tjfontaine>I know you want to remove domains from EEs which if possible with out the rest of observability seems like a fine thing
21:35:54  <tjfontaine>but I'm not sure it's an interface that will provide the kind of extensibility needed for NR and similar
21:36:25  <trevnorris>well, that'd be sad if it didn't because i've been communicating with othiym23 and groundwater every step of the way
21:36:43  <tjfontaine>I know, we need to be very careful with it is all I'm saying
21:36:48  <tjfontaine>we've already integrated AL today
21:37:29  <trevnorris>and, i'm missing what that has to do with EEO
21:37:37  <MI6>joyent/node: Trevor Norris master * d9fc6af : node: change AsyncListener API - http://git.io/TjTPWA
21:37:46  <groundwater>trevnorris: afternoon ya'll
21:38:01  <trevnorris>othiym23: api change pushed ^
21:39:53  <trevnorris>tjfontaine: i'm pretty sure we're having another case of agreeing, but on different terms. I see AL and EEO necessary now because of the "sins of the fathers". basically the strange abstractions that now make it difficult to see what's going on.
21:40:21  <trevnorris>tjfontaine: but I would _love_ to have a simple and straight forward way of doing what you've suggested, but as long as modules like "net" exist, that's impossible.
21:42:00  <tjfontaine>I know you've been working on this longer than I have, but so far I'm not yet convinced, and it's not the part that I'm concerned with right at the moment, mostly just about getting AL public interface into a slightly different shape
21:42:28  <othiym23>I want to see if I can get the EE part of CLS working on top of EEO
21:42:54  <othiym23>if I can, and the implementation isn't super gross, then that will make me feel good about the API surface
21:43:12  <othiym23>because that will mean that two substantial problems can be solved by it
21:45:06  <othiym23>I do share tjfontaine's concern that the designs of both asyncListener and EEO feel a little ad hoc, but I'm a functional programmer at heart, and most things in JS feel a little ad hoc to me
21:45:33  <tjfontaine>heh, I just want to make sure that what we do bless in 0.12 is something that is generally applicable to everyone using node
21:45:46  <tjfontaine>and I think AL is a great piece of work that opens a ton of doors
21:46:08  <tjfontaine>I just want to make sure we're not putting obstacles in our way today that will mean we can't walk through those doors later
21:47:33  <trevnorris>well then. let's get rewriting the sucker. there's a lot that needs to be done.
21:47:46  <tjfontaine>I don't think it needs rewriting
21:47:51  <trevnorris>really? i do.
21:47:53  <tjfontaine>well
21:48:03  <tjfontaine>ok the basic premise I think is sound, having the base class
21:48:17  <trevnorris>i want to disembowel it with my bare hands.
21:48:20  <tjfontaine>and a mechanism for communicating back into js these events
21:48:26  <trevnorris>yeah. that i'm cool with.
21:48:42  <trevnorris>but how the queue is managed, how the storage is handled. that _has_ to change.
21:48:59  <trevnorris>one of the things I learned when working on EEO. I did that mechanism completely wrong.
21:49:23  <trevnorris>and is currently one issue causing some of the edge cases i'm seeing.
21:51:22  * mikealjoined
21:52:01  * indexzeroquit (Quit: indexzero)
21:52:40  <othiym23>my primary concern is making CLS use fewer resources with the core implementation of AL than my polyfill
21:52:49  <tjfontaine>sure
21:53:04  <othiym23>the whole point of landing AL in core was that it would cause New Relic to use less overhead than a monkeypatching-based solution, and we're still working on realizing that
21:53:24  <trevnorris>tjfontaine: as far as needing to require() it, i'm totally cool w/ that. just need to figure out how to get that done since stuff in src/node.js require immediate access to some of the AL functions
21:53:42  <tjfontaine>othiym23: ugh, hopefully we can classify that in an appropriate way to determine the way forward
21:54:10  <tjfontaine>trevnorris: I think we can manage it, it may just be a bit of trickery
21:54:37  <othiym23>it could be that the maintainers of CLS (by which I guess I mostly mean myself) need to put more work into "bluebird-izing" it to minimize closure creation, but it's also possible that AL just catches way more stuff than it needs to for something like CLS to work
21:55:00  <othiym23>tjfontaine: there's too much require trickery in core already
21:55:08  <othiym23>util.deprecate is the bane of my existence
21:55:10  <tjfontaine>othiym23: well, it would be good trickery, not evil trickery
21:55:10  <trevnorris>othiym23: the later is exactly it. AL catches EVERYTHING
21:55:33  <tjfontaine>trevnorris: well it's a safe assumption that it is, it may not be a mortal lock though
21:55:40  <tjfontaine>we'll want to actually classify the data for it
21:56:34  <trevnorris>tjfontaine: everything we're discussing is pretty much in line w/ how I wanted the initial implementation, but found all that was too much to get done for initial implementation.
21:56:39  * mikealquit (Quit: Leaving.)
21:56:59  <tjfontaine>sure, I just wasn't entirely aware of the roadmap
21:57:05  <tjfontaine>something we're going to be fixing going forward :)
21:57:47  <trevnorris>tjfontaine: yeah. i've always wanted the user to be able to classify what they want to listen for, etc., etc. but it was getting out of hand quickly.
21:58:12  <trevnorris>tjfontaine: so I made the assumption that that functionality was additive so it was cut from the initial patch
21:58:50  <tjfontaine>certainly, moving forward I just want us to talk abotu a feature and the apis and then put milestones along the way so that we can see what these things look like and measure our progress and keep things in line with where and when we think things will land
21:59:02  <trevnorris>sounds good to me.
21:59:10  <tjfontaine>it's ok for things to slip during that, just want to be transparent with each other, and with consumers of node
22:01:24  <trevnorris>now, if you'll excuse me. i'm going to go fix the storage mechanism for AL. it's been haunting my dreams lately
22:03:26  <tjfontaine>brb myself as well
22:06:26  * kazuponjoined
22:08:40  * TooTallNatejoined
22:13:56  * kazuponquit (Ping timeout: 252 seconds)
22:17:49  * superjoejoined
22:32:59  * m76quit (Read error: Connection reset by peer)
22:37:04  * brunklejoined
22:45:10  * rendarquit (Quit: Leaving)
22:46:07  * indexzerojoined
23:04:34  * wavdedquit (Quit: Hasta la pasta)
23:06:50  * txdvquit (Read error: Operation timed out)
23:09:55  * kazuponjoined
23:10:46  * txdvjoined
23:16:10  * kazuponquit (Ping timeout: 245 seconds)
23:17:05  <trevnorris>tjfontaine: ping
23:17:32  * c4miloquit (Remote host closed the connection)
23:18:34  <trevnorris>groundwater: ping also.
23:22:11  <tjfontaine>trevnorris: pong
23:22:22  * c4milo_joined
23:22:44  <trevnorris>tjfontaine: right now we loose the context (i.e. "this") of the function that throws. is it possible to preserve this?
23:22:52  * hzquit
23:23:20  <trevnorris>this, meaning context, meaning this. man, what a crappy keyword
23:23:36  <tjfontaine>you mean `this` of where `throw` was actually invoked?
23:23:40  <tjfontaine>no probably not
23:24:46  <trevnorris>suck a duck.
23:25:09  <trevnorris>it should be possible if thrown from a c++ method, since we can catch it and invoke the error handler directly, but still. bugger.
23:25:11  <tjfontaine>it woudl be slightly different if you were asking about where Error was created
23:25:24  <tjfontaine>but those things are decoupled
23:26:24  <trevnorris>the Error object doesn't retain the creation context, does it?
23:26:56  <tjfontaine>no I don't believe so, but it's certainly something we could discuss, but it would be a breaking change :)
23:27:16  * hzjoined
23:27:33  * dcrostaquit (Quit: Textual IRC Client: www.textualapp.com)
23:28:16  <trevnorris>no. the issue is w/ the new storage mechanism. it works beautifully, except once something errors I loose the context, and hence the storage array attached to it.
23:28:41  <trevnorris>so i'm going to have to do some nasty thing of storing the stupid thing in an outer context for retrieval if something throws.
23:28:59  <tjfontaine>so what if, instead of attaching storage to this, we just pass an id?
23:29:17  <trevnorris>each AsyncListener already has its own uid
23:29:41  <trevnorris>problem is we can't just store a single array via id because then gc can't clean anything up. unless you had something else in mind.
23:29:59  <tjfontaine>well I guess it depends on the information that is required
23:30:29  <tjfontaine>if we dispatch create(id) ... before(id, context) ... error(id, error)
23:30:42  <trevnorris>we need to lock each other in a room for a weekend and hash all this out.
23:30:45  <groundwater>trevnorris: changed https://github.com/jacobgroundwater/node/tree/ee-hooks
23:30:55  * mikealjoined
23:30:56  <tjfontaine>have time this coming week?
23:31:30  <trevnorris>not this weekend, but next weekend I do.
23:31:48  <tjfontaine>I didn't mean end, more like during the week, this is our work after all :P
23:31:51  * mikealquit (Client Quit)
23:32:29  <trevnorris>sure. next mon-wed would work.
23:32:54  <tjfontaine>didnt' know how due your wife is :)
23:33:09  <trevnorris>heh, feb 7
23:33:17  <trevnorris>groundwater: awesome. thanks.
23:33:22  <trevnorris>groundwater: do all tests pass?
23:33:36  <groundwater>trevnorris yes
23:33:50  <groundwater>though i still may add more test later
23:34:10  <trevnorris>groundwater: awesome. othiym23 said he'd like to try doing some cls on top of this. i'd like to make sure that's possible before considering this merge-able.
23:34:57  <groundwater>trevnorris: agreed, and i may adjust the tests as necessary
23:35:17  <trevnorris>groundwater: awesome. feel free. and thanks again for your work on this.
23:35:29  <groundwater>trevnorris likewise!
23:35:35  <trevnorris>tjfontaine: i'm mostly open this coming week. just not friday. just let me know when would work for you.
23:35:38  <trevnorris>groundwater: :)
23:36:01  * thlorenzquit (Remote host closed the connection)
23:36:32  * thlorenzjoined
23:36:51  <tjfontaine>lemme figure it out, but my weekend is kinda fubard, so lets push at the least on monday, to earliest tuesday
23:37:02  <tjfontaine>I will get back to you so we can figure it out
23:38:18  * thlorenzquit (Remote host closed the connection)
23:38:24  <trevnorris>sounds good
23:43:00  * inolenquit (Quit: Leaving.)
23:51:38  * vptrjoined
23:56:13  <Ralith>Is there any benefit to enqueueing multiple udp send requests simultaneously as opposed to serially?