00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:10  <trevnorris>othiym23: my benchmarks are, write my own implementation from scratch using minimal everything and compare to the fully featured version.
00:00:23  <mikeal>Python async + threads are the exact thing that pushed me to node in the early days. node was so broken, but less broken than trying to do the same thing in Python.
00:00:28  <trevnorris>othiym23: then attempt to close that gap
00:00:42  <isaacs>"performance vs stability" is a false dichotomy
00:00:51  <mikeal>tjfontaine: you gotta put that on twitter
00:01:07  <tjfontaine>heh
00:01:12  <isaacs>if you get enough people slamming your server, and not enough eperformance, you lose stability
00:01:29  <isaacs>mikeal: see, this is why i should be running @nodejsleaders
00:01:41  <isaacs>mikeal: becasue there's some hilarious-ass shit that we say, which is completely fucking bonkers.
00:01:51  <mikeal>isaacs: more servers?
00:01:51  <isaacs>mikeal: *someone* ought to be making better fun of us.
00:01:58  <othiym23>I liked how the npm account was suddenly endorsing "Yo, Is This Racist?" last night
00:02:06  <isaacs>othiym23: yeah, lol
00:02:09  <othiym23>isaacs, your approach to choosing Twitter accounts is whimsical
00:02:12  <isaacs>othiym23: only for a second
00:02:24  <isaacs>othiym23: and it's not like everyone doesn't already know that @npmjs is my alterego
00:03:03  <othiym23>mikeal: that stuff has all gotten a ton better in Python recently, and Guido announced a PEP at this year's PyCon that makes async stuff first-class in Python
00:03:19  <MI6>joyent/node: isaacs master * 6942a95 : repl: Add 'smalloc' to list of known modules (+1 more commits) - http://git.io/73WNLg
00:03:23  <mikeal>Python has issues.
00:03:26  <tjfontaine>othiym23: ya, and saghul has a version based on libuv
00:03:34  <othiym23>it clearly takes a lot of inspiration from Node and some of the ES6 generator stuff, which I guess is fitting given how much of TC39's generator implementation was stolen from Python in the first place
00:03:34  <mikeal>that's all I'm gonna say. bigger issues than can be solved in code.
00:03:40  <mikeal>community issues, ecosystem issues.
00:03:49  <tjfontaine>GIL issues
00:03:53  <othiym23>hahaha I know alll about your issues with Python, dude
00:04:06  <othiym23>I know you try to keep them to yourself, but I still know somehow
00:04:10  * c4milojoined
00:04:10  <mikeal>they aren't *my* issues because I washed my hands of it years ago
00:04:33  <tjfontaine>havin python problems, I feel bad for you son, I've got 99 issues, but a GIL ain't one.
00:04:57  <mikeal>pkg_tools/setup_tools is more of a plague on Python than the GIL
00:05:12  <tjfontaine>easy_install pip <-- inception?
00:05:26  <mikeal>pip is like drug store makeup on a pig
00:05:30  <tjfontaine>heh
00:05:49  <othiym23>pip isn't even as nice as gem, and that's saying something
00:05:51  * brsonquit (Ping timeout: 260 seconds)
00:05:58  <mikeal>a *decent* installer (still pretty bad) for a poorly hosted ecosystem of packages on a TERRIBLE module system
00:06:14  * brsonjoined
00:06:15  <mikeal>gem is a dream compared to Python's whole packaging/install stack
00:06:51  <mikeal>Python is great at adopting things to standard lib at the exact time everyone realizes how terrible they are
00:08:00  <isaacs>my problem with "easy_install" is that, in my experience, it's never easy, and never installs
00:08:16  <isaacs>the name writes a check the program can't cash
00:08:56  <trevnorris>isaacs: have a perf improvement want to try, but want to know if you'd accept it. don't think it's quite as ridiculous as the thin buffers, but might be getting close :)
00:09:12  <isaacs>trevnorris: awesome, i'm intrigued.
00:11:22  <othiym23>all I know about easy_install is that it makes eggs
00:11:24  <othiym23>I like eggs
00:12:09  <tjfontaine>from your head down to your legs?
00:13:03  <MI6>nodejs-master: #373 UNSTABLE smartos-ia32 (2/619) smartos-x64 (8/619) http://jenkins.nodejs.org/job/nodejs-master/373/
00:14:15  <trevnorris>isaacs: setting external array data is 2-3x's faster than setting a js object property, and getting the data out is practically a noop.
00:15:44  <trevnorris>isaacs: so on a handle instance set enough memory to contain a void* and length to 0 to prevent accidental screw up, then just assign the c++ class instance memory location to that.
00:15:49  <trevnorris>isaacs:
00:16:17  <trevnorris>isaacs: GetIndexedPropertiesExternalArrayData is practically a noop compared to getting a js property out
00:16:24  <isaacs>trevnorris: interesting.
00:16:50  <isaacs>trevnorris: so, the reference from the socket._handle JS object to the actual uv_handle thingie?
00:17:02  <tjfontaine>well it's _handle._handle
00:17:15  <trevnorris>isn't it _handle.__handle?
00:17:16  <trevnorris>:P
00:18:15  <isaacs>trevnorris: sounds interesting.
00:18:15  <trevnorris>actually it'd point to the *Wrap class instance
00:18:20  <isaacs>trevnorris: ok
00:18:31  <trevnorris>to get rid of all the Unwrap action
00:18:33  <isaacs>trevnorris: so we wouldn't have the Unwrap call?
00:18:35  <isaacs>right
00:18:56  <trevnorris>isaacs: just wondering if you'd consider it before I head off to create a patch. :)
00:19:01  <isaacs>i'll consider it
00:19:06  <trevnorris>whoot!
00:19:10  <isaacs>tjfontaine and bnoordhuis are the people to convince on this.
00:19:19  <isaacs>trevnorris: if it's faster, and doesn't break other stuff, i'm 100% in favor.
00:19:24  <tjfontaine>like I said, I'd be interesting to see the numbers :)
00:19:31  <trevnorris>othiym23: add this to your list of, we do it in core but would never recommend to the user. :P
00:19:32  <tjfontaine>*interested
00:19:39  <trevnorris>coolio. this'll be fun
00:19:50  <trevnorris>i'm most interested in crypto performance
00:19:57  <trevnorris>it's done everywhere there.
00:21:05  * jmar777joined
00:22:35  <trevnorris>isaacs: re: buffer dispose. speaking w/ tjfontaine realized that it'll get a little complicated for stuff like fs.write(). since it's async threaded in the background the user could free the memory as it's being written to disk.
00:22:47  <othiym23>trevnorris: about 80% of the stuff you do shouldn't be done in user code, which is fine, because I don't think much of anybody who's not here in this channel right now (execpt piscisaureus and bnoordhuis) understand it
00:22:58  <trevnorris>isaacs: so i'd have to be careful to keep a slice of the data around until the operation is complete
00:23:01  * stagas_joined
00:23:43  <trevnorris>isaacs: just fyi. but the patch is just about stable enough for initial release. i'll have it wrapped up by the end of the week.
00:24:18  <trevnorris>othiym23: haha. i've been wondering what to cover at nodeconf.eu. maybe I should cram all that in :P
00:24:25  * stagasquit (Ping timeout: 268 seconds)
00:24:39  * stagas_changed nick to stagas
00:25:52  <MI6>nodejs-master-windows: #170 UNSTABLE windows-x64 (22/619) windows-ia32 (19/619) http://jenkins.nodejs.org/job/nodejs-master-windows/170/
00:26:06  <isaacs>trevnorris: "All the things that we do in Node-Core that you should NEVER EVER DO"
00:27:55  <othiym23>*opens src/node.cc and lib/node.js* "don't do any of this stuff, guys" *walks off stage*
00:28:07  <tjfontaine>*drops mic*
00:28:33  <trevnorris>haha
00:28:48  <trevnorris>well, that'd give more time to bert and richard
00:30:15  <trevnorris>but seriously, have no idea what to talk about. practically everything i've implemented i'd never recommend.
00:31:15  * c4miloquit (Remote host closed the connection)
00:31:48  * c4milojoined
00:33:44  <othiym23>BTW, if anyone really hates the name "continuation-local storage", feel free to bikeshed
00:34:05  <othiym23>it's gotta say what it does and not instantly confuse everyone who hears it
00:34:11  * othiym23side-eyes domains
00:34:32  <tjfontaine>I really hate it, but I'm struggling for a replacement
00:34:38  <tjfontaine>but I haven't given up yet :P
00:35:37  <othiym23>I do feel that "continuation-local storage" is better than "local contexts", which is what I had originally
00:35:40  <tjfontaine>but I'm not really bothered by naming mismatch, as people often look for tcp and udp, only to find net and dgram
00:35:49  <tjfontaine>ya, local contexts is a no-go
00:36:30  * c4miloquit (Ping timeout: 256 seconds)
00:36:48  <trevnorris>all-the-contexts ?
00:37:02  <isaacs>tjfontaine: yeah, tcp/udp are the correct names. net/dgram are both stupid
00:37:07  <isaacs>it's tcp in all the code
00:38:58  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:39:32  <othiym23>dgram made total sense to me from the beginning, which I guess is yet another way to tell that I am a. old b. a nerd c. an old nerd
00:41:05  <tjfontaine>I have no problem understanding it, it's just not how we express it these days :)
00:41:09  * hzquit (Ping timeout: 248 seconds)
00:43:13  <othiym23>I will say that it was weird that there was net but not tcp, dgram, and then no unix
00:43:43  <isaacs>tjfontaine: fixed that for you: http://npm.im/tcp http://npm.im/udp
00:44:13  <tjfontaine>isaacs++
00:44:18  <isaacs>https://github.com/isaacs/udp/blob/master/udp.js
00:44:29  <isaacs>https://github.com/isaacs/tcp/blob/master/tcp.js
00:44:33  <tjfontaine>ya I looked :)
00:50:09  * st_lukequit (Remote host closed the connection)
00:52:47  * kazuponjoined
00:53:49  <trevnorris>haha, that was easy. already have most of it changed over and all tests passing.
00:55:28  <trevnorris>almost time for the performance tuning \m/(^o^)\m/
01:02:05  * kazuponquit (Ping timeout: 245 seconds)
01:03:44  * abraxasjoined
01:04:37  * mikealquit (Quit: Leaving.)
01:12:36  * dapquit (Quit: Leaving.)
01:19:14  * mikealjoined
01:26:46  <tjfontaine>trevnorris: does it change how util.inspect() sees _handle?
01:27:16  <trevnorris>tjfontaine: doesn't look like it.
01:27:23  <tjfontaine>mk
01:27:44  <trevnorris>tjfontaine: i'm out, see you in a few
01:27:54  <tjfontaine>k
01:37:41  * sblomquit (Ping timeout: 248 seconds)
01:41:23  * kazuponjoined
01:43:14  * kazuponquit (Remote host closed the connection)
01:45:05  * brsonquit (Quit: leaving)
01:46:26  * mikealquit (Quit: Leaving.)
02:17:51  <mordy__>what's the "API-correct" way to get the actual SOCKET/fd from a stream?
02:18:07  <mordy__>or is that intentionally obscured
02:18:24  * trapito_joined
02:20:24  * trapitoquit (Ping timeout: 240 seconds)
02:31:12  * brsonjoined
02:45:14  * bradleymeckjoined
02:54:55  * kazuponjoined
02:59:26  * kazuponquit (Ping timeout: 240 seconds)
03:18:08  * TooTallNatejoined
03:40:02  * st_lukejoined
03:49:45  * dominictarrjoined
03:57:03  * kazuponjoined
04:07:23  * st_lukequit (Remote host closed the connection)
04:16:51  * bradleymeck_joined
04:17:04  * bradleymeck_quit (Client Quit)
04:17:08  * julianduquequit (Quit: leaving)
04:17:31  * bradleymeckquit (Ping timeout: 268 seconds)
04:26:57  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:33:42  * dominictarrquit (Quit: dominictarr)
05:02:34  * kazuponquit (Read error: Connection reset by peer)
05:02:46  * kazuponjoined
05:14:31  <othiym23>trevnorris: I rewrote the CLS docs, they should make more sense now: https://github.com/othiym23/node/blob/a17fea125c0672ae53eb0b3fb6f15adc59d4b184/doc/api/continuation_local_storage.md
05:21:58  <othiym23>er fixed a few typos, so use: https://github.com/othiym23/node/blob/7840d52ae91242c7c10f304e3658b5221f07f7b0/doc/api/continuation_local_storage.md
05:36:17  * jmar777quit (Remote host closed the connection)
05:42:55  * groundwaterquit (Quit: groundwater)
05:45:27  * st_lukejoined
05:58:59  * mikealjoined
05:59:18  * mikealquit (Client Quit)
06:02:51  * defunctzombie_zzchanged nick to defunctzombie
06:07:01  * st_lukequit (Remote host closed the connection)
06:19:13  * trapitojoined
06:20:19  * trapito_quit (Ping timeout: 256 seconds)
06:22:01  * defunctzombiechanged nick to defunctzombie_zz
06:23:29  * bajtosjoined
06:25:40  * felixgejoined
06:28:00  * mikealjoined
06:28:08  * groundwaterjoined
06:49:36  * brsonquit (Quit: leaving)
06:53:19  * rendarjoined
07:09:03  * wolfeidauquit (Remote host closed the connection)
07:19:52  * mikealquit (Quit: Leaving.)
07:19:56  * hueniversejoined
07:20:23  * hzjoined
07:22:56  * defunctzombie_zzchanged nick to defunctzombie
07:29:41  * csaohjoined
07:32:25  * defunctzombiechanged nick to defunctzombie_zz
07:32:59  * `3E|Zzzchanged nick to `3E
07:40:20  * bnoordhuisjoined
07:47:38  * bnoordhuisquit (Ping timeout: 245 seconds)
07:51:48  * leonvvjoined
07:52:33  * Dasmyllerjoined
07:53:27  * dsantiagoquit (Ping timeout: 276 seconds)
07:59:05  * mikealjoined
08:03:05  * wolfeidaujoined
08:26:24  * dsantiag_joined
08:29:02  * dsantiag_changed nick to dsantiago
08:39:23  * trapitoquit (Read error: Connection reset by peer)
08:40:47  * trapitojoined
08:43:03  * bnoordhuisjoined
08:51:32  * dominictarrjoined
08:51:56  * tellnesjoined
08:52:57  * dominictarrquit (Client Quit)
08:56:53  * leonvvquit (Remote host closed the connection)
09:14:22  * dominictarrjoined
09:23:21  * dsantiagoquit (Ping timeout: 256 seconds)
09:23:49  * trapitoquit (Read error: Connection reset by peer)
09:26:30  * trapitojoined
09:40:09  * dsantiagojoined
09:52:38  * bajtosquit (Quit: bajtos)
09:58:07  * kazuponquit (Remote host closed the connection)
10:12:05  * csaohquit (Quit: csaoh)
10:13:54  <indutny>hoya
10:16:01  <bnoordhuis>sup fedor?
10:17:25  * csaohjoined
10:18:26  * wolfeidauquit (Remote host closed the connection)
10:20:12  * twilightfeeljoined
10:22:43  <indutny>bnoordhuis: good
10:22:45  <indutny>how are you?
10:23:46  <twilightfeel>indutny: hi :)
10:23:50  <indutny>hi
10:24:24  <twilightfeel>have you a bit of time todiscuss about custom connection handle? :)
10:24:33  <twilightfeel>https://github.com/joyent/node/issues/4435#issuecomment-22016362
10:25:43  <twilightfeel>i still need some solution, except «fork all the cluster and do what i want» :)
10:26:03  * wolfeidaujoined
10:29:47  * bajtosjoined
10:29:52  * bajtosquit (Client Quit)
10:33:31  <indutny>oh, sorry :)
10:33:34  <indutny>missed the message
10:33:57  <indutny>bnoordhuis: have a minute?
10:35:05  <indutny>bnoordhuis: about twilightfeel's thing - I think, the only solution to this would be refactoring cluster module a bit
10:35:25  <indutny>bnoordhuis: rewriting a RoundRobinHandle as a callback function instead
10:35:38  <indutny>bnoordhuis: though, it might require some exploration before heavily insisting on it
10:35:47  <indutny>bnoordhuis: do you have any thoughts regarding it?
10:37:30  * abraxasquit (Remote host closed the connection)
10:37:44  <bnoordhuis>indutny: just saw the github notification
10:38:07  <bnoordhuis>so, it's nice that you can provide a custom constructor
10:38:16  <bnoordhuis>but how is it going to tie in with the rest of node?
10:38:36  <bnoordhuis>the RoundRobinHandle and SharedHandle classes don't operate in a vacuum
10:38:44  <bnoordhuis>twilightfeel: ^
10:39:03  * wolfeidauquit (Remote host closed the connection)
10:39:33  <indutny>bnoordhuis: hm… may be inheritance?
10:39:46  <indutny>I'm still quite unfamiliar with that new cluster code that you wrote
10:40:41  <twilightfeel>yes, i know, as i wrote in the issue comment, i think supporting these changes for custom handle, if you really needs it, is not so costly as support of the full cluster fork
10:41:11  <bnoordhuis>indutny: what i mean is that there's a lot of under-the-hood action between the cluster, net and dgram modules
10:41:18  <bnoordhuis>the child_process module too, to a lesser extent
10:41:21  <twilightfeel>current handle interface looks simple (for me)
10:41:52  <indutny>bnoordhuis: what about custom `.distribute` method?
10:42:05  <indutny>or, at least, customizable callback here
10:42:22  <indutny>basically, all that user might need - is a way to choose right worker
10:42:29  <indutny>and that's what `.distribute` is basically doing
10:43:00  <bnoordhuis>well, maybe
10:43:13  <bnoordhuis>another issue is that we'd have to effectively freeze the internal cluster api
10:43:29  <bnoordhuis>i'm not ready to do that yet. maybe never
10:43:56  <indutny>hehe
10:44:09  <indutny>well, its just a callback to select worker
10:44:19  <indutny>it has nothing to do with freezing internal api
10:44:39  <bnoordhuis>does too
10:44:48  <bnoordhuis>that constructor is invoked with certain arguments
10:44:56  <indutny>well, you probably got me wrong
10:45:07  <indutny>its not about inheritance from RoundRobinHandle
10:45:17  <indutny>its about new option passed to it
10:45:25  <bnoordhuis>yeah, i got that
10:45:33  <indutny>or, better to cluster itself
10:45:34  <bnoordhuis>your distribute() function needs context though
10:45:50  <indutny>its an async callback
10:45:58  <bnoordhuis>that's the address/port/type/fd data that gets passed to the constructor now
10:45:59  <indutny>and context might be set to `server` object
10:46:01  <indutny>hm..
10:46:03  <indutny>or to `null`
10:46:08  <indutny>i.e. global
10:46:22  <bnoordhuis>yeah, so
10:46:27  <indutny>well, I don't want users to rewrite this function from scratch
10:46:32  <bnoordhuis>if you pass that kind of information to user functions
10:46:39  <bnoordhuis>it effectively becomes public api
10:46:39  <indutny>having an optional callback that might be invoked from it works for me too
10:47:01  <indutny>well, we're talking about adding new API feature anyway :)
10:47:13  <twilightfeel>)
10:47:33  <indutny>cluster.setupMaster({ distribute: function(workers) { return ~~(Math.random() * workers.length) } })
10:47:35  <indutny>;)
10:47:47  <indutny>where workers are basically result of `cluster.fork()`
10:48:05  <indutny>and all other info user should obtain via messaging
10:48:21  <indutny>oh, small correction
10:48:30  <indutny>that `distribute` function should be async
10:48:42  <bnoordhuis>that doesn't work or is pointless with shared handles
10:49:01  <bnoordhuis>there's nothing to distribute because the server handle - and hence the client handle - is already in the worker
10:49:45  <indutny>huh
10:50:05  <indutny>I believe we're talking just about distributing incoming connections
10:50:08  <indutny>not shared handles
10:50:13  <twilightfeel>yes
10:50:30  <bnoordhuis>oh
10:50:40  <bnoordhuis>then there's no need to pass in a custom constructor
10:50:50  <bnoordhuis>i guess that's what threw me off
10:51:23  <bnoordhuis>if we're only talking about master-distributed handles, then yes, a custom .distribute() function could work
10:51:33  <indutny>yikes! :)
10:51:36  <indutny>I convinced ben
10:51:45  <indutny>hehe
10:51:50  <bnoordhuis>well, only partially
10:51:55  <indutny>ok ok
10:52:02  <bnoordhuis>there's still the issue of how to deal with workers coming offline or going away
10:52:17  <bnoordhuis>i guess the user should take care of that himself
10:52:18  <indutny>well...
10:52:33  <indutny>if you want user to care of it himself
10:52:38  <twilightfeel>bnoordhuis: yes, i think so
10:52:44  <indutny>custom distribute function should not receive workers list
10:53:11  <indutny>ah
10:53:11  <indutny>well
10:53:20  <indutny>it might just invoke callback with worker object
10:53:24  <indutny>and it'll be passed to .handoff
10:53:33  <indutny>ok, that sounds reasonably to me
10:53:34  <bnoordhuis>did i just type 'coming offline'. s/offline/online/
10:53:49  <indutny>it doesn't matter that much :)
10:53:53  <indutny>oh
10:53:56  <indutny>I think I see your point
10:54:40  <indutny>worker might be not ready to receive the handle?
10:54:43  <indutny>is it even possible?
10:54:56  <indutny>but whatever it is, users can handle it
10:55:26  <bnoordhuis>well, i hope so
10:55:35  <bnoordhuis>but yes, the worker might not be ready
10:55:42  <bnoordhuis>it happens when shutting down a worker
10:56:05  <bnoordhuis>because conn.close() is effectively synchronous
10:56:32  <bnoordhuis>there's a comment about it somewhere in cluster.js that explains it
10:56:47  <bnoordhuis>there are other edge cases too
10:57:42  <bnoordhuis>let it be said that if (and that's a big if) we're adding a distribute api, i will not be the one writing the docs for it
10:58:37  <bnoordhuis>okay, i'm off to lunch :) biab
10:59:06  <twilightfeel>bnoordhuis: thanks for discussion! :)
11:03:52  * bnoordhuisquit (Ping timeout: 260 seconds)
11:05:49  <indutny>:)
11:05:50  <indutny>brb
11:09:55  * bajtosjoined
11:13:08  * kazuponjoined
11:57:53  * paddybyersjoined
12:13:17  <MI6>joyent/node: Fedor Indutny master * 048e0e7 : tls: asynchronous SNICallback (+1 more commits) - http://git.io/w0O_3A
12:13:25  <indutny>yaY!
12:23:57  * pachetjoined
12:29:42  * kazuponquit (Remote host closed the connection)
12:37:47  * abraxasjoined
12:37:55  * saghulquit (Ping timeout: 245 seconds)
12:41:26  * abraxasquit (Read error: Operation timed out)
12:41:35  * saghuljoined
12:47:02  * rjequit (Ping timeout: 264 seconds)
12:47:26  * paddybyersquit (Ping timeout: 246 seconds)
12:48:38  * rjejoined
12:53:01  * kazuponjoined
12:55:19  * twilightfeelquit (Quit: twilightfeel)
12:55:26  * saghulquit (Ping timeout: 240 seconds)
12:56:01  * paddybyersjoined
12:58:32  * saghuljoined
13:06:10  * kazuponquit (Remote host closed the connection)
13:08:36  * jmar777joined
13:11:27  * bnoordhuisjoined
13:12:25  * kazuponjoined
13:22:02  * paddybyersquit (Ping timeout: 268 seconds)
13:22:41  <bnoordhuis>../../src/node_crypto_clienthello.cc:144: warning: comparison between signed and unsigned integer expressions
13:22:44  <bnoordhuis>../../src/node_crypto_clienthello.cc:146: warning: comparison between signed and unsigned integer expressions
13:22:47  <bnoordhuis>^ indutny
13:25:28  <bnoordhuis>ah... i think it's because (server_names_len + 2) gets widened to int
13:26:52  * kazuponquit (Remote host closed the connection)
13:29:30  * piscisaureus_joined
13:37:26  * piscisaureus_quit (Ping timeout: 240 seconds)
13:38:07  * hzquit (Disconnected by services)
13:38:11  * hzjoined
13:40:38  <MI6>joyent/node: Ben Noordhuis master * 5764966 : crypto: fix signed/unsigned comparison warning - http://git.io/Sv2trg
13:45:47  * c4milojoined
13:50:39  <MI6>joyent/node: Ben Noordhuis master * 45d056e : src: fix WITH_GENERIC_STREAM() type check bug - http://git.io/mOHYjw
13:50:41  <bnoordhuis>indutny: ^
13:55:30  * twilightfeeljoined
14:14:21  * kazuponjoined
14:24:20  * twilightfeelquit (Quit: twilightfeel)
14:27:16  * AvianFlujoined
14:29:20  * kazuponquit (Remote host closed the connection)
14:34:23  * piscisaureus_joined
14:46:17  * mikealquit (Read error: Connection reset by peer)
14:58:33  <isaacs>anyone wanna review some http stuff? https://github.com/joyent/node/pulls/isaacs
15:03:55  * indexzerojoined
15:07:07  * bradleymeckjoined
15:10:43  <roxlu>hey guys!
15:16:59  <isaacs>tjfontaine: before the v0.11 release, we'll have to merge in v0.10.latest
15:17:23  <isaacs>tjfontaine: i'm landing that streams fix from hueniverse in v0.10. it's a good bugfix.
15:17:29  <isaacs>tjfontaine: also, newer npm
15:18:02  * austojoined
15:18:12  <MI6>joyent/node: Eran Hammer v0.10 * 23d92ec : stream: Fix double pipe error emit - http://git.io/2aGOQQ
15:22:40  * piscisaureus_quit (Ping timeout: 264 seconds)
15:25:16  <roxlu>some of my fellow coders are starting to use libuv too and more are getting these windows errors that happen when you include uv.h after winows.h has been included (or I think that's the reason for these errors).
15:25:39  <roxlu>But I'm wondering why uv.h doesn't work then? (or give compiler errors)
15:26:52  * kazuponjoined
15:27:13  * mikealjoined
15:30:05  <bnoordhuis>roxlu: it's because uv.h polyfills a lot of stuff
15:30:59  <indutny>bnoordhuis: thanks
15:31:23  <bnoordhuis>indutny: the WITH_GENERIC_STREAM bug? it was pretty harmless in practice
15:31:30  <indutny>both
15:31:31  <indutny>:)
15:31:35  <bnoordhuis>ah okay :)
15:31:36  <indutny>crypto unsigned/signed
15:31:38  <indutny>and define
15:31:41  <roxlu>bnoordhuis: polyfills?
15:31:43  * roxlugoogling
15:31:55  <indutny>bnoordhuis: oh its pretty awful bug :)
15:32:02  <indutny>a lot of copy paste happened there
15:32:09  <bnoordhuis>roxlu: it sniffs the environment to see what will and won't work
15:32:46  <roxlu>probably not this he: http://www.tooled-up.com/Artwork/ProdZoom/PLCQDP330GS.jpg :)
15:32:49  * mikealquit (Quit: Leaving.)
15:33:12  <bnoordhuis>roxlu: WIN32_LEAN_AND_MEAN being defined/undefined when windows.h is included probably also plays a part
15:33:30  <bnoordhuis>and no, not that kind of polyfill :)
15:33:30  <roxlu>yeah I'm adding that one indeed
15:33:34  <roxlu>haha
15:34:21  <roxlu>a friend who started using libuv (and me too btw) get these uv.h related errors
15:34:37  <roxlu>but not all the time, but their are always kinda tricky to solve
15:35:09  <roxlu>From what I undestood, can I fix it by including uv.h before any winodws.h right?
15:36:29  <bnoordhuis>roxlu: yes, that should do it
15:37:25  <roxlu>wouldn't it be possible to make changes in uv.h to fix this? or is this just not going to work because of windows.h
15:37:46  <roxlu>I'm asking because this would make uv.h even nicer :)
15:38:33  <bnoordhuis>hm, i don't know. piscisaureus is the one to ask
15:38:53  <roxlu>okido
15:40:31  <bnoordhuis>from process_wrap.cc: obj->Get(Number::New(static_cast<double>(i))) -- really?
15:47:37  * groundwaterquit (Quit: groundwater)
15:50:21  <indutny>call in 10 minutes?
15:50:27  <indutny>isaacs: bnoordhuis: ^
15:50:30  <indutny>tjfontaine: ^
15:50:38  <indutny>trevnorris: ^
15:50:43  * hueniversequit (Quit: Leaving.)
15:52:26  <MI6>joyent/node: Ben Noordhuis master * b8a7eed : process_wrap: omit superfluous Number creation - http://git.io/DP3F7Q
15:52:31  <austo>bnoordhuis: I know this is a pretty general question, but is there anything specific I should be looking for when my uv_tcp_t seems to stop listening after a uv_write? (IOW after a broadcast to a bunch of clients)?
15:53:04  <bnoordhuis>austo: are you calling uv_write() on a tcp handle that's listening? or am i misunderstanding you?
15:53:39  <bnoordhuis>indutny: i have another call in a few
15:53:49  <indutny>so… no call today?
15:53:59  * piscisaureus_joined
15:54:33  <tjfontaine>indutny: there should be a call today, afaik
15:55:37  * AvianFluquit (Remote host closed the connection)
15:55:45  <austo>bnoordhuis: no, that's what's happening
15:57:06  * mcavagejoined
15:58:25  * sblomjoined
15:59:03  <trevnorris>morning
15:59:39  * kenperkinsquit (Quit: Computer has gone to sleep.)
16:00:15  <isaacs>good morning
16:00:18  <isaacs>call today yes, please
16:00:21  <isaacs>opening up now
16:00:39  * tjfontainegoes to meeting room
16:00:47  <isaacs>https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:01:09  <austo>bnoordhuis: inside a uv_after_work_cb I iterate through a list of clients and call uv_write on their uv_write_t handles. The message gets delivered but the server seems to stop listening after that.
16:01:13  * brsonjoined
16:02:44  <isaacs>bnoordhuis: you and bert should trade meetings
16:02:45  <bnoordhuis>austo: right, okay. the short answer is: don't do that :)
16:03:16  <bnoordhuis>isaacs: yeah, maybe i'll join the status call. i pretty much know what's going to be discussed at the strongloop call
16:11:33  <austo>bnoordhuis: okay, cool... any suggestions on where to find the long answer?
16:12:57  * mikealjoined
16:21:49  * paulfryzeljoined
16:24:01  * AvianFlujoined
16:24:26  * hzquit (Remote host closed the connection)
16:24:26  * mraleph1joined
16:24:48  * dapjoined
16:24:51  * mralephquit (Read error: Connection reset by peer)
16:25:14  <bnoordhuis>austo: sorry, in a call. biab
16:30:47  <MI6>nodejs-master-windows: #176 UNSTABLE windows-ia32 (18/619) windows-x64 (19/619) http://jenkins.nodejs.org/job/nodejs-master-windows/176/
16:31:22  <austo>bnoordhuis: no problem... I'm doing a little digging anyway
16:32:59  <indutny>bnoordhuis: hoya
16:33:00  <indutny>bnoordhuis: https://github.com/joyent/node/pull/6002
16:34:11  * csaohquit (Quit: csaoh)
16:38:32  * hzjoined
16:41:47  * bradleymeckquit (Remote host closed the connection)
16:42:13  * bradleymeckjoined
16:47:06  * AvianFluquit (Remote host closed the connection)
16:52:13  <trevnorris>bnoordhuis: nice work on the multi context support. so is it mostly working?
16:52:16  * c4miloquit (Remote host closed the connection)
16:52:37  <bnoordhuis>trevnorris: well, mostly working... let's say it's not completely broken right now
16:52:52  <trevnorris>heh, ok
16:53:06  * indexzeroquit (Quit: indexzero)
16:53:07  <bnoordhuis>there's still more work that needs to be done, like adding the ability to start several scripts from the command line
16:53:15  <trevnorris>ooh, cool.
16:53:16  <bnoordhuis>that's not a hard requirement btw, just a nice-to-have
16:53:26  <bnoordhuis>but i might as well get it in now, right?
16:53:33  <trevnorris>sure why not
16:53:56  <bnoordhuis>on that subject, ContextData* context_data or Environment* env? :)
16:54:05  <trevnorris>think it's worth benchmarking right now, or more changes coming that'll change those?
16:54:15  <bnoordhuis>i've been using context_data so far but it's kind of unwieldy to type
16:54:35  <bnoordhuis>don't benchmark it just yet, it's not at that stage yet
16:54:52  <trevnorris>coolio, and Environment* env is more friendly to the fingers for sure
16:55:08  <bnoordhuis>yeah, i think so too. i'll probably change it to that
16:55:23  <tjfontaine>contextdata is perhaps too easy to conflate with v8::Context
16:55:33  <tjfontaine>but they are related
16:56:01  <trevnorris>feels like almost every line in src/ has been touched in v0.11
16:56:01  <bnoordhuis>yeah, one is a property of the other
16:56:10  <bnoordhuis>feels good, doesn't it?
16:56:21  <bnoordhuis>a fresh start, a clean break
16:56:21  * amartensjoined
16:56:34  <bnoordhuis>almost as good as rewriting the whole thing from scratch
16:57:19  <bnoordhuis>okay, enough merry banter, time for dinner. biab :)
16:59:26  * Benviejoined
17:01:35  * bnoordhuisquit (Ping timeout: 240 seconds)
17:04:32  * groundwaterjoined
17:13:01  * bradleymeckquit (Quit: bradleymeck)
17:17:27  * AvianFlujoined
17:19:04  * piscisaureus_quit (Read error: No route to host)
17:19:51  * piscisaureus_joined
17:19:58  * AndreasMadsenjoined
17:20:07  * bradleymeckjoined
17:23:13  * TooTallNatejoined
17:25:50  * AvianFluquit (Ping timeout: 245 seconds)
17:27:08  * paulfryzelquit (Remote host closed the connection)
17:27:48  * paulfryzeljoined
17:30:38  <indutny>isaacs: mind reviewing https://github.com/joyent/node/pull/6002 ?
17:40:26  * indexzerojoined
17:40:32  * c4milojoined
17:40:47  * julianduquejoined
17:41:17  <brson>how cheap are idle callbacks? the rust scheduler executes it's main work in an idle callback, but someone is suggesting to me that it will be faster for us to avoid the idle callbacks and instead use run with NO_WAIT. I'm guessing though that calling an callback is cheap compared to the rest of the work that the uv_run loop has to do
17:41:31  * inolenquit (Quit: Leaving.)
17:41:49  <brson>*idle callback
17:42:41  * inolenjoined
17:44:50  * indexzeroquit (Client Quit)
17:46:39  * AvianFlujoined
17:47:46  * dominictarrquit (Quit: dominictarr)
17:56:16  * sblomquit (Ping timeout: 264 seconds)
17:58:04  * piscisaureus_quit (Ping timeout: 264 seconds)
17:59:17  * indexzerojoined
18:00:45  <tjfontaine>I don't think we need to worry about the merge conflict from https://github.com/joyent/node/commit/3398cce1934004e4d60c7d7605fa7548582c362f because we're doing the cork/uncork work now?
18:03:32  * indexzeroquit (Client Quit)
18:03:32  * defunctzombie_zzchanged nick to defunctzombie
18:07:44  <trevnorris>assert(0); abort(); <- will the abort() ever be reached?
18:07:54  * hzquit (Disconnected by services)
18:07:57  * hzjoined
18:08:30  <tjfontaine>yes, depending on if asserts were compiled in
18:09:03  <trevnorris>ok, so only if asserts were compiled in. cool.
18:14:28  * jmar777quit (Read error: Connection reset by peer)
18:14:57  * jmar777joined
18:23:04  * AvianFluquit (Remote host closed the connection)
18:27:51  * julianduquequit (Ping timeout: 276 seconds)
18:31:55  * jmar777quit (Read error: Connection reset by peer)
18:32:19  * jmar777joined
18:37:48  * bajtosquit (Quit: bajtos)
18:38:26  * brsonquit (Quit: Lost terminal)
18:38:39  * indexzerojoined
18:38:42  * abraxasjoined
18:38:52  * AndreasMadsenquit (Remote host closed the connection)
18:39:04  * brsonjoined
18:43:07  * hzquit (Ping timeout: 264 seconds)
18:43:39  * kazuponquit (Remote host closed the connection)
18:43:40  * abraxasquit (Ping timeout: 264 seconds)
18:48:22  <trevnorris>tjfontaine: so w/ the external array pointer patch we'll be able to place the instance on any js object. imho it could simplify the internals to make the instances themselves attached to the class instead of having everything attached to ._handle or whatever
18:50:45  <isaacs>indutny: looking
18:51:11  <isaacs>indutny: like the new gravatar.
18:51:20  <indutny>thanks
18:52:36  <isaacs>indutny: lgtm, but please let tjfontaine finish the v0.10 merge before landing
18:52:41  <indutny>sure
18:53:19  <isaacs>indutny: is there an issue that this is related to? or is no one using this feature? from the fix, it looks like it's pretty obviously wrong right now...
18:53:24  <indutny>nope
18:54:48  <trevnorris>isaacs: thoughts on using the new method to attach the c++ class instance directly to the js object instead of attaching it to ._handle or whatever?
18:55:25  <isaacs>trevnorris: _handle is internal API. the only thing that i can think that it'd bust is the DTrace and MDB stuff.
18:55:32  <tjfontaine>https://github.com/tjfontaine/node/commit/822552dda6fb740541348492cb540b9ebaac608b
18:55:41  <trevnorris>cool.
18:59:40  <trevnorris>and hey, who the hell cares about dtrace? never found it that useful really.
19:00:41  * AndreasMadsenjoined
19:02:15  <isaacs>dap: ^ also, it's lunch o'clock
19:12:52  * AvianFlujoined
19:13:55  * kazuponjoined
19:23:02  * kazuponquit (Ping timeout: 240 seconds)
19:26:08  * paulfryz_joined
19:26:55  * paulfry__joined
19:29:36  * paulfryzelquit (Ping timeout: 276 seconds)
19:30:45  * paulfryz_quit (Ping timeout: 264 seconds)
19:31:15  * paulfry__quit (Ping timeout: 245 seconds)
19:33:00  <indutny>oh gosh
19:49:34  <creationix>trevnorris, you said " I almost feel like there's some better type of hook system that we could build in here somewhere. That like even domains could ride on."
19:49:47  <creationix>what do you think about my proposed callback hook
19:50:01  <creationix>it certainly fits the description of simple and powerful
19:50:53  <trevnorris>reading
19:52:02  * c4miloquit (Remote host closed the connection)
19:57:01  <trevnorris>ahhh.... holy shit. does the current pr really wrap all nextTick callbacks?
19:58:53  <creationix>trevnorris, I think so https://github.com/joyent/node/pull/5990/files#L5L417
19:59:09  <creationix>I don't quite understand how nextTick is implemented in node
19:59:15  <trevnorris>haha
19:59:23  <creationix>I've always envisioned it as I put in my sample library
19:59:24  <trevnorris>creationix: maybe 5 people do
19:59:35  <creationix>why does it need to be so complicated
19:59:44  <creationix>it's just a queue of callback at the end of every js stack
19:59:54  <creationix>while (callbacks) run callback
20:00:20  <trevnorris>it's gotten simpler, and the fact that domains exist make things much worse.
20:00:25  <trevnorris>but that's the basic idea.
20:00:38  <mikeal>creationix: i think it tries to protect against infinite occurrences of that, so new nextTick()'s can't infinitely block
20:00:47  <mikeal>or is that setImmediate?
20:00:55  <trevnorris>that's setImmedate
20:01:06  <mikeal>nextTick got more confusing with setImmediate :)
20:01:25  <creationix>yep, unfortunate naming
20:01:34  <creationix>nextTick should really be afterTick
20:01:44  * hzjoined
20:02:01  <creationix>setImmediate should be setSoon
20:02:11  <creationix>not that we can change any of that now
20:02:49  <trevnorris>it's actually not that complicated anymore. a lot of stuff has been removed from v0.10
20:02:55  <trevnorris>domains just make it more difficult
20:03:21  * kenperkinsjoined
20:03:36  <indutny>isaacs: tadam https://github.com/joyent/node/pull/6004
20:03:43  <indutny>;)
20:03:44  <creationix>trevnorris, my point with the comment was that even domains don't have to interfere with nextTIck
20:03:49  <indutny>please take a look once you'll have some time
20:03:55  <creationix>but maybe we want them too, hmm
20:04:00  <creationix>s/too/to
20:04:35  <creationix>trevnorris, yeah, I guess it's bad semantics for all nextTicks to run in the top-level domain/context
20:04:50  <creationix>which is what my code would do since all stacks have unwound at that point
20:06:14  * AndreasMadsenquit (Remote host closed the connection)
20:06:51  * brsonquit (Quit: Lost terminal)
20:07:28  <trevnorris>to be honest I still don't understand the need for all this, but that's besides the point. pretty sure there's a hook system that'll allow anyone to add a large number of things w/o interfering with my performance.
20:07:30  * brsonjoined
20:07:55  <creationix>trevnorris, a hook system different than the minimal one I've proposed
20:07:59  <creationix>I'm not talking about cls
20:08:07  <creationix>that can easily live in userspace if there is a hook for it to grab on
20:08:29  <creationix>but monkey-patching from the outside is somewhere between impossible and terrible slow and complicated
20:08:45  <creationix>(for certain event sources)
20:09:15  <creationix>trevnorris, the hook all these use cases have in common is the same
20:09:18  <trevnorris>your api was more the end-user api. i'm more concerned w/ the implementation.
20:09:35  <creationix>in luvit I did it about where node's makeCallback lives
20:09:41  <creationix>luvit has a hook like this
20:11:06  <trevnorris>also i'm not sure how all this will be affected w/ ben's upcoming multi-context changes
20:13:40  * mikealquit (Quit: Leaving.)
20:13:57  * hzquit (Disconnected by services)
20:14:18  * hzjoined
20:15:15  <trevnorris>also i'm getting lost in all the words. is it basically, there's information we want to attach to a given callback that we can inspect at any given moment in time?
20:15:44  <creationix>multi-context?
20:15:44  <trevnorris>creationix: ^
20:15:48  <creationix>what kind of context?
20:15:53  <creationix>like v8 isolate?
20:16:07  <trevnorris>no, v8 context. basically like a proper sandbox.
20:16:19  <creationix>oh, so more than an isolate
20:16:36  <creationix>context like the set of globals in every browser tab?
20:16:56  <tjfontaine>creationix: https://github.com/bnoordhuis/node/compare/joyent:master...multi-context
20:17:16  <trevnorris>well, different. a context basically defines another global scope where stuff can run w/o interfering with everything else.
20:17:22  <trevnorris>man, my brain is fried.
20:18:43  <creationix>right, the global context in js
20:18:53  * bnoordhuisjoined
20:18:54  <creationix>or [context] as the ecma spec puts it
20:19:15  * kazuponjoined
20:20:10  <MI6>joyent/node: Timothy J Fontaine master * b26d346 : Merge remote-tracking branch 'upstream/v0.10' (+11 more commits) - http://git.io/cLgFIg
20:20:16  * c4milojoined
20:20:28  <MI6>nodejs-master-windows: #177 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/177/
20:21:19  <tjfontaine>aha, it's throwing GC overhead limit exceeded
20:21:22  <tjfontaine>fucking
20:21:22  <tjfontaine>java
20:21:54  <creationix>bnoordhuis, so in multi-context, each context will have a copy of all node variables right?
20:21:58  <creationix>it's own require, require cache
20:22:00  <creationix>etc
20:22:06  <creationix>or are some things shared
20:23:15  <creationix>if it's share nothing, then it shouldn't affect the event hook stuff. You'd just need a unique set of event hooks per context
20:23:26  * kazuponquit (Ping timeout: 240 seconds)
20:25:33  <bnoordhuis>creationix: everything has its own copy
20:26:25  <creationix>yeah, then that shouldn't affect this stuff
20:26:50  <creationix>bnoordhuis, but people can share stuff among contexts if they want right?
20:26:57  <creationix>assuming context creation is a js API
20:27:27  <trevnorris>creationix: so back to a previous question. at the most basic level is the point just to attach some data to a listener function and allow that to propagate for the life of the callback?
20:27:38  <creationix>trevnorris, sortof
20:27:44  <creationix>trevnorris, there are many use cases
20:27:49  <creationix>but all of them have a common need
20:28:03  <creationix>they need some function called when an event source is created *and* when the event happens
20:28:15  <creationix>and usually a way to hook before and after the event
20:28:28  <creationix>let's take long-stack traces as an example
20:28:33  <creationix>you need to know the parent stack trace
20:28:38  <creationix>that's the one that creates the event source
20:28:42  <creationix>like the call to setTimeout
20:28:55  <creationix>then later the timer fires in libuv and we call back into javascript
20:29:07  <creationix>I need to be able to remember the stack I had back when setTimeout was called
20:29:15  <creationix>with my proposed API, it's in the closure
20:29:26  <creationix>by replacing the root callback with a new one, we can store anything in the closure
20:30:08  <creationix>since we wrap the event callback, we can do things like try..catch for error handling (domains) or try..finally to know when a scope exits
20:30:40  <creationix>it could be done without closures and arbitrary code, but exposing all the functionality would be a lot of API
20:31:48  * stagasquit (Read error: Connection reset by peer)
20:32:22  <trevnorris>but still, that's all just data. stuff that could be stored in an Object and that needs to propagate with that unique event instance.
20:32:52  <creationix>but how do you know what data to store?
20:33:04  <creationix>you'd have to encompass all the data people might want to read from the system
20:33:28  <creationix>in both my nextTick and cls examples, I read data local to my module's inner closure
20:33:32  <creationix>node could never read that data for me
20:35:08  <trevnorris>let's forget what data we'd want to store for now. instead I'm concerned about when data should be stored.
20:35:37  * jmar777quit (Remote host closed the connection)
20:37:07  <bnoordhuis>creationix: it's TBD if js code can spin up new contexts
20:37:48  <creationix>trevnorris, so the data to be stored needs to read during times that create new callbacks
20:37:53  <creationix>so that new callbacks can later read it
20:37:54  <bnoordhuis>brson: idle handles have close to zero overhead
20:38:06  <isaacs>indutny: lgtm, but minor nit on the test.
20:38:18  <trevnorris>ok, need a break. creationix give me 5. think I might have an internal solution to solve this and the domain's performance problem. but need a moment to clear my head.
20:38:20  <creationix>trevnorris, simple examples are things that are uv_req_t in libuv
20:38:27  <creationix>trevnorris, ok
20:39:30  <indutny>isaacs: which one?
20:39:57  <isaacs>indutny: https://github.com/joyent/node/pull/6004
20:40:14  <indutny>ah, I have received no notification
20:40:15  <indutny>thank you!
20:40:19  <isaacs>indutny: it'd be better to just have a variable to swithc back and forth between the two workers, rather than Math.random
20:40:23  <indutny>got it
20:40:29  * stagasjoined
20:43:53  * mikealjoined
20:44:01  <kellabyte>I remember talk about making it easier to move from one event loop to another, has there been any work on that? I'm maxing out a core so I need to start using more of the CPU :P
20:44:32  <tjfontaine>I think the way is to just use a pipe between them and send the handles with uv_write2, bnoordhuis was talking about it yesterday
20:45:13  <kellabyte>tjfontaine: what do you mean by a pipe between them?
20:45:45  <tjfontaine>uv_pipe_t
20:46:11  <tjfontaine>kellabyte: https://github.com/joyent/libuv/blob/master/include/uv.h#L654-L662
20:47:17  <kellabyte>ah hmm
20:48:28  * mikealquit (Ping timeout: 264 seconds)
20:48:46  <kellabyte>tjfontaine: so you create a thread, and that thread listens on a pipe, and the original socket sends what over the pipe?
20:50:10  <brson>bnoordhuis: thanks for confirming my beliefs!
20:50:22  <trevnorris>creationix: ok, i'm back.
20:51:20  <bnoordhuis>kellabyte: correct, with uv_write2()
20:51:26  <bnoordhuis>man, i really hate that name
20:51:30  <kellabyte>haha
20:52:26  <kellabyte>bnoordhuis: what exactly do I send over the pipe? do I have to keep track of the requests and then the worker threads send a signal back to the event loop thread, looks up a hashmap for the request?
20:53:06  <bnoordhuis>kellabyte: you want to share handles across multiple threads, right?
20:54:17  <kellabyte>bnoordhuis: yeah, can I actually do that?
20:54:22  <bnoordhuis>yep
20:54:36  <bnoordhuis>'share' is not the right word, really. 'hand off' is more appropriate
20:55:19  <bnoordhuis>you create a server socket or uv_accept() a listen socket, then send it over the pipe with uv_write2()
20:55:52  <creationix>trevnorris, alright, what did you come up with
20:56:33  <kellabyte>bnoordhuis: wow hmm!
20:56:46  <bnoordhuis>kellabyte: oh, and the other side should listen on the pipe with uv_read_start2() rather than uv_read_start()
20:56:48  <brson>is there any way to hand off handles without sending them through a pipe? in the rust scheduler I would like to be able to do I/O on whichever event loop a task happens to find itself on - I can't arrange beforehand to establish a pipe between two event loops?
20:56:59  <brson>*no question mark
20:57:46  <MI6>joyent/node: Fedor Indutny master * 166c405 : tls: fix lazy initialization of clienthello parser - http://git.io/dogR5Q
20:58:35  <kellabyte>bnoordhuis: so say this thread receives the handle on the pipe, and now needs to send a response, can it do that?
20:59:01  <bnoordhuis>brson: not right now. we used to have uv_export() and uv_import() functions for that way back when but we scratched those
20:59:13  <indutny>bnoordhuis: ping
20:59:19  <indutny>I need your opinion on implementation of https://github.com/joyent/node/pull/6004/files
20:59:22  <bnoordhuis>brson: i guess we could readd them. it's pretty trivial on unix but probably less so on windows
20:59:31  <indutny>particularly this one comment https://github.com/joyent/node/pull/6004/files#r5614849
20:59:36  <bnoordhuis>indutny: i'm going to sit on the fence on that one for a while
20:59:37  <trevnorris>bnoordhuis: well, even if we don't use the external data pointer patch thing, at least we can commit the macro-ified cleanup of code.
20:59:43  <indutny>bnoordhuis: ah
20:59:54  <indutny>must be unpleasant experience
20:59:58  <indutny>sitting on the fence
21:00:03  <bnoordhuis>indutny: yeah, it's pretty rough
21:00:24  <indutny>I empathize to you heavily
21:00:26  <bnoordhuis>kellabyte: yeah. your read2_cb gets an extra argument, the handle type
21:00:32  <indutny>s/to//
21:00:38  <brson>bnoordhuis: are import/export expensive operations?
21:00:48  <indutny>brb
21:00:59  <brson>bnoordhuis: can i export and reimport between every read/write?
21:01:03  <bnoordhuis>kellabyte: you then create a new handle based on the handle type, call uv_accept(&pipe_handle, &new_handle) and done
21:01:31  <bnoordhuis>brson: you'll probably take a pretty big performance hit on windows that way
21:01:45  * wolfeidaujoined
21:02:09  <bnoordhuis>brson: it won't be cheap on unices either because libuv will have to unregister and reregister the fd with epoll/kqueue/etc. all the time
21:02:13  <tjfontaine>anything else to go in master before I start the release?
21:03:00  <bnoordhuis>kellabyte: btw, you can take a look at test/benchmark-multi-accept.c
21:03:17  * mikealjoined
21:03:20  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:03:21  <brson>bnoordhuis: that's true of read_start/read_stop too I assume? We currently always issue read_stop after a successful read
21:03:22  <kellabyte>bnoordhuis: great, thanks, I don't think I understood that last step you described, lemme go read :)
21:03:25  <bnoordhuis>kellabyte: the test/test-ipc* tests too probably
21:04:11  <bnoordhuis>brson: yes, unless you call read_start again before the next event loop tick
21:04:22  <kellabyte>bnoordhuis: great, thanks! part of my problem now is if a user issues 1 query that takes awhile, all the other cores are idle and this operation is holding people up
21:04:27  * paulfryzeljoined
21:04:34  <kellabyte>bnoordhuis: so need to start thinking about using the cores in the machine better :)
21:04:39  <brson>bnoordhuis: oh, that's good. so it's cheap if i read_stop/read_start without dropping back to the loop?
21:04:42  <brson>that's probably the common case
21:04:54  <bnoordhuis>brson: yeah
21:05:09  * indexzeroquit (Quit: indexzero)
21:05:11  <bnoordhuis>kellabyte: oh. what does a query do? maybe something like a thread pool would be more appropriate
21:05:14  * pachetquit (Quit: leaving)
21:05:16  <tjfontaine>ok, starting v0.11.5
21:05:39  <bnoordhuis>tjfontaine: you should include the diffstat in the announce email :)
21:05:43  <kellabyte>bnoordhuis: it goes off to the DB to process the query, get the results, then it needs to send the http response
21:05:49  <MI6>joyent/node: tjfontaine created branch v0.11.5-release - http://git.io/FmRF0Q
21:05:49  <trevnorris>creationix: lowest level api, event-type listener for queued callbacks. it'll call the callbacks synchronously and pass, at the least, the callback and an object that's promised to propagate with the callback.
21:05:52  <tjfontaine>bnoordhuis: heh
21:06:01  <bnoordhuis>kellabyte: is the db query synchronous or asynchronous?
21:06:03  <kellabyte>bnoordhuis: DB meaning internal storage, thats running in the same C process
21:06:18  <kellabyte>bnoordhuis: synchronous, its just some C calls
21:06:18  <bnoordhuis>ah, okay. so it's cpu bound?
21:06:34  <bnoordhuis>no file or other i/o involved?
21:06:51  <trevnorris>creationix: then the user can store whatever they want. domains could be easily reimplemented on top of that.
21:06:51  <kellabyte>bnoordhuis: there's file io but its not using libuv, its a storage engine in C
21:07:25  <bnoordhuis>kellabyte: okay. in that case that file i/o could become your bottleneck. that's usually when you start offloading work to a thread pool
21:07:36  <bnoordhuis>libuv and node do the same thing for file i/o
21:08:01  <kellabyte>bnoordhuis: but the uv_write to send the response needs to be done on the event loop right?
21:08:15  <bnoordhuis>kellabyte: yes, that's correct
21:08:18  <tjfontaine>jeepers this changelog
21:08:37  <kellabyte>bnoordhuis: so how do you get from the thread pool, back to the event loop thread to send the response?
21:09:12  <creationix>trevnorris, that sounds a lot like context-local-storage
21:09:15  <bnoordhuis>kellabyte: uv_queue_work() handles that for you. you give it a work_cb and a done_cb. the work_cb is invoked in the thread pool, the done_cb on the event loop thread
21:09:16  <othiym23>trevnorris: what's the API look like for getting at that object (which I'm going to call the copilot just for funsies)?
21:09:34  <othiym23>trevnorris: and I agree with creationix, that sounds a lot like the API we've already sketched out
21:09:39  <isaacs>tjfontaine: want me to review the cl?
21:09:59  <bnoordhuis>kellabyte: one thing to keep in mind is that the thread pool on unix defaults to 4 threads currently. you can scale it with the UV_THREADPOOL_SIZE env var
21:10:11  <trevnorris>creationix: maybe, though much slimmer. and should even remove the current domain performance impact we're hit with.
21:10:12  <kellabyte>bnoordhuis: oh! so it automatically calls the done_cb?
21:10:27  <bnoordhuis>kellabyte: yes
21:10:34  <trevnorris>othiym23: not sure. i'm writing the code in my head as we speak.
21:10:47  <trevnorris>othiym23: and by api you've sketched out, you mean your pr?
21:10:49  <kellabyte>bnoordhuis: hmm maybe thats what I should do, throw all my requests into the queue
21:11:13  <othiym23>trevnorris: the interface as documented, not the current implementation
21:11:46  * kenperkinsjoined
21:12:00  <creationix>trevnorris, the nested scopes is where it gets interesting/useful
21:12:09  <creationix>trevnorris, does your idea support that?
21:12:35  <trevnorris>creationix: tentatively, i'll say yes.
21:12:35  <creationix>of it not nested, at least changeable scopes
21:12:41  <creationix>not sure nested is requires
21:12:43  <creationix>*required
21:13:04  <trevnorris>othiym23: a lot slimmer than that. i'm going to write up a quick PR.
21:13:44  <MI6>nodejs-master: #379 UNSTABLE osx-ia32 (3/621) smartos-ia32 (3/621) osx-x64 (2/621) smartos-x64 (9/621) http://jenkins.nodejs.org/job/nodejs-master/379/
21:13:52  <kellabyte>brson: love that rust is using libuv btw :)
21:13:55  <othiym23>creationix:, trevnorris: when I was reworking the docs on the PR last night, I realized that the New Relic agent relies on the current nesting semantics to deal with one function calling a bunch of other functions
21:14:08  <tjfontaine>oh
21:14:41  <creationix>othiym23, yes, you need nesting, but the core implementation may not
21:14:51  <trevnorris>othiym23, creationix: and understand i'm simultaneously reworking some of the basic mechanisms for the tick processor. nothing I like to do more than delete code.
21:15:06  <tjfontaine>bnoordhuis: would you mind doing a libuv release, while I'm doing this changelog pruning?
21:15:06  <creationix>yes, delete away
21:15:40  <othiym23>I'm curious to see how the API can be slimmer, given that it has like five basic operations -- create a namespace, fetch a namespace, set a value, fetch a value, run a set of operations in a new context
21:15:54  <kellabyte>bnoordhuis: thinking of http pipelining, if I chuck requests on the queue, will I be responding to http requests out of order?
21:16:19  <bnoordhuis>tjfontaine: sure
21:16:20  <creationix>othiym23, I don't think your API can be slimmer, but what core provides could be
21:16:41  <tjfontaine>bnoordhuis: thanks
21:17:25  <othiym23>I'll just let trevnorris put together a PR and then take a look
21:18:24  <trevnorris>othiym23: understand, the pr won't accomplish anything on it's own. it's a minimal hook system that'll allow you to implement your proposal.
21:18:50  <trevnorris>othiym23: i started working on this to remove the hit node gets once domains are used.
21:19:42  <creationix>trevnorris, do you know already what the hook API will be
21:19:45  <creationix>I'm very curious
21:19:47  <othiym23>that's great!
21:19:51  * kazuponjoined
21:20:09  <MI6>joyent/libuv: bnoordhuis created tag v0.11.7 - http://git.io/1A7Rww
21:20:12  <othiym23>I'm completely happy with something that lets me keep this whole thing in userspace, especially if it improves overall performance
21:20:13  <MI6>joyent/libuv: Ben Noordhuis master * d34fad7 : Now working on v0.11.8 (+1 more commits) - http://git.io/s5zxxA
21:20:29  <bnoordhuis>tjfontaine: ^
21:20:31  <othiym23>I'd be happy with domains being implemented purely in userspace, as far as that's concerned
21:20:36  <tjfontaine>bnoordhuis: thanks!
21:20:45  * creationixwould be happy with http in userspace
21:20:48  <creationix>:P
21:20:57  <bnoordhuis>kellabyte: yes. there's no guarantee in what order the requests will come back from the thread pool
21:20:57  <othiym23>haha
21:22:19  <othiym23>a point in favor of replacing the module in core with a hook is that the polyfill version I'm going to need to keep around for old versions of Node could be split up into the glue logic and the gross yucky world-monkeypatcher that the core hook replaces
21:22:35  <othiym23>so it would be the same code in both versions, with the only difference being how it gets applied
21:22:59  <kellabyte>bnoordhuis: ok thanks, I'll try to make it do non-pipelined requests first to make sure I have the callbacks proper, and see what I can do there
21:23:38  * st_lukejoined
21:24:23  * jmar777joined
21:24:45  * kazuponquit (Ping timeout: 264 seconds)
21:27:08  <tjfontaine>https://gist.github.com/tjfontaine/6168821 after first cull
21:28:02  <mikeal>Koichi's back!
21:28:04  <brson>kellabyte: thanks! the new libuv-based task scheduler is going to land "any day now"
21:28:06  <mikeal>:)
21:28:06  * stagasquit (Ping timeout: 264 seconds)
21:28:24  <brson>any hour now really
21:28:39  <brson>completely replaces the old C++ scheduler with libuv + pure Rust
21:28:42  <brson><3
21:28:49  <kellabyte>brson: nice :)
21:30:14  <bnoordhuis>tjfontaine: "util: removed duplicated isArray check" and "benchmark: update misc to new v8 API" aren't that interesting, right?
21:30:30  <bnoordhuis>"src: Replace macros with util functions" effectively got reverted (for shame! for shame!)
21:30:54  <tjfontaine>ya isaacs is doing a second pass now
21:31:03  <bnoordhuis>"process_wrap: omit superfluous Number creation" isn't the most interesting change in the world either :)
21:31:21  <MI6>nodejs-master: #380 UNSTABLE smartos-ia32 (7/621) linux-ia32 (1/621) smartos-x64 (7/621) http://jenkins.nodejs.org/job/nodejs-master/380/
21:31:34  <tjfontaine>bnoordhuis: but it certainly could be to someone doing evil things
21:31:44  <tjfontaine>anyway, at least that's the reasoning I took
21:31:53  <isaacs>tjfontaine: https://gist.github.com/isaacs/6168834
21:32:12  <tjfontaine>thanks
21:33:50  <bnoordhuis>isaacs, tjfontaine: "cluster: support setting data on shared server" <- not relevant for non-core people
21:33:59  <bnoordhuis>that's an internal api
21:34:02  <isaacs>bnoordhuis: awesome
21:34:06  <isaacs>ok, i wasn't sure. didn't review that.
21:39:21  <kellabyte>bnoordhuis: thanks so much for the help, time to go off and learn :)
21:39:27  <MI6>libuv-review: #34 FAILURE windows-ia32 (12/192) smartos-x64 (2/191) windows-x64 (5/192) smartos-ia32 (2/191) http://jenkins.nodejs.org/job/libuv-review/34/
21:42:18  <MI6>libuv-master: #152 FAILURE windows (4/192) http://jenkins.nodejs.org/job/libuv-master/152/
21:43:59  <MI6>joyent/node: Timothy J Fontaine v0.11.5-release * 6f92da2 : 2013.08.06, Version 0.11.5 (Unstable) (+1 more commits) - http://git.io/QTA3lQ
21:44:29  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:48:17  * wavdedjoined
21:48:23  * Somebodyjoined
21:49:50  <bnoordhuis>kellabyte: no problem :)
21:50:18  <tjfontaine>dear windows, hurry up with the building and stuff
21:50:56  * bradleymeckquit (Quit: bradleymeck)
21:51:18  <MI6>libuv-master-gyp: #90 FAILURE windows-x64 (5/192) windows-ia32 (4/192) http://jenkins.nodejs.org/job/libuv-master-gyp/90/
21:51:22  <tjfontaine>there we go
21:51:44  <tjfontaine>java.lang.NullPointerException fuck you jenkins/java, fuck you very much
21:52:48  <bnoordhuis>tjfontaine: maybe back to buildbot? :)
21:53:45  <tjfontaine>bnoordhuis: ya, I have plans, and already started on some code yesterday, and will be doing more tonight on it, I'm nearly at my wits end, I'm going to keep it for release orchestration, because it does that ok
22:06:42  * c4miloquit (Remote host closed the connection)
22:07:17  <MI6>nodejs-master-windows: #178 UNSTABLE windows-x64 (21/621) windows-ia32 (26/621) http://jenkins.nodejs.org/job/nodejs-master-windows/178/
22:08:03  * mcavagequit (Remote host closed the connection)
22:09:30  * mikealquit (Quit: Leaving.)
22:09:34  * jmar777quit (Read error: Connection reset by peer)
22:09:42  * jmar777_joined
22:10:11  * mikealjoined
22:12:07  * paddybyersjoined
22:12:32  <TooTallNate>tjfontaine: so are releases all automated now from jenkins?
22:13:28  <tjfontaine>"all", mostly
22:13:34  <tjfontaine>when jenkins isn't fucking me like it is right now
22:15:19  <tjfontaine>ok the windows failure is something else, I'm not even sure what this means
22:15:20  <tjfontaine>g:\VS2010\VC\include\time.inl(133): fatal error C1090: PDB API call failed, error code '23' : '( [g:\jenkins\workspace\nodejs-msi\1d92f228\deps\openssl\openssl.vcxproj]
22:15:23  * ecrjoined
22:15:43  <tjfontaine>and/or why we don't hit that on normal builds
22:16:00  * wavdedquit (Quit: Nighty night)
22:18:34  <trevnorris>bnoordhuis: i know you know this, but wow. I can't believe how much faster args[n].As<Array>()->Get(m); is than args[n].As<Object>()->Get(str);
22:19:02  <trevnorris>s/args[n]/obj/g
22:19:16  <tjfontaine>http://stackoverflow.com/a/13799195
22:19:17  <tjfontaine>hahah
22:19:19  <tjfontaine>ha.
22:20:13  * tjfontainefires off another build where MSI's aren't built in parallel
22:20:26  * kazuponjoined
22:20:50  * julianduquejoined
22:23:25  <bnoordhuis>trevnorris: yeah, that's why i proposed to move everything to lookups by index :)
22:23:52  <trevnorris>bnoordhuis: totally for it. it's one of the hacks i'm using to speed up the whole domain thing.
22:24:30  <bnoordhuis>it's such an obvious optimization in hindsight, i wonder why i didn't think of that before
22:24:41  <trevnorris>I have those all the time.
22:24:50  <trevnorris>like when you pointed out checking for in_tick
22:24:55  * kazuponquit (Ping timeout: 246 seconds)
22:24:56  <bnoordhuis>ah, right :)
22:25:03  <trevnorris>took me 20 mins to fix, but totally didn't see it.
22:25:41  <trevnorris>and to complete the hack, it's just as fast to treat this like an array { 0: someValue }
22:25:50  <bnoordhuis>yeah
22:26:00  <bnoordhuis>v8 doesn't care
22:26:16  <bnoordhuis>v8 is like honey badger in that respect
22:26:23  <trevnorris>heh
22:26:42  * AvianFlu_joined
22:26:43  <tjfontaine>can the honeybadger please eat jenkins next?
22:27:05  * AvianFlu_quit (Remote host closed the connection)
22:27:05  <bnoordhuis>hah, i sense a smidgen of frustration
22:27:12  <bnoordhuis>so what's your plan, tj?
22:27:14  <othiym23>tjfontaine: I sense some frustration in your tone
22:27:18  <othiym23>jinx!
22:27:22  * mikealquit (Quit: Leaving.)
22:27:53  <tjfontaine>bnoordhuis: well, jenkins by default doesn't work the way I want (TheRightWay) anyway, in so far as I want to see a build per commit, not a build per "whatever the fuck has changed since last jenkins could be fucked to try a build"
22:28:54  <tjfontaine>so I have a client that works reasonably well at building and submitting results, I just need the server that keeps track of what outstanding sha's haven't yet been built for a given configuration
22:29:41  * pachetjoined
22:29:50  * AvianFluquit (Ping timeout: 240 seconds)
22:30:22  <trevnorris>is process.domain considered private api?
22:30:54  <tjfontaine>hmm, I wouldn't think so, it's the currently executing domain, so someone could want to know where they actually are
22:31:35  <trevnorris>oy. why couldn't that have been wrapped in a function...
22:34:22  <trevnorris>guess I could hack it as a getter/setter for backwards compatibility.
22:38:16  * paddybyersquit (Ping timeout: 264 seconds)
22:39:04  * mikealjoined
22:39:45  * wavdedjoined
22:42:01  * rendarquit
22:45:48  * mikealquit (Quit: Leaving.)
22:49:00  <trevnorris>bnoordhuis: you still around?
22:49:52  * mikealjoined
22:49:56  <othiym23>trevnorris: process.domain is super useful if you're writing modules that you want to be domains-aware without relying on them being available
22:50:33  <othiym23>in that it allows you to do stuff with the current domain without forcing you to require('domain') and change to the domains control flow path
22:50:45  <othiym23>and I've been recommending that as a pattern to people
22:51:01  <trevnorris>othiym23: that's fine. but i'd rather have had a process.getDomain() or whatever. in terms of optimization, it's impossible when it's exposed that way.
22:52:05  <othiym23>if you define a getter using the V8 API directly, does it have the same performance penalty as using Object.defineProperty?
22:52:46  <trevnorris>i dunno. but how often are you getting/setting the domain property in a second?
22:53:49  <tjfontaine>it's going to be one of those fucking days.
22:54:32  <bnoordhuis>trevnorris: yep
22:54:50  <MI6>joyent/node: trevnorris created branch domains-ben-reviewme - http://git.io/WJzzqg
22:54:57  <othiym23>trevnorris: couldn't really say
22:55:01  <trevnorris>bnoordhuis: can't believe I did that.
22:55:19  <trevnorris>bnoordhuis: almost have another optimization ready to go as well.
22:56:44  <bnoordhuis>trevnorris: lgtm'd
22:56:50  <trevnorris>coolio thanks
22:57:28  <MI6>joyent/node: Trevor Norris master * e3c5019 : domains: properly check if domains are being used - http://git.io/-fsQJg
22:57:52  <tjfontaine>trevnorris: do you care about that going through the CI atm, or can I kill it?
22:58:05  <trevnorris>tjfontaine: kill it
22:58:07  <tjfontaine>thanks
22:58:24  <trevnorris>heh, just promise me you'll take pleasure while you do
22:58:38  <tjfontaine>I take no pleasure right now
22:59:06  <tjfontaine>I'm not sure why/where jenkins lost its mind, but the process that has been working for nightlies and the past 4 releases has decided to be a nightmare today
22:59:11  <bnoordhuis>we should do a "this week in node" newsletter
22:59:23  <bnoordhuis>i guess strongloop already does that with the blog posts
22:59:30  <bnoordhuis>but it's what i like about the rust mailing list
22:59:31  <MI6>nodejs-master-windows: #179 ABORTED http://jenkins.nodejs.org/job/nodejs-master-windows/179/
22:59:36  <trevnorris>tjfontaine: you probably can't get in that last tiny commit, could you?
22:59:48  <tjfontaine>I'd rather not, no
22:59:48  <trevnorris>bnoordhuis: sounds like fun.
22:59:56  <MI6>nodejs-master: #381 ABORTED http://jenkins.nodejs.org/job/nodejs-master/381/
22:59:57  <trevnorris>ah well
23:00:12  <bnoordhuis>trevnorris: yeah. i ghost-write them now for the strongloop blog every week
23:00:28  <bnoordhuis>but jimmy always takes out my puns :(
23:00:54  <trevnorris>hah
23:03:49  <trevnorris>bnoordhuis: don't want a full review yet, but when you have a moment mind giving feedback on my use of macros: https://github.com/joyent/node/pull/5998/files
23:04:21  <trevnorris>bnoordhuis: was able to centralize all wrap/unwrap's in core. so if we don't want to use the external array thingy then it'll be trivial to shove in the old one
23:05:08  <bnoordhuis>trevnorris: if you ping me on the issue, i'll look at it tomorrow. it's 1 am here, i was about to sign off and go to bed
23:05:20  <trevnorris>bnoordhuis: sounds good. rest well
23:05:30  <bnoordhuis>thanks, you too :)
23:15:48  * Somebodyquit (Remote host closed the connection)
23:17:17  * kenperkinsjoined
23:19:23  * paulfryzelquit (Remote host closed the connection)
23:19:33  * hzquit
23:21:00  * kazuponjoined
23:21:29  * kenperkinsquit (Client Quit)
23:22:52  * wolfeidauquit (Remote host closed the connection)
23:23:20  * wolfeidaujoined
23:23:38  * Damn3dquit (Ping timeout: 264 seconds)
23:25:42  * kazuponquit (Ping timeout: 264 seconds)
23:25:44  * felixgequit (Quit: felixge)
23:25:48  * Damn3djoined
23:26:10  * bnoordhuisquit (Ping timeout: 246 seconds)
23:26:16  * AvianFlujoined
23:27:55  * wolfeidauquit (Ping timeout: 245 seconds)
23:32:28  * jmar777joined
23:32:33  * jmar777_quit (Ping timeout: 264 seconds)
23:33:28  * austoquit (Quit: Leaving)
23:34:26  * mikealquit (Quit: Leaving.)
23:37:02  * mikealjoined
23:46:41  <trevnorris>isaacs: hell's yes! I found a use for the smalloc extension!
23:46:52  <isaacs>trevnorris: w00T!
23:46:57  <tjfontaine>oh boy
23:46:58  <isaacs>trevnorris: If you will it, it is no dream, Dude.
23:47:21  <trevnorris>isaacs: seriously, right? and in all places, domains. never would have thought.
23:47:39  <isaacs>trevnorris: hahah
23:51:06  <trevnorris>isaacs: ok, these optimizations are getting intense, even for me. feel like taking a step back and thinking across all core.
23:53:14  <isaacs>hahah
23:53:18  <isaacs>trevnorris: which ones?
23:53:33  <isaacs>trevnorris: also, this sounds like great 1.0 talk.
23:54:06  <trevnorris>isaacs: basically we're communicating state as flags via small allocated object per module (like infoBox), but then we can extend that and store N pointers to callback methods in the external data for quick reference.
23:55:43  <trevnorris>isaacs: so, for example, i'm patching process.domain to use a getter/setter then storing the actual object in a persistent array shared with the native layer. accessing that is 20x's faster than retrieving an object property.
23:56:15  <isaacs>trevnorris: interesting
23:56:16  <trevnorris>isaacs: so I should be able to get domain performance close to the margin of error of not using domains
23:56:20  <isaacs>trevnorris: right
23:57:46  * kazuponjoined
23:58:15  <trevnorris>isaacs: also this way it's trivial to check on either side if we're actively in a domain at any given moment.
23:59:28  <trevnorris>isaacs: so my thought is to extend this with a simpler hook system that calls a listener whenever a callback is passed, to say nextTick, which then receives the callback and an object promised to exist with that callback.