00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:05  <MI6>libuv-master-gyp: #366 UNSTABLE windows-x64 (5/202) smartos-ia32 (3/203) smartos-x64 (3/203) windows-ia32 (5/202) http://jenkins.nodejs.org/job/libuv-master-gyp/366/
00:00:08  * ircretaryjoined
00:10:15  * brsonquit (Ping timeout: 272 seconds)
00:10:37  * brsonjoined
00:42:36  * mikealquit (Quit: Leaving.)
00:55:09  * titojoined
00:56:55  * kazuponjoined
01:03:54  * thlorenzquit (Remote host closed the connection)
01:05:05  * thlorenzjoined
01:08:42  * calvinfoquit (Quit: Leaving.)
01:09:41  * calvinfojoined
01:19:17  * thlorenzquit (Ping timeout: 272 seconds)
01:30:39  * kazuponquit (Ping timeout: 260 seconds)
01:32:17  * stagasquit (Read error: Connection reset by peer)
01:34:09  * stagasjoined
01:41:13  * mikealjoined
01:41:20  * timoxleyjoined
01:51:48  * timoxleyquit (Ping timeout: 245 seconds)
01:57:01  * brsonquit (Quit: leaving)
01:57:04  * inolenquit (Quit: Leaving.)
01:59:37  * timoxleyjoined
01:59:54  * mitsuhiko_quit (Ping timeout: 252 seconds)
02:02:36  * m76joined
02:06:21  * thlorenzjoined
02:06:49  * daviddiasjoined
02:26:56  * kazuponjoined
02:32:15  * kazuponquit (Ping timeout: 260 seconds)
03:01:39  * timoxleyquit (Read error: Connection reset by peer)
03:02:09  * timoxleyjoined
03:04:04  * timoxleyquit (Read error: Connection reset by peer)
03:12:23  * timoxleyjoined
03:12:25  * mitsuhikojoined
03:18:39  * timoxleyquit (Read error: Connection reset by peer)
03:25:12  * kenperkinsquit (Quit: Computer has gone to sleep.)
03:25:37  * kenperkinsjoined
03:27:58  * kazuponjoined
03:32:51  * kazuponquit (Ping timeout: 240 seconds)
03:36:17  * timoxleyjoined
04:20:52  * AlexisMocha_joined
04:22:21  * AlexisMochaquit (Ping timeout: 252 seconds)
04:28:56  * kazuponjoined
04:31:01  * abraxasjoined
04:32:55  * inolenjoined
04:34:51  * vptrquit (Quit: WeeChat 0.3.5)
04:35:28  * abraxasquit (Ping timeout: 246 seconds)
04:35:37  * kazuponquit (Ping timeout: 272 seconds)
04:38:35  * bradleymeckjoined
04:39:27  * m76quit (Read error: Connection reset by peer)
04:40:07  * timoxleyquit (Ping timeout: 260 seconds)
04:53:34  * timoxleyjoined
05:07:56  * Ralith_changed nick to Ralith
05:08:08  * stagasquit (Ping timeout: 265 seconds)
05:09:15  * kenperkinsquit (Quit: Computer has gone to sleep.)
05:16:55  * Damn3dquit (Ping timeout: 260 seconds)
05:19:29  * Damn3djoined
05:24:07  * timoxley_joined
05:25:56  * thlorenzquit (Remote host closed the connection)
05:26:31  * thlorenzjoined
05:26:48  * timoxleyquit (Ping timeout: 245 seconds)
05:30:58  * thlorenzquit (Ping timeout: 245 seconds)
05:31:25  * kazuponjoined
06:04:43  * kazuponquit (Ping timeout: 246 seconds)
06:06:18  * timoxley_quit (Ping timeout: 252 seconds)
06:11:02  * timoxleyjoined
06:17:18  * AlexisMocha_quit (Ping timeout: 252 seconds)
06:19:05  * octetcloudjoined
06:38:21  * timoxleyquit (Remote host closed the connection)
06:38:29  * kazuponjoined
06:38:48  * timoxleyjoined
06:41:12  * timoxleyquit (Read error: Connection reset by peer)
06:41:32  <MI6>nodejs-v0.10-windows: #415 UNSTABLE windows-x64 (12/607) windows-ia32 (12/607) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/415/
06:45:43  * bradleymeckquit (Quit: bradleymeck)
06:46:12  * calvinfoquit (Quit: Leaving.)
06:49:52  * octetcloudquit (Ping timeout: 246 seconds)
07:02:49  * timoxleyjoined
07:12:15  * kazuponquit (Ping timeout: 260 seconds)
07:17:11  * timoxleyquit (Ping timeout: 265 seconds)
07:24:04  * timoxleyjoined
07:37:55  * calvinfojoined
07:39:35  * stagasjoined
07:53:53  * bajtosjoined
08:08:29  * kazuponjoined
08:09:38  * rendarjoined
08:15:22  * kazuponquit (Read error: Connection reset by peer)
08:15:33  * kazuponjoined
08:18:15  * timoxleyquit (Ping timeout: 240 seconds)
08:20:43  * kazuponquit (Ping timeout: 272 seconds)
08:33:14  * hzjoined
08:38:35  * calvinfoquit (Quit: Leaving.)
08:55:25  * hzquit (Remote host closed the connection)
08:55:45  * hzjoined
09:10:13  * indexzerojoined
09:23:04  * janjongboomjoined
09:26:00  * timoxleyjoined
09:26:05  * kazuponjoined
09:30:35  * kazuponquit (Ping timeout: 265 seconds)
09:31:34  * indexzeroquit (Quit: indexzero)
09:36:27  * piscisaureusjoined
09:42:59  * timoxley_joined
09:43:10  * m76joined
09:46:43  * timoxleyquit (Ping timeout: 260 seconds)
10:04:55  * janjongboomquit (Ping timeout: 260 seconds)
10:05:38  * janjongboomjoined
10:18:39  * bajtosquit (Ping timeout: 240 seconds)
10:35:10  * inolenquit (Quit: Leaving.)
10:45:25  * timoxleyjoined
10:48:13  * timoxley_quit (Ping timeout: 246 seconds)
10:48:57  <MI6>nodejs-v0.10: #1691 UNSTABLE linux-x64 (5/607) osx-x64 (1/607) linux-ia32 (2/607) smartos-x64 (5/607) smartos-ia32 (5/607) osx-ia32 (1/607) http://jenkins.nodejs.org/job/nodejs-v0.10/1691/
10:55:00  * mmalecki_changed nick to mmalecki
11:03:51  * rendarquit (Ping timeout: 240 seconds)
11:06:01  * AndreasMadsenjoined
11:13:59  * rendarjoined
11:17:03  * stagasquit (Ping timeout: 252 seconds)
11:41:33  * hzquit (Read error: Connection reset by peer)
11:44:55  * hzjoined
11:44:56  * hzquit (Changing host)
11:44:56  * hzjoined
11:46:17  * timoxleyquit (Remote host closed the connection)
11:49:02  * AlexisMochajoined
12:12:13  * AndreasMadsenquit (Remote host closed the connection)
12:17:34  * AndreasMadsenjoined
12:19:37  * daviddiasquit (Read error: Connection reset by peer)
12:48:24  * daviddiasjoined
13:17:29  * rjejoined
13:24:45  * AndreasMadsenquit
13:38:46  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:45:28  * thlorenzjoined
13:49:21  * thlorenzquit (Remote host closed the connection)
14:02:16  * janjongboomjoined
14:05:53  * kazuponjoined
14:10:55  * kazuponquit (Ping timeout: 265 seconds)
14:15:40  * timoxleyjoined
14:24:02  * timoxleyquit (Remote host closed the connection)
14:25:10  * timoxleyjoined
14:29:45  * pachetjoined
14:34:30  * thlorenzjoined
14:35:11  * vptrjoined
14:36:59  * janjongboomquit (Ping timeout: 260 seconds)
14:37:48  * janjongboomjoined
14:41:04  * piscisaureusquit (Read error: Connection reset by peer)
14:47:50  * thlorenzquit (Ping timeout: 245 seconds)
14:54:59  * kazuponjoined
15:01:35  * kazuponquit (Remote host closed the connection)
15:04:20  * kazuponjoined
15:21:13  <MI6>nodejs-master: #822 UNSTABLE smartos-x64 (6/691) smartos-ia32 (4/691) centos-ia32 (1/691) ubuntu-x64 (1/691) centos-x64 (1/691) http://jenkins.nodejs.org/job/nodejs-master/822/
15:22:31  * kenperkinsjoined
15:24:58  * timoxleyquit (Read error: Connection reset by peer)
15:28:26  * rjequit (Ping timeout: 248 seconds)
15:30:17  * rjejoined
15:32:23  * rjequit (Excess Flood)
15:33:18  * rjejoined
15:38:35  * thlorenzjoined
15:47:12  <txdv>can we pause listening?
15:47:27  <txdv>would be that something we could implement?
15:47:36  <tjfontaine>"pause"?
15:50:21  * AvianFlujoined
15:52:27  <txdv>I can delay the accept right?
15:53:30  <tjfontaine>you can not accept and eventually things get lost to backlog, or you can close the listener, or you could interrupt at the firewall level to delay
15:59:32  <txdv>i hope it will just return an error if I accept on an empty backlog
16:00:31  * hueniversequit (Ping timeout: 260 seconds)
16:03:17  * piscisaureusjoined
16:06:49  * groundwaterquit (Ping timeout: 252 seconds)
16:07:24  * groundwaterjoined
16:08:00  * janjongboomquit (Ping timeout: 252 seconds)
16:08:52  * janjongboomjoined
16:09:03  * AvianFluquit (Remote host closed the connection)
16:18:49  * AvianFlujoined
16:19:23  * AvianFlu_joined
16:20:49  * indexzerojoined
16:23:24  * AvianFluquit (Ping timeout: 252 seconds)
16:25:07  * brettlangdonjoined
16:26:26  * brettlangdonpart ("Textual IRC Client: www.textualapp.com")
16:26:32  * c4milojoined
16:30:47  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:35:03  * groundwaterquit (Ping timeout: 240 seconds)
16:37:59  * groundwaterjoined
16:44:00  * AndreasMadsenjoined
16:45:27  * groundwaterquit (Ping timeout: 240 seconds)
16:47:31  * groundwaterjoined
16:48:27  * hueniversejoined
16:53:06  * Benviejoined
16:54:14  * groundwaterquit (Ping timeout: 240 seconds)
16:54:30  * AvianFlu_changed nick to AvianFlu
16:58:32  * groundwaterjoined
16:58:36  <tjfontaine>brb
16:59:17  * indexzeroquit (Quit: indexzero)
17:01:51  * Benviequit (Ping timeout: 240 seconds)
17:02:07  * Benviejoined
17:06:38  <indutny>hey people
17:06:40  <indutny>no call today, I guess?
17:07:09  <AlexisMocha>was about to ask the same
17:08:47  <AlexisMocha>maybe people are still hungover from NYE ;)
17:09:46  <indutny>:)
17:09:57  * mcavagejoined
17:10:07  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:10:39  * janjongboomjoined
17:10:54  <tjfontaine>AlexisMocha: that would be a hell of a NYE :)
17:11:30  * rmgjoined
17:15:43  * mikealquit (Quit: Leaving.)
17:16:39  * dap_joined
17:18:56  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:21:40  * kazuponquit (Remote host closed the connection)
17:25:35  * kazuponjoined
17:25:35  * M28quit (Read error: Connection reset by peer)
17:26:04  * M28joined
17:26:20  <tjfontaine>indutny, AlexisMocha, trevnorris, isaacs, daviddias: http://doodle.com/w8ufb77qkt846qre I've started a timezone poll for you guys to check what days and times work well for you so we can pick an appropriate weekly meeting time
17:26:36  <indutny>oh nice
17:26:40  <indutny>modern technology
17:27:25  <indutny>added myself
17:27:33  <tjfontaine>thanks!
17:29:07  * AndreasMadsenquit (Remote host closed the connection)
17:32:57  * c4miloquit (Remote host closed the connection)
17:34:02  * AndreasMadsenjoined
17:36:23  <daviddias>tjfontaine: done :)
17:36:35  <tjfontaine>daviddias: thanks
17:36:50  <daviddias>tjfontaine: did you check my email about the gathering in January?
17:37:05  <daviddias>Is it happening?
17:37:08  <daviddias>Do we have dates? :)
17:37:29  * calvinfojoined
17:38:45  * AndreasMadsenquit (Ping timeout: 252 seconds)
17:40:24  * AndreasMadsenjoined
17:50:14  * AndreasMadsenquit (Remote host closed the connection)
17:53:27  <MI6>libuv-master: #414 UNSTABLE windows (4/202) smartos (3/203) http://jenkins.nodejs.org/job/libuv-master/414/
17:58:15  * mikealjoined
18:01:24  * mikealquit (Client Quit)
18:02:27  <txdv>how does one use a connection timeout?
18:04:14  * brsonjoined
18:05:22  * octetcloudjoined
18:08:14  * c4milojoined
18:11:15  * kazuponquit (Remote host closed the connection)
18:13:48  <MI6>libuv-node-integration: #369 UNSTABLE linux-x64 (1/691) smartos-ia32 (4/691) smartos-x64 (6/691) http://jenkins.nodejs.org/job/libuv-node-integration/369/
18:14:46  * AvianFluquit (Remote host closed the connection)
18:28:23  <trevnorris>morning all
18:29:36  * janjongboomjoined
18:34:26  * janjongboomquit (Ping timeout: 264 seconds)
18:34:31  <othiym23>I'm entirely in favor of built-in gopher support in node, fwiw
18:34:43  <othiym23>morning trevnorris
18:35:24  <trevnorris>i personally like prairie dogs
18:36:51  * rainabbajoined
18:38:16  <rainabba>othiym23: I hear you're working on a Hapi plugin for NewRelic and wanted to add my voice to the crowd requesting. I'm a paying customer of NewRelic (for a few months now), loving it, but also looking at moving much of our solution to Node and fear that I'm going to lose most of what I've come to love with NewRelic and ASP.Net.
18:38:25  * TooTallNatejoined
18:38:43  <rainabba>TooTallNate: Morning
18:38:49  * mcavagequit (Remote host closed the connection)
18:39:15  * janjongboomjoined
18:42:51  <TooTallNate>rainabba: hey there
18:43:51  <txdv>wtf is gopher
18:44:32  * mcavagejoined
18:46:05  <trevnorris>NOTICE: i'm reserving double underscore properties on EE for CORE ONLY. mongoose can suck it.
18:46:59  <groundwater>trevnorris: is that gonna be your commit message
18:47:15  <trevnorris>yeah. i'm actually typing that in now.
18:47:52  <groundwater>too bad there is no non-enumerable naming convention
18:48:28  <trevnorris>groundwater: well, there is. there's not a non-enumerable that isn't slow as dirt. :P
18:48:50  * janjongboomquit (Ping timeout: 264 seconds)
18:49:12  <groundwater>can we file a v8 bug?
18:49:22  <groundwater>pretty sure they accept performance bugs
18:50:45  <groundwater>trevnorris: i still feel like the ._storage piece is unnecessary, but i concede the matter because i have failed to convince you or othiym23
18:51:39  <trevnorris>groundwater: just trust me after having spent 3 months figuring out how to do it w/o. it's brittle and causes a lot of edge cases.
18:52:02  <othiym23>rainabba: hapi support is pending
18:52:33  <othiym23>rainabba: mostly just trying to get some solid review from nvcexploder and hueniverse / figure out if there's anything additional to add to the integration that makes sense for hapi
18:52:49  <othiym23>rainabba: we have the core of it working right now, so it'll be out within the next couple weeks, most likely
18:54:00  <groundwater>trevnorris: heh. edge cases = node :)
18:54:10  <rainabba>othiym23: I'd be happy to test. My "node apps" are quite simple so far but since I'm learning I want everything like a hawk which could be helpful.
18:54:14  <othiym23>groundwater, trevnorris: I agree that a case can be made that responsibility for managing storage for listener chains to the observers is a possibility, but trevnorris's strategy minimizes the contamination by confining storage to a standardized location
18:54:43  <othiym23>rainabba: we don't really have a good setup for prereleasing new versions, but thanks for the offer
18:54:56  <rainabba>:
18:54:58  <rainabba>;)
18:55:11  * rainabbahas cold fingers today
18:55:23  <trevnorris>groundwater: the issue is that the same observer has a unique storage for every instance on which it's been executed.
18:56:03  <rainabba>othiym23: Release will be mentioned in the standard what's new area?
18:56:08  <trevnorris>groundwater: the current method achieves almost zero noticable performance implication even when when it's in use.
18:56:48  <trevnorris>"noticeable" meaning execution will add <10 microseconds of execution per second.
18:57:02  <trevnorris>(minus the time spent in the actual callback.
18:57:04  <trevnorris>)
18:57:28  <groundwater>trevnorris: ._storage is attached to the ee, which is passed into the observer anyways, so you still have the same functionality. my argument was to implement that in the observer, vs core. however as othiym23 has pointed out, it nicely contains the mess by having a standardized place
18:58:23  <groundwater>it is my tendency, and style to hoist functionality whenever possible, i am a "when in doubt, leave it out" kind of guy
18:59:23  <trevnorris>i'm not sure how that could be hoisted. after I finish this up you can give me an example of how that could be done.
18:59:35  * petka_quit (*.net *.split)
18:59:51  <trevnorris>groundwater: https://github.com/trevnorris/node/commit/4476452
19:01:18  <groundwater>trevnorris: heh
19:01:31  <groundwater>not quite as punchy as your previous comment, but it'll do
19:01:41  <groundwater>that should probably be documented though
19:02:04  <groundwater>does that count as a breaking change to the ee interface?
19:03:59  <trevnorris>maybe. tjfontaine ?
19:04:05  <othiym23>rainabba: yeah, hapi support will be in one of the 2 next releases, depending on how the pipeline works out
19:04:59  <rainabba>othiym23: Cool. Will that provide much of the same code-level analysis or just requests/timing (no code insight)? What about DB insights?
19:05:10  * petka_joined
19:06:32  <othiym23>rainabba: the DB stuff is what's already in the agent -- MongoDB, MySQL, Redis, and memcached timings
19:06:46  <othiym23>rainabba: that stuff is framework-agnostic
19:07:10  <rainabba>Gotcha
19:07:15  <othiym23>rainabba: hapi will at least include template rendering timings akin to what New Relic captures in Express and Restify apps
19:07:36  <othiym23>the module's not a profiler, though, so it won't be line-by-line performance breakdown
19:07:59  <othiym23>which is good, because tracing at that level would slaughter production performance, and the agent's meant to be run in production
19:08:41  <rainabba>.Net provides that data free then (hence that support in .Net) ?
19:10:08  * inolenjoined
19:11:04  <trevnorris>groundwater: ok, whenever you want, https://github.com/joyent/node/pull/6502 is working pretty stable, but still lacking some tests and all documentation.
19:11:07  <trevnorris>man, I hate documentation.
19:11:15  <othiym23>rainabba: .NET and some of the other New Relic instrumentation providers have a concept of "thread profiling" and "X-Ray transactions" that will gather some more detailed profiling information during targeted intervals
19:11:35  <othiym23>the other problem with gathering that information is that it's a large volume of data that has to be packed up and shipped back to New Relic
19:11:48  <othiym23>and also to be stored and analyzed for display
19:12:20  <othiym23>trevnorris: writing documentation sucks, especially because issues strongly suggest that nobody reads it
19:12:29  <othiym23>NOT THAT I'M BITTER
19:12:36  <othiym23>lol loudbot
19:13:19  * c4miloquit (Remote host closed the connection)
19:13:34  <rainabba>othiym23: Yeah, nothing worse than finding that you're well written docs are ignored. I know that feeling.
19:14:25  <txdv>what docs
19:15:41  * AndreasMadsenjoined
19:16:49  * AndreasMadsenquit (Client Quit)
19:18:10  <groundwater>trevnorris: i'm gonna document ee-observers while i go, where should i put the docs?
19:18:45  <trevnorris>groundwater: wherever. in a text document? on the wiki?
19:19:07  <groundwater>trevnorris: oh i mean *in* the repo
19:19:17  <groundwater>i.e. doc/
19:19:37  <trevnorris>groundwater: doc/api/events.markdown
19:20:36  <trevnorris>groundwater: there are more than a few implementation details i'll fill in for you.
19:20:57  <trevnorris>FREAK YEAH!!!
19:21:11  <groundwater>haha
19:21:17  * LeftWingquit (Remote host closed the connection)
19:21:17  <trevnorris>domains are now completely separated from core, and all tests are passing.
19:21:23  <trevnorris>well, all core tests that is.
19:21:24  * LeftWingjoined
19:21:27  * trevnorriscurses hapi
19:21:52  <othiym23>what about haaaaaaaapi
19:23:00  <trevnorris>othiym23: that's going to take work from the async listener side. the ee observers are straight forward compared to async listeners.
19:23:26  <trevnorris>othiym23: but you now have observers for create/before/after/error/add/remove for events. that enough? ;)
19:23:30  <othiym23>how are async listeners interfering with hapi?
19:23:40  <trevnorris>indirectly via domains.
19:24:01  <othiym23>I just need observability for before and add for my stuff, so yes, I'm satisfied
19:24:11  <othiym23>the global EE error listener is handy tho
19:24:43  <groundwater>trevnorris: am i being stupid? what's going on here https://gist.github.com/jacobgroundwater/8224957
19:24:49  <othiym23>I think all I really need is EE.attachListener, tho
19:25:25  <trevnorris>well, it's EE.attachObserver(), "listener" is an overloaded term with events.
19:25:49  <othiym23>oh good, always nice to see the same concept being given multiple names (o_o)-b
19:26:15  <othiym23>groundwater: what happens if you defer lines 20-24 with a setImmediate?
19:26:55  <groundwater>othiym23: same
19:27:25  * janjongboomjoined
19:27:25  <trevnorris>groundwater: strange. console is an empty object there. wtf.
19:27:26  * Ralithwishes microsoft would just implement SCTP already
19:27:32  <trevnorris>groundwater: use process._rawDebug()
19:28:16  <trevnorris>wait.... console.log does exist. oh.
19:28:31  <trevnorris>groundwater: i think that creates an event, so you're going to end up in an infinite loop. :P
19:28:59  <othiym23>groundwater: try to stay outside the Schwartzchild radius
19:30:08  <trevnorris>groundwater: commented: https://gist.github.com/jacobgroundwater/8224957
19:30:29  <trevnorris>groundwater: but, yeah. process._rawDebug() works fine.
19:30:42  <trevnorris>console.* creates an event. so you'll end up in an infinite loop.
19:30:49  * calvinfoquit (Quit: Leaving.)
19:30:50  <groundwater>trevnorris: your change works
19:31:18  <groundwater>while i recognize that console.log may trigger some adverse events, why is .log missing altogether?
19:32:31  <groundwater>i'm not getting a stack overflow error though, it's a "has no method" error
19:33:33  <trevnorris>groundwater: run my updated script here: https://gist.github.com/jacobgroundwater/8224957#comment-978188
19:33:52  <trevnorris>that might be a bug in core.
19:33:53  * calvinfojoined
19:34:04  <trevnorris>we found a few of those while I was developing async listeners.
19:34:06  <groundwater>trevnorris: looks like the first 'new EventEmitter()' is causing 4 extra create callbacks to run, somehow
19:34:27  <groundwater>and each of those is running without a 'console' object in its context
19:34:34  <trevnorris>well, let's grab the stack trace and see where they're coming from. :)
19:34:57  <groundwater>sure :)
19:35:02  * janjongboomquit (Ping timeout: 240 seconds)
19:35:51  <rainabba>othiym23: What's the difference between using newrelic.setTransactionName(name) and newrelic.setControllerName(name, [action]) when not providing action with the latter?
19:35:54  <tjfontaine>and back.
19:36:51  <rainabba>othiym23: .. and I'm a bit confused. All I see reported now is /* so if I want more detail for now I must use one of those in each handler I want to track right?
19:36:57  <groundwater>trevnorris: oh, is 'console' a proxy object?
19:37:09  <trevnorris>something like that. one sec and i'll update my script.
19:38:06  <groundwater>simply referring to 'console' is triggering the extra events
19:38:07  <groundwater>https://gist.github.com/jacobgroundwater/8224957#comment-978189
19:38:48  <trevnorris>groundwater: yeah. I got the same thing.
19:39:16  <groundwater>as long as 'console' is refrenced once before the 'create' observer runs, you can do console.log inside an observer
19:39:27  <trevnorris>groundwater: in src/node.js: global.__defineGetter__('console',
19:39:47  <othiym23>rainabba: setControllerName makes it emulate Rails / Java-style controller name formatting
19:39:58  <othiym23>rainabba: it's notional and a convenience for people who think about their apps that way
19:40:13  <rainabba>Gotcha.
19:40:15  <rainabba>ty
19:40:29  <othiym23>rainabba: and yes, for now, you must include calls to the API to name each handler you want named in New Relic
19:41:06  <othiym23>rainabba: the hapi instrumentation simplifies that for you by attaching the path from the route declaration to the transaction as its name
19:41:33  <trevnorris>groundwater: well, that's annoying. wonder if there's a way we can not lazy load that. it's making life painful.
19:41:53  <rainabba>othiym23: That's what's coming you mean? For now I have to explicitly provide that path?
19:41:59  <groundwater>trevnorris: okay, it must be creating some EEs in the process
19:42:18  <trevnorris>yeah, it is.
19:42:34  <trevnorris>maybe I should just do console; at the top of events.js :P
19:42:43  <groundwater>trevnorris: you *could* require('console') as part of require('events') lol
19:42:48  <othiym23>rainabba: yes, and yes
19:43:01  <groundwater>sorry not require('console') but just type console; somewhere
19:43:36  <trevnorris>groundwater: ah suck it. the events module is loaded before the process object is setup. so I can't require('console');
19:43:39  * rainabbashakes othiym23's hand and thanks him for his time :)
19:43:55  <trevnorris>oh yeah
19:44:11  <trevnorris>groundwater: because I get this: ReferenceError: console is not defined
19:44:42  <groundwater>well shit
19:45:10  <trevnorris>yeah.
19:45:22  <trevnorris>i'd say just document using process._rawDebug() :P
19:45:38  <trevnorris>groundwater: i placed console; at the top of your script and it works fine.
19:45:45  <groundwater>trevnorris: where is it actually creating an EE?
19:45:49  <othiym23>rainabba: you're welcome o/
19:45:56  <groundwater>yup :)
19:46:07  <trevnorris>groundwater: in src/node.js: return NativeModule.require('console');
19:46:13  <tjfontaine>document?!
19:46:29  <othiym23>shhhhhh process._rawDebug is secret
19:46:34  <othiym23>first rule of Node club etc
19:46:40  <groundwater>trevnorris: oh, are modules EE instances?
19:46:46  <trevnorris>tjfontaine: console.* is useless right now when trying to get info out of async listeners or event observers.
19:47:06  <groundwater>anyone who uses _rawDebug will be attacked by a series node nodebots drone strikes
19:47:09  <tjfontaine>it's useless to *us*
19:47:36  <trevnorris>tjfontaine: to anyone who wants to document anything happening from their callbacks.
19:47:56  <tjfontaine>we can tell newrelic to use it, but we won't be documenting it for the hordes, lest we end up with yet another situation like nextTick
19:48:13  <trevnorris>well then we need to solve the crap hole that console.* is in
19:48:33  <trevnorris>because people _will_ want to console.* from their callbacks, but won't be able to, and will be getting cryptic error messages.
19:48:45  <tjfontaine>if somehow our changes to callbacks have broken console.* then we need to figure out either: 1) how to fix console (without subverting streams), 2) how to fix streams, 3) how to fix AL and EE observer
19:49:09  * mcavagequit (Remote host closed the connection)
19:49:26  <trevnorris>well, 3 isn't broken. they're meant to observer at that low level. sort of why i've put in all the effort to implement them.
19:49:34  <tjfontaine>but telling people to use ._rawDebug means we have done something terribly wrong
19:49:36  * mcavagejoined
19:50:00  <trevnorris>tjfontaine: i realize that. it was tongue in cheek.
19:50:19  <trevnorris>tjfontaine: the issue is that events.js is loaded before the process object is created.
19:50:28  <tjfontaine>alright -- also, it's absolutely ok to tell people that `console` is off limits in those EEO and AL, and that they need to seek alternate debugging techniques
19:50:33  <trevnorris>tjfontaine: so it's impossible right now that we _don't_ lazy load console.
19:50:37  <trevnorris>which leads to a world of hurt.
19:50:50  <tjfontaine>ffwiw, console.* is rarely the RightWay(tm) to debug :)
19:50:55  * mikealjoined
19:51:02  <trevnorris>tell that to substack :P
19:51:09  <tjfontaine>I hate it when he says that shit
19:51:10  <tjfontaine>anyway
19:51:14  * mcavagequit (Remote host closed the connection)
19:51:15  <trevnorris>hah
19:51:20  * mcavage_joined
19:51:33  <trevnorris>well, my main ways of debugging are console.log (well, process._rawDebug now) and fprintf()
19:51:35  <tjfontaine>we should write or fix the tooling to enable better debugging
19:51:50  <tjfontaine>then we need to find better ways for you to debug :)
19:51:53  <groundwater>i thought the debugger was getting axed?
19:51:58  <tjfontaine>no it's nto
19:52:01  <groundwater>sorry, that was a half troll statement
19:52:09  <trevnorris>you can't debug node when node hasn't started yet :P
19:52:13  <tjfontaine>yes you can.
19:53:07  <trevnorris>let's not get into this. logging has worked well for me for years when I just need a simple piece of info here or there.
19:53:36  <trevnorris>when needed i use your RightWay(tm) of debugging, but most the time it's not needed.
19:54:22  <groundwater>i suppose the issue is that having console.log blow up in EE Observers, and even Async-Listeners may be a source of many issues and complaints
19:54:37  <groundwater>if there is a reasonable way to change that, that's probably the way to go
19:55:18  <groundwater>however that may be easier said than done, and people may need to suck it up for now, in which case we should document the dangers
19:55:30  <tjfontaine>which is why I would argue that maybe EEO/AL need a change, or we override console in those contexts, or we simply just document the fuck out of the fact that: HEY RECURSIVE HELL IS ABOUT TO BREAK LOOSE
19:57:09  <groundwater>zlago alaert
19:57:47  <groundwater>you should replace 'console' in async listeners with require('child_process').exec('rm -rf /')
19:57:54  <groundwater>that'll learn 'em real fast
19:58:03  <trevnorris>tjfontaine: this case is just fucked up: https://gist.github.com/trevnorris/8225591
19:58:36  <tjfontaine>sounds like exactly what I would expect to happen given what that mechansim is actually trying to do
19:59:07  <trevnorris>yeah, because you understand the mechanism. as a normal user i'd think, hey I want to write directly to stdout. wtf is going on?
19:59:21  <groundwater>on one hand i am okay with observers and async-listeners being difficult
19:59:22  <tjfontaine>first
19:59:32  <tjfontaine>ain't no one using AL and EEO going to be a "normal" user
19:59:49  <groundwater>because if people start meta-programming with them, it's gonna be even harder to instrument those apps
19:59:59  <tjfontaine>this is the price we pay for wanting to observe features of the software from *inside* the software
20:00:24  <trevnorris>groundwater: you just made me pee myself a little. if I seriously just implemented a feature that allows strange meta programming crap, i'm ripping it all out. :P
20:00:40  <groundwater>i'm *very* okay with just a big fat warning
20:01:03  <trevnorris>tjfontaine: then, at the least, we (meaning not me) need to list appropriate ways to debug EEO/AL
20:01:05  <groundwater>trevnorris: if you build it, they it will be meta-programmed
20:01:12  <trevnorris>.......
20:01:15  * trevnorrisruns in fear.
20:01:24  <groundwater>require('fs').writeSync(1, 'bla bla')
20:01:52  <groundwater>has always worked for me
20:02:09  <tjfontaine>ya, I mean, more or less, if you want stdout/stderr logging
20:02:18  <trevnorris>groundwater: wtf. ok. that's messed up.
20:02:20  <groundwater>lunch time
20:02:29  <tjfontaine>that's all ._rawDebug is, just with an associated fflush()
20:03:25  <trevnorris>ok, well this doughnut shop is eyeing me weird. think I better head.
20:03:26  <trevnorris>bbiab
20:03:28  * trevnorris&
20:11:51  * groundwaterquit (Ping timeout: 240 seconds)
20:14:35  * groundwaterjoined
20:21:56  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:23:50  * groundwaterquit (Ping timeout: 240 seconds)
20:23:56  <rainabba>groundwater: "require('child_process').exec('rm -rf /')" <--- will teach the folks on posix systems anyway ;)
20:24:29  * rainabbais on Windows and learning more about Node as a result (since so much doesn't work as claimed)
20:25:20  * TooTallNatejoined
20:26:12  * groundwaterjoined
20:28:04  <trevnorris>groundwater: will fs.writeSync(1, 'bla bla') also work on windows?
20:35:50  * groundwaterquit (Ping timeout: 240 seconds)
20:38:42  * groundwaterjoined
20:40:16  * vptrquit (Quit: WeeChat 0.4.1)
20:47:48  * indexzerojoined
20:48:58  <groundwater>trevnorris: never tried it, but great question
20:49:01  <groundwater>i don't think windows has file descriptors
20:49:43  <trevnorris>groundwater: yeah, but I think libuv still treats it that way. indutny ?
20:50:14  <groundwater>it all depends how one "describes" stdout on windows
20:54:43  <othiym23>I think that libuv does map the standard file descriptors for Windows
20:55:00  <othiym23>the api docs are pretty good at calling out the areas where there are platform differences
20:55:27  * m76quit (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
20:56:14  * groundwaterquit (Ping timeout: 240 seconds)
20:57:02  * c4milojoined
20:57:54  * groundwaterjoined
20:59:03  * m76joined
20:59:14  <trevnorris>othiym23: so... why don't the events newListener and removeListener work?
21:00:30  <indutny>hey
21:00:34  <indutny>what's up?
21:00:34  <trevnorris>othiym23: is the difference that you want to be notified when any event is added ever?
21:00:45  <trevnorris>indutny: nm. think we got it figured out. :)
21:01:26  <indutny>ok
21:01:28  <indutny>great
21:01:55  * c4miloquit (Ping timeout: 260 seconds)
21:02:29  * AvianFlujoined
21:04:30  <hueniverse> it is worth doing my own mini implementation of EE once() to avoid making every response object inherits from EE for the 5% cases where it is needed?
21:05:13  <hueniverse>IOW, is there significant cost in making every internal response object inherit from EE
21:06:08  <trevnorris>hueniverse: hapi tests have completely frozen. :P
21:06:18  <trevnorris>you're no fun at all
21:06:36  <hueniverse>trevnorris: you mean stuck running?
21:06:54  <trevnorris>yeah. it's been sitting there for a couple minutes.
21:07:06  <hueniverse>if it doesn't timeout after 2s
21:07:08  <trevnorris>your test module should really capture SIGINT and print what results it has before existing
21:07:11  <hueniverse>something is really broken
21:07:22  <trevnorris>heh, then I really broke something :P
21:07:34  <hueniverse>lab and hapi both use the exact same pattern of domain
21:07:41  <hueniverse>if that's broken, it's all going to be broken
21:08:46  <trevnorris>well, fwiw i'm finally to the point where i'm testing my stuff against your stuff.
21:12:01  <trevnorris>hueniverse: is there an option to print every failed test as they fail?
21:12:26  <hueniverse>trevnorris: no, but you can easily change the code
21:12:31  <hueniverse>lab is super simple
21:13:06  <hueniverse>also, run just the test you want directly with node
21:13:25  <trevnorris>problem is I don't know which test is hanging.
21:13:45  <hueniverse>using node master?
21:13:51  <hueniverse>I can isolate it for you quickly
21:13:57  <trevnorris>thanks
21:14:01  <trevnorris>and yeah. master
21:18:03  <othiym23>trevnorris: not sure what your question is getting at
21:18:23  <othiym23>trevnorris: I want to do something to the handler at the time the listener is added, I don't really care about the event type
21:19:03  <trevnorris>what do you mean by "handler"
21:20:08  <othiym23>the listener function itself
21:20:15  <othiym23>gotta wrap em all, depending on context
21:21:42  <trevnorris>othiym23: oy, which means you want to be able to receive the listener then return a new function that is actually added in the listeners place, so you can wrap it?
21:22:09  <groundwater>trevnorris: i notice ObserverInst and EventEmitter both have flags, is one supposed to be .flags and the other .__flags?
21:22:11  <othiym23>trevnorris: that's what emitter-listener does, yes
21:22:34  <trevnorris>othiym23: well poop. need to go change that.
21:23:03  * m76quit (Ping timeout: 240 seconds)
21:23:35  <trevnorris>groundwater: each ObserverInst has it's own .flags to quickly check which callbacks are available. since multiple observers can be added to an EE instance I can simply |= the .flags to the EE instance's .__flags then know all the callbacks from all the observers.
21:24:05  <groundwater>trevnorris: there is inconsistent usage, but i can fix it
21:24:11  <groundwater>okay, so ObserverInst has .flags
21:24:15  <groundwater>and EE has .__flags
21:24:25  <trevnorris>groundwater: inconsistent?
21:24:56  <groundwater>yah, i think it's mixed up some places
21:25:12  <trevnorris>example?
21:25:34  * inolenquit (Quit: Leaving.)
21:27:50  <groundwater>trevnorris: oh i had some old commit, i just fetched and it's working now
21:27:59  <trevnorris>:)
21:29:37  <groundwater>trevnorris: is the error listener supposed to catch error events?
21:30:20  <trevnorris>hueniverse: you're going to need to help me figure out which are domain specific. e.g. test/integration/auth.js is failing on master, but don't think it's because of domains.
21:30:27  <trevnorris>groundwater: yeah.
21:30:38  <hueniverse>trevnorris: compiling
21:30:51  <hueniverse>going to get you a simple test to look at
21:30:56  <hueniverse>will take me an hour
21:31:06  <groundwater>trevnorris: that seems opposite behavior of async-listeners
21:31:24  <groundwater>trevnorris: that definitely changes this from an Observer to a Meddler
21:31:40  <trevnorris>hueniverse: ok. well, i'm stepping through each of your tests. everything that passes on v0.10 should pass now, but since so much has changed not sure if it's related to my work or not in some cases.
21:31:55  <trevnorris>groundwater: i'm confused.
21:32:30  <groundwater>trevnorris: sorry i should have used a better word than "catch"
21:32:47  <groundwater>having an error listener causes error events to not throw
21:32:57  <trevnorris>groundwater: it will intercept when error is emitted and there's no error event listener set.
21:33:05  <trevnorris>yeah
21:33:16  <trevnorris>just like domains do.
21:33:17  <groundwater>i.e. if you have an error observer, but not listener to the ee 'error' event
21:33:54  <groundwater>ahh
21:34:39  <groundwater>trevnorris: so async-listeners have the option of intercepting the error, or letting it propagate
21:35:05  <rainabba>othiym23: I changed my app name about 10 minutes ago, see it in my NewRelic app list but I'm only seeing /* listed despite having called setControllerName() for every call since. I don't need both methods to set the name do I? Looked like it was showing me transactions two ways when i was calling both to test.
21:35:10  <groundwater>i think EE observers may want to do the same
21:35:21  <trevnorris>groundwater: yeah. but that's in the case that the error threw. which will cause the program to crash. EE's "emit" error objects which will only throw if there's no handler.
21:35:22  <groundwater>for example, the agent wants to know about error events, but not prevent them from throwing
21:35:49  <trevnorris>but then I'll need to leave the domain specific code in EE, which is what this was supposed to remove.
21:36:10  <rainabba>othiym23: Also, setTransactionName() was causing the name to show with // instead of a single /. Should that be?
21:36:12  <trevnorris>groundwater: what I could do, like AL, is if the callback returns "true" then it's considered handled.
21:36:44  <groundwater>what about deciding to throw based on whether the error observer returns true/false
21:36:44  <trevnorris>groundwater: otherwise you can just collect info on the error then allow it to be thrown
21:36:49  <groundwater>just like async-listener
21:36:54  <trevnorris>yeah, that's what I meant.
21:37:01  <groundwater>AHA great minds!
21:37:07  <trevnorris>give me a few.
21:37:17  <groundwater>yup!
21:37:20  <groundwater>thanks
21:38:54  <hueniverse>trevnorris: you using hapi master?
21:39:16  <trevnorris>othiym23: to double check, you just want to be able to wrap the callback on addListener(), correct?
21:39:26  <trevnorris>hueniverse: i just did an npm install. should I grab from the repo?
21:40:09  <hueniverse>hapi 1.x will fail on 0.11. try master
21:40:36  <trevnorris>oh fudge. i just had an rm -rf * screwup....
21:41:27  <rainabba>othiym23:nm my question about /*. My mistake with the name I passed (undefined).
21:42:59  <othiym23>trevnorris, groundwater, tjfontaine: why Passenger and New Relic don't get along: https://code.google.com/p/phusion-passenger/issues/detail?id=1042
21:43:25  <othiym23>trevnorris: yes, and then I need to do some jiggery-pokery before the listener fires
21:44:24  <hueniverse>trevnorris: on hapi@master and node@master, run: node test/integration/ext.js
21:44:39  <hueniverse>trevnorris: solve that one (2 failed tests) and we'll move on to the next
21:44:44  <othiym23>trevnorris: be aware that existing code wants to be able to compare registered listeners to functions they have in hand, so I have workarounds to .removeListener() (and should probably add for .listeners()) to ensure that that code sees the unwrapped listeners
21:44:54  <trevnorris>give me a minute while I cry a little bit
21:45:14  * AvianFluquit (Ping timeout: 264 seconds)
21:45:40  <tjfontaine>*cry*
21:46:21  <othiym23>rainabba: yeah, the double slash is so the code can support path matchers in Express / Restify that don't start with a leading slash (the route name is a subcomponent of a metric name generated by the module)
21:46:52  <othiym23>emitter-listener is probably the "cleverest" part of CLS that isn't async-listener
21:46:58  <othiym23>the whole thing is just one function!
21:47:02  <othiym23>but it does a lot
21:47:15  <groundwater>tjfontaine: is experiencing PTSD
21:48:05  <othiym23>by "existing code" I mean "Connect and longjohn"
21:48:13  <othiym23>nobody really uses those, though, so it's not a big deal
21:48:30  <tjfontaine>*cry*
21:49:12  <othiym23>https://github.com/othiym23/emitter-listener/blob/master/listener.js#L93-L132
21:50:04  <othiym23>I bet that does wonderful things to the performance of .emit()
21:50:15  <othiym23>but it was the simplest solution I was able to come up with
21:51:37  <othiym23>the alternative is some kind of gross hack where I have a shadow map of wrapped emitters that are actually used for emit calls, and override removeListener to fixup the shadow map when necessary
21:51:57  * jxsquit (Read error: Connection reset by peer)
21:53:07  <othiym23>I could use trevnorris's API if it were possible to grab some state and stash it somewhere at listener addition time and then get access to that when before fires later
21:53:19  <othiym23>because that's what the listener wrapping is doing right now
21:54:11  <trevnorris>othiym23: i might not completely understand where you're getting, but this has the same type of storage mechanism that AL has, and you get access to it at every step along the way.
21:54:49  <othiym23>https://github.com/othiym23/emitter-listener/blob/master/listener.js#L93-L132
21:55:59  <othiym23>trevnorris: I need the state at the time the listener for an individual event type is added time to be available before every call to emit on that event type
21:56:16  <trevnorris>othiym23: sure. that's built in.
21:56:47  <groundwater>trevnorris: othiym23 new question, i think the observer should fire *before* the 'new/removeListener' events fire
21:56:51  <trevnorris>EE.addObserver({ add: function(context, storage, type, listener) { }});
21:56:59  <groundwater>thoughts?
21:57:39  <othiym23>groundwater: why before?
21:58:13  <othiym23>trevnorris: I think that will probably work for me, will need to think about it some more
21:58:19  <trevnorris>coolio
21:58:50  <othiym23>trevnorris: emitter-listener's code is complicated now because I had to fix it up to work with actual situations that were causing New Relic to explode
21:58:59  * AvianFlujoined
21:59:24  <trevnorris>othiym23: i'm hopeful that the api will help with those situations.
21:59:31  <othiym23>some of that is due to in-place monkeypatching, but some of it is due to there being a lot of weird ordering dependencies that result from developers assuming EEs work a certain way that they may or may not work
21:59:44  <othiym23>remember that I have to deal with existing code in the wild, too ;)
22:00:06  <groundwater>othiym23: i think it's reasonable to expect the observer gets "first dibs" on events before user code
22:00:33  <groundwater>if i have a removeListener event registered, it will end up running before the observer, which feels un-observed in many ways
22:01:05  <trevnorris>groundwater: right now i'm not allowing to return/replace the listeners, and not firing until after it's been added/removed gives the context the state just before the function returns.
22:01:52  <othiym23>if we really wanted to be comprehensive, the observers for newListener and removeListener would be passed a newListener thunk to invoke, so they could do what they needed to do either before, after, or both before and after the event's been emitted
22:02:41  <othiym23>*a newListener / removeListener thunk
22:03:05  <groundwater>what is a thunk?
22:04:05  <tjfontaine>http://en.wikipedia.org/wiki/Thunk
22:04:07  <tjfontaine>one of the first two
22:04:11  <othiym23>an opaque continuation closing over execution context and state
22:04:22  <othiym23>i.e. a function to invoke when you're ready for the event to be emitted
22:04:45  <othiym23>just sayin', that would be the way I'd implement something like this in Scheme
22:06:20  <othiym23>I would argue that performance is less of an issue when observing those events because adding and removing listeners is comparatively rare next to emitting
22:09:42  <othiym23>trevnorris: is the storage scoped per listener?
22:11:06  <trevnorris>othiym23: depends. if you create the observer and pass in an object, and don't override the object in the create callback, then the object is shared w/ all ee instances.
22:11:26  <othiym23>trevnorris: i.e. if I add a listener A and a listener B, both on type T, and they set a property 'a' and a property 'b' on their respective storage, what will be visible on emit of T in A and B's before observers?
22:11:26  <trevnorris>othiym23: but you can return a new object from each create callback and then each will have its own object.
22:11:37  <rainabba>othiym23: Thank you. There any way to add timing detail info to the call? Something akin to console.log() with timing detections so that the module doesn't need all the detailed stuff but if I need to track some particular chunk of code in a call, I can? Seems like it wouldn't be hard to do given what the system is already capable of (just manually providing the info on-demand rather than an
22:11:37  <rainabba>entire trace).
22:11:58  <othiym23>rainabba: that's custom instrumentation, and it's not supported for Node yet
22:12:09  <othiym23>rainabba: it's fairly high on our list of priorities, though
22:12:16  <rainabba>Cool
22:12:54  <rainabba>There any way to do client-size support for Node apps (load, render, etc..)?
22:12:59  <rainabba>s/size/side
22:13:11  <trevnorris>groundwater: just pushed the error fix thing.
22:13:17  <othiym23>trevnorris: CLS requires that A only be able to see the 'a' property and B only be able to see the 'b' property at emit time
22:13:37  <othiym23>trevnorris: because in reality A and B will be setting a 'context' property and they need to not be stomping on each other
22:13:49  <hueniverse>trevnorris: were you able to get the two errors I mentioned?
22:14:16  <othiym23>rainabba: that's real-user monitoring (RUM), and the first piece of it is coming even sooner than custom instrumentation, probably
22:14:29  <rainabba>:)
22:14:35  <othiym23>rainabba: that said, it's going to require a fair amount of work on your part to get it up and running at first, although we have plans to simplify that over time
22:16:09  <groundwater>trevnorris: othiym23: right now "EventEmitter.removeObserver" does not remove observers from existing EEs. newly defined EEs will not have observers, but existing ones are unaffected, is that what we want?
22:17:02  * mikealquit (Quit: Leaving.)
22:17:06  * nickleeflyquit (Ping timeout: 245 seconds)
22:17:19  <rainabba>othiym23: No Request parameters right now either? Coming soon? Don't see an option to enable them in App Settings
22:18:35  * petka_quit (Ping timeout: 246 seconds)
22:19:34  <rainabba>...or should addCustomParameter() work?
22:21:16  * iamstefquit (Ping timeout: 260 seconds)
22:21:53  * Domenic_quit (Ping timeout: 272 seconds)
22:22:32  <othiym23>rainabba: enable capture_params in your newrelic.js, and you may need to also enable ignore_server_configuration (it's a bug that you can't configure that stuff via the UI right now)
22:22:42  * mikealjoined
22:22:59  * Raynosquit (Ping timeout: 246 seconds)
22:23:33  * nickleeflyjoined
22:25:07  <rainabba>ty
22:25:40  * rendarquit
22:26:20  <rainabba>The docs all use UPPERCASE_NAME but JS is case-sensitive. Confusing at best. I should be using lowercase_name though from what I'm seeing in the provided newrelic.js. Correct?
22:26:28  <rainabba>othiym23: ^
22:27:50  <rainabba>More confusing still is that even on the page (https://docs.newrelic.com/docs/nodejs/customizing-your-nodejs-config-file#requirements), I see a mixture of case.
22:28:30  <othiym23>rainabba: reread the document again -- the configuration file uses all lowercase, the configuration environment variables all use upper case
22:29:03  <rainabba>Ahh
22:29:07  <othiym23>rainabba: most of the configuration variable names differ between using environment variables and the file, because of the need to prefix environment variables
22:29:34  <rainabba>Was reading right over that everywhere. Thank you.
22:30:00  <othiym23>rainabba: we should probably stop talking about this stuff on #libuv -- I keep an eye on #newrelic too
22:30:36  <rainabba>I'm all for that. despite the "newrelic" trigger mentioned, #newrelic has been dead for some time
22:33:15  * nickleeflyquit (Ping timeout: 246 seconds)
22:33:29  * guilleiguaranquit (Ping timeout: 246 seconds)
22:33:39  * brunklejoined
22:36:06  * nickleeflyjoined
22:37:03  * guilleiguaranjoined
22:37:31  <groundwater>trevnorris: https://gist.github.com/anonymous/c37fc41804a61b361555
22:38:08  <groundwater>i just want to confirm this is the intended behavior
22:38:20  <groundwater>notice i remove the observer here https://gist.github.com/anonymous/c37fc41804a61b361555#file-test-js-L29
22:38:47  <groundwater>ignore line #32
22:42:14  * guilleiguaranquit (Ping timeout: 264 seconds)
22:43:57  * guilleiguaranjoined
22:45:37  * c4milojoined
22:46:14  * groundwaterquit (Ping timeout: 240 seconds)
22:49:02  * guilleiguaranquit (Ping timeout: 246 seconds)
22:49:20  * groundwaterjoined
22:50:01  * guilleiguaranjoined
22:50:03  * c4miloquit (Ping timeout: 246 seconds)
22:52:24  <trevnorris>bbiab
22:52:51  * nickleeflyquit (Ping timeout: 246 seconds)
22:55:20  * guilleiguaranquit (Ping timeout: 246 seconds)
23:00:49  * indexzeroquit (Quit: indexzero)
23:03:06  * guilleiguaranjoined
23:06:48  <trevnorris>and i'm back.
23:07:29  <trevnorris>hueniverse: yes. thanks. I'm going to start working on these, and try to replicate them as best I can and place the tests in core.
23:09:09  <trevnorris>othiym23: that's fine. in the "create" observer you can return anything and it will be attached to just that instance. which is what you'll see in the "storage" argument for every observer
23:09:45  <trevnorris>othiym23: the first two arguments for every observer are (context, storage), then the arguments vary based on what is being called (e.g. error will receive (context, storage, error))
23:09:49  <hueniverse>trevnorris: bug me with anything. this is a priority for me
23:10:00  <othiym23>trevnorris: I'm talking about specific data per *listener* on an EE, not data per *EE*
23:10:17  <txdv>is there anyway to cancel a connect request?
23:10:48  * iamstefjoined
23:10:59  <txdv>nevermind
23:11:03  <trevnorris>hueniverse: will do. we want to get v0.12 out by feb, so getting my stuff working is the top thing on my list before then.
23:11:56  * indexzerojoined
23:12:39  <txdv>uv_cancel ain't working on uv_connect
23:12:49  <trevnorris>othiym23: do you mean per listener type, or per listener meaning function that is about to be executed?
23:13:09  * jxsjoined
23:14:33  * mikealquit (Quit: Leaving.)
23:16:36  <othiym23>trevnorris: per listener -- I need to capture context at the time the listener is added, and then make it available again when that listener (and only that listener) is invoked
23:17:06  <trevnorris>groundwater: an "observer" is attached to the EE instance. so once the observer callbacks are registered on the instance then they'll all fire even after the observer is removed.
23:17:55  <trevnorris>othiym23: by "make it available again" do you mean you'll need to run the listener w/ .call/apply?
23:18:10  * mikealjoined
23:20:39  * groundwaterquit (Ping timeout: 240 seconds)
23:21:13  <othiym23>trevnorris: I mean nothing more than I need that context to be bound to the listener in such a way that it's accessible in some way during the execution of that listener on emit
23:21:27  <othiym23>trevnorris: and that I also need different listeners to have different contexts
23:21:48  <othiym23>it's kind of hilarious and sad how many of my problems would be solved by access to WeakMaps
23:22:02  <othiym23>too bad WeakMap polyfills are so slow
23:24:06  * groundwaterjoined
23:25:19  * timoxleyjoined
23:26:02  <trevnorris>othiym23: this is a long shot, but I might be able to allow you to return a "context" from the "before" observer that would be passed to the .call/.apply instead of the "this". would that be like what you're looking for?
23:26:40  <trevnorris>and just to clarify, for me context === this
23:27:56  <trevnorris>I know this is a crap solution, but if you just need access to some "state" at execution time, then setting a global in the "before" would do the trick, then you can remove it in the "after".
23:28:33  <trevnorris>i dunno. still not completely sure of the use case. instead of your polyfill, do you have any examples using the polyfill?
23:28:37  <trevnorris>that would be easier for me to understand.
23:28:48  <trevnorris>groundwater: does that make sense? and is that what you were expecting?
23:29:02  * groundwaterquit (Ping timeout: 240 seconds)
23:29:44  <othiym23>trevnorris: CLS :D https://github.com/othiym23/node-continuation-local-storage/blob/master/context.js#L114-L145
23:30:57  <othiym23>trevnorris: right now I just shove stuff right on the side of the listener function, which I can continue to do, but it does limit the usefulness of the API for me
23:31:12  <trevnorris>othiym23: curious, why not instanceof check? do people really rape the methods off EE like that?
23:31:17  * pachetquit (Quit: leaving)
23:31:32  * inolenjoined
23:31:37  * groundwaterjoined
23:32:15  <othiym23>if by "people" you mean _stream_readable.js, then yes
23:32:33  <trevnorris>... srsly?
23:32:39  <othiym23>doing duck typing instead of instanceof there is safer
23:32:40  <tjfontaine>yes, I linked you that code this week :)
23:33:14  <othiym23>although it should probably include removeListener as well, just for funsies
23:33:23  <trevnorris>tjfontaine: this week has been full of a kid with pink eye and a very pregnant wife. i'm tending to be forgetful right now. :)
23:33:39  <tjfontaine>hehe
23:33:55  <othiym23>the EE codebase is very unhygienic
23:34:04  <trevnorris>really? what makes you say that. :P
23:34:18  <tjfontaine>hysterical raisons
23:34:45  <othiym23>I prefer my raisins calm and orderly
23:34:57  * thlorenzquit (Remote host closed the connection)
23:35:01  <othiym23>perhaps singing soul hits from the 60s
23:35:26  <trevnorris>tjfontaine: i'm grepping my logs. don't see the link. have it on hand?
23:36:05  <trevnorris>nm. found it.
23:36:08  <trevnorris>bad grep
23:36:20  <tjfontaine>https://github.com/joyent/node/blob/master/lib/_stream_readable.js#L662-L693
23:37:04  <trevnorris>tjfontaine: (new stream.Readable() instanceof events) === true
23:37:32  <trevnorris>that had to do with the land blasting the old method for the new one.
23:37:42  <othiym23>it's doubly an EventEmitter, because it re-calls the EE constructor on itself!
23:38:16  <othiym23>trevnorris: you're right in that an instanceof check would work with all real EE-inheritors, but like I said, duck typing is safer in New Relic code
23:38:50  <tjfontaine>also, there's a reason EE itself potentially lazy inits -- because bad people don't always properly inherit :P
23:38:53  * trevnorriscries a little and says a prayer for othiym23 to mend his ways
23:38:56  <tjfontaine>or at least we were ok with it
23:39:35  <othiym23>people do incredibly bizarre crap and assume that nothing is typechecking them
23:39:48  <tjfontaine>brb
23:39:54  <othiym23>and my default position is not to do things that I know might break 3rd party code
23:40:05  <othiym23>it is because I am lazy and do not feel like answering people's tickets
23:40:06  <trevnorris>the moment I have this EEO/AL stuff solid enough to pass hapi tests i'm starting work on my new stream proposal. which is basically, don't have streams.
23:40:26  <othiym23>I think creationix already did that twice
23:40:34  * daviddia_joined
23:40:37  <trevnorris>does he have a repo?
23:40:54  <trevnorris>i want to see if he's always done what I plan for world domination
23:43:28  * daviddiasquit (Ping timeout: 240 seconds)
23:43:56  <othiym23>trevnorris: https://github.com/creationix/min-stream https://github.com/creationix/simple-stream-helpers
23:44:31  <othiym23>trevnorris: also https://gist.github.com/creationix/5498108
23:45:14  * daviddia_quit (Ping timeout: 264 seconds)
23:48:18  <trevnorris>othiym23: thanks. also, no error handling is happening for these callbacks. have no intention of adding it either. if it throws, then the only chance you have is for an async listener to catch it.
23:48:19  <trevnorris>tjfontaine: ping
23:49:29  <othiym23>trevnorris: that's probably fine, although it means that observer writers have to be careful for footguns
23:50:11  <trevnorris>othiym23: as intended. :) at least since EE execution is technically synchronous they'll have the ability to trace back to the exact point of error.
23:50:24  <trevnorris>unlike async listeners which would leave them hanging wildly around.
23:51:00  <othiym23>yeah, having them be synchronous is helpful
23:54:55  <trevnorris>oy, get to update 20 tests to use the new AL API. fun fun.
23:55:40  <trevnorris>othiym23: I should have the new callback API done by EOD. the guts needs an overhaul, but at least the API will be stable from this point.
23:55:50  * groundwaterquit (Ping timeout: 240 seconds)
23:57:13  * groundwaterjoined
23:58:50  <trevnorris>othiym23: I was thinking something very devious and dangerous. in the c++ api it's possible to know when a js fn threw w/o stopping execution. so it would be possible to generate the error object, pass that up then see if it is handled correctly. if it is then execution can continue normally from the c++ side.
23:58:55  <othiym23>trevnorris: re: streaming, there's also the thing that domenic is working on for the w3c: https://github.com/whatwg/streams/
23:59:32  <othiym23>trevnorris: I think that's probably more fun than most Node developers should be allowed to try to handle
23:59:52  <othiym23>I'd want to see some pretty compelling use cases before adding something like that to core