00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:03  <MI6>libuv-master-gyp: #203 FAILURE windows-x64 (3/195) windows-ia32 (4/195) osx-ia32 (1/195) http://jenkins.nodejs.org/job/libuv-master-gyp/203/
00:00:09  * ircretaryjoined
00:12:59  * AvianFluquit (Remote host closed the connection)
00:14:14  * AvianFlujoined
00:18:06  * `3rdEdenquit (Ping timeout: 252 seconds)
00:23:38  * mikealquit (Quit: Leaving.)
00:24:32  * mikealjoined
00:30:01  * mikealquit (Quit: Leaving.)
00:30:22  <trevnorris>othiym23: there you go. AsyncWrap::MakeCallback now handles everything in core. (ok, except for EmitDebugEnabledAsyncCallback, EmitExit, and CheckImmediate all in node.cc. still need to figure those out)
00:35:08  * EhevuTovquit (Quit: This computer has gone to sleep)
00:37:47  * mikealjoined
00:44:39  * dominictarrjoined
00:47:58  * dominictarrquit (Client Quit)
00:53:18  * groundwaterquit (Quit: groundwater)
00:54:13  <othiym23>sweeet
01:00:56  * mikealquit (Quit: Leaving.)
01:02:09  * mikealjoined
01:04:18  * mikealquit (Client Quit)
01:07:01  * c4miloquit (Remote host closed the connection)
01:09:23  * loladiroquit (Quit: loladiro)
01:11:24  * wwicksjoined
01:14:54  * othiym23&
01:14:54  <LOUDBOT>OH GOOD A METAFILTER THREAD ON HOMEOPATHY
01:17:38  * wavdedjoined
01:17:48  * loladirojoined
01:21:05  * amartensquit (Quit: Leaving.)
01:25:47  * c4milojoined
01:35:17  * AvianFluquit (Remote host closed the connection)
01:35:52  * loladiroquit (Quit: loladiro)
01:36:24  * AvianFlujoined
01:37:40  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:39:42  * abraxasjoined
01:49:44  * inolenquit (Quit: Leaving.)
01:54:49  * dap1joined
02:00:30  * amartensjoined
02:00:37  * amartensquit (Client Quit)
02:01:34  * wavdedquit (Quit: Hasta la pasta)
02:17:25  * `3E|GONEjoined
02:35:08  * inolenjoined
02:36:48  * julianduquequit (Ping timeout: 245 seconds)
02:40:21  * dap1quit (Quit: Leaving.)
02:51:16  * octetcloudquit (Ping timeout: 245 seconds)
02:59:37  * defunctzombie_zzchanged nick to defunctzombie
03:05:43  * julianduquejoined
03:24:47  * inolenquit (Quit: Leaving.)
03:27:53  * EhevuTovjoined
03:30:57  * inolenjoined
03:32:33  * AvianFluquit (Remote host closed the connection)
03:40:30  * loladirojoined
03:42:40  * EhevuTovquit (Quit: This computer has gone to sleep)
03:43:16  * EhevuTovjoined
03:44:12  * mikealjoined
03:44:26  * mikealquit (Client Quit)
03:49:25  * mikealjoined
04:00:42  * octetcloudjoined
04:16:49  * defunctzombiechanged nick to defunctzombie_zz
04:22:59  * st_lukejoined
04:28:54  * julianduquequit (Ping timeout: 252 seconds)
04:28:56  * defunctzombie_zzchanged nick to defunctzombie
04:37:55  * defunctzombiechanged nick to defunctzombie_zz
05:09:24  * loladiroquit (Quit: loladiro)
05:10:06  * defunctzombie_zzchanged nick to defunctzombie
05:10:21  * st_lukequit (Remote host closed the connection)
05:10:37  * c4miloquit (Remote host closed the connection)
05:22:55  * st_lukejoined
05:23:06  * defunctzombiechanged nick to defunctzombie_zz
05:24:59  * karupa64quit (Ping timeout: 256 seconds)
05:26:43  * karupa64joined
05:28:59  * brsonquit (Quit: leaving)
05:38:34  * paddybyersquit (Quit: paddybyers)
05:39:27  * paddybyersjoined
05:44:27  * octetcloudquit (Ping timeout: 248 seconds)
05:56:39  <trevnorris>hello all
05:57:58  * TooTallNatejoined
05:58:17  <trevnorris>othiym23: you staying up late again tonight?
06:00:27  <othiym23>trevnorris: sooooorta
06:00:32  <othiym23>dealing with EventEmitters
06:00:38  <othiym23>they're not making me happy
06:00:44  <trevnorris>othiym23: oh, fun. i'm working on removing them from core. :)
06:00:47  <othiym23>I'm having to monkeypunch them and do live monkeypatching
06:00:58  <trevnorris>hah, that's awesome.
06:01:06  <othiym23>I really don't like it
06:01:15  <trevnorris>don't like what?
06:02:21  <othiym23>trevnorris: this: https://gist.github.com/othiym23/6774425
06:02:35  <othiym23>I wish there were a simpler way to do what I'm trying to do
06:05:16  <othiym23>trevnorris: if you have any code review on that or questions about what I'm trying to do, feedback would be gratefully accepted :D
06:05:55  <trevnorris>well, i'm pretty warped on my clonazepam. so I wouldn't trust anything I have to say right now anyways :)
06:06:58  <othiym23>sweet!
06:07:00  <othiym23>never mind!
06:07:03  <othiym23>:D
06:07:52  <trevnorris>there was one feature I wanted to hurry and implement, but know i'm not sure if i''laksdf;lakfjd;lagkjjjjj;fgjfd
06:09:11  <othiym23>yeah, maybe tonight's a good night to chill
06:09:16  <trevnorris>though I did get an idea of how to remove domains. it's going to require injecting some code into the js side, but it'll be a lot less expensive than what we're doing on the native side.
06:09:30  <othiym23>I will be toddling off to bed as soon as I get this gross thing into a satisfactory state
06:09:33  <othiym23>it's tough to test
06:10:01  <othiym23>"injecting" -> monkeypatching?
06:10:08  * st_lukequit (Remote host closed the connection)
06:10:17  <trevnorris>heh, yeah.
06:11:09  * bnoordhuisjoined
06:11:28  <othiym23>interesting
06:12:17  <othiym23>the part I'm least happy with is monkeypatching emit and nuking the EE's hidden class by just shoving a random property onto the side of it
06:12:35  <othiym23>but whatever, I'm also creating a bunch of closures, so there's no way this thing is super fast anyway
06:14:27  <trevnorris>bnoordhuis: hey dude. you're on way freakin early. :)
06:15:10  * st_lukejoined
06:18:16  <bnoordhuis>trevnorris: kids, you know
06:18:25  <trevnorris>bnoordhuis: ah yeah. know how that goes.
06:23:24  * st_lukequit (Remote host closed the connection)
06:26:11  * c4milojoined
06:31:11  <trevnorris>bnoordhuis: sorry for the massive review size. been working non-stop trying to get domains worked out of c++ before the v0.12 cutoff.
06:34:25  <bnoordhuis>oh well
06:38:25  <MI6>joyent/node: Ben Noordhuis v0.10 * b7f36e1 : doc: link to pre-built binaries, add install note - http://git.io/S0XLsA
06:39:45  <bnoordhuis>so. how much closer to v0.12 are we?
06:41:16  <MI6>nodejs-v0.10-windows: #237 UNSTABLE windows-ia32 (7/600) windows-x64 (8/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/237/
06:41:20  * `3E|GONEchanged nick to `3rdEden
06:41:28  * rendarjoined
06:41:54  * `3rdEdenchanged nick to Guest49716
06:41:59  <trevnorris>bnoordhuis: well, as far as my stuff is concerned. it's working, and there's no performance regression. so it could land now, after passing review. just trying to get the domain stuff out before isaacs gets back from vacation.
06:42:19  * Guest49716changed nick to `3E
06:42:26  <trevnorris>if not then removing domains can be a v0.13 thing.
06:42:40  * `3Echanged nick to `3rdEden
06:46:24  <MI6>nodejs-v0.10: #1511 UNSTABLE linux-ia32 (2/600) smartos-x64 (2/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1511/
06:53:46  * dominictarrjoined
06:54:40  * AvianFlujoined
06:55:59  <MI6>nodejs-v0.10-windows: #238 UNSTABLE windows-ia32 (7/600) windows-x64 (7/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/238/
07:00:39  * hzjoined
07:03:34  * wolfeidauquit (Remote host closed the connection)
07:04:54  * AvianFluquit (Remote host closed the connection)
07:06:11  * AvianFlujoined
07:14:43  * kazuponjoined
07:25:50  * TooTallNatequit (Quit: Computer has gone to sleep.)
07:32:55  * c4miloquit (Remote host closed the connection)
07:45:01  * dominictarrquit (Ping timeout: 246 seconds)
07:48:52  * dominictarrjoined
07:54:51  * wolfeidaujoined
07:59:30  * bnoordhuisquit (Ping timeout: 264 seconds)
08:06:09  * dominictarrquit (Quit: dominictarr)
08:10:33  * inolenquit (Ping timeout: 252 seconds)
08:14:53  <roxlu>hey guys, I'm working on a multithreaded app where I have a struct AVPacket{} .. which is shared among different threads, I want to create a simple reference counting system ...
08:15:16  <roxlu>I want to add a "AddRef" and "Release" function to AVPacket(), that does the ref counting ...
08:15:24  * bnoordhuisjoined
08:15:25  <roxlu>but this means I would need a mutex per AVPacket ..
08:16:24  <roxlu>I can think of another solution ... but I'm wondering if using ~300 mutexes (that's the avarage number of packets I have) to do ref counting is not a smart idea?
08:17:25  * inolenjoined
08:23:04  <roxlu>indutny: any thoughts maybe?
08:25:48  * bnoordhuisquit (Ping timeout: 240 seconds)
08:38:38  * EhevuTovquit (Quit: This computer has gone to sleep)
08:40:54  * bnoordhuisjoined
08:50:33  * inolenquit (Ping timeout: 245 seconds)
08:54:56  * inolenjoined
09:08:50  <bnoordhuis>roxlu: why are you sharing the objects between threads in the first place?
09:14:22  <MI6>joyent/node: Alex Kocharin master * 60a1dbd : debugger: repeat last command - http://git.io/6VnEfg
09:20:09  <MI6>joyent/node: Alex Kocharin master * 028e652 : debugger: show current line, fix for #6150 - http://git.io/ckk77Q
09:25:19  <MI6>nodejs-master: #587 UNSTABLE osx-x64 (1/644) osx-ia32 (1/644) smartos-x64 (7/644) linux-ia32 (1/644) http://jenkins.nodejs.org/job/nodejs-master/587/
09:30:58  <trevnorris>bnoordhuis: food for thought since i'm about to hit the sack. the solution i've come up with is to inject some code into key places on the JS side where the Wrap isn't instantiated until later
09:30:59  <trevnorris>I find it more important to get the domain specific code out of c++ than js, and i'm pretty sure there's a way to do that.
09:31:06  <trevnorris>figured it'd at least be a good starting point.
09:32:06  <trevnorris>well, see you all in about 6 hours for our call (are we still having one?)
09:34:29  <MI6>nodejs-master: #588 UNSTABLE osx-ia32 (1/644) smartos-x64 (7/644) http://jenkins.nodejs.org/job/nodejs-master/588/
09:36:15  <MI6>nodejs-master-windows: #380 UNSTABLE windows-x64 (23/644) windows-ia32 (21/644) http://jenkins.nodejs.org/job/nodejs-master-windows/380/
09:38:25  * dominictarrjoined
09:40:49  * wolfeidauquit (Remote host closed the connection)
09:46:56  <rendar>bnoordhuis: i was thinking to this: if (uv_fs_can_watch_files_creation()) { watch fs with UV_CREATE operation } else { poll file listing } -- the same for file deletion, what you think about that?
09:48:21  * bnoordhuisquit (Ping timeout: 245 seconds)
09:57:57  <MI6>nodejs-master-windows: #381 UNSTABLE windows-x64 (20/644) windows-ia32 (20/644) http://jenkins.nodejs.org/job/nodejs-master-windows/381/
10:04:13  * dominictarrquit (Quit: dominictarr)
10:06:19  * bnoordhuisjoined
10:13:07  * Kakerajoined
10:16:37  * kazuponquit (Remote host closed the connection)
10:19:09  * kazuponjoined
10:20:16  * kazuponquit (Remote host closed the connection)
10:21:20  * dominictarrjoined
10:22:55  * bnoordhuisquit (Ping timeout: 256 seconds)
10:41:53  * dominictarrquit (Quit: dominictarr)
10:46:22  <MI6>nodejs-v0.10: #1512 UNSTABLE smartos-x64 (3/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1512/
10:51:13  * abraxasquit (Remote host closed the connection)
11:09:22  * bnoordhuisjoined
11:21:29  * loladirojoined
11:23:03  * loladiroquit (Client Quit)
11:23:19  <MI6>joyent/libuv: Ben Noordhuis master * 636f205 : Merge remote-tracking branch 'origin/v0.10' (+20 more commits) - http://git.io/ATPFvg
11:27:37  * wolfeidaujoined
11:28:43  <MI6>libuv-master: #264 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/264/
11:30:53  <MI6>libuv-master-gyp: #204 FAILURE windows-x64 (3/195) windows-ia32 (3/195) http://jenkins.nodejs.org/job/libuv-master-gyp/204/
11:34:29  <roxlu>bnoordhuis: I'm working on a video encoder which needs to encodes multiple video streams at the same time using the same raw input buffer
11:36:18  <bnoordhuis>roxlu: how long will each thread stay in its critical section?
11:36:36  <bnoordhuis>if it's only for a few instructions, a couple of mutexes won't hurt
11:36:41  <roxlu>you mean the part where I increment/decrement the refcount?
11:36:46  <bnoordhuis>yes
11:37:36  <roxlu>I'm incrementing like this: https://gist.github.com/roxlu/68a0e34ef735fe655409#file-memorypool-h-L111-L127
11:38:54  <bnoordhuis>roxlu: sorry, have to run again. just keep in mind that uncontended locks are nearly free
11:39:14  <roxlu>ok awesome, thanks. I think I'm good here then
11:39:34  <roxlu>if I run into problems I'll go and look for another solution
11:39:50  <roxlu>but for now only max 4 threads will share the same resource
11:42:32  <MI6>libuv-node-integration: #249 UNSTABLE linux-ia32 (1/644) smartos-x64 (7/644) http://jenkins.nodejs.org/job/libuv-node-integration/249/
11:44:30  * bnoordhuisquit (Ping timeout: 252 seconds)
11:48:46  * Kakeraquit (Ping timeout: 245 seconds)
12:09:21  * Domenic_quit (Ping timeout: 245 seconds)
13:17:05  * loladirojoined
13:24:12  * Kakerajoined
13:26:54  * Kakeraquit (Read error: Connection reset by peer)
13:27:10  * Kakerajoined
13:35:23  * rendarquit (Read error: Connection reset by peer)
13:43:53  * vptrjoined
13:45:15  * paddybyersquit (Quit: paddybyers)
13:45:38  * AvianFluquit (Remote host closed the connection)
13:58:07  * loladiroquit (Quit: loladiro)
14:01:18  * kellabytequit (Quit: Quit)
14:04:52  * inolenquit (Quit: Leaving.)
14:05:13  * mikealquit (Quit: Leaving.)
14:05:29  * kellabytejoined
14:08:03  * Domenic_joined
14:09:06  * vptrquit (Ping timeout: 264 seconds)
14:10:55  * vptrjoined
14:15:35  * bnoordhuisjoined
14:16:41  * Domenic_quit (Ping timeout: 245 seconds)
14:17:48  * Raynosquit (Ping timeout: 268 seconds)
14:18:04  * `3rdEdenquit (Ping timeout: 260 seconds)
14:20:22  * kenperkinsjoined
14:26:45  * mikealjoined
14:33:19  * rendarjoined
14:33:20  * rendarquit (Excess Flood)
14:34:07  * rendarjoined
14:37:15  * Kakeraquit (Ping timeout: 240 seconds)
14:41:52  * Domenic_joined
14:43:58  * mikealquit (Quit: Leaving.)
14:44:21  * c4milojoined
14:44:46  * kellabytequit (Changing host)
14:44:46  * kellabytejoined
14:44:46  * kellabytequit (Changing host)
14:44:46  * kellabytejoined
14:45:15  * `3Ejoined
14:53:50  * mikealjoined
15:00:26  * `3Echanged nick to `3rdEden
15:09:10  * AvianFlujoined
15:17:39  <MI6>nodejs-master: #589 UNSTABLE osx-x64 (1/644) smartos-x64 (6/644) http://jenkins.nodejs.org/job/nodejs-master/589/
15:20:45  <MI6>joyent/node: Ben Noordhuis master * f311963 : test: update require path after file move - http://git.io/Xhhizg
15:22:52  * mikealquit (Quit: Leaving.)
15:30:02  <MI6>nodejs-master: #590 UNSTABLE osx-x64 (1/644) smartos-x64 (7/644) http://jenkins.nodejs.org/job/nodejs-master/590/
15:32:45  * kazuponjoined
15:32:58  * bradleymeckjoined
15:41:02  * piscisaureus_joined
15:41:48  * octetcloudjoined
15:42:00  <piscisaureus_>hello
15:42:10  <bnoordhuis>sup bertje?
15:42:19  <bnoordhuis>also, sup sam?
15:43:53  * TooTallNatejoined
15:43:55  <piscisaureus_>I'm in lisbon
15:44:10  * mikealjoined
15:44:36  <bnoordhuis>how does that make you feel?
15:44:53  <piscisaureus_>umsy
15:44:55  * dapjoined
15:45:13  <piscisaureus_>are we going to have a meeting at 6/9?
15:45:35  <piscisaureus_>iow is isaacs back?
15:46:44  * defunctzombie_zzchanged nick to defunctzombie
15:46:48  <bnoordhuis>no (i think) and i don't have anything to discuss so i don't mind skipping it
15:47:37  <MI6>nodejs-master-windows: #382 UNSTABLE windows-x64 (19/644) windows-ia32 (23/644) http://jenkins.nodejs.org/job/nodejs-master-windows/382/
15:47:38  * defunctzombiechanged nick to defunctzombie_zz
15:47:46  * loladirojoined
15:47:55  * Kakerajoined
15:57:57  * bnoordhuisquit (Ping timeout: 240 seconds)
15:59:57  <tjfontaine>call?
16:00:46  <tjfontaine>piscisaureus_: you out because of lxjs?
16:00:51  <trevnorris>tjfontaine: here, we doing on?
16:00:53  <trevnorris>*one
16:01:19  <tjfontaine>trevnorris: guess it's a question if indutny and bnoordhuis sblom and TooTallNate wanna join
16:01:35  <indutny>oooooooooooooooo
16:01:36  <indutny>call
16:01:54  <piscisaureus_>tjfontaine: I'll try to join. The hotel wifi is really shit tho so we'll see if it works
16:02:56  <tjfontaine>k
16:02:56  <piscisaureus_>tjfontaine: is my link wrong or am I the only one?
16:04:26  <trevnorris>link?
16:05:13  <tjfontaine>trevnorris: https://plus.google.com/hangouts/_/calendar/aXNhYWNzY2hsdWV0ZXJAZ21haWwuY29t._8gr32d1p611k8b9o6cr48b9k6op3eba18cr32b9k88s3cgpi8d2k8dq560
16:06:05  <piscisaureus_>indutny: fedooooor!
16:06:19  <piscisaureus_>indutny: you're missing out.
16:06:23  <indutny>oh
16:06:24  <indutny>gosh
16:06:28  <indutny>one sec
16:06:39  <piscisaureus_>sorry network dropped
16:08:03  * loladiroquit (Quit: loladiro)
16:13:13  * vptrquit (Ping timeout: 246 seconds)
16:15:36  * loladirojoined
16:18:42  * Raynosjoined
16:19:44  <trevnorris>https://github.com/joyent/node/pull/6011
16:22:26  <piscisaureus_>trevnorris: tjfontaine: I'll stop making attempts to participate
16:22:37  <piscisaureus_>I'll look at the code and ask questions asynchronously
16:25:07  <trevnorris>piscisaureus_: what was the question you were in the middle of?
16:25:30  <piscisaureus_>trevnorris: do you get a meaningful state for read calls/callbacks?
16:25:43  <piscisaureus_>because they originate deeply inside the guts of node
16:28:16  <trevnorris>piscisaureus_: so, when an "event" is queued (e.g. TCPWrap instantiation) it will check if there is any async listeners active.
16:28:16  <trevnorris>if so then it'll call out to js and each listener can return an object that'll be attached to that request, for that listener
16:28:16  <trevnorris>that return value, along with the actual context of the object running are passed to the before/after callbacks before and after the callback has run.
16:28:52  <piscisaureus_>trevnorris: <3 it
16:28:58  <trevnorris>:)
16:28:59  <piscisaureus_>trevnorris: it's almost Tasks
16:30:18  <trevnorris>there is one thing I haven't been able to figure out. that's how to pass the context directly to the error callback. but a work around right now is to attach the context to the "domain" object in the before, since the domain object is passed to the error callback.
16:30:49  <trevnorris>but that way you can know the entire stack of resources that were involved when something errors.
16:30:59  * mikealquit (Quit: Leaving.)
16:31:43  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:32:43  <piscisaureus_>On a more general note
16:32:57  <piscisaureus_>I don't like that we're sticking all these random things onto the process object
16:34:02  <tjfontaine>which in particular?
16:34:43  <piscisaureus_>addAsyncListener
16:34:44  <piscisaureus_>also
16:34:45  <piscisaureus_>features
16:34:48  <piscisaureus_>versions
16:34:50  <piscisaureus_>hrtime
16:34:53  <piscisaureus_>dlopen
16:35:01  <piscisaureus_>maxTickDepth
16:35:04  <piscisaureus_>kill
16:35:18  <piscisaureus_>dlopen is probably okay
16:35:21  <trevnorris>maxTickDepth is gone :)
16:35:23  <piscisaureus_>kill is probably more something for os
16:35:33  <piscisaureus_>process.EventEmitter
16:35:58  <piscisaureus_>I know that most of these are now "fixed"
16:36:14  <tjfontaine>a lot of those are pretty old things, I am fine with features going away though :)
16:36:36  <rvagg>dlopen and verisons surely belong there
16:37:17  <trevnorris>piscisaureus_: well, the asyncListener stuff is a new API, so those can go wherever. think a new module should be created for them or something?
16:37:20  <piscisaureus_>well versions and arch and platform and config are about the build and not really much about the process instance
16:37:33  <piscisaureus_>maybe require('loop') <-- for fancy stuff with the event loop
16:37:47  <piscisaureus_>also _getActiveHandles and _getActiveRequests
16:37:53  * amartensjoined
16:37:57  <piscisaureus_>rvagg: ohai. Where are you at?
16:38:00  <tjfontaine>well, how about __noReallGiveMeEvilThings
16:38:05  <tjfontaine>*noReally
16:38:07  <rvagg>http://npm.im/loop you're a bit late to be making up new package names
16:38:16  <rvagg>piscisaureus_: I'm at the cinema, on a beanbag
16:38:24  <piscisaureus_>is the wifi better there?
16:38:34  * loladiroquit (Quit: loladiro)
16:38:43  <piscisaureus_>rvagg: no we can just hijack it
16:38:48  <rvagg>piscisaureus_: I have a local SIM now! but yeah, they have conference wifi up and running
16:38:50  <piscisaureus_>2.1.1 last updated 2 years ago
16:39:12  <piscisaureus_>but apparently people are using it
16:39:14  <rvagg>piscisaureus_: a hive of activity down here
16:40:02  <piscisaureus_>yeah I guess
16:40:22  <piscisaureus_>rvagg: but really this would mean I have to quit
16:40:28  <piscisaureus_>we can never add any more modules to core
16:40:31  <trevnorris>tjfontaine: know what would be cool? if you places a setter on process.execArgv, and if a user placed something on there you use your module to automatically load it :)
16:40:34  <rvagg>at the cinema I mean, if you're looking for a new place to be
16:40:34  <piscisaureus_>because all meaningful names are taking
16:40:38  <piscisaureus_>*taken
16:40:56  <piscisaureus_>rvagg: ah!
16:41:07  <rvagg>perhaps the cruft can go in require('util')
16:41:14  <rvagg>.. which has plenty of cruft already
16:41:18  <tjfontaine>a concept of builtin vs external modules in the loader would probably be helpful :)
16:41:26  <piscisaureus_>yeah
16:41:43  <piscisaureus_>tjfontaine: I appoint you as the master isaacs convincer
16:41:49  <tjfontaine>trevnorris: I have no idea what you mean by that, and am afraid to ask
16:42:01  <tjfontaine>piscisaureus_: heh, well I don't have a good vision for how that would work
16:42:21  <piscisaureus_>tjfontaine: me neither
16:42:33  <tjfontaine>for development purposes I would also like the opportunity to move lib/* out, but it's really not that bad to constantly recompile
16:42:35  <piscisaureus_>tjfontaine: the "problem" of course is that the namespace is flat
16:42:39  <tjfontaine>yup
16:42:55  <piscisaureus_>tjfontaine: so we might go all java-y and have org.node.loop :)
16:43:07  <rvagg>oh man...
16:43:07  <tjfontaine>I just threw up in my mouth
16:43:10  <trevnorris>tjfontaine: you have a module that allows you to load a flag after the process is running, correct?
16:43:14  <tjfontaine>but the point stands
16:43:19  <piscisaureus_>haha
16:43:21  <tjfontaine>trevnorris: yes
16:43:44  <rvagg>the namespace isn't entirely flat since it's character-restricted, you could have something special like require(':loop'), require('~loop')
16:43:53  <tjfontaine>that's exactly what I was going to type :)
16:44:01  <piscisaureus_>tjfontaine: rvagg: I was barely able to type it. But I do think that namespacing is the only way to ameliorate the situation.
16:44:01  <tjfontaine>but it's sorta obtuse
16:44:12  <tjfontaine>piscisaureus_: nod
16:44:18  <trevnorris>piscisaureus_: anything java-y can't possibly be the right answer. ;)
16:44:36  <piscisaureus_>it's something that would work
16:44:44  <tjfontaine>trevor already got called java-y today
16:44:57  <piscisaureus_>but we'd be swapping the dot for the colon
16:45:00  <trevnorris>twice! pissed me off.
16:45:24  <piscisaureus_>do ES6 modules have a concept of namespaces?
16:45:43  <trevnorris>tjfontaine: and process.execArgv shows the flags that you started node with. so set a setter on process.execArgv. so if someone does, say, process.execArgv.push('--harmony'); it'll automatically load it. ;P
16:46:14  <tjfontaine>lul
16:46:24  <tjfontaine>but I do basically taht :)
16:46:26  <piscisaureus_>tjfontaine: you know that is dutch for dick?
16:46:34  <trevnorris>heh, awesome.
16:46:37  <tjfontaine>piscisaureus_: I do :)
16:46:58  <tjfontaine>trevnorris: mine stays fairly local though
16:47:38  <tjfontaine>trevnorris: so there's require('setflags').flags which re-reports execArgv and what ever has been set, but it doesn't have a setter to handle the case you're referring to
16:48:02  <trevnorris>that's awesome. bet you're real proud of that code. ;)
16:48:13  <tjfontaine>I cry a little at night because of it
16:48:13  * kazuponquit (Remote host closed the connection)
16:48:13  <tjfontaine>:)
16:50:21  <trevnorris>so, i'm really lost from this whole namespace, or whatever, conversation. though I do know I'd like us to standardize a lower level API that sits directly on top of the *Wrap classes. oh, the possibilities are sooooo awesome!
16:50:46  <trevnorris>then the event emitter can sit on top of that. so we can do with the event emitter what I'm working on with domains now.
16:50:55  <piscisaureus_>trevnorris++
16:51:08  <trevnorris>piscisaureus_: thanks :)
16:51:40  <trevnorris>the performance implications are tremendous. makes me giggle thinking about it.
16:52:19  <trevnorris>tjfontaine: think this asyncListener stuff should be officially documented, or leave it out for now?
16:52:36  <tjfontaine>trevnorris: document it, if at least for our sake
16:52:50  <tjfontaine>trevnorris: doesn't necessarily mean it needs to be included in what we produce for api
16:53:07  <trevnorris>true.
16:53:08  <tjfontaine>trevnorris: but if new relic is going to depend on it we need to work out what that means for our future
16:53:37  <piscisaureus_>trevnorris: is the API as you outlined in the PR what it became?
16:54:13  <piscisaureus_>trevnorris: although not urgen, I would like to also get notified of the return value of the async function
16:54:14  <trevnorris>piscisaureus_: let me double check. but I think yes.
16:54:44  * loladirojoined
16:54:44  <trevnorris>piscisaureus_: meaning, you'd like it to be passed as an argument to the after callback?
16:54:57  <piscisaureus_>trevnorris: yes
16:55:02  <trevnorris>cool.
16:55:07  * kazuponjoined
16:55:14  <piscisaureus_>trevnorris: so currently in node the return value of a callback is always ignored
16:55:31  <piscisaureus_>trevnorris: but you could actually use it in a meaninful way which is what I am planning for phase 2
16:56:00  <piscisaureus_>(but first I'd have to coerce people into not returning random crap from a callback)
16:58:01  <piscisaureus_>trevnorris: also you should move `domain` to be that last argument ...
16:58:18  <trevnorris>piscisaureus_: you mean in the error callback?
16:58:20  <tjfontaine>for interrupt the callback path?
16:58:25  <piscisaureus_>trevnorris: yes
16:58:53  <trevnorris>othiym23: ping
16:58:57  <piscisaureus_>trevnorris: for `after` it should be `context, returnValue, domain`
16:59:24  <trevnorris>piscisaureus_: i'm fine w/ that. want to know how much work it'll add to othiym23 stuff.
16:59:28  <piscisaureus_>trevnorris: the reasoning is simply this
16:59:35  <trevnorris>since he's already written an entire test suit for it. :)
16:59:35  <piscisaureus_>trevnorris: domains are bad
16:59:42  <piscisaureus_>trevnorris: they should eventually disappear
17:00:04  <trevnorris>piscisaureus_: oh. domain isn't like, the domain module. "domain" is the object returned from the listener. nothing to do with each other.
17:00:05  <piscisaureus_>trevnorris: but if you make it anything but the last parameter the shadow of domains will always remain in the API
17:00:15  <piscisaureus_>oh haha
17:00:21  <piscisaureus_>ok cool
17:01:45  * brsonjoined
17:16:19  * piscisaureus_quit (Ping timeout: 260 seconds)
17:17:39  * vptrjoined
17:26:56  * mikealjoined
17:28:32  * c4miloquit (Remote host closed the connection)
17:34:23  * piscisaureus_joined
17:48:01  * EhevuTovjoined
17:57:25  * TooTallNatejoined
18:02:19  <trevnorris>othiym23: you'll want to update your latest branch. was adding more tests, and realized that the "after" callbacks were never firing. :P
18:09:41  <trevnorris>piscisaureus_: done. now the after callback receives the return value of the callback.
18:11:06  * EhevuTovquit (Quit: This computer has gone to sleep)
18:11:39  * bnoordhuisjoined
18:14:16  * kazuponquit (Remote host closed the connection)
18:14:40  <trevnorris>bnoordhuis: hey dude, heard your kid was sick?
18:14:58  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:16:44  <bnoordhuis>trevnorris: yeah, but it turned out to be pretty much okay. just a flu
18:17:11  <bnoordhuis>or "just a flu", it's a pretty dangerous thing with newborns of course
18:17:38  <bnoordhuis>but he's in the hospital for observation and doing well again after two days
18:17:47  <trevnorris>yeah. i remember every little thing for the first couple months were like a small panic.
18:18:03  <trevnorris>good to hear. :)
18:18:33  <bnoordhuis>yeah :) he and his mom are coming home tomorrow again
18:22:56  * TooTallNatejoined
18:34:01  * loladiroquit (Quit: loladiro)
18:36:48  * loladirojoined
18:37:14  * loladiroquit (Client Quit)
18:41:19  * c4milojoined
18:41:37  <bnoordhuis>indutny: see it as motivation :)
18:41:43  <indutny>haha
18:42:02  <indutny>bnoordhuis: you know what's motivation
18:42:10  <indutny>looking at your own house burning
18:42:12  <indutny>muhahaha
18:42:30  <indutny>that was a joke, obviously
18:44:09  <tjfontaine>I think the russian just threatened to burn your house down
18:44:13  <bnoordhuis>hrm, but motivation for what?
18:44:19  <bnoordhuis>by then it's too late, isn't it?
18:44:41  <bnoordhuis>maybe motivation for looking for a new house
18:45:07  <trevnorris>this is really strange. I'm passing an argument to a nextTick callback (injected in src/node.js) and it causes the http benchmark to fail with:
18:45:07  <trevnorris>Error: This socket has been ended by the other party
18:45:15  <bnoordhuis>at any rate, your soft skills can still use some work, fedor :)
18:45:48  <tjfontaine>heh
18:46:47  <tjfontaine>can I make npm not go over https?
18:47:02  <tjfontaine>ah I can
18:47:58  <tjfontaine>trevnorris: good news for you, bad news for indutny :)
18:48:19  <trevnorris>tjfontaine: how do you mean? i'm lost now :(
18:48:58  <tjfontaine>trevnorris: likely most of your master regressions wrt npm installs appear to be related to tls, if you `npm config set registry http://registry.npmjs.org/` lemme know if you can do installs
18:49:11  <MI6>joyent/libuv: Ben Noordhuis master * 0d435a5 : unix: remove uv__pipe_accept() (+1 more commits) - http://git.io/u-62Rg
18:49:26  <tjfontaine>I'm seeing truncation on downloads, which is where the checksum mismatches are coming from
18:50:27  <bnoordhuis>tjfontaine: master or v0.10?
18:50:33  <tjfontaine>bnoordhuis: master
18:50:35  <bnoordhuis>because if it's v0.10, it might be this: https://github.com/joyent/node/issues/6107
18:50:58  <tjfontaine>ya I need to look at that one as well, but this seems to be tls related
18:51:17  * Benviequit (Ping timeout: 248 seconds)
18:51:58  <trevnorris>alright, here we go.
18:52:20  <trevnorris>if I can get through npm --dev install newrelic, then i'll consider it fixed.
18:52:59  <trevnorris>tjfontaine: yeah. that seems to have fixed it. now the only error I get is:
18:52:59  <trevnorris>../src/node_zlib.cc:101: void node::ZCtx::Close(): Assertion `!write_in_progress_ && "write in progress"' failed.
18:53:43  <tjfontaine>nice
18:54:10  <othiym23>trevnorris: that's uh kind of amazing -- did you add some tests to make sure that after doesn't regress?
18:54:13  <othiym23>lemme pull and rebuild
18:54:42  <trevnorris>othiym23: which, that after never actually ran, or that i'm now passing the return value of the callback?
18:54:47  <trevnorris>either way, both are done.
18:54:58  <MI6>nodejs-master-windows: #383 UNSTABLE windows-x64 (24/644) windows-ia32 (26/644) http://jenkins.nodejs.org/job/nodejs-master-windows/383/
18:55:05  <MI6>libuv-master: #266 UNSTABLE windows (5/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/266/
18:55:07  <othiym23>trevnorris: where does the return value get passed?
18:55:14  <othiym23>as a third parameter, or as the context?
18:55:19  <trevnorris>othiym23: after: function(context, domain, returnValue);
18:55:32  <othiym23>trevnorris: OK, I'll add that to the polyfill (it's easy enough to do)
18:55:49  <trevnorris>piscisaureus_: i'm interested to see what plans you have for that functionality
18:55:52  <othiym23>(I don't think I need it personally tho
18:55:54  <othiym23>)
18:56:03  <trevnorris>no. it was a request by piscisaureus_
18:56:36  <piscisaureus_>trevnorris: hold on, writing a gist
18:57:18  <MI6>libuv-master-gyp: #205 FAILURE windows-x64 (4/195) windows-ia32 (3/195) http://jenkins.nodejs.org/job/libuv-master-gyp/205/
18:57:44  <indutny>trevnorris: what's up?
18:57:49  <indutny>by other party?
18:57:52  <tjfontaine>bnoordhuis: do we need to pin gyp to a specific version so that doesn't fail?
18:58:02  <indutny>who is writing such odd messages?
18:58:06  <trevnorris>indutny: eh? what? a party? count me in!
18:58:22  <indutny>Error: This socket has been ended by the other party
18:58:42  <indutny>ah
18:58:43  <indutny>EPIPE
18:58:47  <indutny>and so what?
18:58:51  <indutny>its totally ok
18:59:00  <trevnorris>indutny: oh, so in src/node.js, where the nextTick callback is called. if you pass anything to the nextTick callback and run the http_simple test. that's how it fails.
18:59:08  <piscisaureus_>trevnorris: https://gist.github.com/piscisaureus/6783332
18:59:23  <indutny>trevnorris: oh, interesting
18:59:40  <indutny>trevnorris: I guess its bug?
19:00:10  <trevnorris>indutny: i'm experimenting with passing the calling context as an argument to nextTick, so we can remove some closures we have in core, and yeah.
19:00:13  <tjfontaine>shouldn't both cb's return a result?
19:00:29  <trevnorris>might be a bug. i'm investigating how it's getting there.
19:01:20  <othiym23>piscisaureus_: so `data` would end up being passed into the setCallback callback as `result`? fancy!
19:01:35  <piscisaureus_>othiym23: that's the idea
19:01:48  <othiym23>spooky action at a distance!
19:01:53  <othiym23>that's my kind of insanity
19:02:13  <trevnorris>oy, I fear the can of worms this patch will open up.
19:02:18  <piscisaureus_>othiym23: the stage 1 plan is to have an explicit function to call
19:02:18  * vptrquit (Ping timeout: 252 seconds)
19:02:43  <othiym23>trevnorris: all my tests pass with the current tip of flippin-tick-thing, so goodjob
19:02:46  <piscisaureus_>othiym23: but eventually just returning is nicer. Consider that throwing an error is also just returning in a way
19:02:51  <trevnorris>othiym23: :)
19:03:09  <othiym23>piscisaureus_: yeah, it's an interesting counterpoint to the asynchronous generator approach
19:03:10  <piscisaureus_>othiym23: but this would only work if people stop returning crap from their callbakcs
19:03:19  <othiym23>I'll think about it some more
19:03:22  <othiym23>yeah
19:03:27  * othiym23& for lunch
19:03:32  <bnoordhuis>tjfontaine: don't know. did gyp change on that machine?
19:04:21  <bnoordhuis>tjfontaine: fwiw, i always use the version of gyp that's bundled with master
19:06:09  <piscisaureus_>othiym23: I think my task plans and "your" async listener are much closer than I initially suspected
19:06:27  <piscisaureus_>othiym23: however I think you are going to run into problems when people use flow control libraries or do connection pooling
19:06:49  <piscisaureus_>because you can't reliably track contexts when users implement callback mechanisms on their own
19:08:30  <MI6>libuv-node-integration: #250 UNSTABLE smartos-x64 (7/644) http://jenkins.nodejs.org/job/libuv-node-integration/250/
19:09:25  * TooTallNatequit (Read error: Connection reset by peer)
19:16:40  * TooTallNatejoined
19:18:47  * loladirojoined
19:19:07  * loladiroquit (Client Quit)
19:19:54  * qmx_joined
19:21:09  * bnoordhuisquit (Ping timeout: 248 seconds)
19:21:10  * ingmar5joined
19:21:49  * lucabjoined
19:24:12  * roxlu_joined
19:24:20  * niska`joined
19:24:29  * vptrjoined
19:26:07  * mburns_joined
19:27:10  * creationix_joined
19:27:16  * Damn3dquit (*.net *.split)
19:27:18  * niskaquit (*.net *.split)
19:27:21  * mburnsquit (*.net *.split)
19:27:21  * creationixquit (*.net *.split)
19:27:22  * roxluquit (*.net *.split)
19:27:22  * KiNgMaRquit (*.net *.split)
19:27:22  * qmxquit (*.net *.split)
19:27:24  * kaesoquit (*.net *.split)
19:27:24  * lucabchanged nick to kaeso
19:27:31  <indutny>http://plasmasturm.org/log/6debug/
19:27:33  * qmx_changed nick to qmx
19:27:39  * creationix_changed nick to creationix
19:28:21  <piscisaureus_>7. Who did that?
19:28:50  * loladirojoined
19:31:09  * Damn3djoined
19:32:51  * loladiroquit (Client Quit)
19:33:54  * loladirojoined
19:35:19  * loladiroquit (Client Quit)
19:36:08  * piscisaureus_quit (Ping timeout: 240 seconds)
19:37:18  * loladirojoined
19:37:33  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
19:37:52  * loladiroquit (Client Quit)
19:41:28  * EhevuTovjoined
19:49:04  * defunctzombie_zzchanged nick to defunctzombie
19:49:49  * AvianFluquit (Remote host closed the connection)
20:03:06  <othiym23>aw, I was gonna tell Bert that so far EventEmitters have been a huge pain in my ass but that control flow libraries have been fine
20:03:30  <othiym23>as long as they're using CPS at some level, the asyncListener library works fine
20:03:48  <othiym23>and I now have .bindEmitter on CLS to deal with the EventEmitter case
20:03:56  * julianduquejoined
20:04:02  <othiym23>it would be nice to have that in the asyncListener API somehow, even though it's not really async
20:14:52  * kazuponjoined
20:17:20  * defunctzombiechanged nick to defunctzombie_zz
20:21:38  * Benviejoined
20:22:06  * kazuponquit (Ping timeout: 245 seconds)
20:25:05  * bradleymeckquit (Quit: bradleymeck)
20:26:16  * julianduquequit (Ping timeout: 246 seconds)
20:27:14  * julianduquejoined
20:30:48  * vptrquit (Ping timeout: 240 seconds)
20:31:51  * bnoordhuisjoined
20:36:02  * bradleymeckjoined
20:39:15  <trevnorris>othiym23: yeah. emitters aren't going into asyncListener. though emitters are on my plate.
20:39:16  <trevnorris>read the first "experimental" task here: https://github.com/joyent/node/issues/6252
20:39:24  <trevnorris>(it's been updated since you've probably last read it)
20:41:30  <othiym23>trevnorris: my use case is pretty much people using EEs in their own code, but yeah, that looks nice for core
20:47:51  <trevnorris>othiym23: it almost hurts to say that this actually helped. https://gist.github.com/trevnorris/6784855
20:48:13  <othiym23>hahaha
20:48:15  <othiym23>see!
20:49:11  * kazuponjoined
20:51:44  <trevnorris>indutny: so yeah, here's the long trace of that strange message passing a value to the nextTick callback: https://gist.github.com/trevnorris/6784855
20:53:26  * kazuponquit (Ping timeout: 240 seconds)
20:53:30  <trevnorris>ah, it might be because onend() in _stream_duplex does a fn.bind()
20:54:26  <indutny>trevnorris: ok, good :)
20:55:58  <trevnorris>indutny: ah yeah. now I see it. Socket#end expects arguments, but also passed to nextTick.
20:57:06  <othiym23>trevnorris: so is that third parameter to after a permanent addition?
20:57:44  <indutny>trevnorris: I'm not really sure what's the problem here, actualy
20:57:47  <indutny>actually*
20:57:59  <indutny>trevnorris: what's wrong with fn.bind()?
20:58:03  <indutny>aaah
20:58:10  <indutny>you mean that stack trace is a bit misleading?
20:58:13  <indutny>or what?
20:58:19  <trevnorris>indutny: oh, nothing in core. it's from a change i'm introducing to pass the "this" as the function argument on a nextTick callback.
20:58:28  <indutny>ok
20:58:31  <othiym23>just like how Java does it!
20:58:43  <othiym23> /bait
20:58:59  <trevnorris>othiym23: if you say that again, i'm going to destroy this PR :P
20:59:07  <othiym23>but...
20:59:11  <othiym23>I'll be good!
20:59:41  * othiym23has been writing Java since 1995, fwiw
21:00:00  <trevnorris>seriously. someone in an issue told me my javascript was java-y. made my eyes bleed.
21:00:26  <othiym23>he's just as obnoxious about half the time on the Google group, I wouldn't take it personally
21:15:27  * vptrjoined
21:17:47  * bnoordhuisquit (Ping timeout: 240 seconds)
21:23:34  <tjfontaine>ircretary: tell bnoordhuis no, libuv-gyp clones the git repo just like it does on windows builds, so any changes are upstream
21:23:34  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
21:24:14  <trevnorris>tjfontaine: i'm doing a ll_prof output, and see "156258 24.6% //anon-35"
21:24:19  <trevnorris>do you know what the "anon" is?
21:26:12  <tjfontaine>I don't, but I would imagine unamed I guess?
21:26:18  <tjfontaine>a specific one
21:28:26  * bradleymeckquit (Quit: bradleymeck)
21:29:41  <trevnorris>tjfontaine: yeah. it says "ticks per library" so. eh, whatever.
21:29:42  * vptrquit (Ping timeout: 252 seconds)
21:30:19  <trevnorris>just did an ll_prof of http_simple. #1 result: 32574 5.1% LazyCompile:*exports._unrefActive timers.js:471
21:30:26  <trevnorris>wtf is going on there
21:30:56  <tjfontaine>is there anything above the stack there?
21:31:45  <trevnorris>no. did a flat output. i'll reprocess
21:40:38  <trevnorris>really wish this python parsing script could use more than one core.
21:40:43  <trevnorris>these dumps are huge.
21:42:31  <octetcloud>trevnorris: "your code looks like java" is the node equivalent of "your mother wears army boots". that guy's comments were so off the wall, they veered into funny
21:42:56  <octetcloud>where are you nextTick context passing changes? they sound interesting, I'd like to take a look
21:43:16  <othiym23>I'm pretty sure my mom did wear army boots at one point, but it was the late 60s and things were different then
21:43:19  * defunctzombie_zzchanged nick to defunctzombie
21:43:41  <tjfontaine>I presume there were bras being burned as well
21:44:02  <othiym23>not my mom, she's way too nerdy for that
21:44:05  <trevnorris>octetcloud: were on my machine. i've overwritten them already, but the change was simple. it sits on pr6011
21:45:08  <trevnorris>mother effin. remind me never to raw output the disassembly of a large javascript dump. totally useless.
21:46:04  <othiym23>at some point I should clean up and publish my scripts for dealing with --trace-all output
21:46:10  <othiym23>they make it almost useful!
21:46:13  <othiym23>for short tracing sessions!
21:46:50  <tjfontaine>heh
21:47:02  <tjfontaine>I would love to see the output
21:47:18  <othiym23>mostly I just reduce and collate some
21:47:53  <othiym23>with some stitching up of things that are related by context (sorta post hoc transaction tracing, but it's SUPER heuristic and based on all kinds of stupid assumptions about pointer values)
21:49:52  * kazuponjoined
21:50:07  <octetcloud>trevnorris: digging through 6011, looking for an example of how ctx is passed to tick cb, and not finding it
21:50:56  <trevnorris>octetcloud: oh, sorry. that's because I can't do it. in core there are places where a function is passed to a nextTick that also can expect arguments if called normally.
21:50:57  * mikealquit (Quit: Leaving.)
21:51:11  <trevnorris>octetcloud: so it'll take a lot of work to make that functionality useful.
21:52:16  <trevnorris>tjfontaine: so _unrefActive is coming from Socket._writeGeneric net.js:604 and Socket._writev net.js:667
21:54:10  * mikealjoined
21:54:11  <tjfontaine>right
21:54:12  * indexzerojoined
21:54:14  * kazuponquit (Ping timeout: 240 seconds)
21:54:20  <octetcloud>trevnorris: makes sense
21:54:23  * bnoordhuisjoined
21:54:29  <tjfontaine>and below is that it complaining about the list manipulation?
21:55:13  <trevnorris>tjfontaine: not sure. just grabbed a short stack from --prof
21:55:37  <octetcloud>trevnorris: what did it look like? var s = this; nextTick(function(self) { assert(self === s) } )? the current 'this' getting passed down as explicit arg?
21:56:43  <trevnorris>octetcloud: lower level than that. when an async event completes, it comes in through MakeCallback. each async request has a request object associated to it. so I was sending the request object up the chain.
21:58:03  <trevnorris>octetcloud: so it's more than a little confusing to use unless you really understand how the internals work. e.g. in duplex, if you nextTick the "this" is actually "nextTick(function(context) { assert(self === context.owner); });"
22:03:39  <octetcloud>trevnorris: did you consider overriding this, so nextTick(function() { assert(this === context); });
22:04:18  * rendarquit
22:04:28  <trevnorris>octetcloud: no. a .call() on a process.nextTick callback is absolutely a no-go. it's way too hot a path.
22:04:40  <trevnorris>we're talking 300k/sec.
22:05:44  <trevnorris>it's a circular problem. not only does it take longer to execute, it requires more memory, which requires more time from the gc. which also hurts performance. etc. etc.
22:06:29  <octetcloud>ok, thanks for the background. fwiw, it looks useful to me, vaguely similar to how this defaults to something useful for EE listeners. maybe i'll see it sometime.
22:06:33  <trevnorris>tjfontaine: something interesting. for some reason accessing "arguments" from a js fn called from c++, when the function is inline-able makes the function call take 5x's longer.
22:07:22  * mburns_changed nick to mburns
22:08:06  <trevnorris>octetcloud: right now function closures are the only way to get some information to any callback to set{Timeout,Interval,Immediate} and nextTick.
22:08:07  <trevnorris>but the best thing to do is to have the body of the function in a higher scope and pass the values you need as arguments.
22:08:18  <trevnorris>can drastically improve performance.
22:08:32  <trevnorris>(for hot paths, of course) :)
22:20:42  <octetcloud>/help whois
22:25:43  * bnoordhuisquit (Ping timeout: 260 seconds)
22:25:52  * paddybyersjoined
22:27:13  <trevnorris>well, this sucks. there's some anonymous function for http that has 954 goto's and a graph like i've never seen. and it has 15 variables apparently. where is this thing?
22:27:42  * Kakeraquit (Ping timeout: 264 seconds)
22:28:11  <tjfontaine>client or server
22:28:40  <trevnorris>tjfontaine: must be server. ran irhydra output against benchmark/http_simple.js
22:28:59  * rblankjoined
22:29:04  * paddybyersquit (Client Quit)
22:34:09  <tjfontaine>here's one for you trevor
22:34:14  <tjfontaine>Path: pummel/test-next-tick-loops-quick
22:34:15  <tjfontaine>FATAL ERROR: JS Allocation failed - process out of memory
22:34:25  <trevnorris>fun. one sec.
22:37:42  <othiym23>trevnorris: updated and cleaned up the polyfill to match your latest changes: https://github.com/othiym23/async-listener/blob/master/glue.js
22:37:47  <othiym23>the polyfill is looking pretty terse right now
22:44:48  <trevnorris>tjfontaine: that test is useless. nextTick now completely drains the queue. they've created an infinitely recursive while(), and tickDone() doesn't run until all callbacks are run.
22:44:59  <trevnorris>tjfontaine: so, the nextTickQueue fills to maximum capacity.
22:45:15  <trevnorris>this case is why setImmediate was created.
22:45:28  <tjfontaine>nod
22:45:32  <tjfontaine>I am just saying
22:45:34  <tjfontaine>we don't run our tests.
22:45:48  <trevnorris>hah, yeah.
22:46:07  <trevnorris>tjfontaine: you doing some cleanup? or just checking our tests?
22:46:37  <tjfontaine>trying to make sure our existing failures aren't covered by some test we're just not fucking running
22:47:44  <trevnorris>othiym23: i'm impressed you were able to emulate it so well.
22:48:26  <trevnorris>tjfontaine: yeah... i feel like our tests need to be cleaned up before the v1.0 release.
22:48:28  * c4miloquit (Remote host closed the connection)
22:48:44  <tjfontaine>I'm going to change make test, to make test-all
22:49:06  * indexzeroquit (Quit: indexzero)
22:49:07  <tjfontaine>then we can make it a pre-commit hook
22:49:08  <othiym23>trevnorris: it's easy, as long as you don't care about promiscuously creating closures everywhere
22:49:10  <trevnorris>um. doesn't make test-all also run test-valgrind?
22:49:21  <trevnorris>hahaha
22:49:36  <othiym23>trevnorris: if you reload glue.js, I even did something really gutwrenching to get the domains into the error handlers
22:49:39  <tjfontaine>no, test-all is not valgrind
22:49:47  <othiym23>I'm confident it will work almost 100% of the time, but it sure looks gross
22:50:03  <tjfontaine>test-all is equivalent to `python tools/test.py --mode=debug,release`
22:50:32  * kazuponjoined
22:53:36  <trevnorris>tjfontaine: one thing that annoys me is that make bench* is always slower and more variant than just running the benchmarks by hand.
22:53:53  <tjfontaine>fix it :)
22:54:00  <othiym23>lol
22:54:47  <trevnorris>tjfontaine: not sure if you remember, but I spent 2 weeks writing one. then isaac replaced it with one he wrote over the weekend.
22:54:57  * kazuponquit (Ping timeout: 252 seconds)
23:02:35  * hzquit
23:05:12  <tjfontaine>trevnorris: well it's just software, we can make it better :)
23:14:41  * rblankquit (Quit: leaving)
23:34:42  * kazuponjoined
23:40:23  * kazuponquit (Ping timeout: 260 seconds)