00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:23  * c4miloquit (Ping timeout: 272 seconds)
00:05:22  * c4milojoined
00:06:09  * c4miloquit (Read error: Connection reset by peer)
00:06:18  * c4milojoined
00:10:30  * dshaw_joined
00:18:14  * defunctzombie_zzchanged nick to defunctzombie
00:22:58  * brsonjoined
00:24:45  * c4miloquit (Remote host closed the connection)
00:29:28  * dshaw_quit (Ping timeout: 240 seconds)
00:31:21  * luxigo_quit (Ping timeout: 252 seconds)
00:40:05  * dshaw_joined
00:47:12  * amartensjoined
00:51:08  * amartensquit (Ping timeout: 240 seconds)
00:57:57  * kazuponjoined
01:00:57  * superjoequit (Read error: Connection reset by peer)
01:07:56  * superjoejoined
01:17:00  * brsonquit (Ping timeout: 252 seconds)
01:19:01  * brsonjoined
01:24:02  <wolfeidau>othiym23: are you using the weak module atm?
01:32:22  * mikealjoined
01:33:06  * mikealquit (Client Quit)
01:33:39  * loladirojoined
01:36:49  <othiym23>wolfeidau: nope, I'm restricted to straight-up ES5 for my work-work, which is bleeding over into my non-work-work
01:37:06  <othiym23>I just play around with WeakMaps / --harmony to keep up to date with ES6
01:38:22  * abraxasjoined
01:47:28  * inolenjoined
01:48:48  * inolenquit (Client Quit)
01:52:00  * paddybyersquit (Quit: paddybyers)
01:56:29  * c4milojoined
02:01:16  * c4miloquit (Ping timeout: 245 seconds)
02:07:22  * dshaw_quit (Quit: Leaving.)
02:26:57  * brsonquit (Quit: leaving)
02:27:04  * c4milojoined
02:43:00  * dshaw_joined
02:46:07  <trevnorris>so close to having domains completely removed from core.
02:50:51  * inolenjoined
02:53:21  * inolenquit (Client Quit)
02:57:06  * amartensjoined
03:01:08  * amartensquit (Ping timeout: 240 seconds)
03:01:40  <groundwater_>\o/
03:03:19  <wolfeidau>othiym23: aha sweet
03:04:42  <wolfeidau>really want to --harmony some time soon :)
03:34:13  * amartensjoined
04:00:48  * c4miloquit (Remote host closed the connection)
04:02:05  * piscisaureus_joined
04:02:42  <piscisaureus_>ircretary: notes
04:02:49  <piscisaureus_>ircretary: tell trevnorris I don't think WeakObject should inherit from AsyncWrap
04:02:49  <ircretary>piscisaureus_: I'll be sure to tell trevnorris
04:03:04  <trevnorris>piscisaureus_: bite me :P
04:03:16  <piscisaureus_>trevnorris: still awake huh
04:03:30  <trevnorris>yeah. only 9 here.
04:03:39  <piscisaureus_>oh right
04:04:00  <piscisaureus_>trevnorris: WeakObjects dont make callbacks, atleast not always
04:04:17  <piscisaureus_>trevnorris: I now get the ListenerCallback for ContextifyScript every time I require a native module
04:09:18  <piscisaureus_>trevnorris: we might need ObjectWrap back for that :-p
04:09:23  <piscisaureus_>or duplicate code
04:09:40  * kazuponquit (Remote host closed the connection)
04:10:09  * kazuponjoined
04:10:36  * defunctzombiechanged nick to defunctzombie_zz
04:14:39  * kazuponquit (Ping timeout: 252 seconds)
04:19:39  <trevnorris>piscisaureus_: think you can give me a break there. i've been working on hooks for your tasks thing, and think I have an implementation that'll work.
04:20:30  <piscisaureus_>trevnorris: sure I can give you a break :)
04:23:10  <trevnorris>piscisaureus_: the basics are, you can create an AsyncWrapScope type thing, and keep a double linked list of all the classes within that scope. any new instantiated class in that scope will be added to the list, and removed when in the destructor.
04:23:45  <trevnorris>piscisaureus_: also AsyncWrap will have a virtual member like AsyncWrap::CleanMeUp() or some such that when a scope is destroyed it'll run through the list and call on every existing class.
04:24:33  <piscisaureus_>trevnorris: kewl. I have something like that now. Although I can't access the AsyncWrap from the listener cb
04:24:44  <piscisaureus_>trevnorris: right now I'm just adding reference counts
04:24:52  <trevnorris>yeah. i'm meaning to put a hook in for that for the 6011 pr
04:24:56  <trevnorris>so you don't have to wait.
04:25:06  <piscisaureus_>trevnorris: nice
04:25:28  <piscisaureus_>trevnorris: I have a patch that adds a final argument to 'before' and 'after', namely isFinal
04:25:43  <piscisaureus_>isFinal == true when the callback is a handle_wrap.close callback or any req_wrap callback
04:26:21  <piscisaureus_>trevnorris: async_wrap and weak_object are not good friends because there is no deterministic destructor for weak objects
04:26:50  <piscisaureus_>this is really only an issue for zlib::ZCtx and crypto::Hmac and maybe some
04:28:25  <trevnorris>piscisaureus_: I see what you're saying. my reason for choosing WeakObject was because it already needs to store fields like Environment and the Persistent.
04:28:45  <piscisaureus_>trevnorris: I understand :)
04:28:46  <trevnorris>didn't want to have to add duplicate code for some of that stuff
04:28:56  <piscisaureus_>trevnorris: we could add a base class for that though (ObjectWrap anyone?)
04:29:06  <trevnorris>already had to for ssl, it has an ->ssl_env() since I couldn't get around the code duplication.
04:30:17  <piscisaureus_>trevnorris: the real issue is I think that ZCtx and a couple of these crypto functions should not rely on Weak callbacks
04:30:33  <piscisaureus_>trevnorris: so I need to fiddle some code in that makes their end predictable
04:31:25  <trevnorris>piscisaureus_: ok. i'm interested to see what you have. one of my thoughts was that AsyncWrap would be inherited from classes that do _anything_ async, regardless of whether they call MakeCallback
04:31:26  <piscisaureus_>oh and StatWatcher too
04:32:07  <piscisaureus_>trevnorris: that's okay as long as these classes have some sort of end to them
04:32:17  <piscisaureus_>trevnorris: but that is not the case for e.g. ContextifyScript
04:38:50  * abraxasquit (Remote host closed the connection)
04:41:07  <trevnorris>piscisaureus_: got it.
04:41:47  <trevnorris>piscisaureus_: well, I'm in the middle of a serious Halo match. let me know more of what you find, and we'll work out the best way to implement those hooks.
04:41:59  <trevnorris>I do think we can get that in 6011
04:42:35  <piscisaureus_>trevnorris: the only actual problem is for StatWatcher and ZCtx. The other classes that derive from WeakObject don't actually use MakeWeak/ClearWeak
04:42:44  <piscisaureus_>trevnorris: so they can just inherit from AsyncWrap
04:42:51  <piscisaureus_>trevnorris: ok, go back shooting!
04:42:58  <piscisaureus_>trevnorris: have fun
04:43:03  <trevnorris>piscisaureus_: awesome. good to know. thanks :)
04:46:08  <othiym23>meanwhile I finally have EventEmitters working more or less correctly with CLS
04:46:21  <othiym23>monkeypatching EEs is not a straightforward task
04:46:27  <othiym23>https://github.com/othiym23/shimmer/blob/master/index.js#L86-L189
04:50:08  <loladiro>Hey piscisaureus_, I'm getting a handle_queue node who's pref and next are equal. That's not valid, right?
04:50:16  <loladiro>*prev
04:50:42  <piscisaureus_>loladiro: that means that the linked list is empty I think
04:50:52  <loladiro>It's not though
04:51:21  <loladiro>There's a like like A -> B -> C -> D -> C -> D etc
04:51:36  <piscisaureus_>loladiro: yup that looks off indeed
04:52:06  <piscisaureus_>loladiro: but is it singly linked? Can you check the back references too?
04:52:15  <loladiro>let me check
04:52:34  <piscisaureus_>because in the above picture I want to know what C.prev is
04:52:55  <loladiro>C.prev is B
04:53:33  * kazuponjoined
04:53:58  <loladiro>Ok, going from A backwards I eventually get to D, but that's fine since C.prev is B
05:13:38  * abraxasjoined
05:26:39  * defunctzombie_zzchanged nick to defunctzombie
05:31:53  * Kakera_joined
05:34:50  * dshaw_quit (Quit: Leaving.)
05:42:33  * AvianFluquit (Remote host closed the connection)
05:43:02  * AvianFlujoined
05:47:30  * AvianFluquit (Ping timeout: 245 seconds)
06:00:08  * Kakera_quit (Ping timeout: 240 seconds)
06:05:45  * dshaw_joined
06:12:46  * dshaw_quit (Read error: Connection reset by peer)
06:13:03  * dshaw_joined
06:16:23  * FROGGSjoined
06:17:16  * loladiroquit (Quit: loladiro)
06:17:41  * dshaw_quit (Ping timeout: 272 seconds)
06:20:51  * defunctzombiechanged nick to defunctzombie_zz
06:38:06  * mikealjoined
06:40:47  * inolenjoined
06:41:07  <MI6>nodejs-v0.10-windows: #291 UNSTABLE windows-ia32 (11/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/291/
06:42:16  * mikealquit (Ping timeout: 245 seconds)
06:43:49  * mikealjoined
07:03:54  * dshaw_joined
07:08:37  * dshaw_quit (Ping timeout: 272 seconds)
07:12:49  * rendarjoined
07:54:54  * luxigo_joined
07:55:53  * paddybyersjoined
08:01:22  <indutny>morning
08:01:25  <indutny>sleepies
08:01:26  <indutny>:)
08:01:32  <indutny>piscisaureus_: how are you?
08:03:57  <piscisaureus_>indutny: hey
08:04:09  <piscisaureus_>indutny: I'm doing good. What about yourself?
08:04:15  <indutny>good too :)
08:04:38  * dshaw_joined
08:08:57  * dshaw_quit (Ping timeout: 252 seconds)
08:28:02  * inolenquit (Quit: Leaving.)
08:32:35  * luxigo_quit (Ping timeout: 272 seconds)
08:44:06  * amartensquit (Quit: Leaving.)
08:45:13  * kazuponquit (Remote host closed the connection)
08:45:39  * kazuponjoined
08:50:00  * kazuponquit (Ping timeout: 245 seconds)
08:53:50  * kazuponjoined
09:05:26  * dshaw_joined
09:06:17  * kazuponquit (Remote host closed the connection)
09:06:44  * kazuponjoined
09:10:18  * dshaw_quit (Ping timeout: 268 seconds)
09:11:08  * kazuponquit (Ping timeout: 240 seconds)
09:11:22  * dshaw_joined
09:12:11  * inolenjoined
09:16:01  * dshaw_quit (Ping timeout: 272 seconds)
09:21:29  * kazuponjoined
09:30:54  * hzjoined
09:36:33  * bnoordhuisjoined
09:47:43  * mralephquit (Read error: Connection reset by peer)
09:47:46  * mraleph1joined
09:52:34  * inolenquit (Quit: Leaving.)
09:58:50  * inolenjoined
10:02:49  <indutny>bnoordhuis: morning
10:03:00  <bnoordhuis>indutny: hey
10:03:08  <indutny>bnoordhuis: how are you?
10:03:37  <bnoordhuis>same old. we're having an autumn storm here
10:03:51  <indutny>ouch
10:04:11  <bnoordhuis>oh, it's not that bad. the house is still standing
10:04:12  <indutny>bnoordhuis: https://www.google.ru/search?q=autumn+storm&newwindow=1&source=lnms&tbm=isch&sa=X&ei=kTZuUvSxAuXd4QSRjYGYAw&ved=0CAcQ_AUoAQ&biw=1439&bih=751 ?
10:04:21  <indutny>which one of images represent it
10:04:22  <indutny>:)
10:04:53  <bnoordhuis>i see lots of bad art
10:05:05  <indutny>bnoordhuis: ok
10:05:26  <bnoordhuis>that's search bubble for you, eh?
10:05:36  <bnoordhuis>*bubbles
10:06:06  <indutny>yeah
10:06:07  <indutny>so
10:06:08  <indutny>bnoordhuis: so here are some stuff from me for you today: https://github.com/joyent/libuv/pull/971, https://github.com/joyent/libuv/pull/965, https://github.com/joyent/libuv/pull/970
10:07:08  <indutny>bnoordhuis: btw, I've finally managed to organize my inbox in gmail
10:07:23  <indutny>bnoordhuis: added "Top Priority" and "In-progress" tags to inbox overview
10:07:31  <bnoordhuis>very good. i see you're commenting on github issues too now
10:07:39  <indutny>haha
10:07:44  <indutny>yeah, I've more visibility now
10:11:16  * Kakera_joined
10:12:06  * dshaw_joined
10:16:21  * inolenquit (Quit: Leaving.)
10:16:27  * dshaw_quit (Ping timeout: 248 seconds)
10:25:34  * kazuponquit (Remote host closed the connection)
10:26:03  * kazuponjoined
10:29:26  * inolenjoined
10:30:19  * kazuponquit (Ping timeout: 246 seconds)
10:34:59  <indutny>bnoordhuis: want me to review anything?
10:35:20  <indutny>bnoordhuis: also, how is your deffering-events-in-kqueue.c fix going?
10:36:20  <bnoordhuis>indutny: you mean review any of my patches? i don't think i have anything
10:36:26  <indutny>yeah
10:36:31  <indutny>what are you working on then?
10:36:39  <bnoordhuis>'tis a secret
10:36:40  <indutny>reviewing other people's stuff? :)
10:36:42  <indutny>aaah
10:36:42  <indutny>ok
10:37:03  <bnoordhuis>not really, just looking into instrumenting v8, maybe exposing some cpu/profiler hooks in node, etc.
10:37:45  <bnoordhuis>also, i'm trying to wrap my head around how you'd use generators to create e.g. a streaming parser
10:38:45  <bnoordhuis>it's not really clicking for me just yet. i guess i should shake off the notion that generators are real continuations
10:40:50  <indutny>haha
10:40:57  <indutny>just yield in right places
10:41:29  <indutny>btw, what really make me curious
10:41:41  <indutny>is how this thing is working with underlying C++ stack
10:41:53  <indutny>isn't possible for generators to pass through JS-C++ boundary?
10:42:18  <bnoordhuis>not sure what you mean
10:42:35  <bnoordhuis>they're ordinary functions in most respects. a generator can call into c++ land, no problem
10:42:47  <indutny>but can it call yield from C++ callback?
10:42:59  <indutny>I guess it should be invoked in the scope of function, not callback, right?
10:43:09  <bnoordhuis>oh, like that. yeah, yielding like that works
10:43:22  <indutny>hm...
10:43:35  * indutnyis going to read a bit more on generators
10:43:37  <bnoordhuis>i wonder what return value c++ land sees though
10:43:45  <indutny>indeed
10:43:59  <indutny>ah
10:44:05  <indutny>you can't call yield from callback
10:44:06  <indutny>ok
10:44:47  <bnoordhuis>let me do a quick test
10:45:03  <indutny>hm...
10:46:38  <indutny>it seems that you can write `yield ` only in `function*`
10:46:43  <indutny>basically in generator's scope
10:46:53  <bnoordhuis>yes
10:47:08  <indutny>aaaah
10:47:08  <bnoordhuis>i guess they're basically shallow continuations
10:47:12  <indutny>it should be the other way
10:47:19  <indutny>iterator.next() should be called
10:47:25  <indutny>once async action is done
10:47:36  <indutny>so all async stuff should be happening out of the iterator
10:48:02  <rendar>indutny: basically with generators you save the actual state of a function, snapshotting it :)
10:48:36  <indutny>rendar: indeed
10:48:54  <indutny>I was just trying to figure out how deep this snapshot it
10:48:57  <indutny>s/it/is/
10:49:01  <indutny>and its totally shallow
10:49:25  <rendar>yeah
10:49:47  <rendar>the deepets form of that are continuations in Scheme, iirc
10:50:03  <MI6>nodejs-v0.10: #1566 UNSTABLE smartos-x64 (5/603) smartos-ia32 (5/603) osx-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1566/
10:50:48  <indutny>yeah, iterators are not continuations at all
10:50:59  <indutny>it would be rather interesting to have continuations in JS
10:51:08  <indutny>but that might cause some trouble in C++ backend
10:51:20  <indutny>since it'll need to store stack
10:52:39  <bnoordhuis>well, generators do store (parts of) the call stack
10:53:00  <bnoordhuis>the implementation in v8 is quite interesting btw, you should take a look sometime
10:55:37  <indutny>I'll definitely do
10:55:41  <indutny>bnoordhuis: parts
10:55:50  <indutny>bnoordhuis: what are you talking about?
10:55:51  <indutny>:)
10:56:05  <indutny>bnoordhuis: I can't see any parts of call stack that are preserved
10:56:20  <indutny>what I really see
10:56:29  <bnoordhuis>is dead people?
10:56:31  <indutny>is that it does almost the same as splitting one function into multiple
10:56:39  <bnoordhuis>or that
10:56:58  <bnoordhuis>you have composing yield a.k.a. yield*
10:57:00  <indutny>https://github.com/indutny/spoon
10:57:05  <indutny>hm?
10:57:06  <indutny>yiled*
10:57:09  <indutny>yield*
10:57:13  <bnoordhuis>it's like python 3's yield from
10:57:21  <indutny>I don't really use python that much
10:57:25  <indutny>where can I read about it?
10:57:36  <bnoordhuis>that is, function f calls generator A which yields to generator B which yields to f
10:57:43  <indutny>ah
10:57:45  <indutny>just found it
10:57:49  <bnoordhuis>because B calls yield* instead of yield
10:58:09  <indutny>so, its recursion for iterators, right?
10:58:18  <bnoordhuis>yeah
10:58:33  <bnoordhuis>you could implement e.g. trampoline-based recursion that way
10:59:11  <bnoordhuis>well, in that particular example you don't strictly need yield*, i guess
10:59:23  <indutny>haha
10:59:26  <indutny>well
10:59:41  <indutny>still it should be the same as splitting function in multiples
10:59:49  <indutny>with some JS-API hacks on top of it
10:59:53  <indutny>let me look at the source
11:00:02  <bnoordhuis>yeah, but the idea is that you can compose generators
11:00:13  <bnoordhuis>so A doesn't have to know about B and vice versa
11:00:17  <indutny>I see
11:02:48  <indutny>god, v8 takes much longer to clone since last year :P
11:05:17  <bnoordhuis>hm, two people killed by falling trees in amsterdam
11:05:40  <bnoordhuis>guess i'll stay indoor today
11:05:42  <FROGGS>O.o
11:06:56  <mmalecki>bnoordhuis: I saw one crack down on my way to the office, it didn't kill anyone tho
11:07:46  <bnoordhuis>mmalecki: you're in amsterdam now or?
11:07:52  <mmalecki>bnoordhuis: yes
11:08:08  <indutny>bnoordhuis: so
11:08:12  <indutny>bnoordhuis: I took a look at v8
11:08:17  <indutny>bnoordhuis: its indeed pretty nice
11:08:21  <indutny>bnoordhuis: and very simple
11:08:24  <bnoordhuis>mmalecki: be careful then
11:08:43  <mmalecki>bnoordhuis: yup, staying inside. how's it in Benland?
11:09:23  <bnoordhuis>mmalecki: stormy :) a friend of mine got a tree on his (parked) car earlier today
11:09:44  <mmalecki>oh shit. you watch out too :)
11:10:00  <indutny>bnoordhuis: hope his car was insured
11:10:01  <bnoordhuis>yeah. i'll probably hold off on doing groceries until tomorrow
11:10:18  <indutny>bnoordhuis: http://www.dontstarvegame.com/
11:10:32  <bnoordhuis>indutny: don't worry, i'm stocked up on beer so i'm good
11:10:44  <indutny>you can always order delivery
11:10:46  <indutny>anyway :P
11:10:50  <bnoordhuis>yeah, true :)
11:11:01  <bnoordhuis>so generators, yes, they're quite nice
11:11:12  <bnoordhuis>too bad v8 won't optimize if it sees them
11:11:29  <bnoordhuis>that will probably get better in the fullness of time though
11:12:09  <indutny>bnoordhuis: haha
11:12:14  <indutny>bnoordhuis: perhaps
11:12:24  <indutny>though, I see few obstacles on this way
11:12:47  <indutny>but they definitely are solvable
11:12:53  * dshaw_joined
11:17:08  * dshaw_quit (Ping timeout: 240 seconds)
11:22:52  * Rabenklauejoined
11:37:16  * Kakera_quit (Ping timeout: 245 seconds)
11:54:18  * `3rdEdenchanged nick to `3E|DOING|THINGS
11:54:19  * `3E|DOING|THINGSchanged nick to `3E|AFK
11:54:22  * `3E|AFKchanged nick to `3E|DOING|THINGS
12:13:40  * dshaw_joined
12:17:48  * dshaw_quit (Ping timeout: 240 seconds)
12:35:33  * `3E|DOING|THINGSchanged nick to `3rdEden
12:50:21  * inolenquit (Quit: Leaving.)
13:05:43  * stagasjoined
13:08:51  * AvianFlujoined
13:14:23  * dshaw_joined
13:18:08  * loladirojoined
13:18:45  * dshaw_quit (Ping timeout: 245 seconds)
13:23:09  * abraxasquit (Remote host closed the connection)
13:25:28  * abraxasjoined
13:37:07  * abraxasquit (Remote host closed the connection)
13:47:59  * Rabenklauequit (Ping timeout: 262 seconds)
13:55:05  * loladiroquit (Quit: loladiro)
13:55:07  * stagasquit (Read error: Connection reset by peer)
14:04:38  * pachetjoined
14:04:38  * pachetquit (Changing host)
14:04:38  * pachetjoined
14:04:52  * AvianFluquit (Remote host closed the connection)
14:05:21  * AvianFlujoined
14:10:12  * AvianFluquit (Ping timeout: 265 seconds)
14:15:08  * dshaw_joined
14:17:39  * pachetquit (Quit: leaving)
14:20:01  * dshaw_quit (Ping timeout: 272 seconds)
14:20:36  * bnoordhuisquit (Ping timeout: 245 seconds)
14:45:57  * Kakera_joined
14:46:46  * bnoordhuisjoined
14:48:04  * `3rdEdenchanged nick to `3E|BRB
14:50:34  * pachetjoined
14:52:42  * inolenjoined
14:55:20  * AvianFlujoined
14:55:23  * bnoordhuisquit (Ping timeout: 272 seconds)
15:00:25  * `3E|BRBchanged nick to `3rdEden
15:02:41  * AvianFlu_joined
15:03:23  * bnoordhuisjoined
15:04:33  * hzquit
15:05:53  * AvianFluquit (Ping timeout: 272 seconds)
15:06:40  * loladirojoined
15:07:15  * loladiroquit (Client Quit)
15:10:08  * loladirojoined
15:15:52  * dshaw_joined
15:15:55  * AvianFlu_changed nick to AvianFlu
15:17:21  <MI6>joyent/node: Ben Noordhuis master * 4c0195e : http: remove MethodToString() (+1 more commits) - http://git.io/JO21BA
15:20:46  * dshaw_quit (Ping timeout: 265 seconds)
15:21:07  <MI6>nodejs-master: #644 UNSTABLE osx-x64 (1/651) smartos-ia32 (5/651) smartos-x64 (8/651) http://jenkins.nodejs.org/job/nodejs-master/644/
15:26:12  * pachetquit (Ping timeout: 252 seconds)
15:27:26  <MI6>nodejs-master-windows: #437 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/437/
15:32:06  * pachetjoined
15:32:12  * pachetquit (Changing host)
15:32:12  * pachetjoined
15:34:46  * kazuponjoined
15:37:38  <MI6>nodejs-master: #645 UNSTABLE osx-x64 (1/652) smartos-ia32 (5/652) smartos-x64 (11/652) http://jenkins.nodejs.org/job/nodejs-master/645/
15:37:48  * abraxasjoined
15:42:26  * abraxasquit (Ping timeout: 240 seconds)
15:44:03  <isaacs>good morning
15:47:54  <bnoordhuis>morning isaac
15:49:54  <MI6>joyent/node: isaacs master * 3c5ea41 : vm: Copy missing properties from context - http://git.io/pP-w0w
15:50:04  <isaacs>bnoordhuis: thanks for the review ^
15:50:19  <isaacs>bnoordhuis: hopefully Domenic_ or I can get around to making that irrelevant before 0.12
15:50:26  * dshaw_joined
15:50:54  <isaacs>now to figure out wtf i was doing before noticing that uglify was broken...
15:53:02  <bnoordhuis>isaacs: seen this? -> https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm
15:53:55  <isaacs>bnoordhuis: yes, a discussion is ongoing in public-webapps
15:53:58  <Domenic_>bnoordhuis: isaacs: yeah we need to kill that.
15:53:59  <isaacs>about this very thing
15:54:07  <Domenic_>i just havne't had the time to make the counterproposal
15:54:07  <isaacs>bnoordhuis: it's pretty much everything wrong.
15:54:16  <Domenic_>isaacs: it's revamped as of this morning
15:54:32  <isaacs>https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm#error-uris_for_streams
15:54:35  <isaacs>??
15:54:40  <isaacs>why does a stream need a uri?
15:54:55  <isaacs>we don't have uris for dom nodes, event emitters, javascript objects, etc.
15:55:00  * dshaw_quit (Ping timeout: 245 seconds)
15:55:54  * mcavagejoined
15:56:49  <isaacs>in principle, i think a non-event-emitter-bound, easy-to-use, easy-to-extend, consistent data streaming interface for the browser would be fucking FANTASTIC
15:57:15  <isaacs>and it'd probably even be worth the arduous task of migrating Node to that pattern, once established in the browser.
15:57:26  <isaacs>(or making Node streams interop with them, whatever, who knows)
15:57:39  <isaacs>but they have to solve actual problems, and not just be api wankery
15:57:47  * amartensjoined
15:59:25  * octetcloudjoined
16:00:11  <MI6>nodejs-master-windows: #438 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/438/
16:00:22  <bnoordhuis>weird. i have this benchmark that doesn't complete when --prof is given on the command line
16:00:47  <bnoordhuis>when i strace it, eventually node stops doing anything but sending SIGPROFs from the profiler thread to the main thread
16:01:26  <bnoordhuis>and the occassional write(9, "code-creation,LoadPolymorphicIC,"..., 62) = 62
16:01:38  <bnoordhuis>and futex syscall...
16:01:50  * hueniverse1joined
16:02:11  * c4milojoined
16:04:06  <MI6>nodejs-master: #646 UNSTABLE osx-x64 (1/654) smartos-ia32 (6/654) linux-x64 (1/654) smartos-x64 (8/654) osx-ia32 (3/654) linux-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/646/
16:05:14  * hueniversequit (Ping timeout: 265 seconds)
16:06:00  <Domenic_>isaacs et al: if you push multiple times onto a stream, then call read(cb), should the stream give you back the first chunk you pushed, or a concatenation of all of them? Asking from the perspective of which is lower-level/more aligned with how OS's work.
16:06:34  <bnoordhuis>hrm, i suspect that the v8 profiler has trouble with really deep call stacks
16:11:06  * julianduquejoined
16:15:09  <isaacs>Domenic_: what's read(cb)?
16:15:19  <isaacs>Domenic_: (not being facetious)
16:15:27  <isaacs>Domenic_: well, not very ;)
16:16:06  <Domenic_>isaacs: well from what I remember last time there are two APIs that can be built on top of each other: read(cb) and poll + readCurrentBuffer + state.
16:16:17  <isaacs>my point is that I think there is still an open question of whether to do a) read(cb) (and deal with artificial deferral if data's available now) or b) poll(cb);chunk=read() (and deal with bookkeeping)
16:16:59  <isaacs>i think that the poll/state approach is better, because a push(chunk) can come at any time, so you need *some* sort of state and bookkeeping anyway
16:17:32  <isaacs>but i'm not sure if that's optimized for the pipe() case
16:17:38  <isaacs>streams3 made node's streams much faster.
16:17:53  <isaacs>fast enough to use directly in http, because we skip the bookkeeping when there's a pipe flowing
16:18:04  * sblomjoined
16:18:07  <isaacs>and instead just have push() emit a 'data' event, and do nothing else.
16:18:44  <isaacs>but, anyway, push(a);push(b);read();read();read()
16:18:58  <isaacs>could return either [a+b,null,null] or [a,b,null]
16:19:07  <Domenic_>exactly my question :)
16:19:22  <isaacs>as long as the third one returns null, and the "b" comes after the "a"
16:19:35  <isaacs>in object mode, they're *never* concatenated
16:19:46  <isaacs>and, it'd be nice if streams were less string/buffer specific, i think
16:19:59  <isaacs>ie, skip the concatenation business
16:20:05  <Domenic_>ok I was thinking of that, yes
16:20:14  <Domenic_>it is pretty much the only thing preventing streams from being completely generalized
16:20:16  <isaacs>that means rethinking the watermark stuff, of course.
16:20:20  <Domenic_>hmm
16:20:39  <isaacs>because what does "7 chunks" even mean for your memory water mark?
16:20:51  <isaacs>could be 7x1GB or 7x1b
16:21:31  <piscisaureus_>Promise readPromise = stream.read(1024); <-- Is that ES6 code?
16:21:31  <piscisaureus_>who snug in the types?
16:21:35  <Domenic_>right, tricky.
16:21:36  <hueniverse1>tjfontaine: yt?
16:21:46  <tjfontaine>hueniverse1: hi
16:21:53  <Domenic_>piscisaureus_: nope they're just making syntax errors i guess
16:22:20  <piscisaureus_>I agree with the async read and write
16:22:40  <indutny>heya
16:22:41  <indutny>bnoordhuis: you still there?
16:22:44  <indutny>bnoordhuis: I'll land that proctitle thing in v0.10
16:22:45  <hueniverse1>tjfontaine: back at looking at the memory leak. I am finally able to reproduce it outside production with a very simple test. just takes 10+ hours to notice the trend
16:22:53  <Domenic_>isaacs: but you can do no-concat without perf or memory impacts?
16:22:55  <indutny>bnoordhuis: and then going to do merge
16:22:56  <tjfontaine>hueniverse1: excellent http or https?
16:22:57  <indutny>bnoordhuis: any objections?
16:23:01  <hueniverse1>http
16:23:13  <tjfontaine>hueniverse1: excellent, do you have a gist?
16:23:13  <isaacs>Domenic_: we already don't concat when piping
16:23:25  <piscisaureus_>Domenic_: result.data and result.size and result.eof are kinda unfortunate though. Why not just pass an (array)buffer or a string or null?
16:24:17  <Domenic_>piscisaureus_: that proposal is garbage, i am trying to kill it with a counterproposal
16:24:19  <hueniverse1>tjfontaine: https://gist.github.com/hueniverse/b2da3ab04ed2109652cb
16:24:27  <Domenic_>isaacs: ok cool, makes sense
16:24:28  <tjfontaine>hueniverse1: thanks
16:24:30  <hueniverse1>tjfontaine: over time, this will slowly leak
16:24:43  <isaacs>piscisaureus_: the code is webidl, not javascript/es
16:24:48  <hueniverse1>it's using a single file from hapi: client.js which is a very simple http client wrapper
16:25:05  <isaacs>webidl is a special code that only runs on human brains
16:25:27  <piscisaureus_>isaacs: Example 1 at https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm?
16:25:31  <piscisaureus_>isaacs: doesn't look like it
16:25:35  * kenperkinsjoined
16:25:44  <hueniverse1>tjfontaine: I am going to c/p it and simplify it but the example isn't using much from it. right now I mostly want someone to look and see if I'm doing something obviously stupid.
16:25:47  <tjfontaine>hueniverse1: ok, do you have any cores from this?
16:25:52  <tjfontaine>hueniverse1: ok
16:26:06  <hueniverse1>tjfontaine: nope. I just ran it locally
16:26:13  <piscisaureus_>isaacs: I can tell webidl from js :)
16:26:20  <Domenic_>piscisaureus_: start of a counterproposal at https://gist.github.com/domenic/0c47ae300608341f3d7f but I haven't had time to work on it recently. Gotta pick up the pace this week though in order to counteract this new thing.
16:26:48  <isaacs>piscisaureus_: ohh, hahah, found the bit yor'e referring to
16:26:54  <isaacs>piscisaureus_: yeah, that's copy-pasta, i'm sure
16:27:09  <isaacs>piscisaureus_: but yes, i'm sure that no one ever ran this code.
16:27:20  * TooTallNatejoined
16:27:47  <isaacs>piscisaureus_: implementations are done by mere mortals, once the spec is finished by the esteemed specificationati
16:28:57  <bnoordhuis>indutny: when i remove those #ifdefs in the proctitle patch, everything seems to work okay
16:29:06  <bnoordhuis>indutny: hence my 'probably not needed' comment
16:29:11  <indutny>bnoordhuis: well, I know
16:29:16  <indutny>bnoordhuis: but that's how it is in webkit
16:29:21  <indutny>and chromium is doing the same thing
16:29:28  <indutny>are you on 10.8?
16:29:31  <bnoordhuis>yes
16:29:39  <bnoordhuis>and that's never going to change
16:29:41  <indutny>perhaps it won't work on 10.6 or 10.7?
16:29:49  <indutny>we're still supporting them anyway
16:29:54  <indutny>right?
16:29:55  <bnoordhuis>easy to test
16:29:56  <bnoordhuis>saghul: ping
16:30:08  <saghul>bnoordhuis pong
16:30:16  <bnoordhuis>saghul: can you test something for us on os x 10.6?
16:30:22  <saghul>sure thing
16:30:26  <bnoordhuis>indutny: ^
16:30:41  <indutny>saghul: https://github.com/joyent/libuv/pull/973/files
16:30:51  <indutny>saghul: but assuming that MAC_OS_X_VERSION_10_9 is 1
16:30:57  <indutny>saghul: i.e. with removed ifdefs
16:31:02  <saghul>ok
16:31:11  <bnoordhuis>or by turning the #ifdefs into #ifndefs :)
16:31:13  <saghul>should I check if it compiles, runs the test suite, ?
16:31:17  <bnoordhuis>yes, please
16:31:19  <indutny>saghul: thanks
16:32:13  <indutny>http://www.youtube.com/watch?v=aWN9oqTSs14
16:32:26  <indutny>please turn this music on while doing it
16:34:52  <saghul>compiles
16:35:05  <sblom>indutny: I've found the new soundtrack for today. Thanks
16:35:09  <indutny>haha
16:35:14  <indutny>sblom: you're welcome
16:36:15  <Domenic_>Oh nodejsreactions, so perfect.
16:37:46  * defunctzombie_zzchanged nick to defunctzombie
16:38:06  <saghul>indutny bnoordhuis test pass!
16:38:16  <indutny>saghul: thanks
16:38:24  <bnoordhuis>nice
16:38:26  <indutny>bnoordhuis: so... moving to that thing, right?
16:38:32  <indutny>bnoordhuis: do we have proc title test? :)
16:38:35  <bnoordhuis>yes
16:38:35  <indutny>saghul: are you on 10.6?
16:38:41  <bnoordhuis>we have a few in node as well
16:38:45  <indutny>bnoordhuis: ok
16:38:46  <saghul>indutny yes!
16:38:53  <indutny>bnoordhuis: lets assume that its cross-version thing
16:38:57  <saghul>10.9 is finally usable with multiple screens
16:39:12  <saghul>but at work we support 10.6 so I'm not moving all machines just yet :-)
16:39:34  <indutny>bnoordhuis: I'll show you a gist for v0.10 in a couple of minutes
16:39:36  <indutny>bnoordhuis: ok?
16:40:05  <bnoordhuis>ok
16:42:04  <bnoordhuis>514 11.1% 11.3% node::DTRACE_HTTP_SERVER_REQUEST(v8::FunctionCallbackInfo<v8::Value> const&) <- our dtrace/stap probes have quite a bit of overhead...
16:42:47  <tjfontaine>only for stap really
16:42:58  <tjfontaine>because otherwise we check _ENABLED() which doesn't exist for stap
16:43:13  <bnoordhuis>where is that check done? in js land?
16:43:29  <tjfontaine>no, you still incur the boundary jump, but it's not that bad
16:43:34  <tjfontaine>more often than not it doesn't appear
16:44:01  <indutny>bnoordhuis: https://gist.github.com/indutny/7200299
16:44:07  <bnoordhuis>well, i hope so
16:44:38  <indutny>tjfontaine: we should try moving this stuff into external arrays, or something like this
16:44:41  * TooTallNatequit (Ping timeout: 272 seconds)
16:44:45  <indutny>tjfontaine: I bet dtrace will allow us doing so
16:44:56  <indutny>aah, probably it won't
16:45:06  <indutny>tjfontaine: it is a linker thing, right?
16:45:10  <indutny>_ENABLED()
16:45:23  <indutny>it should be just storing position and reserving space for a constants
16:45:29  <indutny>bnoordhuis: LGTY?
16:45:36  <bnoordhuis>i haven't even looked yet...
16:45:45  <indutny>https://gist.github.com/indutny/7200299
16:45:46  <indutny>;)
16:46:20  <bnoordhuis>have you tested it?
16:46:35  <indutny>bnoordhuis: yes
16:46:43  <indutny>seems to be building and passing test
16:46:53  <indutny>./out/Debug/run-tests process_title process_title
16:47:20  <bnoordhuis>what happens when you upgrade libuv in node?
16:47:55  <bnoordhuis>patch lgtm in principle
16:48:27  <indutny>bnoordhuis: let me try it
16:48:44  <indutny>bnoordhuis: patch for master was working
16:48:45  <indutny>;)
16:48:51  <indutny>bnoordhuis: I was testing it in node
16:48:58  * TooTallNatejoined
16:51:10  * dshaw_joined
16:52:30  <indutny>bnoordhuis: considering that it'll work - can I land it?
16:52:33  <indutny>I mean
16:52:33  <piscisaureus_>pGetCurrentProcess
16:52:35  * mikealquit (Quit: Leaving.)
16:52:36  <indutny>can I land it after testing
16:52:39  <piscisaureus_>os x is starting to look like windows
16:52:40  <indutny>piscisaureus_: already fixed, thanks
16:52:54  * loladiroquit (Quit: loladiro)
16:52:54  <indutny>piscisaureus_: you must be looking at LSSetApplicationLaunchServicesServerConnectionStatusType
16:52:55  <piscisaureus_>soon it will be GetCurrentProcessExW
16:53:13  <indutny>hahaa
16:53:21  <indutny>DCMA them
16:54:06  <bnoordhuis>indutny: sure, land it
16:54:15  <indutny>seems to be working
16:54:16  <indutny>landing
16:54:29  <MI6>joyent/libuv: Fedor Indutny v0.10 * 08e0e63 : darwin: avoid calling GetCurrentProcess - http://git.io/6glOHw
16:54:40  <piscisaureus_>BOOL WINAPI GetCurrentProcessEx(_out LPHANDLE lpHandle, BOOL bInheritHandles)
16:54:42  <tjfontaine>yay, no more cloudup not responding :)
16:54:59  <indutny>tjfontaine: not yet :)
16:55:04  <bnoordhuis>"seems to be working"...
16:55:45  <tjfontaine>indutny: there are ways we can make the dtrace probes less expensive, by just relying more on the jit and its inline caches, fewer ->Get's in C++ will make the path faster, but requires people being ok with caching those lookups in JS
16:55:59  <piscisaureus_>Is it not possible to detect OS X version at runtime?
16:56:01  <indutny>tjfontaine: indeed
16:56:11  <indutny>piscisaureus_: I think it should be, why not?
16:56:21  * dshaw_quit (Ping timeout: 272 seconds)
16:56:34  <piscisaureus_>indutny: then why are we landing a patch with an ifdef?
16:56:45  <tjfontaine>hueniverse1: what should the server code for this be? or just a nop hapi server?
16:56:46  <indutny>without it
16:57:23  * mikealjoined
16:57:42  <bnoordhuis>piscisaureus_: i don't see an #ifdef
16:57:45  * c4miloquit (Remote host closed the connection)
16:58:47  <indutny>bnoordhuis: going to merge into v0.10
16:58:48  <indutny>err
16:58:50  <indutny>into master
16:59:10  <piscisaureus_>bnoordhuis: indutny: sorry *shame* was looking at old patch
16:59:24  <bnoordhuis>indutny: godspeed
16:59:24  <MI6>joyent/libuv: Fedor Indutny master * ab02252 : Merge branch 'v0.10' (+3 more commits) - http://git.io/Q5AEkw
16:59:55  <bnoordhuis>only two conflicts? we're not trying hard enough
16:59:57  <indutny>yeah, I just wanted to make sure that we won't waste time on resolving merge later
17:00:06  <indutny>since I've originally written it for master
17:00:11  * bnoordhuismoves some files around for the sake of it
17:00:15  <indutny>tjfontaine: when do we have scheduled v0.10 release?
17:00:18  <indutny>bnoordhuis :)
17:00:23  <indutny>bnoordhuis: that won't help
17:00:25  <tjfontaine>if there's enough, tomorrow
17:00:34  <indutny>bnoordhuis: you should try changing indent around
17:00:37  <indutny>bnoordhuis: adding braces
17:00:43  <indutny>and moving ifdef clauses
17:00:48  * amartensquit (Quit: Leaving.)
17:00:51  <indutny>changing all ifdefs to ifndefs
17:01:40  <indutny>tjfontaine: would be good to have libuv updated then ;)
17:02:27  <tjfontaine>:)
17:02:34  <tjfontaine>libuv releases happen before each node release :)
17:04:17  * dshaw_joined
17:06:05  <indutny>:)
17:06:07  <indutny>ok
17:06:38  <tjfontaine>actually, unless libuv-master + node-master require more integration work
17:06:58  <tjfontaine>in which case we can do a libuv release asap so I don't have to worry about doing api updates :)
17:08:02  <indutny>ok :)
17:08:04  <indutny>gotcha
17:09:16  <tjfontaine>right, there is some integration work needed, so I will do a libuv release if you want to do the next parts :)
17:09:37  <tjfontaine>it's your code anyway
17:09:46  <tjfontaine>../src/fs_event_wrap.cc: In static member function 'static void node::FSEventWrap::Start(const v8::FunctionCallbackInfo<v8::Value>&)':
17:09:49  <tjfontaine>../src/fs_event_wrap.cc:114:31: error: too many arguments to function 'int uv_fs_event_init(uv_loop_t*, uv_fs_event_t*)'
17:09:52  <tjfontaine>:)
17:10:58  <indutny>oh, not mine
17:11:04  <indutny>saghul: ? :)
17:11:13  <indutny>tjfontaine: I think its just an argument removed
17:11:18  <saghul>pong
17:11:20  <indutny>tjfontaine: should be fine to remove it from fs_event_wrap.cc
17:11:31  <indutny>bnoordhuis: btw, do you have any progress on my other libuv patches?
17:11:35  <tjfontaine>heh
17:11:43  <saghul>yes, uv_fs_event_init has less arguments now
17:13:01  * c4milojoined
17:13:02  <saghul>indutny tjfontaine https://github.com/joyent/libuv/commit/9d44d786ada6cf94e1bdcee7d777c790ca712a78
17:13:13  <indutny>exactly
17:13:47  <indutny>tjfontaine: basically, you need this https://github.com/joyent/libuv/commit/9d44d786ada6cf94e1bdcee7d777c790ca712a78#diff-5737b5ae6c6acd2f41d43cd5a1ae5bbcR228
17:14:10  <indutny>ok, going to reboot to windows
17:14:12  <indutny>and play some games
17:14:13  <tjfontaine>sure, was just hoping to get someone else tod o my work :P
17:14:17  <indutny>hahaha
17:14:19  <tjfontaine>but I'll do it :)
17:14:25  <indutny>that's not just your work
17:14:29  <indutny>that what we all do here
17:14:31  <indutny>and yeah
17:14:31  <tjfontaine>hehe
17:14:33  <indutny>I feel a bit lame
17:14:37  <indutny>sorry :P
17:14:48  <tjfontaine>bnoordhuis: same question as fedor, do you have any other pending patches you want in before I do a libuv release?
17:15:06  <indutny>ttyl
17:15:09  <tjfontaine>later
17:17:15  * bnoordhuisquit (Ping timeout: 265 seconds)
17:22:38  <tjfontaine>piscisaureus_: hm, ping?
17:26:28  * Chip_Zer-quit (Quit: Terminated with extreme prejudice - dircproxy 1.2.0)
17:30:02  <tjfontaine>ircretary: tell bnoordhuis there are a lot of changes for this next libuv release, it'd be helpful to me if you did it since you know what you would like to see in the changelog
17:30:02  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
17:43:03  * amartensjoined
17:44:06  * Collinjoined
17:44:15  * dshaw_quit (Quit: Leaving.)
17:44:50  * zotjoined
17:44:57  * zotpart
17:46:40  * mikealquit (Quit: Leaving.)
17:46:47  * mikealjoined
17:46:57  <hueniverse1>tjfontaine: the server is just anything that accepts the requests
17:47:06  <tjfontaine>hueniverse1: ok, thanks, that's what I figured
17:50:52  <hueniverse1>tjfontaine: emailed you the chart showing the leak trend over 10+ hours.
17:51:03  <tjfontaine>yup, looking now
17:57:18  * st_lukejoined
18:00:25  * sblomquit (Ping timeout: 245 seconds)
18:01:11  <groundwater_>trevnorris: ping
18:02:42  * brsonjoined
18:02:47  * superjoe30joined
18:07:54  <trevnorris>groundwater_: pong
18:07:57  <trevnorris>afternoon all
18:08:37  <groundwater_>i want to test how performant / non-performant some of our hackery to event emitters are doing, is there a benchmark suite i should try running it against?
18:09:37  <trevnorris>groundwater_: i'd say most important is check the performance against normal benchmarks. check if it has any affect at the macro level.
18:09:58  <groundwater_>trevnorris: so just 'make bench' ?
18:10:24  * pachetquit (Quit: leaving)
18:11:16  <trevnorris>groundwater_: that'll take a while. you can also do things like "make bench-http", but also run the commands individually. like ./node benchmark/http/http/client-request-body.js dur=5 type=asc bytes=32 method=write
18:11:48  <isaacs>ugh, npm bug in latest release
18:11:57  <groundwater_>trevnorris: thanks, i'll start there
18:11:58  <isaacs>(latest npm release, not node release)
18:13:54  <tjfontaine>isaacs: glad we found it today and not tomorrow :)
18:14:06  <isaacs>tjfontaine: :)
18:14:29  <hueniverse1>tjfontaine: https://gist.github.com/hueniverse/a655af7be0a13145e132
18:14:43  <hueniverse1>tjfontaine: this one has no external deps, much simpler
18:14:54  * indexzerojoined
18:14:57  <hueniverse1>tjfontaine: it also leaks much faster
18:15:29  <hueniverse1>tjfontaine: main diff is that in this case, I don't read the response to the http request, just res.destroy() it
18:15:45  <tjfontaine>hueniverse1: I'm not seeing the leak here from your numbers http://us-east.manta.joyent.com/tjfontaine/public/walmart.png
18:16:12  <hueniverse1>rss is clearly trending up
18:16:33  <trevnorris>piscisaureus_: what's been going on?
18:16:38  <hueniverse1>look at the jump third of the way from the right
18:16:50  <tjfontaine>at 5000?
18:17:06  <hueniverse1>more like 4200
18:17:16  <tjfontaine>ok I will continue with the second script
18:17:21  * AvianFluquit (Remote host closed the connection)
18:18:11  <hueniverse1>tjfontaine: this has been the main issue with this. it is slow when not under production load at peak, and even then, it is a trend, not a continuous growth
18:18:29  <trevnorris>groundwater_: to be honest I have a slight hack for domains on EE that'll allow me to completely remove domains from core.
18:18:29  <hueniverse1>tjfontaine: if you chart the trend line, it is very clearly there
18:18:35  <trevnorris>don't know why I didn't think of it before.
18:19:11  <groundwater_>trevnorris: what's the hack?
18:19:19  <groundwater_>code?
18:20:52  <trevnorris>groundwater_: i'll let you know when I update the PR w/ it
18:21:37  * AvianFlujoined
18:21:40  <groundwater_>trevnorris: othiym23 and i were thinking that if a similar api to async-listeners were exposed on EEs that domains/CLS could be implemented on top of that
18:25:26  <othiym23>trevnorris: basically we need to have a function that fires when a listener is added to an emitter that then passes state to be set up before / after said listener is run on an emit
18:26:59  * kazuponquit (Remote host closed the connection)
18:27:26  * kazuponjoined
18:27:51  <othiym23>trevnorris: here's what I have right now, and it uses closures galore: https://github.com/othiym23/shimmer/blob/master/index.js#L86-L217
18:28:20  <othiym23>also it does some pretty squirrelly shit try not to pay too much attention to that
18:29:52  <trevnorris>othiym23: honestly I think EE is one of the roots of evil in core, so I have little concern for that :P
18:31:22  <trevnorris>othiym23: wow yeah. that's kinda intense. I almost have my domain patch working. i'll let you know when it's done.
18:31:48  * kazuponquit (Ping timeout: 240 seconds)
18:31:50  * bnoordhuisjoined
18:32:50  <superjoe30>what's evil about EventEmitter?
18:33:33  <othiym23>everything about its implementation is complicated due to all the weird perfomrance tuning done on it, and EEs are used for WAYYYYY too many things in core
18:33:40  <superjoe30>ah
18:33:45  <trevnorris>superjoe30: EE is actually synchronous, but we use them as a layer of abstraction to emit async events.
18:34:02  <superjoe30>I've seen that switch statement on the number of args
18:34:03  * Collinpart
18:34:08  <trevnorris>the abstraction adds enough complexity that working around it within core itself has been a PITA
18:35:56  <trevnorris>also it's a hugely stupid performance hit were we could be doing some awesome optimizations.
18:36:24  <trevnorris>i already have it on my performance todo list for v0.13 to remove usage of EE for internal messaging.
18:36:27  <othiym23>superjoe30: there's also weird stuff like if you monkeypatch an EE that's being used in a streams1 stream, .on / .addListener will get overwritten when they're called because the stream reinitializes the stream by calling EventEmitter.call(this) on it
18:36:34  <othiym23>it's all just gnarly
18:36:59  <superjoe30>this is all good news to me
18:37:10  <superjoe30>because it means that I can do nothing and in future node.js versions my code will be faster :)
18:37:23  <superjoe30>>:-)
18:37:29  <superjoe30>^^ devil horns
18:37:37  <othiym23>if only that were true for me...
18:37:55  <superjoe30>congrats on your new relic post, btw
18:37:59  <superjoe30>that was fun to read
18:38:12  <trevnorris>piscisaureus_: ANSWER ME!!!
18:45:02  * julianduquequit (Quit: leaving)
18:48:23  * loladirojoined
18:52:18  <trevnorris>othiym23: haha, just got to thinking. my hack is going to step on your hack. :P
18:52:18  <trevnorris>well, if I can get it working. going to give it one more hour before I throw in the towel.
18:52:46  * mikealquit (Quit: Leaving.)
18:53:53  * bnoordhuisquit (Ping timeout: 272 seconds)
18:58:06  * kazuponjoined
19:15:10  * AvianFlu_joined
19:15:10  * AvianFluquit (Read error: Connection reset by peer)
19:18:45  * indexzeroquit (Quit: indexzero)
19:20:35  * bnoordhuisjoined
19:31:37  * kazuponquit (Ping timeout: 265 seconds)
19:31:54  * superjoequit (Ping timeout: 272 seconds)
19:35:24  * AvianFlu_changed nick to AvianFlu
19:35:39  * Benvie_joined
19:36:41  <trevnorris>othiym23: api question.
19:36:48  * sblomjoined
19:40:09  <hueniverse1>tjfontaine: the last code sample shows the leak too. confirmed after am hour 38m
19:42:09  * superjoejoined
19:42:49  <trevnorris>groundwater_: or you. just have a API curious question.
19:47:00  * inolenquit (Quit: Leaving.)
19:49:29  * bradleymeckjoined
19:49:53  * dshaw_joined
19:53:10  * mikealjoined
19:55:57  * indexzerojoined
19:56:38  * wavdedjoined
19:58:14  <indutny>bnoordhuis: heya
19:58:17  <indutny>and I'm back
20:07:15  <bnoordhuis>indutny: duly noted
20:07:25  <indutny>bnoordhuis: duly noted that you're here too
20:07:31  <indutny>may I remind you again about libuv stuff
20:07:42  <bnoordhuis>indutny: you may
20:07:42  * dshaw_quit (Quit: Leaving.)
20:07:43  * loladiroquit (Quit: loladiro)
20:07:48  <indutny>bnoordhuis: I do
20:07:50  <indutny>I did
20:08:18  <bnoordhuis>you have
20:08:28  <indutny>I had
20:08:38  <trevnorris>...
20:10:25  <indutny>trevnorris: you did
20:10:51  <trevnorris>indutny: yes, I did forget what I was going to ask you guys. curse me for not utilizing ircretary.
20:13:48  <tjfontaine>hueniverse1: ya, I'm running it
20:14:34  <othiym23>trevnorris: back from lunch
20:15:17  <othiym23>if your hack steps on my hack, I'll just fix my hack
20:15:24  <othiym23>I'm pretty used to it at this point
20:15:24  <trevnorris>othiym23: nm on the idea. oh, and I just fixed a silly/stupid bug. mostly affects performance.
20:15:29  <othiym23>it's the lot of the instrumentation engineer
20:15:35  <trevnorris>and i'm not going to do the domain thing.
20:15:49  <trevnorris>the EE constructor will still need to know whether it's being instantiated in an active domain or not.
20:15:51  <othiym23>heh OK
20:15:53  <trevnorris>(which I hate btw)
20:16:11  <hueniverse1>so what's the state of 0.11?
20:16:26  <tjfontaine>it's being released tomorrow, provided we agree on the windows fix
20:16:29  <othiym23>it's gross code but it makes domains way more useful (at the cost of being magical / hard for people to understand when domains are or aren't doing the heavy lifting for them)
20:17:27  <tjfontaine>hueniverse1: or do you mean in more "when is 0.12"? :)
20:17:39  <trevnorris>othiym23: my hack was to hijack the emit callback, and check if the ee had a .domain. then if it did then just ee.domain.enter() before the emit then .exit() after. async listeners take care of the rest.
20:18:34  <hueniverse1>I don't need 0.12, just would like to try out a 0.11 that has no known issues to compare the memory leak issues
20:19:01  <hueniverse1>we're not likely to deploy 0.12 this year
20:19:12  <hueniverse1>but I can play with it in tiny scale live
20:19:29  <trevnorris>dude. v0.12 is going to be so much awesomer!
20:19:52  <othiym23>trevnorris: yeah, that's more or less what groundwater_ and I were talking about doing in our emitterListener API
20:19:57  <hueniverse1>dude. v0.10 was a fucking nightmare :-)
20:20:18  <hueniverse1>deploying 0.10 was a huge mistake for us, and in some way still is
20:20:37  <othiym23>hueniverse1: I used lab to write the tests for the hapi-cls plugin I put together this weekend
20:20:47  <othiym23>getting it running was kinda confusing, but I like it!
20:20:49  <hueniverse1>which is also why I want to deploy 0.11 now on a couple boxes so when 0.12 comes out, I know what I'm dealing with
20:20:52  <trevnorris>heh, well v0.12 has some things I think you'd want. e.g. now more SlabAllocator.
20:21:06  <trevnorris>*no more
20:21:13  <hueniverse1>othiym23: it works pretty much the same as mocha
20:21:20  <hueniverse1>have you used that before?
20:21:44  <hueniverse1>trevnorris: no need for a sales pitch
20:21:49  <othiym23>hueniverse1: I have about 20K+ lines of mocha code in the new relic module so uh yes ;)
20:22:14  <trevnorris>hueniverse1: and it's going to have my new buffer implementation, and it's going to have ... ;)
20:22:16  <hueniverse1>so what about lab was diff? we just use diff names, but in all the hapi tests we alias it to look the same
20:22:23  <othiym23>hueniverse1: I was just confused by working with the test runner, I think because I had a different version of the runner installed globally than I did in the project
20:22:33  <hueniverse1>ah
20:22:36  <othiym23>once I drove it via npm test everything started working
20:22:41  <hueniverse1>it's really just a domain wrapper :-)
20:23:01  <hueniverse1>and it fails every time domains fail to catch an error
20:23:11  <othiym23>https://github.com/othiym23/hapi-cls/blob/master/package.json
20:23:22  <othiym23>that seems pretty simple to me ;)
20:24:27  <hueniverse1>lab was basically mocha with 90% of the featured removed, then moved to use domains instead of global uncaught
20:24:41  <hueniverse1>but then we added coverage and other nice little things
20:25:05  <hueniverse1>we either use npm test
20:25:12  <hueniverse1>or npm link lab, then just lab
20:25:25  <hueniverse1>I don't have it npm install -h
20:25:26  <hueniverse1>-g
20:25:30  <othiym23>can you just run node test.js with the files like you can with tap?
20:25:31  <hueniverse1>I hate -g
20:25:57  <hueniverse1>hmm, don't think so
20:26:06  <othiym23>cool, then it wasn't brain damage on my part
20:26:16  <hueniverse1>the require('lab') doesn't include the runner
20:26:24  <othiym23>fwiw, I find that super useful so I can do stuff like node debug test.js to walk through a failing test case
20:26:25  <hueniverse1>just the func defs
20:26:29  <othiym23>got it
20:26:38  <hueniverse1>open an issue on lab
20:26:41  <hueniverse1>we can add that
20:26:43  <othiym23>I do like how it's more explicit about that stuff than mocha
20:26:46  <othiym23>cool, I will
20:27:40  <hueniverse1>I can do something like node test.js -r (or some flag to tell lab to load the running)
20:27:44  * indexzeroquit (Quit: indexzero)
20:28:09  * kazuponjoined
20:28:19  * loladirojoined
20:29:24  * indexzerojoined
20:33:30  <hueniverse1>trevnorris: if the leak is still going to show up in 0.11, I'm naming it Trevor!
20:34:32  <trevnorris>hueniverse1: heh. well, there are still a handful of allocators in core besides the SlabAllocator (for crypto/tls) but none of those are exposed to the user.
20:34:58  <trevnorris>hueniverse1: if you are getting any leaks i'll be interested to see what' going on. should be easier to track down w/ the buffer simplification.
20:35:20  <hueniverse1>testing the gist now with 0.11.7
20:35:28  <hueniverse1>curious to see if it shows up there too
20:35:40  <hueniverse1>should know in an hour or so (that's how long it takes the trend to appear)
20:36:04  <trevnorris>been writing docs for AsyncListeners for almost 2 hours now. that's about all my brain can take...
20:39:08  <trevnorris>hueniverse1: that gist public?
20:39:43  <hueniverse1>https://gist.github.com/hueniverse/a655af7be0a13145e132
20:41:39  * indexzeroquit (Quit: indexzero)
20:47:36  <hueniverse1>trevnorris: the new chart is much prettier /\/\/\/\/\/\/\/\/\/\/\/\/\
20:48:02  <hueniverse1>trevnorris: but from 10m still looks like an upwards trend, but need to give it more hours for real insight
20:48:30  <trevnorris>hueniverse1: cool. let me know how it goes :)
20:48:32  * julianduquejoined
20:48:48  <hueniverse1>is 0.11.7 much diff from master?
20:49:08  <tjfontaine>significant, a v8 upgrade at the least
20:54:05  <sblom>hueniverse1: is that an ASCII sparkline? :p
20:58:46  * st_lukequit (Read error: Connection reset by peer)
20:59:08  * st_lukejoined
21:01:22  * kazuponquit (Ping timeout: 246 seconds)
21:02:09  <hueniverse1>sblom: that's my proc memory under 0.11
21:02:12  * dshaw_joined
21:06:57  * kuplatup1uchanged nick to kuplatupsu
21:10:57  <MI6>joyent/node: isaacs v0.10 * 4b5e6a3 : npm@1.3.13 - http://git.io/BpNZyg
21:11:14  <isaacs>tjfontaine: ^
21:11:18  <isaacs>tjfontaine: landing on master shortly
21:11:24  <tjfontaine>as a merge?
21:12:35  <MI6>joyent/node: isaacs master * 0396b20 : Merge remote-tracking branch 'ry/v0.10' (+4 more commits) - http://git.io/0TdoCA
21:12:42  <isaacs>tjfontaine: yes :)
21:12:45  <trevnorris>hueniverse1: here's a revision that'll kick the crap out of your server a lot harder. https://gist.github.com/trevnorris/7204785
21:12:58  <isaacs>tjfontaine: so, also got the 3 doc patches
21:13:01  <isaacs>nothing major, otherwise
21:13:39  <tjfontaine>nod
21:14:21  <tjfontaine>trevnorris: lul, no kidding hahah
21:14:25  * bradleymeckquit (Quit: bradleymeck)
21:14:43  <trevnorris>tjfontaine: :)
21:15:37  <trevnorris>tjfontaine: it's a strange pass time to enjoy figuring out how to get node to crap its pants. :P
21:15:59  * c4milo_joined
21:16:22  <tjfontaine>heh
21:16:30  <bnoordhuis>tjfontaine: 'next libuv release' == libuv master?
21:16:37  <tjfontaine>bnoordhuis: yes, libuv-master
21:16:45  * c4miloquit (Ping timeout: 272 seconds)
21:16:52  <bnoordhuis>okay
21:16:57  <tjfontaine>there's a non-trivial amount of changelog action, and I'm not sure if you want to trim and what the policy etc is for it
21:17:39  <bnoordhuis>the policy is that i like to see my own name appearing often
21:17:45  <tjfontaine>heh
21:17:48  <bnoordhuis>besides that anything goes
21:17:49  <tjfontaine>well you're there
21:17:58  <tjfontaine>there's also a bug in the release script :)
21:18:03  <bnoordhuis>oh?
21:18:20  <tjfontaine>- if (err.code == 'ENOENT' &&
21:18:21  <tjfontaine>+ if (err && err.code == 'ENOENT' &&
21:19:07  <bnoordhuis>ah, that's for the configure.ac, isn't it?
21:19:16  <tjfontaine>yup
21:19:37  <bnoordhuis>i was going to blame bert for that but it might actually have been me who wrote that
21:20:19  <tjfontaine>heh I'm not sure who, but anyway that was breaking when I was starting the release and then decided to abort
21:20:29  * pachetjoined
21:20:29  * pachetquit (Changing host)
21:20:29  * pachetjoined
21:20:30  <bnoordhuis>ah no, it was bert. order has been restored to the force
21:23:40  <bnoordhuis>tjfontaine: fixed, cheers
21:24:19  <tjfontaine>np
21:24:28  <tjfontaine>looking through 6432
21:24:38  <bnoordhuis>it's full of awesome, isn't it?
21:24:45  <tjfontaine>heh
21:24:54  <bnoordhuis>the hacks to get those dtrace object files in the right place, however...
21:25:00  <trevnorris>ok, if you guys don't review 6011 soon it's going to be bigger than a v8 upgrade :P
21:25:25  <bnoordhuis>trevnorris: i admit i always zone out halfway through
21:25:27  <tjfontaine>bnoordhuis: indeed, I want to do it entirely different SomeTime(tm) as well, such that we're just running over every object file anyway so it's less of a hassle
21:25:48  <trevnorris>bnoordhuis: haha. well, it's impressive you make it half way.
21:26:55  <bnoordhuis>linux-core.c:633: erreur: déréférencement d'un pointeur de type incomplet <- those french
21:27:18  <trevnorris>wtf. how'd you get that?
21:27:46  <tjfontaine>you better stop derefing that incomplete type :)
21:28:09  <bnoordhuis>i like how they translated 'pointer' to 'pointeur'
21:28:20  <tjfontaine>heh
21:29:43  <othiym23>trevnorris: we're getting our shit together with respect to CI and perf testing the New Relic stuff, and we'll probably have an environment where we can load test 6011 within the next couple weeks
21:30:00  <tjfontaine>iow thanks for the gin jacob
21:30:14  <othiym23>it won't be as elaborate as hueniverse1's setup
21:30:19  <othiym23>I can't believe he actually plied you with gin
21:30:23  <othiym23>also straight gin is nasty
21:30:24  <trevnorris>othiym23: coolio. though I might cry if it hasn't been merged by then.
21:30:34  <tjfontaine>well, I suggested it, I never thought he would follow through :)
21:30:41  <othiym23>smh at bnoordhuis making trevnorris cry
21:31:08  <trevnorris>oh, it's not just bnoordhuis. piscisaureus_ has some stuff for me as well.
21:31:33  <trevnorris>IF HE'D RESPOND TO ME, I MIGHT BE ABLE TO GET IT DONE
21:31:33  <LOUDBOT>YOU GUYS NEED TO COORDINATE, K?
21:31:48  <othiym23>on point as usual LOUDBOT
21:32:04  <hueniverse1>othiym23: what setup?
21:32:13  <trevnorris>makes me wonder if LOUDBOT is actually sentient.
21:32:18  <MI6>nodejs-v0.10: #1567 UNSTABLE smartos-x64 (7/603) smartos-ia32 (8/603) linux-x64 (4/603) linux-ia32 (3/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1567/
21:32:27  <othiym23>hueniverse1: whatever it is you're running to figure out these leaks
21:32:43  <tjfontaine>heh
21:32:50  <hueniverse1>node client.js
21:32:53  <hueniverse1>is all I do
21:32:54  <tjfontaine>who said anything about figuring anything out :)
21:32:59  <hueniverse1>it spits our rss every 10s
21:33:05  <hueniverse1>and I load it into excel
21:33:06  <hueniverse1>tada!
21:33:19  <tjfontaine>I use gnuplot, but same diff :)
21:33:45  <hueniverse1>we're now down to 8mb leak a day per server
21:33:50  <hueniverse1>down from 200mb a day
21:33:53  <othiym23>OK, maybe we can hit that level of sophistication
21:34:00  <hueniverse1>because we are doing a lot less upstream traffic
21:34:04  <hueniverse1>by moving things around
21:34:10  <hueniverse1>but the basic leak is still very much there
21:34:20  <hueniverse1>and we now think we know where it is coming from
21:34:25  <hueniverse1>which is what my gist is about
21:34:37  <MI6>nodejs-master: #647 UNSTABLE osx-x64 (2/654) smartos-ia32 (10/654) smartos-x64 (10/654) linux-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/647/
21:37:37  <hueniverse1>othiym23: you coming to our meeting 11/6 at joyent? I got your cookbook (also who do you want to signed to)
21:37:58  <othiym23>SHERWOOD MCGRAW, of course ;)
21:38:04  <othiym23>and yeah, I'll be there, no need to mail it
21:38:08  <othiym23>got a ticket and everything
21:38:11  <trevnorris>bnoordhuis: is there a reason why https://gist.github.com/trevnorris/7205304 isn't enough to fix https://github.com/joyent/node/issues/995 ?
21:38:17  <trevnorris>seems like a simple request.
21:40:44  * abraxasjoined
21:41:07  <hueniverse1>SHERWOOD MCGRAW?
21:41:07  <LOUDBOT>I'M HERE TO HIT ON LADIES WITH MY MOTHERFUCKING RHYMES
21:41:43  <othiym23>hueniverse1: that was my character name for RTConf, either that or Forrest if Sherwood McGraw is too doofy for you to put up with
21:41:50  * indexzerojoined
21:43:22  <hueniverse1>othiym23: whatever you want. I'm putting it on a sticky note when the pile goes to the chef tomorrow
21:44:13  <groundwater_>tjfontaine: after looking at your jenkins setup i'm not sure that bottle was big enough
21:44:36  <othiym23>hueniverse1: I think it's in keeping with the spirit of the event to have it signed to Sherwood McGraw
21:44:40  <isaacs>trevnorris: add a test, and that lgtm. i think the question was how to handle encodings, since that'snot in the API, but i'm ok just shrugging on that one.
21:44:45  <othiym23>I'll store my nametag with it so I don't forget what the deal is there
21:44:45  <isaacs>trevnorris: and assume that strings are utf8
21:45:04  <trevnorris>isaacs: coolio, thanks.
21:45:09  <isaacs>bnoordhuis: does this agree with you? you'd called dibs on that issue, presumably because you cared about it last year?
21:45:31  * abraxasquit (Ping timeout: 272 seconds)
21:46:24  <hueniverse1>othiym23: did you take your plate home? they all disappeared :-)
21:46:46  <othiym23>hueniverse1: I did! Were we not supposed to keep them?
21:47:18  <hueniverse1>othiym23: cool. I didn't want most of the shit back. People took everything. Like $3K work of shit :-)
21:47:57  <othiym23>we handed the flatware and those cool tweezers back to the folks who were helping you as servers
21:48:09  <othiym23>those tweezers were rad, I may have to get some of my own
21:48:53  <bnoordhuis>trevnorris, isaacs: right, so that seems like the obvious fix. you can't specify an encoding that way though
21:49:01  <hueniverse1>othiym23: there was a huge pile of stuff in the back room where we were setting up (15 sets of mortar and pestle...) 120 planters, etc.
21:49:46  <trevnorris>bnoordhuis: well, i'm ok saying if you really care about performance you'll turn it into a Buffer beforehand. adding an encoding option at the end that can bubble down the parameters chain would really suck.
21:50:11  <bnoordhuis>trevnorris: yeah, i don't really disagree. also, something is better than nothing
21:50:17  <bnoordhuis>unless it's herpes
21:50:23  <trevnorris>hehe
21:51:24  * wavdedquit (Quit: Hasta la pasta)
21:52:57  * loladiroquit (Quit: loladiro)
21:53:17  * julian_duquejoined
21:53:17  * loladirojoined
21:53:41  * julianduquequit (Ping timeout: 248 seconds)
21:54:14  <indutny>bnoordhuis: have a minute?
21:54:34  <bnoordhuis>indutny: 60, 59, 58...
21:54:44  <indutny>bnoordhuis: ok, so https://github.com/indutny/libuv/blob/c36a1726ba986eb26c804ca44125bb0f94b9c1b8/src/unix/linux-core.c#L224
21:54:52  <indutny>bnoordhuis: what do you think about passing ->pevents here
21:55:00  <indutny>bnoordhuis: and doing if (pevents != 0) check before calling cb
21:55:28  <indutny>bnoordhuis: should prevent it from emitting events after io_stop()
21:56:12  <bnoordhuis>indutny: you mean checking if (pe->events & w->pevents) != 0?
21:56:22  <indutny>hm...
21:56:31  <indutny>isn't pevents the new events?
21:56:35  <bnoordhuis>yes
21:56:37  <indutny>which just wasn't yet applied
21:56:46  <indutny>why should we bother with ->events at all?
21:56:50  <bnoordhuis>no, but it's the event mask the watcher is interested in
21:56:55  <indutny>aah
21:56:57  <indutny>ok
21:57:03  <indutny>well
21:57:07  <bnoordhuis>w->events is there so i can check that w->pevents != w->events :)
21:57:14  <indutny>haha
21:57:18  <indutny>I thought w->events = w->pevents
21:57:25  <indutny>that's what you do in the watcher update loop anyway
21:57:46  <bnoordhuis>yeah, so the logic is that if w->events != w->pevents, we need to do an update
21:58:01  * kazuponjoined
21:58:10  <bnoordhuis>because if w->events == w->pevents, we're already subscribed to all events the watcher is interested in
21:58:47  <bnoordhuis>basically, it's there to avoid to making superfluous system calls
21:59:14  * julianduquejoined
21:59:18  <indutny>bnoordhuis: I see
21:59:26  <indutny>bnoordhuis: why do I need to apply it as mask then?
21:59:27  * julian_duquequit (Ping timeout: 260 seconds)
21:59:34  <indutny>it couldn't have more or less, anyway
21:59:39  <indutny>it could just contain old value
21:59:51  <indutny>and if pevents is non-zero - then we're interested in any result
22:00:02  <indutny>at least, it seems that its how it is in epoll
22:00:16  <indutny>because you don't distinguish read/write events in linux-core.c
22:00:45  <indutny>and just give people what they want
22:00:51  <bnoordhuis>not sure i follow
22:00:52  <indutny>bnoordhuis: isn't that true?
22:00:55  <indutny>well
22:01:11  <indutny>1. the only place where events is set is : "w->events = w->pevents"
22:01:17  <bnoordhuis>yes
22:01:28  <indutny>2. w->cb(loop, w, w->events) in epoll
22:01:35  <indutny>3. why not w->pevents then?
22:01:37  <indutny>:)
22:01:48  <indutny>why should we give users events they're not interested in
22:01:55  <indutny>ah
22:01:58  <indutny>I see now
22:02:07  <indutny>it could be that we're not subscribed to writes
22:02:15  <indutny>and going to stop reading and start writing
22:02:18  <bnoordhuis>look more closely, fedor :)
22:02:26  <indutny>so events and pevents will be both non-zero
22:02:31  <indutny>but not events has actually happened
22:02:35  <indutny>ok
22:02:42  <bnoordhuis>i'll give you a hint
22:02:46  <indutny>bnoordhuis: should I call w->cb(loop, w, w->events & w->pevents) ?
22:02:49  <bnoordhuis>"3. why not w->pevents then?
22:02:52  <bnoordhuis>er
22:03:02  <bnoordhuis>"2. w->cb(loop, w, w->events) in epoll" <- it's not w->events
22:03:15  <indutny>it is
22:03:20  <bnoordhuis>nuh uh
22:03:24  <indutny>aaaaaaaah
22:03:26  <indutny>its pe->events
22:03:27  <indutny>sorry
22:03:30  <bnoordhuis>:)
22:03:34  <indutny>hahaha
22:03:39  <indutny>ok
22:03:47  <indutny>I should use a mask when invoking callback too then
22:03:55  <bnoordhuis>yeah
22:04:46  <trevnorris>bnoordhuis, isaacs: small fix. here's the diff for quick review: https://gist.github.com/trevnorris/7205304
22:04:59  <indutny>bnoordhuis: going to update PR
22:06:13  <tjfontaine>trevnorris: you should clarify the bytelength stuff, it's still kinda confusing
22:06:29  <trevnorris>tjfontaine: that's why it's linked to Buffer.byteLength :)
22:06:41  <bnoordhuis>tjfontaine: https://gist.github.com/bnoordhuis/c4365943f4eadea5603e <- those are arguably the important changes since v0.11.13
22:07:00  <tjfontaine>trevnorris: yes, but ... the wording still is difficult :)
22:07:19  <tjfontaine>bnoordhuis: you want me to do a release with those?
22:07:27  <tjfontaine>(in the changelog)
22:07:34  * c4milo_quit (Remote host closed the connection)
22:08:53  <bnoordhuis>tjfontaine: it's for the node changelog, right?
22:09:33  <bnoordhuis>tjfontaine: i picked the most important changes since the last libuv upgrade in node
22:09:55  <tjfontaine>bnoordhuis: no, the node changelog will just be "uv upgraded" but I wasn't sure what needed culled when doing a libuv-release
22:10:04  <indutny>bnoordhuis: sorry, force pushed PR
22:10:25  <indutny>bnoordhuis: i've incidentally rebase it over origin/master
22:10:29  <indutny>s/rebase/rebased/
22:10:56  <indutny>bnoordhuis: anyway, its much simpler now : https://github.com/joyent/libuv/pull/970/files
22:11:52  <bnoordhuis>tjfontaine: ah, okay... one sec
22:12:50  <indutny>tjfontaine: have we released 0.10 with fsevents fixes?
22:12:54  <indutny>bnoordhuis: ^
22:12:58  <indutny>I meant call-stack improvements
22:13:00  <indutny>aaah
22:13:00  <tjfontaine>indutny: I think so yes
22:13:08  <indutny>Just realized that there was no such code here
22:13:10  <indutny>in 0.10
22:13:13  <indutny>nvm
22:13:17  <tjfontaine>right
22:14:32  <bnoordhuis>tjfontaine: okay, it's the right list. there have been no other v0.11 libuv releases
22:14:50  <tjfontaine>do I cull test's and revert's?
22:14:56  <bnoordhuis>yes
22:14:58  <bnoordhuis>at least, i do
22:15:03  <tjfontaine>any ordering necessary?
22:15:28  <bnoordhuis>i just keep them in chronological order
22:15:37  <tjfontaine>ok
22:16:11  <bnoordhuis>indutny: you know the new 24 hour rule, right? :)
22:17:31  * Kakera_quit (Read error: Connection reset by peer)
22:18:21  * Kakera_joined
22:28:11  <indutny>bnoordhuis: oh man, that doesn't count :)
22:28:23  <indutny>bnoordhuis: meh, whatever works for you
22:28:38  <indutny>dutch bureaucrat :)
22:29:05  <SquirrelCZECH>guys
22:29:09  <SquirrelCZECH>please tell me
22:29:11  <SquirrelCZECH>please
22:29:29  <SquirrelCZECH>that "pyuv" is ported on android, so I do not have to use twisted in my project? (python)
22:29:35  <isaacs>i am halfway through https://github.com/joyent/node/pull/6011/files
22:29:46  <isaacs>trevnorris: but, oh no! my neighbors downstairs are making bacon!
22:29:52  <isaacs>now i must bacon
22:29:54  <othiym23>haha
22:29:59  <isaacs>the smell is overpowerful
22:30:04  * isaacsoff to bacon
22:30:06  <othiym23>I've actually looked at the whole thing
22:30:21  <isaacs>i am at long last +1 on the API, and the premise
22:30:24  <othiym23>fortunately I am undstractable by bacon
22:31:09  <isaacs>from what i can gather, my downstairs neighbors subsist entirely on bacon, over-cooked hamburgers, and marijuana
22:31:21  <isaacs>this is mostly what i've inferred from the smells
22:31:33  * kazuponquit (Ping timeout: 248 seconds)
22:31:38  <isaacs>which come directly into my apartment
22:31:47  <trevnorris>isaacs: damn that bacon!!!!
22:31:52  <isaacs>i dont' mind the bacon or the pot, but they seriously burn the shit out of some burgers, and it just is sad.
22:31:59  <isaacs>it's an abuse of perfectly fine beef.
22:32:08  <isaacs>actually it's probably safeway trash, but whatever.
22:33:12  <bnoordhuis>SquirrelCZECH: don't know about pyuv but libuv should work on android
22:33:18  <SquirrelCZECH>bnoordhuis: hmm
22:33:29  <SquirrelCZECH>and if pyuv is just bindings for libuv
22:33:39  <SquirrelCZECH>then it should work too, or should be easy to make it work
22:33:43  <bnoordhuis>yeah, there's a pretty good chance it'll work
22:33:46  <SquirrelCZECH>saghul: tip tap? :-)
22:34:10  <saghul>SquirrelCZECH sup?
22:34:24  <SquirrelCZECH>saghul: did you tried your awesome and perfect library "pyuv" on android?
22:34:37  * SquirrelCZECHjust refers to "QPython"
22:34:45  <saghul>SquirrelCZECH thanks for the kind words ;-) no, I haven't
22:35:06  <SquirrelCZECH>saghul: believe me, Twisted is "twisted evil creature"
22:35:15  <SquirrelCZECH>so pyuv is really, really perfect thing
22:35:28  <saghul>but there is no reason why it wouldn't work, if you have a working python interpreter and the headers to build it
22:35:37  <SquirrelCZECH>nah
22:35:45  <SquirrelCZECH>saghul: never builded something for android though...
22:36:08  <saghul>saghul
22:36:16  <saghul>SquirrelCZECH me neither, sorry :-S
22:36:27  * pachetquit (Quit: leaving)
22:36:30  <SquirrelCZECH>nah, this is going to be long night :-/
22:38:33  <SquirrelCZECH>saghul: can I ask you a question?
22:38:36  <SquirrelCZECH>how it works?
22:38:44  <SquirrelCZECH>your pyuv library?
22:38:55  <SquirrelCZECH>it's C code that fakes itself as python library
22:39:06  <SquirrelCZECH>or python code that imports libuv?
22:39:18  <saghul>it's C code, which extends Python
22:39:29  <saghul>Python has an API for C extensions, I just use it
22:40:05  <trevnorris>isaacs: damn that bacon!!!!
22:40:11  <trevnorris>whoops. second time :P
22:40:41  <isaacs>yes. i will damn that bacon to the eternal fires of my frying pan.
22:40:43  * isaacsaway bacon
22:42:50  * julianduquequit (Quit: leaving)
22:43:16  * julianduquejoined
22:47:13  <indutny>bnoordhuis: https://github.com/joyent/libuv/issues/974
22:47:13  <SquirrelCZECH>saghul: so first thing is to compile it for adnroid, naaaah
22:47:16  <bnoordhuis>isaacs: LazyCompile: *endReadable _stream_readable.js:881:21 <- that function seems to call process.nextTick() way too much
22:47:20  <indutny>bnoordhuis: I think you never though, that it could happen :P
22:47:52  <bnoordhuis>hah :)
22:48:47  <indutny>bnoordhuis: I think he might have * domain in network
22:48:55  <indutny>bnoordhuis: I already seen that in a few organization
22:49:01  <indutny>organizations*
22:50:29  <bnoordhuis>[GC] 1247 19.0% :-(
22:50:38  <bnoordhuis>(running some http benchmarks)
22:50:57  <bnoordhuis>that's with a fake socket, so no i/o overhead/variance
22:51:17  * AvianFlu_joined
22:51:19  * AvianFlu_quit (Remote host closed the connection)
22:52:01  * defunctzombiechanged nick to defunctzombie_zz
22:53:25  <indutny>bnoordhuis: no surprise
22:53:40  <indutny>bnoordhuis: time to move to unmanaged memory
22:53:47  <indutny>mraleph1: we need your help to remove GC from v8
22:54:31  <indutny>ok
22:54:33  <indutny>ttyl, guys
22:54:34  <indutny>time to sleep
22:54:37  <indutny>cheers
22:54:55  * AvianFluquit (Ping timeout: 272 seconds)
22:55:28  <bnoordhuis>night, fedor :)
22:56:07  <isaacs>bnoordhuis: yeah, i think it'd be good to comb through a lot of that stuff and see where the nextTicks are strictly necessary, and where they're just extra
22:56:24  <isaacs>bnoordhuis: that's part of what prompted my zalgo post. if you are deferring a lot (as we are in some cases) then it's not free.
23:04:03  * M28joined
23:04:10  * M28part
23:06:56  <hueniverse1>trevnorris: 0.11.7 also has the same leak
23:07:09  <hueniverse1>(assuming it is a leak and not a bug in my code)
23:07:47  <hueniverse1>the trend in 0.11.7 is MUCH easier to see. memory is much more stable, and the leak seems smaller.
23:08:20  <hueniverse1>100k over 2.5 hours
23:08:54  <trevnorris>hueniverse1: what're the totals from process.memoryUsage()?
23:09:33  <hueniverse1>https://gist.github.com/hueniverse/689904238bf847b982e3
23:09:48  <hueniverse1>rss, total heap, used heap, queued requests
23:10:13  <hueniverse1>each line is 10s sample
23:10:30  <tjfontaine>don't worry I am working on this, it appears to be active C/C++ memory
23:10:52  <tjfontaine>I'm going to be making some pretty graphs and logs to help identify this
23:11:08  <hueniverse1>I think the leak in 0.10 is twice as bad as in 0.11 but both have the same trend slope
23:11:10  <trevnorris>hueniverse1: can you try that gist I posted earlier? it removes more work from the gc and hits the service harder.
23:11:26  <hueniverse1>trevnorris: didn't see
23:11:29  <hueniverse1>link?
23:11:39  <trevnorris>hueniverse1: https://gist.github.com/trevnorris/7204785
23:12:40  <trevnorris>hueniverse1: the last argument is how many requests were completed per 10s interval
23:12:58  <hueniverse1>k
23:13:09  <hueniverse1>I'll take a look once I am back from feeding the farm
23:13:15  <trevnorris>coolio.
23:13:41  <trevnorris>hueniverse1: also, are you hitting a service or do you mean for the connection to err?
23:14:17  <trevnorris>tjfontaine: have an example: https://gist.github.com/trevnorris/7205304
23:14:21  <trevnorris>that enough?
23:15:18  <tjfontaine>heh the example may not be too necessary, what about something like: "will be based on byteLength not on character position"
23:15:32  <trevnorris>tjfontaine: coolio. so no example then?
23:15:59  <tjfontaine>"with consideration fror multi-byte characters, offset and length with be with respect to byteLength and not character position"
23:16:20  <trevnorris>heh, ok. that's what i'll put :)
23:16:25  <tjfontaine>:)
23:19:20  <tjfontaine>I'm not saying I'm all that clear, it's just trying to find the message that you're trying to deliver
23:19:44  <trevnorris>i deliver messages best via code, so english examples are appreciated :)
23:19:50  * bnoordhuisquit (Ping timeout: 240 seconds)
23:20:11  * bnoordhuisjoined
23:21:50  * Kakera_quit (Ping timeout: 240 seconds)
23:25:55  * indexzeroquit (Ping timeout: 246 seconds)
23:25:57  * julian_duquejoined
23:26:06  * julianduquequit (Disconnected by services)
23:26:11  * julian_duquechanged nick to julianduque
23:27:15  <MI6>joyent/node: Trevor Norris master * 8130744 : dgram: send() can accept strings - http://git.io/oaHFJw
23:28:04  * kazuponjoined
23:29:48  * paddybyersquit (Quit: paddybyers)
23:29:55  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:39:10  * st_lukequit (Remote host closed the connection)
23:40:56  <trevnorris>isaacs: ah, just saw your comment "i am at long last +1 on the API, and the premise". cool, thanks :)
23:41:27  <isaacs>trevnorris: found a bug tho (just commented)
23:41:40  * abraxasjoined
23:42:22  <isaacs>trevnorris: doing a nextTick in clearImmediate is a relevant contract change.
23:44:16  <trevnorris>isaacs: yeah. my thought was that 1 you always say to not depend on the order of async calls 2 it still gets cleared before the immediate can run again and 3 timers are such a PITA :P
23:44:19  <isaacs>trevnorris: iow, by spamming setTimeout with flips back and forth, yes, you can in fact cause the nextTick in clearInterval to be run AFTER the next run of the interval,if it's scheduled for this tick
23:44:30  <MI6>nodejs-master: #648 UNSTABLE osx-x64 (1/654) smartos-ia32 (7/654) smartos-x64 (9/654) linux-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/648/
23:44:35  <isaacs>trevnorris: 2 is not guaranteed.
23:44:45  <isaacs>trevnorris: if the nextTick is there
23:45:06  <isaacs>trevnorris: that's what the contract changes
23:45:51  <trevnorris>isaacs: first, thanks for the doc note.
23:46:01  <isaacs>trevnorris: in other words, in https://gist.github.com/isaacs/7206752 it should be impossible to get it to throw on line 30
23:46:20  * abraxasquit (Ping timeout: 265 seconds)
23:46:58  <isaacs>trevnorris: but becuse timers and intervals use that stupid shared handle thing, that's not the case.
23:47:25  <isaacs>re: docs, no problem, i'm even happy to write it, once done reviewing.
23:47:30  <isaacs>i wnt to get this thing landed tonight.
23:47:38  <isaacs>no one's strongly opposed, it's just big and gnarly.
23:47:44  <isaacs>maybe tomorrow if tjfontaine tells me to hold off :)
23:50:54  <isaacs>trevnorris: oh, simpler example: i=setInterval(fn);clearInterval(i);i=setInterval(fn)
23:51:16  <isaacs>trevnorris: so, the clear happens after the second set, but doesn't matter, actually, because i guess that's a different interval?
23:51:20  <isaacs>maybe my test is overly contrived.
23:51:32  <isaacs>still, why must there be a nextTick in clearInterval? smells funny, at least.
23:54:36  <isaacs>trevnorris: oh, yeah, it is a problem. even with a single timer
23:56:33  * TooTallNatequit (Remote host closed the connection)
23:57:18  * TooTallNatejoined
23:59:20  <hueniverse1>trevnorris: just run a server that accepts traffic on the port and returns a response.
23:59:25  * sblomquit (Ping timeout: 272 seconds)