00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:01:45  * loladiroquit (Quit: loladiro)
00:11:01  * c4miloquit (Remote host closed the connection)
00:14:11  * hzquit
00:20:27  * kazuponjoined
00:24:38  * kazuponquit (Ping timeout: 240 seconds)
00:39:00  * c4milojoined
00:40:47  * amartensjoined
00:45:15  * amartensquit (Ping timeout: 252 seconds)
00:58:44  <othiym23>trevnorris: https://gist.github.com/othiym23/6748219 is also broken under your current build
00:59:01  <othiym23>looks lot simpler than the last one, but that's because I didn't bundle in all the dependencies
00:59:17  <othiym23>if you comment out line 10, it works
00:59:29  <othiym23>still working on what it is that bunyan is doing that breaks things
01:15:30  <othiym23>trevnorris: actually, bunyan isn't necessary: https://gist.github.com/othiym23/6748316
01:15:36  <othiym23>in that one, comment out line 4 and everything works
01:17:26  <othiym23>trevnorris: and if you move line 4 to after line 7, things work as well, so the order at which the asyncListener is registered is important
01:20:59  * kazuponjoined
01:24:51  * loladirojoined
01:25:08  * kazuponquit (Ping timeout: 240 seconds)
01:41:01  * c4miloquit (Remote host closed the connection)
01:44:35  <othiym23>trevnorris: stepping past the end of the setImmediate callback containing the console.log leads me to believe that something's losing the domain created by the cls.run call on line 9
02:00:22  * groundwaterquit (Quit: groundwater)
02:13:08  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:21:32  * kazuponjoined
02:25:57  * groundwaterjoined
02:25:58  * kazuponquit (Ping timeout: 245 seconds)
02:30:02  * defunctzombiechanged nick to defunctzombie_zz
02:42:35  * zhengjoined
03:12:09  * defunctzombie_zzchanged nick to defunctzombie
03:15:14  * kellabytequit (Ping timeout: 256 seconds)
03:22:05  * kazuponjoined
03:24:45  * zheng_joined
03:29:12  * zhengquit (Read error: Connection reset by peer)
03:34:18  * kazuponquit (Ping timeout: 245 seconds)
03:39:11  * c4milojoined
03:44:54  <trevnorris>othiym23: ping
03:45:29  * kellabytejoined
03:46:36  <trevnorris>othiym23: timers are difficult, and I realize there's some strange problem in there, but haven't exactly figured out what's going on.
03:46:36  <trevnorris>othiym23: since first you get a call on TimerWrap::OnTimeout() MakeCallback, but then for every timer as well in the while loop where the timers are actually run.
03:48:54  <trevnorris>othiym23: but i've tried to make sure the async listener only runs exactly onces per timer, so I've strangely injected it into lib/timer.js. maybe I just have to allow the listener to run for every callback added, and for the actual wrap. i'll patch it and try it out.
03:51:26  <othiym23>trevnorris: reload https://gist.github.com/othiym23/6748316
03:52:11  <othiym23>I've isolated the problem to happening if 1. console.log is being called for the first time inside a setImmediate callback which causes 2. a ContextifyScript to be created
03:52:32  <othiym23>that causes runAsyncQueue to be run over the existing queue and causes the domain to be overwritten
03:52:35  <othiym23>still digging into why
03:58:32  * mikealquit (Quit: Leaving.)
03:59:06  <othiym23>apparently just adding a console.log('+') isn't enough to fix it, so there's more going on there
04:00:27  * kazuponjoined
04:02:40  <trevnorris>othiym23: i'm not sure how to treat set{Timeout,Interval,Immediate} because they all use such a strange mechanism. they can fire when the TimerWrap is first being created, but then they're added to a linked list an processed in order when called if they're supposed to be run in the same number of ms.
04:03:31  <othiym23>right
04:03:32  <trevnorris>so you can have multiple fires for the same actual callback. one is called from the MakeCallback into the actual function in lib/timer that processes all the timers in order.
04:03:52  <trevnorris>but since each timer can have their own domain, they also need to be individually processed.
04:04:11  <othiym23>it turns out that adding a console.log('whatever') at the beginning of the script moves the problem elsewhere
04:04:47  <trevnorris>are you on the absolute latest? i added async wrap to a few other places in src/ this afternoon.
04:05:09  <othiym23>no, let me pull and rebuild
04:06:28  <othiym23>trevnorris: rebuilt, no change in behavior
04:06:38  <trevnorris>othiym23: try one more time. pushed this moment.
04:06:43  <trevnorris>(another change)
04:07:06  <othiym23>trevnorris: my expectation is that once the context is created for the callback to a timer, the listener would never be called for that context again
04:07:28  <othiym23>trevnorris: put another way, the domain on those contexts should be immutable, shouldn't they?
04:07:32  <othiym23>rebuilding
04:08:14  <trevnorris>othiym23: well, try this. any domain passed will persist to the next call. oh. let me add a patch that'll allow you do debug this easier.
04:08:46  * kazuponquit (Ping timeout: 245 seconds)
04:08:52  <othiym23>trevnorris: same dealio
04:09:25  <othiym23>by the way, I think this but is the same one that was in the longer bug gist I sent you on Thursday, just with process.nextTick instead of setImmediate
04:10:26  <othiym23>I think it's the exact same problem regardless of which timer function you use -- something is synchronously causing the listener to be run on an already-started async context, overwriting the original domain object with whatever listener returns at that point in time
04:12:14  <trevnorris>othiym23: just pushed another change. if a domain already existed on the object's context it'll pass that domain to the listener. so add a check in your listener to see if a domain exists.
04:13:01  <trevnorris>interesting. especially that it would happen on nextTick.
04:19:46  <othiym23>trevnorris: I'll give that a shot, and while I do that, take a look at https://gist.github.com/othiym23/6749302
04:23:02  <othiym23>trevnorris: the domain is never getting passed to listener
04:23:58  <othiym23>oh oops forgot to force-pull hold on
04:25:28  <othiym23>trevnorris: that fixes it
04:25:33  <othiym23>trevnorris: but that's a pretty gross hack ;)
04:25:39  <trevnorris>what fixes it?
04:26:57  <othiym23>your latest fix + a test added to the CLS listener to see if a domain has been passed in, and to just return that if it's been passed
04:27:22  <trevnorris>othiym23: ok, just forced pushed an update that removed the debug passing the domain thing. that isn't supposed to go into production.
04:27:50  <trevnorris>othiym23: I have a check that checks the return value of the listener, and it'll only reset the domain if a new return value is returned from the listener.
04:28:08  <trevnorris>but you're saying that the listener is being called multiple times for the same async event?
04:30:34  <othiym23>trevnorris: I'm not sure what you mean by "same async event"
04:31:07  <trevnorris>othiym23: e.g. run of a timer.
04:31:21  <trevnorris>it should only run once, and the context should always be unique.
04:31:29  <trevnorris>if that's not the case, then there's a fundamental flaw.
04:31:36  <trevnorris>so nothing should be overwritten.
04:32:26  <othiym23>if you look at that gist, there's a call to the listener that produces an 'immediate' object with an async queue attached
04:32:41  <othiym23>the domain of that immediate object is {safe : true}
04:32:49  <trevnorris>which test, you have several now :)
04:32:53  <trevnorris>ah, that one
04:33:55  <trevnorris>othiym23: we, or at least I, need a much simpler test case. i'm getting confused tracing through all this. or at least, i'm not understanding the fundamental concept of the end goal.
04:34:01  <othiym23>later on, WriteStream.Socket._writeGeneric calls createWriteReq, which triggers a call to runAsyncQueue, which in turn calls the listener, overwriting the domain with whatever the active CLS context was
04:34:17  <othiym23>that second call to the listener seems wrong to me
04:34:25  <othiym23>at least happening on that immediate object
04:34:42  <othiym23>that seems to me to be a different async event, which would get its own scope
04:34:47  <othiym23>am I wrong in thinking so?
04:34:59  <trevnorris>the second call shouldn't be happening if there's already an _asyncQueue object set.
04:35:13  <othiym23>that is where the problem lies, then
04:35:56  <othiym23>trevnorris: let me see if I can come up with a simpler test case than dragging all of CLS in
04:36:00  * TooTallNatejoined
04:37:21  <trevnorris>othiym23: there's no obvious reason why createWriteReq would trigger runAsyncQueue
04:40:54  <trevnorris>othiym23: scratch that. wtf. it triggers an instantiation of WriteWrap, and passes the same object handle. thus calling two async wrap calls on the same object.
04:40:59  <trevnorris>you've got to be freakin kidding me.
04:42:47  <trevnorris>wait, no. that shouldn't be happening. they're creating a new "context" for the completion of the write request.
04:44:12  <trevnorris>othiym23: you can see that on line 626 of lib/net.js. they create a new object with the callback when the write request is completel.
04:47:36  <othiym23>trevnorris: but that should get its own context, right?
04:48:58  <trevnorris>othiym23: well, there's the ._handle which is it's own instance and has already run runAsyncQueue, but the WriteReq instantiation on StreamWrap::WriteBuffer will also have a call, but yeah. the context in that case will be the object created on 626 of net.js, not _handle.
04:50:13  <trevnorris>othiym23: and I can show that. line 460 of src/stream_wrap.cc makes the AsyncWrap::MakeCallback call against WriteWrap* req_wrap.
04:50:17  <trevnorris>not the TCPWrap instance.
04:51:12  <trevnorris>othiym23: that was an issue I was having. at first I called it on the StreamWrap* wrap, but that was causing conflicts.
04:51:46  <trevnorris>and tests failed because the context object used by AsyncWrap::MakeCallback was incorrect.
04:52:31  <trevnorris>ugh. I can't believe how much object manipulation we're doing in c++. but must resist. that's all v0.13 optimizations.
04:56:32  <wolfeidau>Gday all
04:56:57  <wolfeidau>I am having an interesting issue with node cross compile atm
04:58:03  <wolfeidau>If i use ./configure + make i get the error, if I just use make with CONFIG_FLAGS i don't
04:58:51  <wolfeidau>It has something to do with something called mksnapshot? in the v8 build region i believe
04:59:16  * mikealjoined
05:00:13  * defunctzombiechanged nick to defunctzombie_zz
05:00:22  <wolfeidau>probs a bit late for US people..
05:00:38  <othiym23>trevnorris: https://gist.github.com/othiym23/6749497 is about as simple an example as I can contrive (read the comments)
05:00:54  <othiym23>wolfeidau: if I knew anything about cross-compiling v8 I'd help you out ;)
05:01:14  <wolfeidau>othiym23: :)
05:01:34  <wolfeidau>So far i have come to the conclusion that is a dark art
05:02:42  <trevnorris>othiym23: just fyi, runAsyncQueue does a falsey check for the domain. so if you return 0, it won't be set. that so if you pre-pass a domain, it won't be overwritten but guess i should just check for "undefined" and make that the definitive case. thoughts?
05:03:22  <othiym23>trevnorris: I think checking for undefined is the best thing to do, yeah
05:03:33  * mikealquit (Ping timeout: 248 seconds)
05:04:47  <trevnorris>othiym23: ok, fix pushed.
05:05:42  * kazuponjoined
05:07:13  <othiym23>trevnorris: thoughts on https://gist.github.com/othiym23/6749497 ? It works with my polyfill
05:07:52  <trevnorris>othiym23: trying some stuff out. give me a few
05:08:01  <othiym23>np
05:10:23  * kazuponquit (Ping timeout: 260 seconds)
05:11:10  <trevnorris>othiym23: yeah. so something is definitely wrong: https://gist.github.com/trevnorris/6749541
05:13:20  <trevnorris>othiym23: ok. so i'm pretty sure it's because asyncStack isn't being handled properly.
05:14:03  <othiym23>awesome, that's the part of this all that I still don't understand ;)
05:15:16  <trevnorris>othiym23: in loadAsyncQueue i'm printing context.callback (if it exists) and it shows that all the nextTick callbacks run in the correct order. so give me a few to figure out why the stack is jacked.
05:17:40  * mraleph1quit (Quit: Leaving.)
05:21:54  <trevnorris>othiym23: fwiw, the domain going out of runAsyncQueue is always correct. now, figuring out why context._asyncQueue is different for the timer callback between then and loadAsyncQueue
05:25:42  * mikealjoined
05:28:04  <othiym23>trevnorris: unless I'm badly misunderstanding, the _asyncQueue is getting changed by runAsyncQueue getting run on it again by a different async event
05:29:09  <trevnorris>....
05:29:31  <trevnorris>um, yeah. wow. how did I miss that.
05:30:37  <trevnorris>othiym23: ok, give me a min. i'll have that fixed.
05:35:39  <trevnorris>othiym23: ok, run against that
05:35:53  <othiym23>k, one sec
05:37:04  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:37:05  <othiym23>thumbs up, let me try it with my other tests now
05:40:57  * loladiroquit (Quit: loladiro)
05:44:03  * loladirojoined
05:44:28  <othiym23>trevnorris: my agent tests are passing now for the first time, barring some flakiness that is probably unrelated to asyncListener stuff
05:44:34  <othiym23>good job!
05:45:08  <trevnorris>othiym23: thanks. more so I'm sorry. drastic oversight on my part. all this abstractness is killing my attention to the details.
05:46:54  <othiym23>consider this my review of the PR ;)
05:47:07  <othiym23>I definitely have a much better handle on how the JS side works now
05:47:23  <trevnorris>heh, thanks.
05:48:51  * loladiroquit (Client Quit)
05:49:52  <trevnorris>you now have a view into everything except crypto PBKDF2 and RandomBytes (working on the later), and CheckImmediate/EmitExit in node.cc
05:50:28  <trevnorris>but even got access to cares
05:50:40  <trevnorris>so it should give you a pretty good idea of what's going on.
05:50:52  <trevnorris>there is more api that I need to implement as well to emulate domains.
05:51:55  <trevnorris>e.g. the ability to add a listener to an existing handle (oh, I hate that), and think it'd be nice to allow setting listeners in c++.
05:55:58  * zheng_quit (Ping timeout: 245 seconds)
05:56:23  * zheng_joined
05:58:59  * c4miloquit (Remote host closed the connection)
05:59:54  * amartensjoined
06:00:42  <othiym23>I see the parallel code paths all over the place for domains and agree it would be nice to get rid of them
06:01:38  <othiym23>it's funny, my original intent for CLS was to rework domains to run on top of them, because they behave very similarly
06:02:13  <othiym23>but I also sorta said "screw this" when I saw how much work it was going to be to monkeypatch domains to run on a different substrate
06:05:40  <trevnorris>hah, yeah.
06:06:18  <trevnorris>othiym23: doubt i'll be able to get all that work done by v0.12 release, but it's on my definite todo list before v1.0
06:06:54  <trevnorris>othiym23: right now the path is to make sure all c++ Wrap classes are always instantiated at the same time as their js counterparts.
06:07:12  <othiym23>yeah, I saw your conversation with bnoordhuis, and that seems sane to me
06:07:47  <trevnorris>so that first. which is probably going to be non-trivial.
06:08:31  <trevnorris>then domains will be removed from c++ core code at least, and most of lib/. except for events.
06:08:41  <trevnorris>they'll always have to be in lib/events.js
06:09:15  <trevnorris>well, we've already discussed this. sorry, ramble when I get tired.
06:09:24  <othiym23>yeah, I'm having to monkeypunch individual EEs to get CLS working with them the way I want
06:09:33  <othiym23>nah, that's OK
06:10:42  <trevnorris>oy. doubt i'll be able to get everything done on my v0.13 todo list. oh well, guess I'll just need to prioritize. :P
06:41:18  <MI6>nodejs-v0.10-windows: #234 UNSTABLE windows-ia32 (7/600) windows-x64 (7/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/234/
06:52:03  * zheng__joined
06:55:23  * zheng_quit (Ping timeout: 260 seconds)
07:06:13  * kazuponjoined
07:11:01  * kazuponquit (Ping timeout: 248 seconds)
07:13:35  * hzjoined
07:15:12  * hzquit (Client Quit)
07:32:52  * hzjoined
07:35:57  * paddybyersjoined
07:46:00  * EhevuTovjoined
08:06:55  * kazuponjoined
08:11:17  * kazuponquit (Ping timeout: 248 seconds)
08:12:00  * rendarjoined
08:15:40  * stagasjoined
08:20:47  * EhevuTovquit (Quit: This computer has gone to sleep)
08:48:24  <trevnorris>othiym23: side note, using removeAsyncListener will allow the listener to propagate with requests already made (e.g. track code already executed) but it doesn't track new incoming requests (e.g. http requests made to your server). just fyi.
09:05:07  * bnoordhuisjoined
09:07:28  * kazuponjoined
09:12:05  * kazuponquit (Ping timeout: 248 seconds)
09:22:11  * amartensquit (Quit: Leaving.)
09:52:38  * amartensjoined
09:56:38  * dominictarrquit (Quit: dominictarr)
10:01:18  * amartensquit (Ping timeout: 252 seconds)
10:02:16  * dominictarrjoined
10:08:06  * kazuponjoined
10:10:13  * bnoordhuisquit (Ping timeout: 248 seconds)
10:12:52  * kazuponquit (Ping timeout: 256 seconds)
10:45:19  * bnoordhuisjoined
10:46:15  <MI6>nodejs-v0.10: #1508 UNSTABLE linux-ia32 (1/600) smartos-x64 (2/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1508/
10:57:13  * amartensjoined
11:02:12  * rjequit (Ping timeout: 260 seconds)
11:04:07  * amartensquit (Ping timeout: 260 seconds)
11:05:46  * piscisaureus_joined
11:08:33  * kazuponjoined
11:09:00  * rjejoined
11:13:18  * kazuponquit (Ping timeout: 264 seconds)
11:23:32  * Kakerajoined
11:28:27  * `3rdEdenquit (Ping timeout: 248 seconds)
11:43:13  * stagasquit (Read error: Connection reset by peer)
11:44:35  * paddybyersquit (Quit: paddybyers)
12:01:53  * amartensjoined
12:06:16  * amartensquit (Ping timeout: 245 seconds)
12:09:06  * kazuponjoined
12:14:44  * bnoordhuisquit (Ping timeout: 240 seconds)
12:20:11  * kazuponquit (Ping timeout: 248 seconds)
12:37:08  * st_lukejoined
12:39:11  * piscisaureus_quit (Ping timeout: 245 seconds)
12:42:41  * zheng__quit (Quit: Leaving)
12:59:33  * st_lukequit (Remote host closed the connection)
13:02:12  * amartensjoined
13:06:51  * amartensquit (Ping timeout: 256 seconds)
13:14:29  * st_lukejoined
13:17:21  * kazuponjoined
13:22:03  * kazuponquit (Ping timeout: 252 seconds)
13:26:57  * `3E|GONEjoined
13:58:14  * st_lukequit (Remote host closed the connection)
14:00:18  * kellabytequit (Remote host closed the connection)
14:02:31  * amartensjoined
14:06:48  * amartensquit (Ping timeout: 240 seconds)
14:17:51  * kazuponjoined
14:22:47  * kazuponquit (Ping timeout: 256 seconds)
14:40:42  * zhengjoined
14:41:42  * kazuponjoined
14:45:20  * loladirojoined
14:51:21  * bnoordhuisjoined
14:58:36  * `3E|GONEchanged nick to `3rdEden
15:02:53  * amartensjoined
15:07:08  * amartensquit (Ping timeout: 240 seconds)
15:09:40  * paddybyersjoined
15:17:29  <MI6>nodejs-master: #585 UNSTABLE smartos-ia32 (2/643) linux-x64 (1/643) smartos-x64 (5/643) http://jenkins.nodejs.org/job/nodejs-master/585/
15:22:43  * kazuponquit (Remote host closed the connection)
15:22:49  * paddybyersquit (Quit: paddybyers)
15:26:37  * defunctzombie_zzchanged nick to defunctzombie
15:33:40  <roxlu>hi guys I'm trying to use libuv in a project but when I use it the entry points for the dll aren't found anymore. I've not yet had this issue before and I'm wondering if someone knows what this means and how to solve this
15:33:56  <roxlu>it's something wierd with another dll http://i.imgur.com/s37Wxbr.png
15:34:37  * zhengquit (Quit: Leaving)
15:58:58  * dominictarrquit (Quit: dominictarr)
15:59:49  * mikealquit (Quit: Leaving.)
16:03:11  * amartensjoined
16:04:18  * mikealjoined
16:07:33  * amartensquit (Ping timeout: 248 seconds)
16:08:03  * AvianFlujoined
16:15:12  * kellabytejoined
16:15:26  * kellabytequit (Changing host)
16:15:26  * kellabytejoined
16:15:26  * kellabytequit (Changing host)
16:15:26  * kellabytejoined
16:44:52  * dominictarrjoined
16:48:17  * dominictarrquit (Client Quit)
16:54:03  * dominictarrjoined
16:55:34  * kenperkinsquit (Quit: Computer has gone to sleep.)
16:56:55  * bnoordhuisquit (Ping timeout: 256 seconds)
16:59:27  * loladiroquit (Quit: loladiro)
17:03:31  * amartensjoined
17:05:48  * loladirojoined
17:07:48  * amartensquit (Ping timeout: 240 seconds)
17:10:53  * inolen1joined
17:10:53  * inolenquit (Read error: Connection reset by peer)
17:11:55  * AvianFluquit (Remote host closed the connection)
17:13:54  * AvianFlujoined
17:16:17  * stagasjoined
17:53:36  <MI6>libuv-master: #262 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/262/
17:57:25  * dominictarrquit (Ping timeout: 248 seconds)
17:58:07  * dominictarrjoined
18:01:14  * groundwaterquit (Quit: groundwater)
18:06:53  <MI6>libuv-node-integration: #247 UNSTABLE smartos-ia32 (1/643) linux-ia32 (1/643) smartos-x64 (6/643) http://jenkins.nodejs.org/job/libuv-node-integration/247/
18:08:37  * defunctzombiechanged nick to defunctzombie_zz
18:23:39  * defunctzombie_zzchanged nick to defunctzombie
18:26:38  * st_lukejoined
18:32:36  * paddybyersjoined
18:44:56  <MI6>nodejs-master-windows: #378 UNSTABLE windows-x64 (21/643) windows-ia32 (20/643) http://jenkins.nodejs.org/job/nodejs-master-windows/378/
18:56:34  * groundwaterjoined
19:01:24  * groundwaterquit (Ping timeout: 252 seconds)
19:02:19  * c4milojoined
19:03:53  * amartensjoined
19:07:00  * amartensquit (Read error: Operation timed out)
19:08:06  * TooTallNatejoined
19:09:33  * hzquit
19:10:54  * st_lukequit (Remote host closed the connection)
19:12:20  * st_lukejoined
19:14:05  * groundwaterjoined
19:16:48  * st_lukequit (Ping timeout: 252 seconds)
19:18:35  * groundwaterquit (Ping timeout: 256 seconds)
19:22:43  * dominictarrquit (Quit: dominictarr)
19:23:43  * groundwaterjoined
19:26:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:29:23  * amartensjoined
19:30:01  * groundwaterquit (Ping timeout: 245 seconds)
19:34:11  * groundwaterjoined
19:38:28  * groundwaterquit (Ping timeout: 245 seconds)
19:39:47  * c4miloquit (Remote host closed the connection)
19:41:50  * paddybyersquit (Quit: paddybyers)
19:53:43  * c4milojoined
19:56:52  * paddybyersjoined
19:57:46  * defunctzombiechanged nick to defunctzombie_zz
19:58:06  * groundwaterjoined
20:01:01  * defunctzombie_zzchanged nick to defunctzombie
20:05:14  * groundwaterquit (Ping timeout: 256 seconds)
20:08:00  * st_lukejoined
20:14:19  * dominictarrjoined
20:18:17  * amartensquit (Quit: Leaving.)
20:18:30  * AvianFluquit (Remote host closed the connection)
20:22:14  * hzjoined
20:22:29  * defunctzombiechanged nick to defunctzombie_zz
20:27:38  * paddybyersquit (Quit: paddybyers)
20:30:39  * dominictarrquit (Ping timeout: 260 seconds)
20:34:33  * dominictarrjoined
20:43:49  * defunctzombie_zzchanged nick to defunctzombie
20:44:51  * c4miloquit (Remote host closed the connection)
20:46:37  * c4milojoined
20:49:04  * AvianFlujoined
20:54:37  * bnoordhuisjoined
20:55:20  * st_lukequit (Remote host closed the connection)
20:57:42  * AvianFluquit (Ping timeout: 264 seconds)
21:00:54  * paddybyersjoined
21:05:16  * groundwaterjoined
21:08:19  * defunctzombiechanged nick to defunctzombie_zz
21:08:40  * AvianFlujoined
21:30:17  * einarosquit (Remote host closed the connection)
21:32:59  * AvianFluquit (Remote host closed the connection)
21:35:43  * inolen1changed nick to inolen
21:39:42  * bnoordhuisquit (Ping timeout: 264 seconds)
21:43:24  * abraxasjoined
21:45:55  * einarosjoined
21:47:26  * abraxasquit (Ping timeout: 240 seconds)
21:48:40  * hzquit
21:59:17  * rendarquit
22:02:30  * LOUDBOTquit (Ping timeout: 264 seconds)
22:03:01  * paddybyersquit (Quit: paddybyers)
22:07:48  * EhevuTovjoined
22:07:57  * LOUDBOTjoined
22:08:28  * dominictarrquit (Ping timeout: 240 seconds)
22:14:34  * dominictarrjoined
22:23:25  * c4miloquit (Remote host closed the connection)
22:43:11  * dominictarrquit (Ping timeout: 260 seconds)
22:45:09  * dominictarrjoined
22:50:59  * AvianFlujoined
23:02:38  * Kakeraquit (Ping timeout: 240 seconds)
23:02:59  <hueniverse>Found more crypto methods not properly bound to active domain
23:03:13  <hueniverse>but I'm too lazy to tell you which one exactly
23:06:40  * AvianFluquit (Remote host closed the connection)
23:07:49  * AvianFlujoined
23:09:18  * c4milojoined
23:12:53  * TooTallNatejoined
23:13:53  * c4miloquit (Ping timeout: 245 seconds)
23:16:14  <wolfeidau>hueniverse: #helping ? :)
23:24:54  <hueniverse>wolfeidau: at least of the the Crypto methods used in Iron is not bound to the active domain which means if a test fails, the test tool aborts because the domain it uses to catch the exception isn't bound anymore
23:27:34  * stagasquit (Read error: Connection reset by peer)
23:42:08  <wolfeidau>hueniverse: ah I have just started to mess with domains but understand how important it is to get resources bound to the domain is :) BTW iron looks very cool
23:45:00  * st_lukejoined
23:45:26  * dominictarrquit (Ping timeout: 245 seconds)
23:47:18  * dominictarrjoined
23:53:04  <othiym23>trevnorris: https://github.com/othiym23/node-continuation-local-storage/blob/master/test/tracer-scenarios.tap.js
23:53:14  <othiym23>trevnorris: I ported the test scenarios out of the agent and onto CLS
23:53:54  <othiym23>trevnorris: it should be possible to take those and turn them into test scenarios free from ties to CLS, but I'm too lazy to do that right now ;)
23:54:18  <othiym23>hueniverse: if trevnorris manages to get the asyncListener stuff everywhere it needs to go, maybe he can fix some of those domain issues along the way
23:57:18  <tjfontaine>some of them were done in master
23:59:07  <hueniverse>othiym23: it's only hurting me in testing so not urgent. it should not take too much effort to narrow down the missing binding in 0.10
23:59:17  <MI6>libuv-master-gyp: #202 FAILURE windows-x64 (3/195) windows-ia32 (3/195) http://jenkins.nodejs.org/job/libuv-master-gyp/202/