00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:05:23  * EhevuTovquit (Quit: This computer has gone to sleep)
00:05:42  * jmar777quit (Remote host closed the connection)
00:06:13  <othiym23>you don't say
00:06:15  <othiym23>;)
00:10:58  <tjfontaine>hahaha
00:11:36  <tjfontaine>trevnorris: your best bet is probably systemtap actually
00:11:52  <tjfontaine>trevnorris: that's not really an endorsement of its stability though
00:12:06  <trevnorris>tjfontaine: yeah, or I suck it up and use the smartos machine you guys gave me access to. ;P
00:12:44  <tjfontaine>trevnorris: there's also mlogin :)
00:12:49  <tjfontaine>but ya
00:13:05  <tjfontaine>trevnorris: there's also the vmware/virtualbox images for smartos or omniti
00:14:04  <trevnorris>tjfontaine: yeah. might try that. just one of those things you don't do until you really really have to do it.
00:15:56  <tjfontaine>you may want me to reprovision that tls-bench one with a newer base image
00:16:22  * dshaw_1quit (Quit: Leaving.)
00:17:38  <tjfontaine>ya, there's not much there -- I can blow that away and reprovision closer to westcoast and with a newer image
00:17:49  * st_lukequit (Remote host closed the connection)
00:18:49  <othiym23>has it gotten any easier to bootstrap SDC in vmware?
00:18:58  <tjfontaine>all of sdc, or smartos?
00:19:08  <othiym23>I can't remember which I bootstrapped last time
00:19:13  <othiym23>probably just SmartOS
00:19:28  <tjfontaine>I mean that's the primary development platform for most of these guys
00:19:28  <othiym23>my image is like a year and a half old at this point
00:19:30  <tjfontaine>so I would hope so
00:19:53  <othiym23>is there a way I can upgrade the SmartOS installation itself from inside zone 0?
00:20:15  <tjfontaine>othiym23: ya, smartos itself is just a usb stick, so your zones stay where they are
00:20:17  <othiym23>gotta be blunt, the wiki confuses the shit out of me when I try to figure out how to do stuff
00:20:39  <tjfontaine>yes, it's not the greatest at explaining what's going on
00:20:52  <tjfontaine>but you just swap out one disk image for the new one, and continue your life on
00:20:57  <othiym23>yeah, I know, I have it running in vmware with the hypervisor instruction emulation enabled so I can use the KVM :3
00:21:30  * AvianFluquit (Remote host closed the connection)
00:21:58  * AvianFlujoined
00:22:07  <othiym23>hmm... gonna have to figure out how to do that without wrecking my whole world, because all my storage pools / zones are living in a virtual disk file and I'm not sure how to swap out the SmartOS image
00:22:14  <othiym23>this is what I get for having a nice UI
00:22:23  <othiym23>probably just need to mangle the config files by hand
00:22:24  * dshaw_joined
00:22:48  <tjfontaine>othiym23: my understanding is that it should just work :)
00:24:22  <othiym23>only one way to find out! :>
00:24:38  <tjfontaine>well the good news is, you can snapshot the disk image :)
00:25:45  <othiym23>I only have a couple zones, and they're all hellaciously out of date, so it's not a big deal if they get nuked, but it was *such* a pain in the ass getting them up and running in the first place
00:26:33  * dshaw_quit (Ping timeout: 240 seconds)
00:26:57  * octetcloudquit (Ping timeout: 268 seconds)
00:27:00  <tjfontaine>othiym23: you should just get zones in the jpc :P
00:27:43  <othiym23>probably, yeah
00:28:02  <tjfontaine>honestly though, what you'll actually want is SNGL when we get in the JPC
00:28:11  <othiym23>but then I have to, like, talk to people to find out what the partnership details are so I can not pay my own dollars for it
00:28:18  <othiym23>vas ist das?
00:29:17  <tjfontaine>this is coming very very shortly as I understand it, http://www.joyent.com/blog/jonathan-perkins-on-why-smartos-is-not-gnu-linux
00:29:43  <tjfontaine>basically the environment feels much more like your GNU/Linux environment
00:30:21  <tjfontaine>so instead of getting things stuck in /opt/local, their prefix is /usr and then the other stuff is in like /platform or similar
00:30:30  <tjfontaine>sorry /system
00:30:42  <othiym23>honestly, I'm comfortable with the Solaris fs layout
00:31:10  <tjfontaine>well the other thing, is it's going to finally be (real) multiarch
00:31:15  <othiym23>I did ops on Solaris for many years, and as an ex-Java developer I started my career with an UltraSPARC sitting on my desk
00:31:51  <tjfontaine>sure, but I would imagine a few of the apps you have to test the various agents on expect things to be more linuxy than unix agnostic
00:31:59  <othiym23>I mostly just want to be able to use real DTrace and mdb when I get stuck on rando Node stuff
00:32:04  <othiym23>need me some jstack helpers
00:32:08  <tjfontaine>indeed
00:32:19  <othiym23>surprisingly, I have run into very few Linux-specific issues thus far
00:32:27  <trevnorris>tjfontaine: suck. I forgot what I set my password to on smartos.nodejs.org, oh well, guess I can just ssh as root and change it.
00:32:33  <othiym23>unless you count dealing with Heroku's particular brand of insanity
00:32:39  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:32:46  <tjfontaine>well the node community is pretty good about it, mostly because dependencies are generally in-tree
00:33:05  <tjfontaine>trevnorris: your ssh key isn't on the nodecore account?
00:33:24  <trevnorris>tjfontaine: it is. but I was trying to sudo, and it was asking for my password
00:33:31  <tjfontaine>ah
00:33:50  <tjfontaine>you wanna hear my coworkers piss and moan, try and talk to them about using sudo :)
00:33:50  <trevnorris>tjfontaine: I login directly as myself. god kills a kitten every time a user ssh's as root when they don't need to. :P
00:33:55  <trevnorris>haha
00:34:15  <trevnorris>ok. so now. how to change my password.
00:34:23  <tjfontaine>passwd trevnorris
00:34:41  <trevnorris>awesome. that was easy
00:34:43  * trevnorrispart ("Leaving")
00:34:47  * trevnorrisjoined
00:35:25  <trevnorris>tjfontaine: damn. i'm "not in the sudoers file"
00:35:28  <trevnorris>wtf
00:35:33  <tjfontaine>heh
00:38:51  <trevnorris>tjfontaine: mind if I add myself to the %staff group?
00:39:00  <trevnorris>they already have sudo priviledges
00:46:33  * dshaw_joined
00:46:59  <tjfontaine>trevnorris: that's fine
00:47:18  <trevnorris>coolio thanks
00:51:59  * TooTallNatejoined
00:54:14  * jmar777joined
00:54:41  <wolfeidau>tjfontaine: Heya mate pmap https://gist.github.com/wolfeidau/6708375 what are the anon items?
01:00:06  <tjfontaine>those are mmap anon sections, so basically the v8 heap
01:03:22  * mcavage_joined
01:04:36  <wolfeidau>tjfontaine: aha
01:04:58  <wolfeidau>tjfontaine: man you need to write some posts about this stuff :)
01:05:56  <wolfeidau>I am currently relying on blog posts with bad screen shots atm http://techapostle.blogspot.com.au/2012/11/smartos-improves-nodejs-debugging.html
01:05:59  <tjfontaine>wolfeidau: yes, I have 3 blog posts to do, I'm finishing one up now on how to "debug node in parallel"
01:06:15  <tjfontaine>wolfeidau: immediately after that will be nodeconfeu wrap up
01:06:22  <tjfontaine>wolfeidau: following that will be mdb
01:06:25  * mcavagequit (Ping timeout: 268 seconds)
01:06:32  <tjfontaine>mdb will actually be two blog posts
01:06:37  <wolfeidau>tjfontaine: awesome! I will leave you alone then :)
01:06:41  * AvianFluquit (Remote host closed the connection)
01:06:52  <tjfontaine>one on debugging memory leaks in native modules, and one on debugging memory leaks in javascript
01:07:55  <tjfontaine>wolfeidau: but keep asking questions as it reaffirms which pieces I need to focus on
01:09:21  <wolfeidau>tjfontaine: Yeah i would be screwed if i wasn't a solaris admin many years ago :)
01:09:31  <tjfontaine>heh
01:09:48  <wolfeidau>Getting all the stuff running was a sinch if you know svc* tools
01:09:55  * dapquit (Quit: Leaving.)
01:09:57  <wolfeidau>Still miss solaris
01:10:25  <wolfeidau>pmap is a great tool btw
01:10:35  * AvianFlujoined
01:10:56  <tjfontaine>indeed
01:11:11  <tjfontaine>I find all the tools related to it quite excellent
01:11:19  <tjfontaine>just with documentation that isn't very approachable
01:11:47  <tjfontaine>othiym23: hey, how do I opt out of newrelic promoted tweets? :)
01:12:00  <wolfeidau>Yes
01:12:08  <tjfontaine>I mean, I already know about you guys, I think I'm just costing you money
01:12:35  <tjfontaine>othiym23: actually I'm just jealous
01:13:25  <othiym23>the easiest way to opt out of promoted tweets is to use TweetBot as your client
01:13:46  <tjfontaine>ya, I use echofon on my phone, so I also don't see them there
01:14:21  <tjfontaine>I don't mind in reality, I just feel bad for the companies who pay for it, because you pay for a % of viewers and then for clicks
01:15:30  * jmar777quit (Write error: Broken pipe)
01:16:02  * dshaw_quit (Quit: Leaving.)
01:16:27  * jmar777joined
01:16:58  * jmar777quit (Remote host closed the connection)
01:22:26  * defunctzombiechanged nick to defunctzombie_zz
01:25:47  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:27:01  * dshaw_joined
01:38:34  * amartensquit (Quit: Leaving.)
01:39:11  * abraxasjoined
01:48:28  * dshaw_quit (Quit: Leaving.)
01:50:32  * c4milojoined
02:02:37  * groundwaterquit (Quit: groundwater)
02:16:57  * julianduquequit (Ping timeout: 241 seconds)
02:26:18  * mikeal1quit (Quit: Leaving.)
02:39:43  * brsonquit (Ping timeout: 260 seconds)
02:41:00  * kazuponjoined
02:41:27  * brsonjoined
02:43:37  * TooTallNatejoined
02:47:22  * dshaw_joined
02:49:18  * hueniversejoined
02:51:39  * dshaw_quit (Ping timeout: 248 seconds)
03:02:26  * julianduquejoined
03:03:03  * brsonquit (Ping timeout: 252 seconds)
03:05:01  * brsonjoined
03:19:55  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:28:34  <Domenic_>i report all promoted tweets as spam, which blocks that tweeter forever and then i never see their promoted tweets
03:28:39  <Domenic_>my blacklist is... large...
03:48:00  * EhevuTovjoined
03:53:53  * bradleymeckjoined
03:56:46  <trevnorris>tjfontaine: we're a great team. I'll show people how to make their apps 2x's faster, and you can show them how to fix everything I broke in the process. :P
04:03:14  * c4miloquit (Remote host closed the connection)
04:07:54  * kazuponquit (Ping timeout: 264 seconds)
04:08:56  * kazuponjoined
04:09:36  * indexzerojoined
04:11:15  * EhevuTovquit (Quit: This computer has gone to sleep)
04:21:34  * AvianFluquit (Remote host closed the connection)
04:26:34  * brsonquit (Quit: leaving)
04:29:50  * defunctzombie_zzchanged nick to defunctzombie
04:59:46  <tjfontaine>trevnorris: haha <3
05:08:30  * bradleymeckquit (Ping timeout: 264 seconds)
05:11:05  <trevnorris>othiym23: you still up?
05:16:04  * bradleymeckjoined
05:19:23  * mikealjoined
05:19:30  <trevnorris>test
05:19:31  <trevnorris>this
05:19:41  <tjfontaine>failed
05:19:44  * mikealquit (Client Quit)
05:22:14  <trevnorris>just going to think out loud here. i'm fine if domains can't be separated from lib/events.js. but need to find a way to get rid of the domain specific c++.
05:22:14  <trevnorris>the issue is, say, a user creates a server. this is an event emitter so if a domain is created when the server is instantiated, the actual TCPWrap class still hasn't been called until .listen() is called.
05:22:27  <othiym23>trevnorris: here I ammmm
05:23:45  * mikealjoined
05:23:55  <othiym23>trevnorris: so we're talking about eliminating the need to have MakeDomainCallback?
05:24:10  <trevnorris>othiym23: what would you expect the following to do: https://gist.github.com/trevnorris/6710157
05:24:48  <trevnorris>othiym23: and yes.
05:25:13  <othiym23>trevnorris: hold on a sec
05:25:14  <trevnorris>othiym23: well, more so the need to check if a domain object exists on an incoming callback
05:25:17  <trevnorris>coolio
05:26:21  <trevnorris>tjfontaine: you can chime in on that gist too, if you have nothing else to do :)
05:26:47  <tjfontaine>remind me in the morning, please and thank you :)
05:27:02  <trevnorris>heh, no worries. it's nothing big
05:27:09  <othiym23>trevnorris: how about this: https://gist.github.com/othiym23/6710163
05:27:14  <tjfontaine>k I'm just winding down for the day
05:27:22  <othiym23>just so we're clear on what we're talking about here
05:27:52  <othiym23>I would say in that scenario I would no longer expect errors to be reported on the domain once the domain listener has been removed
05:28:45  <othiym23>HOWEVER, I would also not be sad if requests in flight before the async listener were removed did get handled due to being cached or already wrapped up in execution state or whatever
05:29:03  <othiym23>I guess I didn't really need to get all shouty with my "however" there
05:29:05  <othiym23>sorry
05:29:38  <trevnorris>eh, no worries. it's hard to offend me. :)
05:29:50  <trevnorris>well, to my gist. would you expect the server to be captured by the asyncListener's error handler?
05:30:02  <trevnorris>well, and before/after
05:31:53  <othiym23>I don't think I would be surprised by it going either way, unless it were somehow inconsistent
05:32:03  <othiym23>like, I can see removing the listener just turning off all the behavior
05:32:08  * AvianFlujoined
05:32:37  <othiym23>but I can see it leaving in lingering hooks to the stuff that was created while the asyncListener was active
05:33:06  <trevnorris>oh, maybe I haven't explained how removeAsyncListener works. it just means remove it from the active queue. but any async "events" run between the two will still receive the listener.
05:33:28  <othiym23>right
05:33:37  <othiym23>I'm just talking about the listen() call
05:34:28  <trevnorris>yeah. here's the problem. var server won't actually receive the active async listener because server._handle (i.e. TCPWrap) isn't instantiated until .listen() is called.
05:34:59  <othiym23>right
05:35:46  <trevnorris>_but_ the domain module allows you to do https://gist.github.com/trevnorris/6710157
05:36:12  <trevnorris>which allows you to attach the error handler before the TCPWrap has been instantiated.
05:36:21  <othiym23>yup
05:36:27  * AvianFluquit (Ping timeout: 248 seconds)
05:36:41  <othiym23>a very powerful feature that I think absolutely noooobody is using
05:36:50  <trevnorris>haha
05:36:53  <trevnorris>I wish
05:36:57  <wolfeidau>Does mdb in smartos require i have my nodejs compiled with the debug flag to get stack information?
05:36:58  <othiym23>the suggested use case for d.add() is d.add(req); d.add(res)
05:37:24  <trevnorris>the performance advantage of async listeners is that it toggles a flag on the AsyncWrap class which is just an integer check at MakeCallback time.
05:37:56  <trevnorris>but that only happens if the async listener is active at the time the Wrap is instantiated
05:39:04  <trevnorris>wolfeidau: that's a question for tjfontaine, but think he's out for the night.
05:39:21  <othiym23>trevnorris: help me understand, is your intent to have domains be adding and removing the domain async listener in a way analogous to today's d.enter() / d.exit()
05:39:34  <tjfontaine>wolfeidau: no
05:39:56  * paddybyersquit (Quit: paddybyers)
05:39:57  <othiym23>trevnorris: I'm trying to understand whether removeAsyncListener is something that would be happening frequently enough to be an issue in practice
05:40:40  * paddybyersjoined
05:41:04  <trevnorris>othiym23: my initial implementation basically just inserted a process.{add,remove}AsyncListener(this._listener); into enter/exit
05:41:04  <trevnorris>and in Domain I had this._listener = process.createAsyncListener(noop, callbacksObj, this);
05:41:22  <tjfontaine>wolfeidau: what's going on?
05:41:27  <trevnorris>it worked great, up until I found this little problem.
05:42:17  <wolfeidau>tjfontaine: so I have this list of culprits https://gist.github.com/wolfeidau/6710244 now that first column i can ::findjsobjects on it but not ::jsstack
05:42:37  <wolfeidau>tjfontaine: Really i have NFI what that first column really means :)
05:42:38  <trevnorris>othiym23: in practice a user shouldn't be adding/removing a listener very often. once a listener is attached to an event it re-attaches it automatically to every asynchronous event called in it's call stack.
05:43:01  <wolfeidau>tjfontaine: I know those numbers are going up
05:43:08  <wolfeidau>And my process is using more ram
05:43:36  <tjfontaine>wolfeidau: welly ou ahve a bunch of empty objects and arrays
05:43:36  <wolfeidau>tjfontaine: But just need the next step in steping into or around to find the code it matches
05:43:45  <tjfontaine>wolfeidau: so do something like this
05:43:56  <tjfontaine>9fb5cbc3709::findjsobjects -l | ::jsprint
05:44:33  <othiym23>trevnorris: still thinking it through
05:44:35  <wolfeidau>yeah was just going to say i do 13488e0ff99::findjsobjects | ::jsprint
05:45:04  <wolfeidau>but i can't run the stack one
05:45:17  <othiym23>trevnorris: trying to parse "once a listener is attached to an event it re-attaches it automatically to every asynchronous event called in its call stack"
05:45:36  <othiym23>trevnorris: event is in there twice and I think it is referring to two different things ;)
05:45:36  <trevnorris>othiym23: I haven't actually tried this one in practice, but if I understand the code the server here will still be tracked by the domain: https://gist.github.com/trevnorris/6710157
05:46:31  <wolfeidau>tjfontaine: So i do 9fb5cbc3709::findjsobjects -l | ::jsprint then I want to see where the hell a bunch of anonmous functions actually come from
05:47:16  <wolfeidau>tjfontaine: Then i do 9fb5cbc3709::findjsobjects -l | ::jsprint -a and i see some things like callee: 9fb5cbc3639: function <anonymous> (as <anon>),
05:47:23  <tjfontaine>ya so you want to use findjsobjects -m and the later findjsobjects -r, but their usage is a little frustrating to figure out on their own
05:47:28  <tjfontaine>so ya, you have closures :)
05:47:32  <trevnorris>othiym23: check out how normal use is handled here: http://git.io/HOpChA
05:47:32  <trevnorris>othiym23: and how errors are handled here: http://git.io/BZIRkQ
05:47:50  <tjfontaine>wolfeidau: always helpful to name your functions :D
05:48:23  <wolfeidau>tjfontaine: I am the ops guy, inherited code
05:48:27  <tjfontaine>hehe
05:48:38  <tjfontaine>wolfeidau: so, from here, you want to just start taking cores on a regular basis
05:48:43  <wolfeidau>tjfontaine: After this excersise I am going to just go through and name everything :)
05:48:45  <tjfontaine>wolfeidau: especially since you're unfamiliar with it
05:48:56  <tjfontaine>wolfeidau: you're probably looking for sets of objects that grow at the same rate
05:49:09  <wolfeidau>Yeah i have 6 core files
05:49:32  <wolfeidau>And in each case 411bbde969 6142 3 Buffer: length, parent, offset
05:49:38  <wolfeidau>That goes up
05:49:42  <tjfontaine>yay, your leaking buffers :)
05:49:43  <wolfeidau>Along with a few others
05:49:55  <tjfontaine>that's realtively easy to track down probably
05:49:58  <tjfontaine>*relatively
05:50:04  <othiym23>trevnorris: try running this and nc-ing something to port 8000 https://gist.github.com/othiym23/6710287
05:50:11  <wolfeidau>tjfontaine: that sounds rather ominous :)
05:50:22  <tjfontaine>wolfeidau: is offset non-zero?
05:50:58  <tjfontaine>also is this v0.10?
05:51:35  <wolfeidau>Yes this is 0.10.18
05:51:37  <wolfeidau>https://gist.github.com/wolfeidau/6710244
05:51:51  <wolfeidau>Added some output of 13488e18e71::findjsobjects -l | ::jsprint -a
05:52:13  <tjfontaine>excellent
05:52:21  <trevnorris>othiym23: yeah. it does capture the error like I thought.
05:52:23  <tjfontaine>you're slicing 13bytes off a buffer and holding on to it for too long
05:52:34  <wolfeidau>tjfontaine: aha
05:52:56  <trevnorris>othiym23: it's pretty much a round about way of doing .add()
05:52:58  <tjfontaine>wolfeidau: witht he way buffers work there that could potentially leak a 1mb chunk of memory for a while
05:53:20  <wolfeidau>Yeah at the moment it is 1 or 2 mb per minute
05:53:25  <tjfontaine>baecc01d851 2405 2 PacketHeader: length, number
05:53:30  <tjfontaine>probably there
05:53:39  <tjfontaine>or related to it
05:53:46  <tjfontaine>this all seems like binary protocol related shtuff
05:54:04  <wolfeidau>It is using MySQL and Redis connections
05:54:15  <wolfeidau>On a regular basis
05:54:32  <wolfeidau>So how do i look into that
05:54:37  <tjfontaine>ok -- so
05:54:51  <trevnorris>wolfeidau: ooh, I just figured out how to use dtrace and track down the jstack of syscall::mmap*:entry today. it's freakin awesome!
05:55:12  <tjfontaine>I *think* you ::findjsobjects -m a specific buffer, and then you use ::findjsobjects -r to find references to it
05:55:14  <wolfeidau>trevnorris: Yeah i was messing with that earlier
05:55:22  <tjfontaine>which should lead you back to the object that's holding the buffer
05:55:26  <wolfeidau>dtrace is the bomb
05:55:38  <wolfeidau>tjfontaine: ok will try that
05:55:38  <trevnorris>seriously.
05:55:44  <othiym23>trevnorris: yeah, the add() is implicit because the domain was active when the EE was created
05:55:50  * EhevuTovjoined
05:56:00  <othiym23>trevnorris: I made the gist into a self-contained test case if you want it
05:56:28  <trevnorris>othiym23: ah, nice. thanks.
05:57:16  <tjfontaine>> b3bf05c5::findjsobjects -m
05:57:16  <tjfontaine>findjsobjects: marked b3bf05c5
05:57:16  <tjfontaine>> ::findjsobjects -r
05:57:17  <tjfontaine>b3bf05c5 referred to by b3bcd1e1.paths
05:57:37  <tjfontaine>> b3bcd1e1::jsprint
05:57:38  <tjfontaine>{
05:57:38  <tjfontaine> children: [],
05:57:38  <tjfontaine> paths: [
05:57:38  <tjfontaine> "/var/tmp/.medusa/node_modules/once/node_modules",
05:57:45  <tjfontaine>all kinds of stuff like that
05:57:51  <trevnorris>othiym23: on the side, one strange affect is it'll also catch sync errors as well. e.g.
05:57:51  <trevnorris>(function myBad() { process.addAsyncListener(...); throw new Error('yeah!'); }());
05:58:06  <wolfeidau>tjfontaine: yeah i didn't know you could mark
05:58:07  <othiym23>trevnorris: I've been working with this daily for over a year now, and I *still* have a hard time explaining to people how domains, EEs, and time interact
05:58:08  <trevnorris>othiym23: it'll allow you to catch the error in myBad() and continue execution if you want.
05:58:13  <tjfontaine>wolfeidau: nod
05:58:48  <trevnorris>othiym23: I can understand. took me a week of investigating before I realized the full extent of how these things work together.
05:59:06  <tjfontaine>trevnorris: documentation :)
05:59:29  <othiym23>trevnorris: that's not super different from how domains and process.on('uncaughtException', ...) work today, albeit maybe with better context available
05:59:53  * wwickspart
06:00:05  <othiym23>tjfontaine: you know, that was my take on it for a while, but even after teaching 300+ people about domains, the stuff trevnorris and I are talking about is still really abstract and slippery
06:00:24  <trevnorris>othiym23: true. just that since it's called _async_ listener, want' thinking about it during implementation. :)
06:00:25  <tjfontaine>othiym23: I want it more for myself and other core maintainers :P
06:00:32  <trevnorris>hah, seriously.
06:00:47  <othiym23>and putting it into words ends up sounding like "homeomorphic endofunctors on category Hask" to most people even if you're really careful
06:01:18  <trevnorris>tjfontaine: ok, you hold me to this. once this patch is in (since it's changing how a few things work) i'll write up docs on how this works.
06:01:33  <tjfontaine>othiym23: haha <3 you're the best you know, I just love your descriptions
06:01:34  <othiym23>tjfontaine: yeah, that would be suuuper handy, still, trying to write this shit down gets me accused of being some kind of egghead on the regular
06:01:38  <trevnorris>but then I'll hide it and only share the link to other core maintainers. :P
06:01:42  <tjfontaine>trevnorris: can do
06:02:01  <tjfontaine>trevnorris: we can put it in a non-printing version of doc :P
06:02:09  <trevnorris>hehe
06:02:19  <othiym23>I promise to review trevnorris's documentation and not share the sekrit URL with auslanders
06:02:33  <trevnorris>:)
06:02:33  <tjfontaine>othiym23: ya, I just ahve to stop and think about this stuff all the time, and it's always like rediscovering atlantis at times :)
06:02:51  <tjfontaine>or something I'm getting tired
06:03:01  * wwicksjoined
06:03:16  <trevnorris>honestly, the fact that all our c++ *Wrap classes are completely abstracted away into EventEmitters makes it so painful.
06:03:19  <tjfontaine>wolfeidau: any luck, have my dronings been an help or a hinderance?
06:03:25  * wwickschanged nick to Guest72322
06:04:21  <othiym23>I know this is a super niche request, but if we could lock Max in a cabin for a couple months, Misery-style, until he produces "mdb & Dtrace for Node developers and ops engineers", it would be totally useful
06:04:24  * Guest72322quit (Remote host closed the connection)
06:04:25  <othiym23>to me
06:05:17  <tjfontaine>hehe
06:05:48  <tjfontaine>I have the basics of something like that started for two blog posts, I'm hoping to get them hammered out tomorrow and friday/weekend
06:05:55  <trevnorris>because then the *Wrap exists on the ._handle property, and might not be instantiated even though the EE has been. and it gets super complicated with streams, because you have like readable._readableState._handle
06:06:04  <wolfeidau>tjfontaine: I think i blew up mdb Assertion failed: fjs->fjs_marking, file ../../../common/modules/v8/mdb_v8.c, line 3109, function findjsobjects_referent
06:06:35  <wolfeidau>tjfontaine: Happens when i run baecc0387f1::findjsobjects -r
06:06:43  <wolfeidau>After the mark
06:07:00  <wolfeidau>So damn close lol
06:07:18  <trevnorris>othiym23: so back to the task at hand, it's proving difficult to emulate how domains handle even emitters in the cases where the c++ *Wrap isn't instantiated at the same time as the js object.
06:07:29  <tjfontaine>wolfeidau: heh, don't use an address with the -r and see if that helps
06:09:10  * bradleymeckquit (Quit: bradleymeck)
06:09:28  <trevnorris>othiym23: so imo the correct thing to do would be to instantiate the *Wrap class at the same time as the JS object, but that would require some major-ish rewrite.
06:09:45  <trevnorris>and i'm not sure ben would be thrilled about that.
06:10:23  <tjfontaine>wolfeidau: also, you might try putting your core file in manta, and then using mlogin, as that has a potentially much newer mdb and v8.so (not knowing what world you're operating in right now)
06:10:45  <wolfeidau>tjfontaine: seems i am a bad
06:10:48  <othiym23>trevnorris: I'm not even sure that's the right thing to do, for anything other than asyncListener's needs
06:11:18  <othiym23>lazilly setting the handle on the listen call feels correct to me, so you don't start paying for something until you're actually using it
06:11:24  <wolfeidau>tjfontaine: I had the memory address in there
06:11:49  <othiym23>trevnorris: also I rewrote https://gist.github.com/othiym23/6710287 into a real node/test-style test
06:12:06  <tjfontaine>wolfeidau: nod, it should handle that better, but can you now find marked entries?
06:12:17  <trevnorris>othiym23: that, and imho it removes a level of complexity to understand and debug
06:12:18  <trevnorris>also, I consider the actual use case. is there anyone out there seriously creating 1000 servers w/o letting any of them listen?
06:12:31  <trevnorris>oh nice. thanks.
06:12:31  <wolfeidau>tjfontaine: yeah without the -r so just ::findjsobjects
06:12:41  <wolfeidau>-r returns this
06:12:58  <wolfeidau>mdb: must specify or mark an object to find references
06:13:16  <othiym23>trevnorris: I'd have to look at the socket.io code base
06:13:18  * LOUDBOTquit (Ping timeout: 264 seconds)
06:13:28  <tjfontaine>wolfeidau: did you mark an address first?
06:13:30  <trevnorris>haha, ok
06:13:31  <othiym23>bye bye LOUDBOT
06:13:44  * othiym23fires 21-gun salute to LOUDBOUT RIP
06:13:57  <wolfeidau>tjfontaine: Now getting way for information
06:14:12  <trevnorris>othiym23: also, in the end it's going to overall improve performance because we can remove expensive checks that are going to be run potentially hundreds of thousands of times /sec.
06:14:49  <othiym23>trevnorris: I'm only being semi-facetious, there's a lot of network modules out there that do lots of things weird with creating listeners / clients they don't actually use
06:14:53  <tjfontaine>wolfeidau: how would you feel about sharing a core, I know that can be dangerous territory (you should only do this with great discretion)
06:15:08  <trevnorris>othiym23: it's the same reason why removing the SlabAllocator was an overall win. yeah we malloc a lot more, but removing the checks and complexity was a bigger win.
06:15:18  <trevnorris>oy
06:15:28  <wolfeidau>tjfontaine: This isn't from production but yeah i know the drill :)
06:15:37  <tjfontaine>trevnorris: also libumem eats mallocs for a living
06:15:43  <tjfontaine>wolfeidau: heh good
06:15:45  <othiym23>trevnorris: your arguments are persuasive, I'm just used to thinking in terms of lazy instantiation being the smart thing to do by default
06:15:55  * julianduquequit (Ping timeout: 248 seconds)
06:15:59  <wolfeidau>tjfontaine: I will keep plugging away atm and see how i go
06:16:15  <trevnorris>tjfontaine: :)
06:16:17  <wolfeidau>tjfontaine: If i don't get anywhere i mite take you up on that
06:16:32  <tjfontaine>wolfeidau: ok, I'm kinda fading for the night -- but I will be around again on the morrow
06:17:03  <wolfeidau>tjfontaine: No stress mate this system is recovering fine anyways so the odd out of memory isn't all bad :)
06:17:12  <trevnorris>othiym23: and I agree, but only in regards to the bigger picture. an instantiated c++ class is at most going to take, what, 5kB mem and 200ns to instantiate.
06:17:18  <wolfeidau>Just want to get to the bottom of the issue
06:17:34  <wolfeidau>tjfontaine: Thanks again for your help it is appreciated
06:17:35  <tjfontaine>wolfeidau: was it v8 OOM, or system oom?
06:17:42  <trevnorris>othiym23: but every Object::Has() in c++ costs 50ns. and we're doing that for every callback for every I/O operation.
06:17:45  <wolfeidau>v8 oom
06:17:56  <wolfeidau>at 1.5g or so is that correct?
06:17:58  <tjfontaine>wolfeidau: you know you can --max-old-space or whatever so it uses more
06:18:02  <tjfontaine>wolfeidau: ya that's v8
06:18:26  <tjfontaine>max_old_space_size
06:18:40  * LOUDBOTjoined
06:18:45  <othiym23>YAY
06:18:54  <tjfontaine>OMG LOUDBOT IS HERE TO SAVE US
06:18:54  <LOUDBOT>ONLY BELIEVERS IN DEATH WILL DIE
06:19:01  <tjfontaine>so true
06:19:02  <wolfeidau>tjfontaine: I am in the process of breaking this system into smaller pieces
06:19:08  <tjfontaine>wolfeidau: nod
06:19:13  <trevnorris>othiym23: in heavy I/O you're already instantiating upwards of +50k ReqWrap classes/sec. one for each request.
06:19:20  <wolfeidau>So i am more keen to know why for future debugging :)
06:19:27  <tjfontaine>nod
06:19:33  <trevnorris>othiym23: so it's not like creating 1000 more for a bunch of unused servers is going to make a difference.
06:19:55  <wolfeidau>My skills profiling Java apps prooved invaluble in a lot of cases :)
06:20:10  <wolfeidau>I would like to skill up here as well
06:20:12  <tjfontaine>you poor bastard.
06:20:20  <othiym23>trevnorris: I am keenly interested to see what the benchmarks say about your work once you've figured out how to get domains working on asyncListener
06:20:20  <wolfeidau>haha
06:21:17  <othiym23>trevnorris: and I think I'm more or less with you now, I think my main concern now is scope creep causing this feature to slip out to 0.13
06:21:57  <wolfeidau>tjfontaine: I am close to understanding this crzy mdb thing need to read how this mark and -r work
06:22:17  <wolfeidau>At the moment i am just typing stuff :)
06:22:21  <trevnorris>othiym23: well, it works right now with all the domain stuff still injected in. made that commit so if I don't figure out the rest at least that much could get in.
06:22:30  <othiym23>I sort of kind of really wish that streams2 had had a little more time to gel in 0.9 before 0.10.0 went out the door, on a semi-related note
06:22:55  <othiym23>it felt like isaacs was all, "welp that's done (shipitsquirrel)"
06:23:03  <trevnorris>heh
06:24:18  <trevnorris>othiym23: so really, pr 6011 is ready for testing as far as the async listener part goes. just the part of removing domains from core still remains.
06:24:41  <othiym23>that reminds me, I should give it a quick run-through
06:25:06  <trevnorris>othiym23: oh, I do need to integrate it w/ ben's commit today so you get access to all the tls/crypto/zlib stuff as well.
06:25:10  <trevnorris>but that should be a breeze.
06:26:01  <trevnorris>the commit message for 234529d should have probably gone into doc/ :P
06:27:02  <trevnorris>othiym23: oh, and what do you think about passing the calling "this" as the first argument on a nextTick callback?
06:27:25  <trevnorris>don't have performance numbers, but it would prevent a lot of unnecessary function scoping.
06:28:28  <othiym23>trevnorris: I think it's a great idea as long as we can collectively come up with a sane way of explaining to people why it's there and how they'd make use of it
06:28:50  <othiym23>did you figure out how to get stuff like Pipe.nextTick from showing up in stacktraces yet?
06:29:05  <trevnorris>heh, yeah. I have a hard time explaining why anything I do with core is sane. :P
06:29:27  <trevnorris>actually, it was Pipe._tickCallback
06:29:33  <othiym23>yeah that
06:29:33  <trevnorris>let me tell you, that was confusing
06:31:25  <othiym23>thanks to you butting heads against that, I now understand how V8 comes up with its names for stacktraces
06:31:37  <trevnorris>haha, glad I could help
06:32:04  <othiym23>although it's still sort of spooky to me how it manages to find a plausible name for an anonymous function expression that's only, like, assigned to a var somewhere
06:32:22  <trevnorris>heh, it does to pretty well at that.
06:32:48  <othiym23>JavaScript seems to engender a certain level of magic in the tools people use for it
06:32:52  <othiym23>not sure how I feel about that
06:32:54  <trevnorris>what's really confusing though is when it gives you a function name (e.g. Pipe._tickCalback) and the line number. you go look, and they're not the same.
06:36:16  <othiym23>trevnorris: first attempt at using your fork to run the New Relic agent (with TLS): https://gist.github.com/othiym23/6710551
06:36:23  <othiym23>that's using flippin-tick-thing as the branch
06:36:42  <othiym23>yeah, that has been spooky dark magic to me since I started using node
06:37:00  <trevnorris>ah suck. thought I fixed that.
06:38:22  <trevnorris>othiym23: do you have the test that caused that? I have a quick fix, but want to make sure it really does fix the actual problem.
06:38:56  <othiym23>trevnorris: let me see if I can isolate it down to a small repro, the New Relic module codebase does a lot of stuff
06:39:16  <trevnorris>othiym23: thanks much.
06:43:51  <othiym23>trevnorris: the good news is that all of the continuation-local-storage tests work without a hitch
06:44:45  <othiym23>and CLS feature-tests for process.addAsyncListener before trying to load the polyfill, so that's with your version of addAsyncListener in use
06:44:49  <othiym23>it's a nontrivial test suite
06:45:40  <trevnorris>othiym23: oh, that's a nice surprise.
06:46:38  <othiym23>trevnorris: you can play along at home by 'npm install newrelic; cd node_modules/newrelic; npm install; make unit' while I try to narrow it down on my own
06:46:52  <trevnorris>coolio. thanks.
06:47:10  <othiym23>the integration tests require you have mysql, mongodb, memcached, and redis installed, so you probably don't want to mess with them right now ;)
06:48:35  <trevnorris>heh, yeah.
06:48:48  <othiym23>'./node_modules/.bin/mocha test/agent.test.js' will get me a failure most of the time
06:48:54  <othiym23>but not always
06:49:02  <othiym23>something racy in there somewhere?
06:49:05  <othiym23>that's kinda a bummer
06:50:59  <trevnorris>strange. i'll figure that out.
06:51:07  <trevnorris>i'm having a problem installing
06:51:18  <trevnorris>npm install keeps giving me a shasum mismatch and aborting
06:51:29  <trevnorris>but that leaves all the .lock files in ~/.npm
06:51:37  <trevnorris>so trying to install again just locks up
06:52:02  <trevnorris>wtf. keep getting ../src/node_zlib.cc:101: void node::ZCtx::Close(): Assertion `!write_in_progress_ && "write in progress"' failed.
06:53:10  <trevnorris>dammit. again. this is really pissing me off.
06:53:55  <othiym23>is this with your build of node, or with 0.11.8, or 0.10.19?
06:54:18  <trevnorris>tip of master
06:54:19  * mcavage_quit (Read error: Connection reset by peer)
06:54:24  <trevnorris>actually, using my patch.
06:54:39  * mcavagejoined
06:55:04  <trevnorris>you probably know this, but I do my installs with: /path/to/build/node $(which npm) --nodedir=/path/to/build/ install
06:55:25  <trevnorris>so I don't have to screw around with global installs and what not
06:55:31  <trevnorris>haha finally!
06:56:43  * rendarjoined
06:57:00  <othiym23>you're probably getting hit with whatever npm issue has been causing everybody else's installations to fail since the upgrade to 0.10.19
06:57:05  <MI6>nodejs-v0.10-windows: #229 UNSTABLE windows-ia32 (9/600) windows-x64 (7/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/229/
06:57:05  <othiym23>you develop on Linux, right?
06:57:46  <trevnorris>yeah
06:58:34  <othiym23>so when I do a cold run of agent.test.js it will succeed, but subsequent runs (when I'm presuming everything is being pulled out of buffer) will crash
06:58:40  <othiym23>still working on isolating the crash
06:59:31  * felixgejoined
06:59:31  * felixgequit (Changing host)
06:59:31  * felixgejoined
06:59:32  * mcavagequit (Read error: Connection reset by peer)
06:59:33  * mcavage_joined
06:59:49  <trevnorris>oy, so what's the command to have npm install all your deps deps?
07:00:04  <trevnorris>mocha is giving me "Cannot find module 'assertion-error'"
07:02:52  <trevnorris>wow, this is making installation really painful.
07:03:11  <othiym23>'npm install' should do it
07:03:44  <othiym23>so I'm in loadAsyncQueue, and context._asyncQueue is undefined, but context.domain._asyncQueue is not
07:03:57  <othiym23>do I have some commits on flippin-tick-thing I shouldn't?
07:04:22  <othiym23>whoops context[0].domain._asyncQueue
07:05:04  * EhevuTovquit (Quit: This computer has gone to sleep)
07:05:40  * EhevuTovjoined
07:05:51  <othiym23>trevnorris: context[0].domain._asyncQueue[0] === context[0] -> true
07:05:55  <othiym23>is this something you'd expect?
07:07:44  <trevnorris>um. that looks strange. why is context an array?
07:07:58  <othiym23>haha the error handed to errorHandler is the earlier error from inside the asyncListener code
07:08:00  <trevnorris>also, I've recently (in the last hour) force pushed updates to the branch
07:08:04  <othiym23>INCEPTION
07:08:36  <othiym23>I didn't pull from your fork on this checkout until right after I said "I should build your PR"
07:09:28  <trevnorris>ok
07:10:07  <othiym23>trevnorris: https://gist.github.com/othiym23/caab91ee22d4362819d1
07:10:17  <othiym23>that's the stack on the error that got handed off to errorHandler
07:10:54  <trevnorris>that is quite the stack trace.
07:10:58  <othiym23>unfortunately using console.log there (shockingly) caused the debug session to terminate
07:11:00  <othiym23>yeah, well, mocha
07:11:14  <othiym23>getting mocha out of the agent codebase is on my list of things to do
07:11:20  <othiym23>the createWrap in there is suggestive, though
07:11:31  <othiym23>sorry, createWriteReq
07:11:41  <trevnorris>dude I seriously can't get anything to run. I can't seem to get all the unmet dependencies
07:11:56  <trevnorris>hahaha!!! finally got it
07:13:00  <othiym23>it looks like if the error handler gets an error while it's handling an error, that will cause an error that gets handed off to errorHandler, finally bringing the whole thing down
07:13:09  <othiym23>so error -> error -> error -> crash
07:13:57  <trevnorris>yeah. I have a toggle that says, if a before/after error, then the error handler also errors then return false (i.e. crash)
07:14:03  <trevnorris>it's to prevent infinite throwing
07:14:23  <othiym23>right
07:14:54  <trevnorris>also, it's really strange because if a before/after throws but execution continues, it's a freakin impossible thing to find.
07:15:06  <othiym23>so createWriteReq is barfing, for some reason, that's getting handed off to process._fatalException, which is emitting an uncaughtException, which mocha in its infinite wisdom is trying to do something with, and then the async listener goes off to the moon
07:15:50  <othiym23>btw the same thing happens even without mocha involved
07:16:01  <trevnorris>wtf. mocha just displayed a pop-up on my screen saying tests passed.
07:16:08  <othiym23>lemme find an integration test (which uses node-tap) that also barfs
07:16:19  <othiym23>haha it's got built-in growl / growl-like integration
07:16:22  * AvianFlujoined
07:16:26  <trevnorris>heh
07:17:24  <othiym23>'node test/integration/connection-failure-413.tap.js' exhibits the same failure
07:17:38  <othiym23>and I'd say it's a pretty simple test, except it pulls in a bunch of the agent code
07:17:44  <othiym23>let me see if I can reduce it further
07:25:27  * piscisaureus_joined
07:33:26  <trevnorris>othiym23: ok. so it looks like somehow the _asyncQueue is being passed in as the context, instead of the context itself. pretty sure it's coming from AsyncWrap::MakeDomainCallback
07:34:37  <othiym23>trevnorris: still digging into my codebase to come up with a self-contained test case
07:34:46  <trevnorris>othiym23: thanks.
07:35:13  <othiym23>it appears to be an outbound HTTP request that triggers it
07:35:40  * AvianFluquit (Remote host closed the connection)
07:39:54  <trevnorris>ok, and it's coming from node::MakeDomainCallback.
07:45:21  <trevnorris>othiym23: ok, and it's coming from cares_wrap. just need to figure out why.
07:57:22  <trevnorris>and that's coming from cares.getaddrinfo from lib/dns.js
07:58:21  <trevnorris>which is coming from dns.lookup
07:58:32  <trevnorris>othiym23: if that helps you narrow down your case at all
08:03:06  <othiym23>hmm
08:03:17  * bnoordhuisjoined
08:03:40  <othiym23>regular DNS lookup succeeds, but maybe the DNS lookup inside http.request is causing weirdness
08:04:59  <othiym23>I reduced too much, have to backtrack until it starts failing again
08:08:10  <trevnorris>othiym23: well, that object you're seeing passed in is the _asyncQueue object that's set on the context of the request
08:08:23  <trevnorris>i'm confused how that's making it out to JS though
08:24:21  <othiym23>almost have it
08:24:34  <othiym23>it's a combination of CLS + http.request, I think
08:24:43  <othiym23>could be dns.lookup, tho
08:32:26  <trevnorris>othiym23: what i'm seeing is that context._asyncQueue is being passed, not context
08:34:19  <othiym23>trevnorris: https://gist.github.com/othiym23/6711428
08:34:37  <trevnorris>othiym23: wow, impressive dude
08:34:42  <othiym23>that's as small as I can make it -- only relies on process.addAsyncListener and the DNS module
08:36:26  <trevnorris>wow, very impressive
08:42:07  <othiym23>trevnorris: actually I lied: https://gist.github.com/othiym23/6711509
08:42:24  <trevnorris>othiym23: hah, wtf.
08:43:47  <trevnorris>othiym23: seriously wtf. you don't even need the before/after callbacks.
08:44:22  <othiym23>something amiss in the ReqWrap for cares?
08:44:27  <trevnorris>must be
08:44:46  <trevnorris>I check the object going in and it's fine
08:44:55  <trevnorris>check the object coming out, and it's different.
08:46:23  <othiym23>it's total yak-shaving at this point, but I shrunk down the gist some more
08:47:11  <trevnorris>hah
08:54:44  * defunctzombiechanged nick to defunctzombie_zz
08:59:12  <trevnorris>oh you've got to be shitting me.
08:59:33  <trevnorris>othiym23: thanks for taking all night to find a total fuck up on my part
08:59:43  <othiym23>trevnorris: looking at src/cares_wrap.cc, how is the AsyncWrap stuff mixed in there?
09:00:05  <trevnorris>othiym23: ReqWrap inherits from AsyncWrap
09:00:13  <othiym23>no problem, dude, learned a bunch in the process
09:00:45  <trevnorris>I got my two implementations crossed, and after looking at this for so long it all looked the same.
09:01:23  <othiym23>so it's all via GetAddrInfoReqWrap?
09:01:47  <trevnorris>yeah
09:02:11  <trevnorris>so dns.lookup creates an object in js and passes that to getaddrinfo
09:02:22  <trevnorris>that in turn instantiates a new GetAddrInfoReqWrap
09:02:39  <trevnorris>which inherits from ReqWrap, which inherits from AsyncWrap
09:03:18  <trevnorris>which uses state sharing to detect there's an active async listener, which then passes the object back out to JS so I can attach the _asyncWrap object with all the callback/domain information you pass to addAsyncListener
09:03:29  <othiym23>right
09:03:33  <othiym23>where's the error?
09:04:50  <trevnorris>in my code. so AsyncWrap has it's own MakeCallback impl. for performance reasons
09:05:05  <trevnorris>btw, just force pushed the fix. go ahead and try running your tests again
09:05:06  <othiym23>right, I'm looking at that right now
09:05:10  <othiym23>OK!
09:05:42  <trevnorris>but there's also node::MakeCallback that's part of the public c++ api so users can safely enter JS again w/ proper error handling and all that stuff
09:06:18  <othiym23>what's the fastest way to nuke my local checkout and force-pull your force-pushed changes?
09:06:24  <othiym23>nuke the branch and re-checkout?
09:06:30  <trevnorris>git fetch <remote>
09:06:41  <trevnorris>git reset --hard <remote>/flippin-tick-thing
09:07:18  <trevnorris>but since they're passing the object I have to do a full check if the object property _asyncQueue is set
09:07:27  <othiym23>thanks
09:07:32  <trevnorris>:)
09:07:52  <trevnorris>but in my tired state I used Object::Get() instead of Object::Has() and passed the return object from ::Get()
09:08:13  <trevnorris>so I was passing the _asyncQueue object, not the context that contains the _asyncQueue object
09:08:37  <trevnorris>but it was hard to manifest since almost all the callbacks in core now go through AsyncWrap
09:08:47  <trevnorris>except a few in cares and tls
09:09:00  <trevnorris>which is why it showed up there.
09:09:03  <othiym23>cool, so my observation that that looked kinda goofy inside the Node debugger was more or less salient
09:09:27  <trevnorris>yeah
09:09:28  <othiym23>("that" = the context)
09:09:49  <othiym23>aw c'mon, make, you didn't need to rebuild all of v8
09:09:59  <othiym23>that's what I get for resetting to master, I guess
09:10:06  <trevnorris>yeah
09:11:25  <othiym23>my fun weekend project when I have time for fun or weekends again is to see how hard it would be to replace v8's regexp implementation with re2, which I imagine will get me up to speed with V8's style of C++ in a big hurry
09:11:55  <trevnorris>sounds hard core.
09:12:44  <trevnorris>othiym23: seriously dude. you just spent 3-4 hours helping me figure out that stupid bug. I owe you one.
09:13:15  <othiym23>I owe you like 20 at this point, so we'll sort it out later ;)
09:13:20  <trevnorris>hah, ok
09:13:34  <othiym23>OK, so now the only test failures I'm seeing are due to the V8 bug that uglify is exercising
09:14:15  <trevnorris>wow, that's a nice surprise at least.
09:14:51  <othiym23>there are a couple other iffy looking failures, but I don't know whether those would be there in the latest 0.11 release because I haven't done any testing against those
09:14:53  <othiym23>one sec
09:14:55  <trevnorris>so, yeah. i'm going to keep working on getting domains out of core, but at least async listeners are working. so if nothing else that can land before v0.13
09:17:22  <othiym23>that's exxxxcellent news
09:17:48  <othiym23>and yeah, a couple of the failures I was seeing still happen on 0.11.7, and may or may not be the fault of the New Relic code, since they're all in integration tests
09:18:14  <othiym23>does look like I have some work to do to get the asyncListener polyfill working properly on 0.11.x, but with luck that won't really be an issue
09:19:19  <trevnorris>coolio. and I still need to integrate with ben's latest commit.
09:19:31  * EhevuTovquit (Quit: This computer has gone to sleep)
09:19:32  <bnoordhuis>../../deps/openssl/openssl/crypto/des/set_key.c:398: error: unsupported inline asm: input constraint with a matching output constraint of incompatible type! :-/
09:19:40  <bnoordhuis>sometimes i hate computers
09:19:45  <bnoordhuis>and other programmers
09:19:58  <indutny>heya
09:20:02  <trevnorris>haha
09:21:00  <trevnorris>bnoordhuis: haven't had a burst of inspiration of how to handle the AsyncWrap and WeakObject, have you? :)
09:21:25  <trevnorris>well, regardless I barely have enough brain cells functioning to make it to bed.
09:21:32  <bnoordhuis>trevnorris: not quite. i did spend some brain power on it
09:21:44  <bnoordhuis>i'll see if i can go through your PR today
09:22:00  <trevnorris>bnoordhuis: thanks much. :)
09:22:25  <trevnorris>i'm surprised you have any brain power to spare. your kids only 2 weeks old now?
09:22:36  <trevnorris>s/kids/kid
09:22:41  <bnoordhuis>10 days now :)
09:22:59  <othiym23>OK, something's busted in Restify in both 0.11.7 and flippin-tick-thing, and my async execution tracer torture test fails under flippin-tick-thing but not with the polyfill, which may or may not be flippin-tick-thing's fault
09:23:07  <trevnorris>awesome.
09:23:10  <othiym23>I'll look into that more tomorrow when I'm more well-rested
09:23:40  <trevnorris>othiym23: coolio. and thanks again. it might be that it's still not fully integrated.
09:24:01  <trevnorris>othiym23: it's only on HandleWrap and ReqWrap, so there are cases where listeners won't get called.
09:24:27  <trevnorris>but bnoordhuis' being real nice hand helping me out there :)
09:25:03  <trevnorris>bnoordhuis: I just remember the first 2 weeks being the hardest. actually, I don't really remember them at all.
09:25:14  <trevnorris>that was a lot of sleep deprivation.
09:27:52  <othiym23>trevnorris: setTimeout is passing the context to before instead of the domain, it appears
09:29:13  <trevnorris>othiym23: well, before and after get (context, domain)
09:29:27  <trevnorris>are you saying that context is passed as both arguments?
09:29:51  <othiym23>hmm... I think I'm assuming that before only gets domain
09:29:56  <othiym23>time to square up the polyfill!
09:30:01  <trevnorris>heh
09:30:21  <othiym23>sorta scary that it only breaks there, though
09:30:32  <trevnorris>hah, know that feeling
09:30:32  <othiym23>I think I'm just putting my stuff right on the context objects right now
09:30:35  <othiym23>pee-eww
09:30:46  <othiym23>OK, that I will definitely fix tomorrow
09:30:53  <othiym23>I need to get to bed uh three hours ago
09:31:04  <trevnorris>i'm with you there.
09:31:08  <othiym23>tty'all later!
09:31:11  * othiym23&
09:31:12  <LOUDBOT>NOT THE BUTTONS MORON
09:31:13  <trevnorris>night all
09:31:15  * trevnorris&
09:31:16  <LOUDBOT>WHO ARE YOU TO SAY WHAT IS ALLOWED
09:40:11  * bnoordhuisquit (Ping timeout: 260 seconds)
09:56:19  * kazuponquit (Remote host closed the connection)
09:58:12  * Kakerajoined
09:58:40  * piscisaureus_quit (Ping timeout: 264 seconds)
10:04:28  * mcavagejoined
10:04:28  * mcavage_quit (Read error: Connection reset by peer)
10:05:10  * mcavage_joined
10:05:10  * mcavagequit (Read error: Connection reset by peer)
10:05:45  * mcavage_quit (Read error: Connection reset by peer)
10:05:54  * mcavagejoined
10:06:11  * bnoordhuisjoined
10:08:11  * mcavage_joined
10:08:11  * mcavagequit (Read error: Connection reset by peer)
10:14:37  * bnoordhuisquit (Ping timeout: 246 seconds)
10:34:07  * bnoordhuisjoined
10:38:16  * mralephquit (Read error: Connection reset by peer)
10:38:24  * mralephjoined
10:46:06  <MI6>nodejs-v0.10: #1503 UNSTABLE smartos-x64 (2/600) osx-ia32 (1/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1503/
11:03:01  * bnoordhuisquit (Ping timeout: 248 seconds)
11:03:56  * dominictarrjoined
11:23:47  * abraxasquit (Remote host closed the connection)
11:24:19  * abraxasjoined
11:27:50  * indexzeroquit (Quit: indexzero)
11:28:28  * abraxasquit (Ping timeout: 240 seconds)
12:00:04  * piscisaureus_joined
12:00:05  * mcavage_quit (Read error: Connection reset by peer)
12:00:16  * mcavagejoined
12:30:29  * piscisaureus_quit (Ping timeout: 248 seconds)
12:35:08  * dominictarrquit (Ping timeout: 240 seconds)
12:45:20  * AvianFlujoined
12:53:29  * nightmar1joined
12:54:20  <nightmar1>what does uv_run return with UV_RUN_NOWAIT?
13:00:28  * Kakeraquit (Ping timeout: 264 seconds)
13:02:12  * bnoordhuisjoined
13:04:59  <saghul>nightmar1 a boolean indicating if you need to run it again because there is pending work to do
13:05:04  * piscisaureus_joined
13:05:30  <piscisaureus_>bnoordhuis: hi
13:05:33  <bnoordhuis>piscisaureus_: https://github.com/joyent/node/issues/6214
13:13:47  * mcavage_joined
13:13:48  * mcavagequit (Read error: Connection reset by peer)
13:14:58  * hzjoined
13:16:52  * Kakerajoined
13:26:26  <nightmar1>hm
13:26:52  <nightmar1>i am creating a udp thing, starting it and stopping it
13:26:55  <nightmar1>i get -1 on the stop
13:28:43  <bnoordhuis>is that an implied question or just an observation?
13:35:42  <nightmar1>observation
13:35:57  <nightmar1>i am doing this in my bindings, so ill try a plain c example first
13:36:44  * jmar777joined
13:38:08  * AvianFluquit (Remote host closed the connection)
13:57:50  * piscisaureus_quit (Ping timeout: 240 seconds)
13:58:39  * bnoordhuisquit (Ping timeout: 256 seconds)
14:22:58  * mikealquit (Quit: Leaving.)
14:25:02  * kazuponjoined
14:28:07  * mcavage_quit (Remote host closed the connection)
14:30:44  * mikealjoined
14:30:45  * jmar777quit (Write error: Connection reset by peer)
14:31:11  * jmar777joined
14:44:55  * piscisaureus_joined
14:50:24  * c4milojoined
14:54:48  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:03:27  * kenperkinsquit (Quit: Computer has gone to sleep.)
15:07:58  * c4miloquit (Remote host closed the connection)
15:15:22  * AvianFlujoined
15:17:13  * dominictarrjoined
15:17:35  <MI6>nodejs-master: #580 UNSTABLE smartos-x64 (6/642) http://jenkins.nodejs.org/job/nodejs-master/580/
15:17:46  * AvianFlu_joined
15:17:46  * AvianFluquit (Disconnected by services)
15:17:53  * AvianFlu_changed nick to AvianFlu
15:28:01  * jmar777quit (Remote host closed the connection)
15:38:11  * kazuponquit (Remote host closed the connection)
15:39:32  * jmar777joined
15:39:33  * octetcloudjoined
15:39:42  * nightmar1quit (Ping timeout: 264 seconds)
15:47:26  * nightmar1joined
16:07:16  * c4milojoined
16:15:37  * jmar777quit (Remote host closed the connection)
16:15:54  * defunctzombie_zzchanged nick to defunctzombie
16:19:03  * defunctzombiechanged nick to defunctzombie_zz
16:19:31  * jmar777joined
16:25:10  <nightmar1>I woud make uv_run ONCE return 1 when uv_stop is being used
16:25:17  * dapjoined
16:27:31  * amartensjoined
16:30:05  * Benvie_joined
16:30:42  * Benviequit (Ping timeout: 240 seconds)
16:30:51  * jmar777quit (Remote host closed the connection)
16:31:40  * mikealquit (Quit: Leaving.)
16:32:38  * inolenquit (Quit: Leaving.)
16:32:55  * jmar777joined
16:40:00  * defunctzombie_zzchanged nick to defunctzombie
16:41:48  <indutny>tjfontaine: hi
16:41:55  <indutny>tjfontaine: what about performance https://github.com/joyent/node/pull/6273 ?
16:42:25  <tjfontaine>what about what performance?
16:44:58  * defunctzombiechanged nick to defunctzombie_zz
16:45:42  <indutny>well
16:45:45  <indutny>I thought we reverted v8
16:45:49  <indutny>update
16:45:53  <indutny>because of performance problems
16:48:21  <tjfontaine>no
16:48:26  <tjfontaine>we reverted because it was crashing
16:48:39  * kazuponjoined
16:54:14  * kazuponquit (Ping timeout: 268 seconds)
16:56:05  * dshaw_joined
16:56:38  <indutny>tjfontaine: ah
16:56:42  <indutny>tjfontaine: ok, then :)
16:57:04  <tjfontaine>:)
17:01:35  * brsonjoined
17:07:15  * AvianFluquit (Remote host closed the connection)
17:08:32  <MI6>joyent/node: Timothy J Fontaine master * eb09145 : test: add regression test for #6235 (+1 more commits) - http://git.io/PWCZ2Q
17:11:21  <othiym23>tjfontaine: does this v8 upgrade include indutny's fix for the KEYWORDS undefined blahblahblah uglify was crashing on?
17:11:41  <indutny>othiym23: that's not mine, but yes
17:11:55  <tjfontaine>indeed
17:12:24  <othiym23>oh right they redid it in their own style
17:12:42  <othiym23>accepting help from outsiders is so uncool
17:15:01  * Benvie_quit (Ping timeout: 245 seconds)
17:15:07  * dominictarrquit (Quit: dominictarr)
17:15:10  * Benviejoined
17:15:34  <othiym23>oh look, there's the GitHub mail that answers my question
17:16:10  * dominictarrjoined
17:17:00  * dominictarrquit (Client Quit)
17:18:13  <MI6>nodejs-master: #581 UNSTABLE osx-ia32 (1/643) smartos-x64 (6/643) http://jenkins.nodejs.org/job/nodejs-master/581/
17:18:14  * inolenjoined
17:28:52  * mikealjoined
17:30:45  * nightmar1quit (Ping timeout: 248 seconds)
17:33:38  * AvianFlujoined
17:38:12  * mikealquit (Ping timeout: 256 seconds)
17:39:15  <Domenic_>vm2 trundles on...
17:40:04  * mikealjoined
17:40:52  * defunctzombie_zzchanged nick to defunctzombie
17:42:03  * dominictarrjoined
17:43:11  * groundwaterjoined
17:47:08  <MI6>nodejs-master-windows: #373 UNSTABLE windows-x64 (22/643) windows-ia32 (23/643) http://jenkins.nodejs.org/job/nodejs-master-windows/373/
17:52:35  <tjfontaine>Domenic_: I presume you saw my response on the "cpu regression" issue?
17:54:15  <MI6>libuv-master: #259 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/259/
17:57:14  * bradleymeckjoined
18:06:34  * TooTallNatejoined
18:07:44  <MI6>libuv-node-integration: #242 UNSTABLE linux-ia32 (1/643) smartos-x64 (6/643) http://jenkins.nodejs.org/job/libuv-node-integration/242/
18:08:13  * dominictarrquit (Quit: dominictarr)
18:09:47  * dominictarrjoined
18:13:58  <Domenic_>tjfontaine: yeah, it wasn't vm's fault, but a general 0.11 thing?
18:14:36  <tjfontaine>Domenic_: it's a v8 3.20 thing, yes -- I suspect once I finally get time to work on benchmark results we're going to see this pop up other places
18:15:11  <Domenic_>yay for vm2! but, uh, sorry for node i guess :P
18:15:14  <tjfontaine>Domenic_: we're exercising v8 in almost exactly the same way regardless of vm1/vm2 [or at least in the way its different it is not appreciable to revert to vm1 to save this time]
18:15:45  <Domenic_>ok cool, wasn't sure how different the mechanisms were, glad to hear they're similar.
18:17:26  <tjfontaine>from at least a profiling standpoint, there's no substantial difference, there is a 3rd spire that appears because setting the proxy global, but removing that only saves 2 seconds from bens test, which actually makes vm2 faster than vm1 on 3.20
18:18:04  <tjfontaine>anyway, vm2 is safe, it's not going to get reverted, but may see significant refactoring to make proper use of v8 in this new world
18:18:24  <tjfontaine>if this regression is evident in a real world use case
18:23:05  <Domenic_>sounds good! :D
18:43:22  * dominictarrquit (Quit: dominictarr)
18:45:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:55:05  * dshaw_quit (Quit: Leaving.)
18:57:50  * defunctzombiechanged nick to defunctzombie_zz
19:00:20  * defunctzombie_zzchanged nick to defunctzombie
19:01:17  <MI6>nodejs-master-windows: #374 UNSTABLE windows-x64 (23/643) windows-ia32 (25/643) http://jenkins.nodejs.org/job/nodejs-master-windows/374/
19:02:36  * defunctzombiechanged nick to defunctzombie_zz
19:03:45  * defunctzombie_zzchanged nick to defunctzombie
19:04:35  * defunctzombiechanged nick to defunctzombie_zz
19:05:57  * TooTallNatejoined
19:06:41  * AvianFluquit (Ping timeout: 245 seconds)
19:07:29  * groundwaterquit (Ping timeout: 256 seconds)
19:08:29  * groundwaterjoined
19:10:32  * EhevuTovjoined
19:18:50  * EhevuTovquit (Quit: This computer has gone to sleep)
19:19:24  * EhevuTovjoined
19:20:41  * c4miloquit (Remote host closed the connection)
19:23:03  * groundwaterquit (Ping timeout: 260 seconds)
19:24:28  * AvianFlujoined
19:25:32  * groundwaterjoined
19:26:41  * bnoordhuisjoined
19:30:06  * groundwaterquit (Ping timeout: 264 seconds)
19:31:37  * groundwaterjoined
19:36:50  * groundwaterquit (Ping timeout: 264 seconds)
19:38:59  * c4milo_joined
19:39:38  * groundwaterjoined
19:40:46  * indexzerojoined
19:41:54  * hij1nx_onaboatchanged nick to hij1nx_inberlin
19:42:17  * hueniversequit (Read error: Connection reset by peer)
20:00:22  * julianduquejoined
20:02:08  * groundwaterquit (Ping timeout: 256 seconds)
20:06:35  * hueniversejoined
20:11:10  * wavdedjoined
20:23:29  <trevnorris>afternoon everyone
20:23:55  <othiym23>afternoon trevor
20:24:22  <othiym23>I think I may have run into some weirdness with process.nextTick and #6011, but I need to come up with a simpler reduction, I think
20:24:50  <trevnorris>ok. have a description for that weirdness?
20:28:25  <othiym23>yeah, async state goes missing from process.nextTick callbacks when there are two overlapping
20:28:28  <othiym23>that's the gist
20:28:34  <othiym23>but like I said, it needs further narrowing
20:28:52  <othiym23>"interleaved", not "overlapping"
20:29:27  <trevnorris>ok. let me know when you have a test case. don't care if it's complex or not.
20:30:11  <othiym23>the failing case is in the middle of a file with 20 other scenarios
20:30:21  <othiym23>the first step is pulling it out of that file and seeing if it still fails ;)
20:30:23  <trevnorris>ah, heh
20:31:39  * groundwaterjoined
20:31:44  * defunctzombie_zzchanged nick to defunctzombie
20:40:06  <trevnorris>bnoordhuis: ping
20:54:17  * c4milo_quit (Remote host closed the connection)
21:04:13  <trevnorris>aahh. it's such a great feeling to delete code.
21:04:55  * indexzeroquit (Quit: indexzero)
21:04:58  <mikeal>the best.
21:05:20  <tjfontaine>mikeal: thanks for the ^5 earlier
21:05:33  <mikeal>no problem :)
21:05:37  <tjfontaine>:)
21:05:56  * skebcio_quit (Read error: Operation timed out)
21:08:03  * skebciojoined
21:08:58  * hzquit
21:10:11  * defunctzombiechanged nick to defunctzombie_zz
21:14:30  * st_lukejoined
21:24:33  * AvianFluquit (Remote host closed the connection)
21:25:32  * jmar777quit (Remote host closed the connection)
21:37:26  * mikealquit (Quit: Leaving.)
21:38:13  * mikealjoined
21:40:37  <bnoordhuis>trevnorris: pong
21:40:46  * st_lukequit (Remote host closed the connection)
21:42:13  <trevnorris>bnoordhuis: on sec. let me remember... ah yeah. s currently we're not initializing some *Wrap classes until, say like, the .listen() event.
21:42:43  <trevnorris>bnoordhuis: from an architecture standpoint would you be totally opposed to initializing the class at the same time the js object is instantiated?
21:44:01  <trevnorris>bnoordhuis: the reason is, right now the the event emitter is a strange abstraction away from what's under the hood. so domains have to hook into it there as well. if we instantiated the c++ class at the same time as the js instance then we could move away from that abstraction.
21:44:18  <trevnorris>bnoordhuis: and I'd be able to successfully remove domain specific code from core.
21:44:41  * wavdedquit (Quit: Hasta la pasta)
21:44:55  <trevnorris>but as it is right now, I can't. because users can do things with the JS object between when it's instantiated and when the Wrap is
21:45:11  * felixgequit (Quit: felixge)
21:47:40  <trevnorris>bnoordhuis: and fwiw performance isn't an issue here. we're already initializing so many ReqWrap instances for every connection/write and what have you that initializing a few a little earlier probably would only be noise in the benchmarks.
21:48:32  <bnoordhuis>trevnorris: no, that doesn't bother me
21:49:02  <trevnorris>bnoordhuis: awesome!
21:51:51  <indutny>hey
21:51:52  <indutny>howdy?
21:51:55  <trevnorris>indutny: sup?
21:52:02  <indutny>all good
21:52:20  <indutny>how are you?
21:52:57  <trevnorris>doing well. just finishing up the only way I can think to integrate this async listener patch into core.
21:53:10  <trevnorris>bnoordhuis will probably find a better way during review :)
21:54:54  * AvianFlujoined
21:56:11  * AvianFlu_joined
21:56:16  * AvianFluquit (Read error: Connection reset by peer)
22:05:21  <trevnorris>indutny: been working on anything interesting?
22:05:26  <indutny>yeah
22:05:26  <indutny>spdy
22:05:40  <trevnorris>fun
22:08:03  <indutny>it is :)
22:08:05  <indutny>indeed
22:09:59  * st_lukejoined
22:13:31  * defunctzombie_zzchanged nick to defunctzombie
22:13:57  * rendarquit
22:16:31  <trevnorris>not sure how you find anything to do with crypto/tls fun, but hey. glad you're around. :)
22:17:15  * Kakeraquit (Read error: Connection reset by peer)
22:17:34  * Kakerajoined
22:18:03  * st_lukequit (Read error: Connection reset by peer)
22:18:04  * st_luke_joined
22:22:13  * AvianFlu_quit (Ping timeout: 245 seconds)
22:25:29  * defunctzombiechanged nick to defunctzombie_zz
22:25:46  * bnoordhuisquit (Ping timeout: 246 seconds)
22:32:03  * st_luke_quit (Remote host closed the connection)
22:34:13  * st_lukejoined
22:41:44  * st_lukequit (Remote host closed the connection)
22:43:16  * Kakeraquit (Ping timeout: 268 seconds)
22:46:32  * st_lukejoined
22:54:42  <othiym23>trevnorris: ping
22:54:48  <othiym23>trevnorris: https://gist.github.com/othiym23/6721743
22:54:50  <trevnorris>othiym23: poong
22:55:04  <othiym23>it's kinda long, but most of it is boilerplate
22:55:28  <othiym23>that works with my polyfill (and I'm pretty sure it *should* work in general), and bails hard under my build of flippin-tick-thing
22:55:55  * st_lukequit (Remote host closed the connection)
22:57:02  <othiym23>my suspicions are on either process.nextTick or function.bind()
22:57:59  * paddybyersquit (Quit: paddybyers)
22:58:05  <trevnorris>what's your expected output?
22:58:36  <trevnorris>othiym23: ^
22:58:59  <othiym23>no errors
22:59:10  <othiym23>i.e. silent output
22:59:51  * mikealquit (Quit: Leaving.)
22:59:59  <othiym23>I'm using a version of async-listener that I've modified locally to conform to the current API, so you'll have to trust me when I say it works ;)
23:00:14  <trevnorris>ok. give me a minute to absorb what's going on
23:00:26  <othiym23>removing the binding and just using straight closures makes no difference
23:01:18  * mikealjoined
23:04:37  <trevnorris>othiym23: ok. this is taking me a bit to understand. if you comment out the nextTick at the bottom then proxied passes
23:05:55  <othiym23>trevnorris: I broke up the gist with some comments delineating which bits came from where, in case that helps
23:06:17  <trevnorris>thanks
23:07:33  <othiym23>the thing is, if you add some logging statements, you'll see that it's the *first* invocation of handler that can't find its transaction
23:08:07  <othiym23>well, I wasn't using _rawDebug, so maybe that's getting tripped up by the event loop
23:10:56  <othiym23>trevnorris: you meant the whole second block encompassed by the process.nextTick at https://gist.github.com/othiym23/6721743#file-nexttick-and-bind-js-L146 , right?
23:11:05  <trevnorris>yeah
23:11:50  <trevnorris>othiym23: ok. so you're adding a listener to the active queue, but you're never getting out of it. that's what you want?
23:12:14  <trevnorris>othiym23: i'd think you only want to activate the listener while what you specify is running, right?
23:12:21  <othiym23>yes, I want the CLS listener to be active for the entire lifetime of the process
23:13:02  <trevnorris>ok
23:13:11  <othiym23>CLS needs to be available from inside 3rd party code
23:13:53  <othiym23>if you've got a suggestion for how I can know when I need to turn it on and off, I'll take it
23:15:35  <trevnorris>othiym23: ben told me it'd be fine to instantiate all the Wrap c++ classes when their js counterparts are instantiated. when that is done you should just be able to do addAsyncL(); runThirdPartyCode(); removeAsyncL(); and everything between those two will be tracked.
23:17:09  <othiym23>right, but turn your thinking inside out -- the agent is running inside other people's applications
23:17:20  <othiym23>it's all third-party code, New Relic is just tagging along for the ride
23:17:48  <trevnorris>othiym23: so they just require you're code at the top of their script?
23:18:10  <othiym23>yep
23:19:29  * indexzerojoined
23:19:54  <othiym23>users require the agent, the agent patches the module loader to check and see if any required modules have instrumentation, monkeypatch them if so
23:20:15  <trevnorris>othiym23: hm. one sec.
23:20:15  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:20:33  <othiym23>then the monkeypatching uses a version of that transactionProxy function to pass state between the various pieces of instrumentation and build up an execution trace as their code runs
23:21:21  * defunctzombie_zzchanged nick to defunctzombie
23:29:26  <trevnorris>othiym23: all you should need to do is process.nextTick(fn() { removeAsyncL(id); });
23:29:47  <trevnorris>once the synchronous part of the script has run, anything else that will be running async will have already been tagged
23:30:16  * TooTallNatejoined
23:30:35  <othiym23>I'll play around with that when I get a chance
23:30:59  <othiym23>I need to be sure I'm getting accurate transaction traces with absolute consistency before I do performance tuning
23:32:53  <trevnorris>othiym23: it's not even anything to do with performance. once it's been tagged, internally it'll automatically push your active listener up the stack and replace it with the currently running async callback.
23:33:35  <trevnorris>othiym23: so once all the sync code has been tagged, you're active listener will just be bouncing up and down the stack, but never get called again.
23:33:53  <othiym23>what's the reason to remove the async listener?
23:34:26  <trevnorris>you mean in general, or your case?
23:34:42  <othiym23>both, but start with in my case
23:35:32  <othiym23>is your intended use case that I should add the async listener each time I want to do a trace, and then remove it after everything's been set up?
23:35:44  <trevnorris>no. that's just an optional use case.
23:36:06  <trevnorris>I've been using it w/o the before/after just to track time lapses between async event instantiations.
23:36:59  <trevnorris>or I've used the before to check the about to run context, then I can keep counters on what's running and when
23:37:10  <trevnorris>there're a lot of use cases other than cls
23:38:08  <trevnorris>othiym23: in your case, it's just because you don't have to keep it around the asyncStack. because it's not doing anything.
23:38:20  <trevnorris>so, you'd just be cleaning up after yourself.
23:38:55  <othiym23>sure, but every web request is going to kick off a transaction trace, because I need the tracer to gather metric
23:39:22  <trevnorris>yeah. and removing the listener once the initial code has loaded won't prevent that.
23:39:23  <othiym23>so if we're handling 10,000 requests per second, I'd need to switch the listener in and out 10,000 times
23:39:30  <trevnorris>no
23:39:56  <othiym23>then how I do :|
23:40:02  <trevnorris>the internals will take care of all that. the listener is attached to the context. and when a listener is about to run it loads that context's asyncQueue into the active queue
23:40:39  <othiym23>I feel like I'm very close to understanding something important here, but I'm not quite there
23:40:51  <trevnorris>one sec. I just added more tests to show you
23:41:30  <trevnorris>othiym23: so check this: http://git.io/svt0rg
23:42:07  <trevnorris>othiym23: I add an active listener, and set it to be removed on the next tick. but all existing async events will still be captured even though it's been removed.
23:42:30  <trevnorris>because their initializers were loaded while the async listener was active.
23:43:03  <othiym23>that makes sense
23:43:30  <trevnorris>othiym23: oh, and don't try out the latest on my branch. the last commit is being a pain and I keep finding breakages.
23:43:59  <othiym23>in my case, I'm taking over http.on('request') and then wrapping the listener with a function that uses CLS to pass state across the continuation chain
23:44:11  <trevnorris>so I guess the point is, if the user requires your module first, and you add an active listener before loading any of your other modules, then nextTick remove it, everything will be tracked.
23:45:29  <othiym23>OK, so here's what I don't understand (sorry, this whole thing seems to breed confusion): what's the motivation for removing the async listener once everything's bootstrapped?
23:45:51  <othiym23>it's just going to keep adding new redundant listeners?
23:45:55  <trevnorris>no
23:46:20  <trevnorris>there's a var asyncStack = []; that's used. when a callback is called that has an _asyncQueue attached it'll load that queue into the active queue
23:46:25  <trevnorris>and push the other up the stack
23:47:08  <trevnorris>if all you want to do is take over the 'request' callback, then I'd suggest in your wrapper to addAsync(); thirdPartyCallback(); removeAsync();
23:47:32  <trevnorris>then everything in the thirdPartyCallback() will have a listener, but nothing else will.
23:47:36  <trevnorris>just helps reduce noise.
23:48:02  <othiym23>I'm going to need to think about that a while, because I'm not really sure how to replicate that behavior in the polyfill
23:49:22  * mikealquit (Quit: Leaving.)
23:49:36  <trevnorris>yeah. i'm not sure either. that's why I was so impressed that you said you'd created a polyfill
23:49:58  <othiym23>it works for CLS!
23:50:31  <othiym23>and I'm pretty sure it'd work for most other applications, but I think the mechanics are sufficiently distinct that it may need to be used slightly differently
23:50:44  <trevnorris>makes sense.
23:50:44  <othiym23>did you figure out what was up with my test case?
23:50:51  <trevnorris>not yet.