00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:01:04  <trevnorris>ok, how is this possible? "at Pipe._tickCallback (node.js:513:11)"
00:01:16  <trevnorris>Pipe doesn't freaking have _tickCallback
00:02:05  * amartensquit (Quit: Leaving.)
00:03:55  * dominictarrquit (Quit: dominictarr)
00:05:21  <TooTallNate>trevnorris: .call()?
00:05:43  <trevnorris>TooTallNate: it has something to do w/ my async listener patch. which doesn't use call anywhere.
00:09:48  * st_lukejoined
00:14:28  <tjfontaine>ircretary: ask bnoordhuis #6214 was causing the v8 instability, how long was it taking to run, and it wasn't just a pure OOM that you were hitting?
00:14:28  <ircretary>tjfontaine: I'll tell bnoordhuis you asked.
00:16:24  <tjfontaine>TooTallNate: thanks.
00:16:51  <TooTallNate>:)
00:19:55  * AvianFluquit (Read error: Connection reset by peer)
00:20:59  * julianduquequit (Ping timeout: 260 seconds)
00:21:29  * bradleymeckjoined
00:21:56  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
00:23:59  * julianduquejoined
00:24:28  * AvianFlujoined
00:30:32  * defunctzombiechanged nick to defunctzombie_zz
00:31:18  * bradleymeckquit (Ping timeout: 264 seconds)
00:34:10  * dshaw_quit (Quit: Leaving.)
00:34:30  * bradleymeckjoined
00:34:34  * bradleymeckquit (Remote host closed the connection)
00:35:14  <trevnorris>for anyone that has a spare hour: https://github.com/joyent/node/pull/6011
00:35:37  <trevnorris>it's mostly passing, but domains are still deeply integrated. I will remove them!!!!
00:35:44  <trevnorris>DAMN YOU DOMAINS TO HELL!!!
00:36:19  * AvianFluquit (Read error: Connection reset by peer)
00:37:01  * AvianFlujoined
00:37:40  * defunctzombie_zzchanged nick to defunctzombie
00:38:10  * wwicks_joined
00:39:45  * MI6joined
00:40:34  * wwicksquit (Ping timeout: 256 seconds)
00:40:34  * wwicks_changed nick to wwicks
00:43:06  <tjfontaine>indutny: you around?
00:44:31  * M28joined
00:45:21  <tjfontaine>indutny: nvm
00:46:55  * amartensjoined
00:48:14  * kellabytequit (Quit: Quit)
00:48:28  * st_lukequit (Remote host closed the connection)
00:55:58  <tjfontaine>ircretary: tell bnoordhuis reverting a9ff21830156b766c9ad2159e9eab4ae1e07b39c and 75124716c7e90733f0a2c6d08457f34155ddab87 while reapplying the vm fix, things are ok, not sure how we get a test case for them
00:55:58  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
00:56:02  <tjfontaine>indutny: ^
01:00:57  * c4milojoined
01:16:27  * jmar777joined
01:18:16  * groundwaterquit (Quit: groundwater)
01:20:12  * st_lukejoined
01:22:08  * kellabytejoined
01:34:11  * mikealquit (Quit: Leaving.)
01:37:16  * abraxasjoined
01:43:23  * jmar777quit (Remote host closed the connection)
01:43:34  <creationix>evening folks
01:43:39  <tjfontaine>gday
01:43:58  <creationix>how do I go about debugging segfaults in threaded libuv code
01:44:12  <creationix>my code is crashing somewhere in getaddrinfo
01:44:29  <creationix>but gdb complains with "couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error"
01:45:07  <tjfontaine>hnmn
01:45:09  * inolenquit (Quit: Leaving.)
01:45:49  <tjfontaine>crashing in getaddrinfo is kinda crazy in general
01:46:21  <tjfontaine>creationix: and the normal `thread apply all bt full` isn't producing usable results?
01:47:48  <creationix>tjfontaine, I have no idea what that means
01:47:54  <creationix>never used threads in gdb
01:48:30  <creationix>hmm, that command doesn't seem to make a difference when applied before run
01:48:38  <tjfontaine>no, this happens when you have a core
01:48:39  <tjfontaine>or
01:48:45  <tjfontaine>when you've breaked for some reason
01:48:49  <creationix>oh, I see
01:48:58  <tjfontaine>it will give you a stack trace for every thread
01:49:04  <tjfontaine>instead of just the active
01:49:16  <tjfontaine>when you're bouncing from thread to thread you: thread 0..n
01:49:34  <tjfontaine>or, you can say: thread apply <somethread | all> <some cmd>
01:49:52  <tjfontaine>or you can do: thread 8\nbt
01:49:54  <tjfontaine>or whatever
01:51:15  <creationix>wow, that's a lot of information
01:51:36  <tjfontaine>learn you some postmortem debugging real fast :)
01:52:05  <creationix>so the only reference to my code is where I call uv_run
01:52:19  <creationix>the last line I see in libuv is src/unix/getaddrinfo.c:33
01:52:52  <tjfontaine>and are there frames above getaddr?
01:53:03  <tjfontaine>is this linux/osx/smartos?
01:53:07  <creationix>linux
01:53:12  <tjfontaine>do you have libc6-dbg?
01:53:26  <creationix>it works fine if I only call two at a time, but if I call 3 in parallel it crashes
01:53:56  <creationix>I did not, installing...
01:53:58  <tjfontaine>you're dispatching all 3 from the same thread?
01:54:16  <creationix>well, three calls from the public libuv API
01:54:26  <creationix>I assume the thread pool allows arbitrary calls
01:54:28  <tjfontaine>yes, but are you calling into libuv from multiple threads?
01:54:34  <creationix>no
01:54:36  <tjfontaine>or do you only have the one thread of your own
01:54:38  <creationix>all from single threaded luajit
01:54:41  <tjfontaine>k
01:55:33  <tjfontaine>this is likely going to be some memory corruption then, because in general the __work_submit stuff is pretty heavily used
01:55:51  <tjfontaine>it's the basis of virtually all fs operations
01:55:59  <tjfontaine>I guess I should clarify, is this master or v0.10?
01:55:59  <creationix>right
01:56:07  <creationix>I'm pretty sure I'm using pointers wrong somewhere
01:56:14  <creationix>I'm just unsure where
01:57:07  * brsonquit (Ping timeout: 260 seconds)
01:57:22  <creationix>the code in question is https://github.com/creationix/luv/blob/master/src/luv_functions.c#L324-L352
01:57:59  * brsonjoined
01:58:27  <tjfontaine>lreq->data_ref = LUA_NOREF;
01:58:31  <tjfontaine>what does that tell the lua gc?
01:58:51  <creationix>that tells it I'm not attaching an extra data object to this request
01:58:57  <creationix>it's a convention in my bindings
01:59:00  <tjfontaine>ok
01:59:20  <creationix>the interesting thing about getaddrinfo is there is no uv_handle_t
01:59:31  <creationix>all my other uv_req_t subtypes have one
02:00:27  <tjfontaine>ok, so, I would set a break point in uv__getaddrinfo_work and see if it's the first/second/third request that's failing, and see what's different about uv__work in that case
02:00:48  <tjfontaine>there's nothing jumping out at me right now
02:01:52  <creationix>thanks for looking, sorry for the mess
02:01:58  <creationix>this is not my area of expertise
02:02:28  <tjfontaine>sure, if it's a pretty small test case I should be able to do some more on it when I get home
02:02:44  <creationix>also, do you know much about getaddrinfo in general
02:02:50  <creationix>I don't even understand what exactly it does
02:02:53  <creationix>the API is strange
02:03:01  <tjfontaine>it uses the libc to do name resolution
02:03:09  <tjfontaine>whcih means it goes through /etc/nsswitch.conf
02:03:19  <tjfontaine>and potentially a bunch of different other system based things
02:03:25  <creationix>so in the initial request I can specify the host and/or the port
02:03:40  <tjfontaine>port doesn't have anything to do with it
02:04:06  <tjfontaine>well
02:04:08  <tjfontaine>ok so it does
02:04:16  <creationix>the thing it calls "service"
02:04:25  <tjfontaine>yes, it's looking in /etc/services
02:04:55  <tjfontaine>I would probably just pass null there
02:05:28  <tjfontaine>ya
02:06:38  <tjfontaine>and then use the hints to delegate on the A/AAAA style operation
02:06:46  <creationix>so, if I pass in "http" or "80" the resulting addresses have 20480 as port
02:06:59  <creationix>and if I pass in "ssh" they come out "5632"
02:07:06  <creationix>so I think I'm doing an invalid cast somewhere
02:07:38  <tjfontaine>well depends on what your /etc/services looks like I guess, but yes that doesn't necessarily seem sane
02:07:59  <tjfontaine>anyway I'm heading out, bbl
02:08:03  <creationix>ok, take care
02:11:16  * kazuponjoined
02:20:26  * toothrchanged nick to toothrot
02:22:51  * kellabytequit (Changing host)
02:22:51  * kellabytejoined
02:22:51  * kellabytequit (Changing host)
02:22:51  * kellabytejoined
02:32:10  * st_lukequit (Remote host closed the connection)
02:36:11  * inolenjoined
03:09:05  * defunctzombiechanged nick to defunctzombie_zz
04:06:03  * julianduquequit (Quit: leaving)
04:09:46  * mikealjoined
04:11:23  * brsonquit (Ping timeout: 245 seconds)
04:24:53  * kazuponquit (Remote host closed the connection)
04:25:54  * mikealquit (Quit: Leaving.)
04:42:20  * defunctzombie_zzchanged nick to defunctzombie
04:42:21  * inolenquit (Quit: Leaving.)
04:42:55  * inolenjoined
05:03:47  * mikealjoined
05:06:52  * kazuponjoined
05:29:46  * Damn3dquit (Ping timeout: 245 seconds)
05:31:41  * ecrjoined
05:34:11  * Damn3djoined
05:39:57  * amartensquit (Quit: Leaving.)
05:49:41  * c4miloquit (Remote host closed the connection)
05:52:10  * AvianFluquit (Remote host closed the connection)
06:25:17  * felixgejoined
06:25:30  * felixgequit (Client Quit)
06:29:03  * kazuponquit (Remote host closed the connection)
06:32:38  * felixgejoined
06:32:38  * felixgequit (Changing host)
06:32:38  * felixgejoined
06:40:12  * amartensjoined
06:41:26  * TooTallNatejoined
06:42:05  * TooTallNatequit (Client Quit)
06:44:18  <MI6>nodejs-v0.10-windows: #228 UNSTABLE windows-ia32 (9/600) windows-x64 (8/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/228/
06:44:48  * amartensquit (Ping timeout: 252 seconds)
06:53:09  * rendarjoined
07:40:35  * amartensjoined
07:44:38  * amartensquit (Ping timeout: 240 seconds)
07:50:22  * dominictarrjoined
08:02:40  * ecrquit (Quit: ecr)
08:06:02  * piscisaureus_joined
08:14:49  * bnoordhuisjoined
08:37:39  * defunctzombiechanged nick to defunctzombie_zz
08:38:02  * zotjoined
08:40:08  * zotpart
08:40:23  <piscisaureus_>hello
08:40:53  * amartensjoined
08:45:38  * amartensquit (Ping timeout: 256 seconds)
08:57:01  <bnoordhuis>sup bertje?
09:13:29  * EhevuTovjoined
09:13:53  * EhevuTovquit (Remote host closed the connection)
09:37:38  <piscisaureus_>hello bnoordhuis
09:41:13  * amartensjoined
09:45:40  * amartensquit (Ping timeout: 246 seconds)
09:57:10  * Kakerajoined
10:11:16  * EhevuTovjoined
10:15:25  * piscisaureus_quit (Ping timeout: 246 seconds)
10:33:02  * EhevuTovquit (Quit: This computer has gone to sleep)
10:35:25  <indutny>hello guys
10:41:33  * amartensjoined
10:45:58  * amartensquit (Ping timeout: 245 seconds)
10:46:00  <MI6>nodejs-v0.10: #1502 UNSTABLE linux-x64 (1/600) smartos-x64 (2/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1502/
10:52:44  * abraxasquit (Remote host closed the connection)
10:56:01  <bnoordhuis>sup fedor?
11:04:07  * indexzeroquit (Quit: indexzero)
11:24:53  <indutny>all good
11:24:58  <indutny>just finished writing spdy client for node-spdy
11:25:03  <indutny>hopefully people will be finally happy
11:25:11  <indutny>and contribute some tests :)
11:30:19  * EhevuTovjoined
11:41:54  * amartensjoined
11:46:42  * amartensquit (Ping timeout: 256 seconds)
11:50:06  * bnoordhuisquit (Ping timeout: 256 seconds)
11:55:47  * bnoordhuisjoined
12:38:34  <dazld>hey all, just wondering, ES6 classes are not currently supported by node --harmony, without doing source transforms..?
12:42:13  * amartensjoined
12:46:32  * amartensquit (Ping timeout: 240 seconds)
12:49:48  * AvianFlujoined
12:52:25  * EhevuTovquit (Quit: Leaving)
13:03:20  * Kakeraquit (Ping timeout: 245 seconds)
13:07:57  * piscisaureus_joined
13:18:35  * Kakerajoined
13:23:39  * AvianFluquit (Remote host closed the connection)
13:33:41  * hzjoined
13:34:05  * hzquit (Client Quit)
13:38:25  * jmar777joined
13:42:33  * amartensjoined
13:46:48  * amartensquit (Ping timeout: 240 seconds)
13:48:40  * paddybyersjoined
14:16:20  * AvianFlujoined
14:17:09  * AvianFlu_joined
14:18:37  * wolfeida_joined
14:18:44  * AvianFluquit (Disconnected by services)
14:18:47  * AvianFlu_changed nick to AvianFlu
14:20:53  * wolfeidauquit (Ping timeout: 248 seconds)
14:23:30  * jmar777quit (Remote host closed the connection)
14:27:29  * mikealquit (Quit: Leaving.)
14:29:20  * wolfeidaujoined
14:29:48  * wolfeida_quit (Ping timeout: 240 seconds)
14:29:54  * bnoordhuisquit (Ping timeout: 256 seconds)
14:42:51  * amartensjoined
14:46:56  * amartensquit (Ping timeout: 240 seconds)
15:09:02  * bradleymeckjoined
15:10:37  * `3rdEdenchanged nick to `3E|BRB
15:13:42  * wolfeida_joined
15:16:38  * wolfeidauquit (Ping timeout: 240 seconds)
15:17:59  <MI6>nodejs-master: #578 UNSTABLE osx-x64 (1/642) smartos-x64 (6/642) http://jenkins.nodejs.org/job/nodejs-master/578/
15:25:21  <trevnorris>morning
15:28:02  * jmar777joined
15:28:27  * hzjoined
15:28:31  * mcavagejoined
15:28:59  * c4milojoined
15:31:48  * mikealjoined
15:36:02  * bnoordhuisjoined
15:40:14  * bnoordhuisquit (Ping timeout: 240 seconds)
15:43:13  * amartensjoined
15:47:38  * amartensquit (Ping timeout: 245 seconds)
15:50:53  * mikealquit (Quit: Leaving.)
16:08:53  * indexzerojoined
16:13:05  <trevnorris>anyone mind taking a look at this strange problem I'm having? http://git.io/v_koaw
16:15:04  * TooTallNatejoined
16:15:18  * dap1joined
16:21:38  * mikealjoined
16:23:03  <tjfontaine>trevnorris: please try before the v8 revert
16:23:20  <tjfontaine>trevnorris: or do you care more about the pipe issue?
16:23:21  <tjfontaine>:)
16:23:51  <trevnorris>tjfontaine: heh, yeah. the fact that process._tickCallback is being reported as Pipe._tickCallback.
16:25:06  <tjfontaine>trevnorris: I will try and get to it
16:25:43  <tjfontaine>It's probably something unfortunate
16:26:31  * amartensjoined
16:26:47  <trevnorris>tjfontaine: thanks. just in case the context is missing, that problem is from my patch. but I don't see what in my patch could be remotely causing that.
16:29:33  <rendar>does libuv has something for interfacing with the filesystem tree? e.g. listing files, copy/remove them etc
16:29:38  * defunctzombie_zzchanged nick to defunctzombie
16:29:42  <tjfontaine>trevnorris: nod
16:30:14  <tjfontaine>rendar: uv_fs_readdir, uv_fs_rename, uv_fs_unlink?
16:30:26  <tjfontaine>rendar: have you met uv.h?
16:30:34  <rendar>tjfontaine: oh thanks, i'll check there :)
16:30:39  * mikealquit (Ping timeout: 240 seconds)
16:33:08  <trevnorris>tjfontaine: ah hell, I know what it's from.
16:33:32  <tjfontaine>trevnorris: yay, less work for me!
16:33:37  <trevnorris>tjfontaine: it was even intentionally a feature. just didn't realize it would manifest itself that way.
16:34:09  <trevnorris>tjfontaine: so I call _tickCallback with the context (i.e. "this") of the calling instance, instead of passing the process object.
16:34:25  <tjfontaine>oh right
16:35:09  <trevnorris>tjfontaine: I did that for the possibility to pass the "this" as the first arg to the nextTick callback, so we wouldn't need to use closures.
16:35:27  <trevnorris>tjfontaine: well, thanks for the help. always nice to have someone else listen :)
16:35:37  <tjfontaine>trevnorris: happy to be your sounding board!
16:36:07  * defunctzombiechanged nick to defunctzombie_zz
16:36:22  <tjfontaine>indutny: have you been able to look into why that particular commit was causing heap corruption in v8?
16:36:46  <indutny>tjfontaine: erm… I didn't
16:36:56  <trevnorris>tjfontaine: what do you think about passing the calling object's context to the nextTick callback?
16:36:59  <tjfontaine>indutny: did you see that I found the commit(s)?
16:37:10  <indutny>nope :)
16:37:15  <indutny>ttyl
16:37:26  <tjfontaine>trevnorris: hm
16:41:40  <trevnorris>tjfontaine: it's so we can get around doing things like: http://git.io/lXOdxw
16:43:40  <trevnorris>tjfontaine: passing a function to nextTick like that is on my list of the most egregious sins
16:43:42  * mikealjoined
16:44:49  <tjfontaine>heh, but *why* trevnorris? :P
16:45:03  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:45:06  * trevnorrisfeels a troll lurking about
16:46:48  * bnoordhuisjoined
16:49:28  <trevnorris>bnoordhuis: have to say, i'm impressed how quickly you got 6262 done.
16:55:49  <trevnorris>bnoordhuis: when you have a spare moment, I would like to discuss your WeakObject patch.
16:55:54  <bnoordhuis>trevnorris: shoot
16:57:09  <trevnorris>bnoordhuis: so my need to remove ObjectWrap is so I could get many of those classes to inherit from AsyncWrap. Then call out using AsyncWrap::MakeCallback. with your patch I'd need to make WeakObject inherit from AsyncWrap. though I'm not sure that'd be the decision you'd like. thoughts?
16:58:13  <bnoordhuis>trevnorris: why should WeakObject is-a AsyncWrap?
16:59:03  * kellabytequit (Quit: Quit)
16:59:04  <trevnorris>bnoordhuis: is-a? you mean inherit from?
16:59:16  * dap1quit (Quit: Leaving.)
16:59:17  <bnoordhuis>trevnorris: yes
17:01:07  <trevnorris>bnoordhuis: some classes that are inheriting from WeakObject are calling MakeCallback, which I am routing though AsyncWrap::MakeCallback
17:01:40  * TooTallNatejoined
17:02:00  <bnoordhuis>trevnorris: okay. and?
17:02:20  * mikealquit (Quit: Leaving.)
17:02:27  * jmar777quit (Read error: Connection reset by peer)
17:02:35  <bnoordhuis>trevnorris: i mean, why won't `class Foo : public AsyncWrap, public WeakObject {` work?
17:03:00  * jmar777joined
17:03:07  <trevnorris>bnoordhuis: both AsyncWrap and WeakObject store the context as a Persistent. I think they'd conflict, but maybe there's a way to get around that?
17:03:24  * octetcloudjoined
17:03:49  <bnoordhuis>trevnorris: composition? leave it up to the inheriting classes to provide the persistent handle on request
17:03:53  <trevnorris>bnoordhuis: though, I did make it so the destructor of the inheriting class is responsible for disposing the Persistent. so if they could each point to the same Persistent, that might work.
17:04:05  <bnoordhuis>trevnorris: e.g. virtual Local<Object> async_object() = 0;
17:05:31  * mikealjoined
17:06:50  <trevnorris>bnoordhuis: ok, also I moved ::object() and ::persistent() to AsyncWrap to remove duplicated code, and WeakObject has ::weak_object(). conflict of API there?
17:07:38  <trevnorris>bnoordhuis: here's the header. maybe my implementation can be improved: http://git.io/u_enBg
17:07:47  <trevnorris>s/maybe/probably
17:09:57  <bnoordhuis>trevnorris: i'd make AsyncWrap more of a mix-in rather than some 'do everything' concrete base class
17:12:53  * defunctzombie_zzchanged nick to defunctzombie
17:16:16  <trevnorris>bnoordhuis: ok. not really familiar w/ how to implement mix-ins in c++.
17:16:19  * trevnorrisoff to google
17:17:04  <tjfontaine>bnoordhuis: did you get a chance to look at the v8 commit(s) I identified as being the problematic ones?
17:17:48  * groundwaterjoined
17:18:34  * AvianFluquit (Remote host closed the connection)
17:19:13  <bnoordhuis>tjfontaine: looked at them, haven't tried them yet though
17:19:30  <bnoordhuis>trevnorris: multiple inheritance really
17:20:01  <bnoordhuis>trevnorris: just that you could model AsycnWrap as a helper class that gets mixed in rather than a fundamental base class
17:22:34  <trevnorris>bnoordhuis: makes sense.for some reason I have in my head that virtual class members should be avoided when possible. is that an incorrect assumption?
17:23:18  <bnoordhuis>trevnorris: well, yes and no
17:23:32  <trevnorris>guess it's just years of working w/ JS that not using single inheritance hierarchies feels weird.
17:23:38  <bnoordhuis>trevnorris: you shouldn't make methods virtual when they don't have to be
17:23:50  <bnoordhuis>recovering java programmers are prone to doing that
17:23:57  <trevnorris>heh
17:24:16  <bnoordhuis>the reason why people try to avoid virtual methods is that they may have to go through the vtable
17:24:28  <bnoordhuis>iow, you incur the hit of a function pointer indirection
17:25:03  <bnoordhuis>but that's usually okay because it's often noise in the benchmarks
17:25:36  <trevnorris>makes sense.
17:27:44  * kellabytejoined
17:31:40  * piscisaureus_quit (Ping timeout: 245 seconds)
17:32:14  * mikealquit (Quit: Leaving.)
17:34:43  <trevnorris>bnoordhuis: ok, have my head wrapped around it. it's just, after years of fighting developers to _not_ use that OOP style in JS it hurts a little inside to be doing it. :)
17:36:48  * groundwaterquit (Ping timeout: 245 seconds)
17:38:50  * groundwaterjoined
17:46:05  <MI6>joyent/node: Ben Noordhuis master * c79d516 : src: remove ObjectWrap dependency from core - http://git.io/0B3MTg
17:47:20  <trevnorris>bnoordhuis: just want to confirm, any virtual members means should have a virtual destructor. will that destructor always get called?
17:48:55  * AvianFlujoined
17:50:26  <bnoordhuis>trevnorris: yes and yes
17:51:19  <bnoordhuis>the virtual destructor is so that deleting from a base pointer/reference will also invoke the child's destructor
17:52:08  <trevnorris>bnoordhuis: coolio. so then, for example, i'd make env(), object() and persistent() all virtual, then remove object_ and env_, allowing those to be defined by the inheriting class?
17:55:15  <bnoordhuis>trevnorris: yes. but let's take a step back: what's the minimum amount of work that AsyncWrap should do?
17:55:40  <bnoordhuis>i mean, does it need access to the env, the wrap object, etc.?
17:55:48  <MI6>nodejs-master: #579 UNSTABLE smartos-x64 (6/642) http://jenkins.nodejs.org/job/nodejs-master/579/
17:55:51  <MI6>libuv-master: #257 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/257/
17:56:35  <trevnorris>bnoordhuis: yes. it's replacing the domain stuff, so it has to access env to get at the shared state object that let's it know if there are async listeners active.
17:57:20  <trevnorris>bnoordhuis: also, it has specific MakeCallback implementation to check the status flags on the class.
17:57:31  * AvianFluquit (Ping timeout: 260 seconds)
17:57:44  <trevnorris>so it needs access to the object
17:57:58  <bnoordhuis>okay. when exactly does it need access to them?
17:58:14  <bnoordhuis>e.g. can you get by with having callers pass them to MakeCallback?
17:58:42  <trevnorris>it checks if the async listeners are active when the constructor runs.
17:58:54  <trevnorris>this let's it know there are callbacks that need to be called immediately.
17:58:55  * brsonjoined
17:59:46  * `3E|BRBchanged nick to `3rdEden
17:59:55  <bnoordhuis>trevnorris: what kind of callbacks? js ones?
17:59:58  <trevnorris>yeah
18:00:10  <bnoordhuis>and you run those from the constructor?
18:00:21  <trevnorris>yeah
18:00:46  <bnoordhuis>your AsyncWrap constructor runs at a time when the object isn't fully constructed yet
18:01:12  <bnoordhuis>that is, with `Foo : public AsyncWrap`, AsyncWrap() runs before Foo()
18:01:17  <trevnorris>yeah, I realize that.
18:01:30  <trevnorris>but the js object exists, and I need to set an object property on it
18:01:45  <bnoordhuis>okay.. what do those callbacks do?
18:02:05  <bnoordhuis>if they call functions that require a fully constructed Foo object, BAM, you're dead
18:02:16  <trevnorris>they don't.
18:02:41  <trevnorris>they can return an object that's then attached to the Persistent object instance so we have access to it when MakeCallback is run.
18:03:13  <trevnorris>but the callbacks don't get access to the constructing object
18:03:48  <trevnorris>I simply set a _asyncQueue object that houses all the information.
18:04:14  <bnoordhuis>okay
18:06:55  <trevnorris>bnoordhuis: it's basically a generic-ified way of doing othiym23's cls stuff. and using the class w/ state sharing allows it to run at almost zero cost when it's not being used.
18:07:12  <trevnorris>where as other implementations I saw would have cost less than trivial performance
18:09:14  <MI6>libuv-node-integration: #240 UNSTABLE smartos-ia32 (1/642) smartos-x64 (6/642) http://jenkins.nodejs.org/job/libuv-node-integration/240/
18:09:42  <othiym23>trevnorris: pretty sure you meant "more than trivial" ther, boss
18:09:58  <trevnorris>othiym23: heh :P
18:10:58  <trevnorris>othiym23: the current patch passes all tests, but that's because I reverted the domain changes. needed to cleanup my commits, and my head, and take that on again.
18:11:11  <trevnorris>othiym23: but at least you can play with the new api :)
18:12:08  <trevnorris>bnoordhuis: guess with that in mind, how would you approach it? or is there a completely different architecture you'd use?
18:12:26  * AvianFlujoined
18:19:14  <bnoordhuis>trevnorris: hrm, let me think about that for a bit
18:19:39  <trevnorris>bnoordhuis: cool. thanks.
18:20:01  * indexzeroquit (Quit: indexzero)
18:25:20  <MI6>nodejs-master-windows: #371 UNSTABLE windows-x64 (22/642) windows-ia32 (23/642) http://jenkins.nodejs.org/job/nodejs-master-windows/371/
18:27:38  * mikealjoined
18:33:28  * AvianFlu_joined
18:34:08  * AvianFluquit (Disconnected by services)
18:34:10  * AvianFlu_changed nick to AvianFlu
18:35:27  <bnoordhuis>i'm receiving github emails wildly out of order...
18:35:42  <tjfontaine>yes.
18:35:44  <tjfontaine>it's absurd
18:40:32  * dshaw_joined
18:41:19  * kellabytequit (Changing host)
18:41:19  * kellabytejoined
18:41:19  * kellabytequit (Changing host)
18:41:19  * kellabytejoined
18:41:51  * hzquit
18:45:52  <mikeal>bnoordhuis: that's just GitHub prioritizing your attention, leave to embrace it :P
18:47:01  <tjfontaine>I need some therapy, so I'm not easily trolled :)
19:02:28  <MI6>nodejs-master-windows: #372 UNSTABLE windows-x64 (24/642) windows-ia32 (21/642) http://jenkins.nodejs.org/job/nodejs-master-windows/372/
19:50:08  * julianduquejoined
19:55:07  <trevnorris>heh, always forget to process.exit() when I listen for SIGINT
20:06:48  * st_lukejoined
20:27:09  * felixgequit (Quit: felixge)
20:27:32  * felixgejoined
20:27:32  * felixgequit (Changing host)
20:27:32  * felixgejoined
20:31:00  * EhevuTovjoined
20:31:55  * dshaw_quit (Quit: Leaving.)
20:35:56  * jmar777quit (Remote host closed the connection)
20:41:33  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:43:08  <trevnorris>othiym23: ping
20:44:07  <othiym23>trevnorris: pon
20:44:11  <othiym23>gggggggggggg
20:44:45  <trevnorris>othiym23: you said you had a large suit of domain based tests?
20:45:00  <trevnorris>othiym23: there's some code that when I remove doesn't cause any tests to fail, and the code itself doesn't make sense
20:45:11  <trevnorris>othiym23: but i'm trying to find if there's a legitimate use for it.
20:45:56  <othiym23>I have a big chunk of tests for addAsyncListener, which are on the async-listener module / repo
20:46:32  <othiym23>trevnorris: can you point me to the code in question and maybe I can write some tests for you / try to reverse engineer why isaacs might have put it there?
20:46:59  <trevnorris>othiym23: the code that doesn't seem to ever fire is in Domain#bind(), that's: if (this instanceof Domain) cb.apply(this, arguments);
20:47:40  <othiym23>time to fire up fugitive in vim and see what that thing's deal is
20:48:10  <othiym23>gimme 10, I need to publish a new build of my thing to npm
20:48:11  <trevnorris>I think you'd have to like, domain.bind(cb).bind(domain); for that code to fire.
20:48:14  <trevnorris>np
20:48:17  <trevnorris>and thanks :)
20:49:18  <othiym23>surprisingly enough, my eval hack had consequences: https://github.com/newrelic/node-newrelic/issues/46
20:49:28  <tjfontaine>SAY IT AINT SO
20:49:29  <othiym23> /sarcasm
20:49:38  <trevnorris>heh
20:49:53  <tjfontaine>loudbot is on point as usual
20:49:53  <othiym23>now I have to blacklist future reserved words because of certain Canadians
20:50:03  <othiym23>yeah, loudbout, good job
20:50:15  <othiym23>are we certain LOUDBOT isn't actually a Buzzfeed employee?
20:50:24  <tjfontaine>heh
20:50:37  <groundwater>not all Canadians are bad
20:50:47  <tjfontaine>proove it
20:50:49  <tjfontaine>-o
20:50:57  <tjfontaine>one exception is alanis
20:50:58  <trevnorris>othiym23: oh, one more API change. it was dumb of me to allow createAsyncListener to accept a third "domain" argument, but not addAsyncListener.
20:51:27  <trevnorris>othiym23: so now both can be passed a domain that'll persist with the life of the event, unless it's overridden by an object returned from the listener.
20:51:52  <othiym23>hmm... I'm going to need to do some catching up for the polyfill and CLS, I think
20:52:06  <othiym23>where is createAsyncListener exposed? via process?
20:52:16  <trevnorris>yeah
20:52:38  <othiym23>refresh my memory, what's the difference between createAsyncListener and addAsyncListener?
20:52:58  <trevnorris>othiym23: with bnoordhuis's removed ObjectWrap today, so now it'll be almost trivial for me to get access to all the tls,crypto,zlib callbacks as well.
20:53:35  <trevnorris>createAsyncListener creates an asyncListener instance and just returns it. addAsyncListener does that and immediately places it on the listening stack.
20:54:03  <trevnorris>but you can pass pre-initialized listeners to addAsyncListener that'll resume listening
20:54:14  <trevnorris>that's if they've been removed via removeAsyncListener
20:54:44  <trevnorris>this is so on Domain instantiation I can: this._listener = process.createAsyncListener(noop, callbacks, this);
20:55:15  <othiym23>sounds reasonable, and like a fairly straightforward refactor for the polyfill
20:55:25  <trevnorris>yeah. nothing major at all.
20:55:31  <othiym23>I'll set aside some time to square the two up
20:56:31  <trevnorris>know how you're going to polyfill the other stuff like tls and crypto internals that never make it to userland?
20:59:16  * felixgequit (Ping timeout: 264 seconds)
20:59:46  <othiym23>everything that can be wrapped with a super gross closure hack will be so wrapped, for the rest people are on their own
21:00:09  <othiym23>for the purposes of CLS, it probably doesn't matter most of the time
21:01:20  <wolfeida_>Anyone got any tips on using mdb to trace leaks?
21:01:26  * wolfeida_changed nick to wolfeidau
21:02:07  <wolfeidau>I managed to get it all up and running against a core file but I am trying to locate what i think is a event emmitter + buffer leak
21:02:42  <tjfontaine>wolfeidau: I guess I shoudl finish the blog post
21:02:42  <wolfeidau>I cannot for the life of me find anything meaty about the tool aside from a log by trevnorris
21:02:53  * dshaw_joined
21:03:06  <wolfeidau>tjfontaine: Yeah!
21:03:10  <tjfontaine>wolfeidau: the canonical "blog" about it at the moment is http://dtrace.org/blogs/bmc/2012/05/05/debugging-node-js-memory-leaks/
21:03:16  <trevnorris>wolfeidau: log?
21:03:18  <tjfontaine>wolfeidau: but so what are you trying to figure out?
21:03:58  <tjfontaine>wolfeidau: do something like this: ::findjsobjects ! sort -k2 [which will give you some interesting results at the end, but should sort your objects by their count]
21:04:03  <wolfeidau>trevnorris: your up in google https://gist.github.com/trevnorris/6016301
21:04:40  <wolfeidau>tjfontaine: I have a production issue where over time v8 heap stays about steady but over all RSS of the process just grows and grows
21:05:04  <tjfontaine>wolfeidau: do you have binary modules involved?
21:05:18  <tjfontaine>wolfeidau: if v8 heap is staying the same, it's not likely to be buffer related
21:05:25  <wolfeidau>tjfontaine: aha
21:05:37  <wolfeidau>The only binary module i can think of is weak
21:05:46  <wolfeidau>Which is used by dnode
21:05:47  <tjfontaine>oh weak, hmm well maybe
21:06:04  <bnoordhuis>wolfeidau: find node_modules/ -name \*.node
21:06:22  <trevnorris>tjfontaine: dude, where are max's slides on finding mem leaks by tracing back through system calls?
21:06:22  <wolfeidau>It is essentially a big RPC server
21:06:29  <trevnorris>from nodeconf.eu
21:06:47  <tjfontaine>trevnorris: somewhere
21:06:51  <trevnorris>:P
21:07:07  * dshaw_quit (Ping timeout: 240 seconds)
21:07:10  <tjfontaine>https://github.com/max123/nodeconfeu/blob/master/nodeconfeu.pdf
21:07:25  <tjfontaine>without the video for context it may not be quite as helpful
21:07:44  <MI6>joyent/libuv: Ben Noordhuis master * 7c7717c : windows: remove duplicate check in stream.c - http://git.io/L7mZ3Q
21:07:51  <wolfeidau>bnoordhuis: Yeah cheers that found two native modules weak and nodetime
21:08:08  <wolfeidau>I mite try turning off nodetime first
21:08:16  <wolfeidau>It isn't essential
21:08:58  <wolfeidau>I will checkout those slides cheers
21:09:13  <wolfeidau>That sort -k2 looks awesome tjfontaine
21:09:17  <tjfontaine>wolfeidau: if you can restart the process, run with UMEM_DEBUG=default in the environment
21:09:19  <trevnorris>tjfontaine: his slides are enough. thanks.
21:09:43  <tjfontaine>wolfeidau: that way if there is a c/c++ leak happening we'll be able to track down the allocation, but in general you will get helpful auditing information
21:09:43  <wolfeidau>tjfontaine: on smartos?
21:09:53  <tjfontaine>wolfeidau: yes
21:10:22  <wolfeidau>tjfontaine: yeah sweet I have a bunch of stuff to check out thanks
21:10:41  * indexzerojoined
21:11:56  <MI6>libuv-master: #258 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/258/
21:12:43  <wolfeidau>o wow that presentation is gold
21:14:13  <MI6>libuv-master-gyp: #197 UNSTABLE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (3/195) smartos-x64 (3/194) osx-ia32 (1/195) http://jenkins.nodejs.org/job/libuv-master-gyp/197/
21:16:13  <othiym23>yeah it is
21:16:25  <othiym23>still bummed I couldn't make it to Max's session at NodeConf
21:16:52  <tjfontaine>it was pretty well received
21:16:57  <othiym23>if anyone reuses the workshop format from this year's NodeConf, they should definitely plan on having a real runthrough day beforehand so everyone can see everyone else's session
21:16:58  <tjfontaine>he got to do a lot of "dump" jokes
21:17:25  <tjfontaine>othiym23: agreed, I really wanted to see yours :/
21:18:43  <tjfontaine>oh hey, found a bug
21:18:46  <wolfeidau>Really need to wrestle everyones mdb command history from them and put it in a gist :P
21:18:58  <othiym23>here's how I solved that dumb eval error: https://github.com/newrelic/node-newrelic/commit/8a317f51e78e593e18d232d4c302d1c3d2b13109
21:19:04  <othiym23>put some duct tape on my duct tape
21:22:01  <tjfontaine>https://gist.github.com/tjfontaine/6706208 so now the question, is this mdb bug, or node bug, or expected node behavior o0
21:23:35  <othiym23>tjfontaine: is that a stream switching in and out of object mode?
21:24:09  <othiym23>or b/w buffers and strings?
21:24:43  <tjfontaine>othiym23: that's a dump from #6214
21:24:53  <wolfeidau>aha ::findjsobjects !sort -k2 works
21:25:05  <tjfontaine>of course it does :)
21:25:06  <wolfeidau>man that is very handy
21:25:08  <MI6>libuv-node-integration: #241 UNSTABLE smartos-x64 (5/642) http://jenkins.nodejs.org/job/libuv-node-integration/241/
21:25:10  <tjfontaine>did you think I was lying? :P
21:25:21  <wolfeidau>haha misread the | vs !
21:25:22  <tjfontaine>::findjsobjects can take a while the first time through
21:25:34  <tjfontaine>ah, | in mdb goes to another mdb command, ! goes out to shell
21:26:06  <wolfeidau>yeah that is win now i can use shell fu on the lists :)
21:26:25  <tjfontaine>that's the idea
21:26:52  <wolfeidau>How did trevnorris get this summary at the top https://gist.github.com/trevnorris/6016301 ?
21:27:01  <tjfontaine><MaxBrunning>I also teach a course on mdb and DTrace</MaxBrunning>
21:27:10  <tjfontaine>wolfeidau: run `::findjsobjects -va`
21:27:17  <tjfontaine>wolfeidau: see also `::help findjsobjects`
21:27:23  <wolfeidau>O man
21:27:28  <wolfeidau>awesome
21:40:28  * dshaw_joined
21:41:26  * bradleymeckquit (Quit: bradleymeck)
21:42:24  * TooTallNatejoined
21:44:20  <tjfontaine>TooTallNate: congrats?
21:44:31  <TooTallNate>tjfontaine: thanks :)
21:44:35  <tjfontaine>:)
21:44:36  * dshaw_quit (Ping timeout: 245 seconds)
21:44:51  <TooTallNate>nice to finally be able to talk about it :D
21:45:02  <tjfontaine>indeed, are you excited?
21:45:10  <tjfontaine>do you welcome your new corporate overlords?
21:45:26  <tjfontaine>or are you bailing? :D
21:45:40  <TooTallNate>tjfontaine: no it's gonna be awesome, i'm very excited
21:45:42  <mikeal>TooTallNate is going to write PHP now
21:45:45  <mikeal>:P
21:45:47  <othiym23>oh sweet, didn't see the news
21:45:48  <tjfontaine>hehe
21:45:50  <TooTallNate>mikeal: hahah
21:46:01  <othiym23>Automattic should be a good home for CloudUp
21:46:03  <mikeal>it's a pretty great company
21:46:25  <othiym23>TooTallNate: congrats to you and everybody!
21:46:32  <TooTallNate>othiym23: thanks!
21:46:33  <mikeal>a lot of the stuff GitHub has been touring around touting as their company culture i remember Matt talking about doing for Automattic years before
21:47:03  <TooTallNate>mikeal: ya, they're like mostly distributed, so it's a cool culture
21:47:12  <TooTallNate>http://automattic.com/map
21:47:58  <bnoordhuis>congrats, nathan. that was quick
21:48:56  <mikeal>not *that* quick
21:49:02  <mikeal>LearnBoost has been around a while
21:49:06  <mikeal>Cloudup is just really new
21:49:20  <mikeal>and is too awesome of a product not to get gobbled up :)
21:49:42  <TooTallNate>bnoordhuis: thanks!
21:59:34  * mikeal1joined
22:00:05  * mikealquit (Ping timeout: 248 seconds)
22:02:13  * jmar777joined
22:06:08  * bnoordhuisquit (Ping timeout: 240 seconds)
22:06:28  * dominictarrquit (Ping timeout: 240 seconds)
22:12:15  * rendarquit
22:12:52  * Kakeraquit (Ping timeout: 256 seconds)
22:18:04  * jmar777quit (Remote host closed the connection)
22:20:40  * julianduquequit (Ping timeout: 260 seconds)
22:23:30  <trevnorris>tjfontaine: you know if there's a way to generate a callstack on a system call in linux?
22:26:13  * jmar777joined
22:27:07  * AvianFluquit (Remote host closed the connection)
22:29:53  * dshaw_1joined
22:46:48  * piscisaureus_joined
22:48:12  * jmar777quit (Remote host closed the connection)
23:17:15  * c4miloquit (Remote host closed the connection)
23:18:45  * julianduquejoined
23:27:50  * piscisaureus_quit (Ping timeout: 240 seconds)
23:29:04  * AvianFlujoined
23:47:09  * jmar777joined
23:51:34  <trevnorris>ok, warning to everyone. dtrace4linux is a little unstable :P
23:56:41  * indexzeroquit (Quit: indexzero)
23:59:55  <MI6>libuv-master-gyp: #198 UNSTABLE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (4/195) linux-ia32 (1/194) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/198/