00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:12  <tjfontaine>ya, being able to jstack() on osx would be hot
00:00:32  <isaacs>omgomgomg i would <3 jsstack on osx so much
00:00:37  <bnoordhuis>i've looked at xnu, on how to fix that
00:00:57  <bnoordhuis>i think the main change is that dtrace-on-osx should be able to page in memory
00:01:00  <isaacs>bnoordhuis: didn't you have some jsstack kind of thing in C++ that sort of worked?
00:01:02  <tjfontaine>anyway, #5163 I'm reasonably convinced should land in master and v0.10 asap, 5166 though needs more help
00:01:12  <bnoordhuis>at least, i think that's what smartos does that os x doesn't
00:01:15  <isaacs>bnoordhuis: we should put that in node as console.megaTrace() or something
00:01:31  <bnoordhuis>isaacs: oh right, i guess i can land that sometime
00:01:49  <bnoordhuis>i'll run gnu indent over it first :)
00:02:12  <isaacs>right, get rid of your weird hipster c style
00:02:24  <bnoordhuis>hipster! well, i never!
00:03:06  <bnoordhuis>if anything, it's crusty. from way back when, when we still had to walk to the library, through the snow, uphill both ways
00:07:15  <mmalecki>bnoordhuis: library? what's that?
00:07:56  <bnoordhuis>that's where poor people go to get internets
00:09:11  <tjfontaine>or pedos to avoid detection
00:09:22  <bnoordhuis>right, forgot about those
00:09:28  <bnoordhuis>silly question, how do you list user probes?
00:09:53  <tjfontaine>dtrace -p <pid> -l -m <provider>
00:10:07  <tjfontaine>if I understand your question
00:10:13  * rendar_quit
00:10:19  <bnoordhuis>ah, well
00:10:34  <MI6>nodejs-master: #129 UNSTABLE osx-x64 (1/573) linux-ia32 (1/573) windows-ia32 (5/573) windows-x64 (6/573) smartos-ia32 (2/573) smartos-x64 (5/573) http://jenkins.nodejs.org/job/nodejs-master/129/
00:10:55  <bnoordhuis>systemtap lets you do `stap -l 'process("node")' path/to/node`
00:10:57  <dap>tjfontaine: did you learn about -m from Brendan?
00:11:02  <tjfontaine>bnoordhuis: https://gist.github.com/tjfontaine/422be586122130ceb6ec
00:11:07  <tjfontaine>dap: no, the man page of course :)
00:11:24  <tjfontaine>dap: at least on osx -l happens after -c
00:11:32  <bnoordhuis>okay, you've got to actually run the process then?
00:11:47  <tjfontaine>bnoordhuis: this is a pid provider, so ya the process needs to be in the air
00:12:09  <tjfontaine>dap: stop me if I use the wrong vernacular :)
00:12:31  <dap>bnoordhuis: dtrace -c /usr/node/bin/node -ln 'node$target:::' < /dev/null
00:13:15  <dap>the probes can be created dynamically (though the node probes aren't), so there's no way to do it without running the process. (we could support that for the node ones.)
00:13:54  <dap>tjfontaine: there's a hypothesis that Brendan's the only one that uses "-P foo" instead of "-n foo:::" and so on :)
00:14:46  <tjfontaine>dap: well I'm sure there's lots he does that most don't do
00:14:49  <bnoordhuis>dap: very nice, thanks
00:14:58  <tjfontaine>this time the man page was my source
00:15:13  <tjfontaine>bnoordhuis: https://gist.github.com/tjfontaine/5273607 I'm not sure if any of this is of interest for you
00:16:00  <bnoordhuis>tjfontaine: quite probably. easier way to get performance data == better
00:16:01  <tjfontaine>bnoordhuis: those are buffer allocs while running the http benchmark
00:16:38  <bnoordhuis>i usually instrument the code with fprintf(log_file) statements now. very ghetto
00:17:22  <tjfontaine>I don't know where having these buffer probes make the most sense to have
00:17:55  <tjfontaine>::MakeFastBuffer should be the sizes that js are most interested in
00:18:52  <bnoordhuis>3 7545 _ZN4node27DTRACE_HTTP_SERVER_RESPONSEERKN2v89ArgumentsE:http-server-response <- aw
00:19:09  <tjfontaine>node$target:::http-server-response
00:19:29  <tjfontaine>bnoordhuis: have you used dap's nhttpsnoop?
00:19:44  <bnoordhuis>no. should i?
00:19:48  <tjfontaine>yes, you should https://github.com/davepacheco/nhttpsnoop :)
00:20:00  <tjfontaine>it makes testing this quite pretty
00:21:22  <isaacs>bnoordhuis: I think that we should seriously consider passing TypeErrors to callbacks for async functions.
00:21:32  <isaacs>bnoordhuis: this debate is wearing me down.
00:21:38  <isaacs>bnoordhuis: and my heart is not in it.
00:21:46  <bnoordhuis>don't give up the good fight, isaac
00:21:58  <bnoordhuis>and don't worry, i'm just warming up
00:22:06  <isaacs>here's the thing...
00:22:14  <isaacs>people are going to use a callback to handle errors from async functions.
00:22:21  <isaacs>we may as well just go with that flow.
00:22:36  <isaacs>maybe have some kind of env or strict mode or flag or something that throws all fo them.
00:22:42  <isaacs>or something.
00:22:59  <dap>under what conditions would one "handle" a TypeError?
00:23:00  <isaacs>but like... it's a mess. there are very few people in the node userbase that actually prefer it this way.
00:23:02  <dap>and what would one do?
00:23:12  <isaacs>dap: well, yo'ud probably return an error to whoever called you.
00:23:24  <isaacs>dap: like, let's say, i have a web service where you post a number, and i give you taht many random bytes.
00:23:24  <mmalecki>isaacs: this is a bad idea, considering how people actually handle errors in their apps
00:23:39  <tjfontaine>how people *don't actually handle errors
00:23:41  <isaacs>mmalecki: actually, throwing is leading them to do even worse things.
00:23:50  <isaacs>process.on('uncaughtException', console.log)
00:23:54  <mmalecki>isaacs: passing a TypeError (which is programmer's mistake) back to a user is, well, sketchy at least
00:23:55  <isaacs>(no, really)
00:24:03  <isaacs>dap: anyway...
00:24:35  <isaacs>dap: let's say, i do something like this: crypto.randomBytes(+userInput, function(er, bytes) { if (er) send400Error(er); else res.end(bytes) })
00:24:52  <isaacs>dap: maybe i check for NaN first
00:25:08  <dap>I see. Would you do this for ReferenceError as well?
00:25:12  <isaacs>var bytes = +userInput; if (!bytes || bytes < 0) return send400Error('not a valid number of bytes');
00:25:37  <isaacs>i guess what i'm suggesting is, "don't put 'throw' in functions that take a callback"
00:25:43  <isaacs>pass whatever you would throw to the cb
00:25:48  <mmalecki>dap has a great point here
00:26:06  <isaacs>dap: you mean, function(obj,cb) { doSomething(obj.foo.bar, cb) }
00:26:15  <isaacs>should i trap the obj.foo == null and pass to the cb?
00:26:23  <dap>for example, yes
00:26:25  <isaacs>i think that's more defensible.
00:26:27  <dap>That's funny — I thought mmalecki had a great point there :)
00:26:37  <isaacs>because we're not explicitly choosing to throw
00:26:44  <isaacs>like, we can't see that one coming.
00:26:44  <mmalecki>no, I mean, our point are kind of the same, dap
00:26:52  <dap>mmalecki: indeed :)
00:26:53  <isaacs>mmalecki: i think that's his point :)
00:27:08  <isaacs>there's back-handed compliments, and then there's loopback compliments.
00:27:34  <bnoordhuis>dtrace -c 'out/Release/node benchmark/http_simple' -n 'node$target:::gc-start { self->ts = timestamp } node$target:::gc-done { @ = quantize(timestamp - self->ts) } tick-2s { printa(@); trunc(@); }' <- works, sweet
00:27:38  <bnoordhuis>nice job, tj
00:28:00  <tjfontaine>was really just cleaning up what dap had done :)
00:28:01  <isaacs>nice :)
00:28:09  <isaacs>dap++ tjfontaine++
00:28:19  * isaacsneeds to write some karma features into ircretary
00:28:28  <tjfontaine>5166 makes everyone at joyent very happy, once it gets prettier
00:29:03  <bnoordhuis>tjfontaine: i can't get it to land on top of #5163 though
00:29:32  <tjfontaine>hrm I wonder what I did wrong
00:29:56  <bnoordhuis>i probably only have to cherry-pick the last commit
00:29:58  <bnoordhuis>let me try that
00:30:04  <tjfontaine>https://github.com/tjfontaine/node/commit/6a7754c16edbbc97670378303b4905145bda8383
00:30:09  <tjfontaine>ya that's what I was going to suggest
00:30:58  <MI6>joyent/node: Timothy J Fontaine master * aa5da48 : dtrace: actually use the _handle.fd value When using the DTrace/systemta (+2 more commits) - http://git.io/IguX7Q
00:31:41  <mmalecki>bnoordhuis: my new thing for C option parsing: https://github.com/mmalecki/saneopt
00:32:17  <tjfontaine>bnoordhuis: I'm not sure that macro change was ready to land, but ok
00:32:46  <bnoordhuis>tjfontaine: oh? should i revert it?
00:33:01  <bnoordhuis>mmalecki: saneopt_t* saneopt = malloc(sizeof(*saneopt)); > saneopt_t* saneopt = malloc(sizeof(saneopt_t));
00:33:35  <dap>isaacs: IMO, it seems better to do the right thing by a carefully written program than to do something passable for a sloppily written one (assuming you agree that process.on('uncaughtException', console.log) is sloppy, and that blowing up fast when a variable is misspelled is the right thing for a carefully written program). In the first case, you're handling actual sloppiness for someone, while in the other you're covering up an honest mistake.
00:33:50  <dap>But I don't have the rest of the context on this discussion. Sorry to swoop in with an opinion — you probably have enough of that.
00:33:52  <mmalecki>bnoordhuis: hah, good catch. thanks
00:34:15  <isaacs>dap: so, "misspelled variable" would be the reference error case, i suppose.
00:34:35  <isaacs>dap: and i'm vehemently opposed to wrapping things in try{} blocks
00:34:46  <isaacs>dap: i think the node-core team is unanimous on that one.
00:35:10  * kazuponjoined
00:35:17  <dap>Right. I view TypeError and ReferenceError like SyntaxError — egregious programmer mistakes that should bring the program down as fast and hard as possible.
00:35:18  <dap>I wouldn't catch it either.
00:35:18  <isaacs>dap: no worries about swooping in wiht a contextless opinion. yes, i do have a lot of that, but in this case, it's appreciated, and thanks for the concern :)
00:35:21  <mmalecki>isaacs: how's "mispelled variable" different from wrong variable type?
00:35:31  <tjfontaine>bnoordhuis: I don't think it's worth a revert, but https://github.com/joyent/node/commit/aa5da48594c1634de9f439bcf223acff3fb1fcd8#L0R94 certainly runs the risk of two SLURP_CONNECTION()'s getting mixed symbols? and it probably needs to check if handle is null/undefined
00:35:43  <dap>"egregious" not being a judgment, of course — it happens — but the program should not try to continue on
00:35:50  <isaacs>mmalecki: javascript is not traditionally a statically typed language.
00:35:54  <isaacs>mmalecki: that's the difference.
00:36:14  <isaacs>dap: also, in the proposed change, it *would* raise the error.
00:36:19  <isaacs>dap: the question is "how"
00:36:38  <bnoordhuis>tjfontaine: mixed symbols? i'm not following, i think
00:36:57  <isaacs>dap: the root problem is that throwing has a much higher probability of collateral damage.
00:37:01  <dap>Especially with the recent v8 change to dump core in the context where the exception is thrown, I'd definitely like to have the whole stack and arguments available.
00:37:21  <tjfontaine>bnoordhuis: if I did SLURP_CONNECTION() twice (though I suppose this woul dbe a compiler error) wouldn't I be saying Local<Object> _handle; twice?
00:37:25  <bnoordhuis>tjfontaine: oh, you mean accidentally defining two _handle locals
00:37:28  <bnoordhuis>right, that :)
00:37:43  <isaacs>dap: right, but you're not going to use that in aweb server that has more than one end-user connected at a time.
00:37:44  <bnoordhuis>easy to fix by wrapping the macros in do { } while (0) blocks
00:38:27  <tjfontaine>bnoordhuis: I think what should really be changed is to check that Get(_handle) actually returned something useful
00:38:28  <isaacs>dap: i mean, realistically, we're talking about cases where you have to shut down gracefully.
00:38:29  <dap>isaacs: I certainly would — because if it's anything like these kinds of bugs have been in my experience, it will be a 1-in-several-thousand case, and my only prayer of figuring out why it happened is having the core file with full program state.
00:39:07  <dap>either that or it will be an every-single-time bug (which is actually more common), which I'll catch in development it just wastes my time to not have the real stack printed out.
00:39:09  <isaacs>dap: please swoop in more.
00:39:22  <isaacs>dap: i mean, not to debate me, but to debate the people that are making the arguments i'm making here to you.
00:39:29  <dap>:)
00:39:34  * kazuponquit (Ping timeout: 245 seconds)
00:39:55  <bnoordhuis>*valp = obj->Get(String::New(#member))->ToInteger()->Value(); <- i assume that code predates IntegerValue()
00:40:08  <tjfontaine>ya, that's my understanding
00:40:15  <isaacs>what's happenign right now is that there are a few people who are complaining loudly about how node crashes so easily, and it's brittle, and the node core team (especially isaacs) doesn't want to do anything to fix the situation, and domains don't even work, because you still have to crash.
00:40:40  <bnoordhuis>tjfontaine: fwiw, the commit looks okay to me as is
00:41:01  <bnoordhuis>tjfontaine: worst case, you'll get fd=0 when _handle is unset
00:41:03  <isaacs>dap: if it was at least more clear that there are node end-users who actually *prefer* it this way (or even, would prefer to just always crash on any throw, and never catch anything) then that's fine.
00:41:25  <isaacs>dap: ie, it'd make it more clear that it's not so clear-cut.
00:41:28  <tjfontaine>bnoordhuis: really? hmm depressing, I was seeing unitialized data in my testing, but I may have tested wrong
00:42:19  <dap>isaacs: that's certainly my view. the only time I use try/catch is for things like JSON.parse.
00:43:03  <dap>Sounds like mmalecki and bnoordhuis agree too (based on ben's "fight the good fight" comment)?
00:44:00  <dap>and if I could, I'd have had JSON.parse return an error instead of throwing :)
00:44:17  <isaacs>dap: yeah, the throw in JSON.parse is excessive.
00:44:20  <isaacs>but then, is it?
00:44:22  <MI6>nodejs-master: #130 FAILURE linux-x64 (1/573) smartos-ia32 (3/573) smartos-x64 (2/573) http://jenkins.nodejs.org/job/nodejs-master/130/
00:44:24  <isaacs>i mean, you think it's json, right?
00:44:27  <bnoordhuis>dap: yes
00:44:28  <isaacs>and you'er tryhing to parse it?
00:44:32  <isaacs>shouldn't you crash hard as fast as possible?
00:44:47  <bnoordhuis>tjfontaine: oh, i guess it could fail if _handle=null
00:44:49  <dap>isaacs: if it's user input, it's not at all a fatal error if it's not valid.
00:44:56  <isaacs>dap: that's exactly the point.
00:44:57  <tjfontaine>bnoordhuis: for instance (and this may be abuse here "[ 1.395787] - GET /uter 48954 client undefined 0 /uter?limit=5&offset=5 -> 1112396529664"
00:45:07  <isaacs>what if the user input is a number >0x3fffffff
00:45:14  <tjfontaine>bnoordhuis: but undefined and 0, mean there wasn'ta remote site anyway
00:45:16  <isaacs>dap: should you throw when you pass that to crypto.randomBytes?
00:45:26  <bnoordhuis>tjfontaine: i can add a check, no problem
00:45:31  <tjfontaine>k
00:45:41  <isaacs>dap: basically, the difference that i can see is that it's a lot easier to check a number range thna to check if a string is valid json.
00:45:47  <isaacs>dap: since JSON is pretty complicated.
00:45:56  <isaacs>dap: but the fact is that you have to know you have to check it
00:45:57  <dap>isaacs: the difference is that there's no JSON.validate. If there were, it would be more reasonable for JSON.parse to throw. Except that model would also be more expensive in the common case (basically parsing it twice).
00:46:00  <isaacs>right
00:46:45  <isaacs>the "more expensive in the common case" is also applicable to the crypto.randomBytes case.
00:47:05  <isaacs>dap: you have to know you have to validate it, and what is valid, and then do exactly the same validation that is done *again* in the function.
00:47:06  <dap>IMO, if you're handling user input, you should explicitly validate it, not rely on the language, especially when the error produced by the language for that case is otherwise indistinguishable from a syntaxerror-level programmer error.
00:47:49  <isaacs>dap: in practice, people do the same thing for crypto.randomBytes that you do for JSON.parse
00:48:03  <isaacs>dap: or they don't, and it's hella surprising
00:48:08  <isaacs>and they get mad.
00:49:34  <dap>Is the proposal to make crypto.randomBytes return an error instead of throw, or to declare that node library routines in general will do that?
00:49:38  <mmalecki>isaacs: do you honestly think that node should follow wrong patterns which some inexperienced programmers introduce?
00:49:57  * bradleymeckjoined
00:50:04  * bradleymeckquit (Client Quit)
00:50:09  <dap>Is there anything I can do to help make it clear that some Node programmers prefer it the way it is? Is the current behavior the problem, or just the perception of people who expect it to work differently?
00:50:11  <isaacs>dap: there are various different proposals.
00:50:17  <mmalecki>with all due respect, but if you don't validate user input, you are unexperienced
00:50:22  <tjfontaine>oh man I broke etw and the windows build
00:50:29  <dap>I mean, most other environments aren't async, and just throw all the time, right? How can one have expectations that this environment would be different here?
00:50:34  <isaacs>dap: the issue is that we broadcast a specific way to handle errors.
00:50:42  <isaacs>dap: those environments aren't doing async io
00:51:06  <isaacs>dap: but yes, it IS a problem in browser JS
00:51:33  <isaacs>especially since "Crash fast and hard" isn't really an option.
00:52:17  <MI6>joyent/node: bnoordhuis created branch tjfontaine-review-this - http://git.io/b2vJBQ
00:52:21  <bnoordhuis>tjfontaine: ^
00:52:41  <isaacs>dap: but if we say "Handle errors like this: thing.on('error'), callback(er), domain.on('error')"
00:53:28  <isaacs>dap: and then we `throw new TypeError('7 is not the right number')`
00:53:34  <isaacs>dap: then we're kinda dicks
00:54:11  <isaacs>dap: and saying, "Well... don't pass a 7 to that function" it doesn't really make anyone think we're less dickish
00:54:21  <isaacs>saying, "Yor'e not experienced" is not really a satisfying response.
00:54:58  * inolenquit (Quit: Leaving.)
00:55:22  <tjfontaine>bnoordhuis: looking good
00:55:35  <mmalecki>isaacs: that's kinda comparable to breaking the law
00:55:47  <tjfontaine>bnoordhuis: it is rather unfortunate that I broke the windows build :/
00:56:04  <mmalecki>do you throw people into jail or call them back to say "hey, don't do that" when they do bad things?
00:56:28  <dap>The way I'd phrase this is: invalid input errors are typically checked synchronously, while runtime errors are not. There's a gray area (e.g., the path argument to mod_fs.readFile), and when calling any function, one must know which is which. But the fact that some errors can only be detected late does not mean it's not useful to detect the ones that can be detected early.
00:56:32  <dap>I've got to run shortly.
00:57:22  <tjfontaine>I'll submit a pr tonight to fix that I guess
00:58:01  <bnoordhuis>tjfontaine: i'm sure all 3 etw users will be pleased :)
00:58:17  <isaacs>dap: thanks for the input.
00:58:24  <tjfontaine>bnoordhuis: well the build is broken broken on windows atm :)
00:58:28  <isaacs>dap: if you're bored later: https://github.com/joyent/node/issues/5149
00:58:30  <isaacs>:)
00:58:31  <MI6>joyent/node: Ben Noordhuis master * 9b8dd39 : dtrace: check if _handle property is set Check that _handle is an object - http://git.io/mZ9S6w
00:58:31  <dap>I understand the annoyance — I hit this once with child_process.exec throwing a synchronous error that I was surprised by. Perhaps I haven't articulated in my head why it feels so wrong to make "obviously invalid input" errors asynchronous, but my gut tells me that the appeal of handling *all* errors asynchronously is a trap.
00:58:57  <bnoordhuis>tjfontaine: ah right. well, pull requests welcome :)
00:59:03  <tjfontaine>hehe
00:59:03  <bnoordhuis>do you have your commit bit yet?
00:59:17  <tjfontaine>I "have" it, but I'm acting like I don't
00:59:23  <bnoordhuis>ah okay :)
00:59:33  <dap>isaacs: thanks for hearing it. good luck!
00:59:54  <tjfontaine>alright bbiab
01:01:14  * mikealjoined
01:02:24  <dap>isaacs: Maybe this is it: one man's bad-user-input TypeError is another man's bonehead-programmer-error mistake, and making it easy to deal with the former at the expense of the latter puts the wrong value first, IMO. I'll try to formulate that and add it to the ticket.
01:02:30  <dap>On that note, I've really gotta run!
01:02:47  <isaacs>dap: thanks!
01:03:57  <isaacs>indutny: i figured out that error. however, fixing it breaks the test you just added: test/simple/test-tls-client-abort3.js
01:04:11  <isaacs>indutny: because you get an extra error about the socket being closed
01:04:24  * dapquit (Quit: Leaving.)
01:09:33  <isaacs>ah, figured it out
01:10:16  <isaacs>indutny: nevermind
01:11:35  <MI6>nodejs-master: #131 FAILURE smartos-ia32 (3/573) smartos-x64 (3/573) http://jenkins.nodejs.org/job/nodejs-master/131/
01:18:36  * benoitcquit (Excess Flood)
01:18:58  * bradleymeckjoined
01:24:19  * benoitcjoined
01:24:47  * bradleymeckquit (Quit: bradleymeck)
01:30:26  * inolenjoined
01:32:59  * mikealquit (Quit: Leaving.)
01:35:47  * kazuponjoined
01:39:26  * mmaleckichanged nick to mmalecki[zzz]
01:40:19  * abraxasjoined
01:40:21  * kazuponquit (Ping timeout: 252 seconds)
01:45:10  * abraxasquit (Ping timeout: 256 seconds)
01:54:01  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:07:13  * bnoordhuisquit (Ping timeout: 240 seconds)
02:16:34  * bnoordhuisjoined
02:17:15  <tjfontaine>isaacs got spanked by the pullreq bot, that's kinda amusing
02:23:28  * benoitcquit (Excess Flood)
02:32:21  * benoitcjoined
02:33:08  * brsonquit (Quit: leaving)
02:36:23  * kazuponjoined
02:43:00  * kazuponquit (Ping timeout: 256 seconds)
02:45:58  * hzquit
02:46:37  * bnoordhu1sjoined
02:48:18  * wolfeida_joined
02:49:28  * stagasjoined
02:51:06  * stephank_joined
02:55:58  * bnoordhuisquit (*.net *.split)
02:56:00  * wolfeidauquit (*.net *.split)
02:56:01  * stephankquit (*.net *.split)
02:56:01  * stephank_changed nick to stephank
03:25:18  <tjfontaine>I'd really like to consolidate this #if HAVE_SYSTEMTAP nonesense in node_dtrace
03:27:38  * bnoordhu1squit (Ping timeout: 245 seconds)
03:36:35  * benoitcquit (Excess Flood)
03:39:29  * kazuponjoined
03:40:26  * txdv_changed nick to txdv
03:40:51  * benoitcjoined
03:44:06  * kazuponquit (Ping timeout: 252 seconds)
04:24:27  * bradleymeckjoined
04:24:41  * bradleymeckquit (Remote host closed the connection)
04:31:23  * brsonjoined
04:34:22  * bnoordhuisjoined
04:37:13  * benoitcquit (Excess Flood)
04:39:15  * bnoordhuisquit (Ping timeout: 260 seconds)
04:40:04  * kazuponjoined
04:41:22  * benoitcjoined
04:44:55  * kazuponquit (Ping timeout: 264 seconds)
04:47:14  * defunctzombie_zzchanged nick to defunctzombie
05:37:37  * benoitcquit (Excess Flood)
05:39:24  * benoitcjoined
05:40:37  * kazuponjoined
05:45:08  * kazuponquit (Ping timeout: 245 seconds)
05:55:45  * benoitcquit (Excess Flood)
06:04:55  * benoitcjoined
06:08:47  * defunctzombiechanged nick to defunctzombie_zz
06:16:00  * brsonquit (Quit: leaving)
06:30:35  * kazuponjoined
06:30:53  * kazuponquit (Read error: Connection reset by peer)
06:31:17  * kazuponjoined
06:45:24  * dominictarrjoined
06:58:47  * benoitcquit (Excess Flood)
07:02:28  * benoitcjoined
07:11:34  * benoitcquit (Excess Flood)
07:19:28  * benoitcjoined
07:21:34  * qmxchanged nick to qmx|away
07:21:52  * mikealjoined
07:27:30  <indutny>isaacs: hey
07:28:23  <indutny>isaacs: this patch works for sure
07:28:27  <indutny>https://github.com/joyent/node/pull/5170/files
07:28:32  <indutny>but...
07:28:37  <indutny>what about net.js? :)
08:03:27  * dominictarrquit (Quit: dominictarr)
08:28:14  * paddybyersjoined
08:33:15  * kazuponquit (Remote host closed the connection)
08:33:43  * kazuponjoined
08:35:15  * rendarjoined
08:38:11  * kazuponquit (Ping timeout: 260 seconds)
09:38:19  * dominictarrjoined
09:44:11  * kazuponjoined
09:44:26  * paddybyersquit (Ping timeout: 255 seconds)
09:47:47  * skebcioquit (Read error: Connection reset by peer)
09:48:05  * dominictarrquit (Quit: dominictarr)
09:48:33  * kazuponquit (Ping timeout: 240 seconds)
09:54:31  * dominictarrjoined
09:58:23  * indexzerojoined
10:15:16  * dominictarrquit (Quit: dominictarr)
10:33:09  * skebciojoined
10:49:20  * mmalecki[zzz]changed nick to mmalecki
10:49:49  * indexzeroquit (Quit: indexzero)
11:42:35  * hzjoined
11:55:36  * felixgejoined
11:55:36  * felixgequit (Changing host)
11:55:36  * felixgejoined
12:53:20  * benoitcquit (Ping timeout: 246 seconds)
12:53:39  * dominictarrjoined
12:55:17  * dominictarrquit (Client Quit)
12:58:02  * benoitcjoined
13:29:57  * `3rdEdenjoined
13:32:22  * stagasquit (Read error: Connection reset by peer)
13:52:35  * c4milojoined
14:00:39  * piscisaureus_joined
14:05:36  * felixgequit (Quit: http://www.debuggable.com/)
14:10:59  <piscisaureus_>hello
14:15:25  * bnoordhuisjoined
14:15:43  * defunctzombie_zzchanged nick to defunctzombie
14:19:34  * defunctzombiechanged nick to defunctzombie_zz
14:32:26  <mmalecki>hi
14:58:04  <bnoordhuis>ho
14:58:11  <tjfontaine>what did you call me?
14:58:51  <tjfontaine>bnoordhuis: how would you feel if I unified the probes between dtrace and systemtap, having that ifdef in there is kinda frustrating
14:59:09  <bnoordhuis>okay by me if you can get it to work
14:59:20  <bnoordhuis>there was a reason it had to be like that but i forgot what it was
14:59:29  <tjfontaine>I'm sure it's similar to the osx reason
14:59:37  <tjfontaine>structs can't be dereferenced in systemtap
15:00:00  <bnoordhuis>right, probably that
15:00:01  <tjfontaine>but there are easier ways to manage that, we should be able to pass null in for that scenario
15:00:08  <bnoordhuis>oh, i've got to go, it seems
15:00:14  <bnoordhuis>back in an hour or so
15:00:16  <tjfontaine>enjoy
15:00:26  <bnoordhuis>i'm going to the beer store so yes, i will :)
15:00:32  <tjfontaine>:)
15:04:43  * bnoordhuisquit (Ping timeout: 245 seconds)
15:10:10  * c4milo_joined
15:18:40  <tjfontaine>piscisaureus_: btw https://github.com/joyent/node/pull/5173
15:19:32  <piscisaureus_>tjfontaine: "BTW I've incentivized you by making the build fail on windows without a change" ??
15:19:44  <piscisaureus_>I thought our incentivization was w/ booz
15:19:53  <piscisaureus_>tjfontaine: but yeah it looks harmless to me
15:20:04  <tjfontaine>heh
15:20:30  <tjfontaine>how can I test that etw is working properly?
15:21:06  <piscisaureus_>tjfontaine: interesting question. You have to build the installer and install node :)
15:21:12  <piscisaureus_>so the ETW manifest gets registered w/ the OS
15:21:40  <piscisaureus_>it wouldbe good to have some sort of test for this
15:21:53  <tjfontaine>oh well good news is that the msi builds aren't fucked
15:22:05  <piscisaureus_>which ones are?
15:22:26  <tjfontaine>previously I couldn't convince WiX to run inside the JRE I was using
15:22:44  * `3rdEdenquit (Remote host closed the connection)
15:22:47  <tjfontaine>but now that I let the system choose the jre for the build slave we have nightly msi's
15:22:54  <tjfontaine>jenkins.nodejs.org/nightlies
15:22:57  <piscisaureus_>woo
15:23:48  <piscisaureus_>The name of the etw source is too long
15:24:02  <piscisaureus_>Should be Just Node and not NodeJS-ETW-Provider
15:24:41  <tjfontaine>indeed
15:27:32  <piscisaureus_>tjfontaine: which platforms can't handle structs btw?
15:27:35  <piscisaureus_>tjfontaine: that's so weird
15:28:37  <tjfontaine>all of systemtap, and dtrace on osx, linux, and probably freebsd
15:31:23  <piscisaureus_>tjfontaine: patch looks harmless
15:31:45  <piscisaureus_>I've never liked how ad-hoc ETW, dtrace and systemtap support was fumbled in there
15:31:48  <piscisaureus_>but *shrug*
15:33:34  <tjfontaine>yes I'm actually looking to unify that this weekend
15:33:45  <tjfontaine>well at least the systemtap/dtrace stuff
15:34:16  <tjfontaine>etw seems pretty resilient to changes so long as I remember to update the signatures
15:34:32  <tjfontaine>all the damn #ifdef's for systemtap bother the crap out of me though
15:42:30  * abraxasjoined
15:47:03  * abraxasquit (Ping timeout: 260 seconds)
15:48:17  * defunctzombie_zzchanged nick to defunctzombie
16:06:43  * bnoordhuisjoined
16:08:07  * AvianFlujoined
16:12:06  * AvianFluquit (Remote host closed the connection)
16:33:12  * dominictarrjoined
16:34:03  * defunctzombiechanged nick to defunctzombie_zz
16:36:08  * dominictarrquit (Client Quit)
16:37:14  * bnoordhuisquit (Ping timeout: 272 seconds)
16:44:41  * mikealquit (Quit: Leaving.)
16:46:23  * c4milo_quit (Remote host closed the connection)
16:46:49  * c4milo_joined
16:47:17  * c4milo_quit (Read error: Connection reset by peer)
16:47:23  * c4milo__joined
17:25:56  * bnoordhuisjoined
17:43:58  * defunctzombie_zzchanged nick to defunctzombie
17:51:11  <tjfontaine>bnoordhuis: so getting systemtap to work, just on clean master, the example isn't working it just keeps telling me to read the readme, but I can list kernel probes fine
17:52:11  <bnoordhuis>tjfontaine: what example is that?
17:52:23  <tjfontaine>stap -l 'process("out/Release/node").mark("*")'
17:53:16  <bnoordhuis>does `stap -l process("node").mark("*")` work?
17:53:31  * defunctzombiechanged nick to defunctzombie_zz
17:53:43  <bnoordhuis>add quotes where appropriate :)
17:54:40  <tjfontaine>stap -l 'process("node").mark("*")'
17:54:41  <tjfontaine>Tip: /usr/share/doc/systemtap/README.Debian should help you get started.
17:55:39  <bnoordhuis>ah debian
17:55:50  <bnoordhuis>your systemtap version is probably too old
17:55:59  <bnoordhuis>what version is it?
17:56:07  <tjfontaine>it's actually ubuntu, and using raring
17:56:30  <tjfontaine>2.1.1 is the version
17:56:47  <tjfontaine>2.1-1~experimental1
17:57:00  <bnoordhuis>hrm, that's recent enough
17:58:26  <bnoordhuis>oh wait, -L, not -l
17:59:42  <bnoordhuis>tjfontaine: ^
18:00:23  <tjfontaine>no difference :/
18:01:25  * paddybyersjoined
18:03:56  <tjfontaine>I'm doing a full debug build, to see if that helps this situation
18:04:05  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:06:43  * c4miloquit (Remote host closed the connection)
18:10:15  * mikealjoined
18:15:13  * mikealquit (Quit: Leaving.)
18:21:08  * qmx|awaychanged nick to qmx
18:27:37  * AvianFlujoined
18:43:34  * paddybyersquit (Ping timeout: 256 seconds)
18:45:50  * c4milo__quit (Remote host closed the connection)
18:46:17  * c4milojoined
18:50:49  * c4miloquit (Ping timeout: 245 seconds)
19:30:24  * qmxchanged nick to qmx|away
20:03:55  * c4milojoined
20:05:52  * c4miloquit (Remote host closed the connection)
20:06:20  * c4milojoined
20:10:50  * c4miloquit (Ping timeout: 256 seconds)
20:17:43  * brsonjoined
20:33:19  * TooTallNatejoined
20:36:53  <MI6>joyent/node: Nathan Rajlich v0.10 * 55ea7cc : repl: use more readable RegExp syntax for spaces This is just a cosmetic (+1 more commits) - http://git.io/3HUg7Q
20:39:19  * brsonquit (Quit: leaving)
20:42:04  <tjfontaine>bnoordhuis: ok, after some time in #systemtap the probes are missing according to readelf
20:43:03  <tjfontaine>in both master and v0.10
20:43:49  <bnoordhuis>tjfontaine: oh? how come?
20:44:03  <tjfontaine>well that would be the question
20:44:36  <tjfontaine>both release and debug, so it's not a strip issue
20:44:49  <tjfontaine>do you have fedora around to see if it works there?
20:45:01  <bnoordhuis>yes, but not on a nearby machine
20:45:11  <bnoordhuis>is the dtrace tool run when you build node?
20:45:27  <tjfontaine>yes, and the node_systemtap.h is there and doesn't look invalid
20:45:39  <bnoordhuis>hrm, weird
20:45:52  <bnoordhuis>i can probably look at it tomorrow
20:46:04  <bnoordhuis>i never got it to work on debian or ubuntu btw
20:46:18  <bnoordhuis>not even when upgrading to systemtap master and a recent kernel
20:46:27  * paddybyersjoined
20:46:53  <tjfontaine>well, I am content with blaming debian if when you get a chance it ends up working for you
20:47:31  <bnoordhuis>okay, i'll try to, er, try it tomorrow
20:47:57  <tjfontaine>:)
20:52:32  <MI6>nodejs-v0.10: #94 UNSTABLE osx-x64 (1/570) windows-x64 (5/570) osx-ia32 (1/570) smartos-x64 (1/570) smartos-ia32 (1/570) windows-ia32 (4/570) linux-ia32 (1/570) http://jenkins.nodejs.org/job/nodejs-v0.10/94/
20:53:14  <MI6>joyent/node: David Braun master * 840a29f : buffer: change output of Buffer.prototype.toJSON() Expand the JSON repre - http://git.io/v6akfA
21:06:29  <MI6>nodejs-master: #132 FAILURE osx-ia32 (1/573) smartos-ia32 (3/573) smartos-x64 (2/573) http://jenkins.nodejs.org/job/nodejs-master/132/
21:08:56  * paddybyersquit (Ping timeout: 272 seconds)
21:13:29  <tjfontaine>bnoordhuis: ok got it, it was a problem with the fact that I had previously been playing with dtrace4linux
21:23:37  * qmx|awaychanged nick to qmx
21:32:13  <bnoordhuis>tjfontaine: ah. dtrace wasn't systemtap's dtrace?
21:40:14  * paddybyersjoined
21:40:21  <tjfontaine>bnoordhuis: right
21:40:42  <tjfontaine>or at least the node_systemtap.h wasn't generated by the right one anyway
21:40:48  * qmxchanged nick to qmx|away
21:44:48  <bnoordhuis>tjfontaine: it's nice to know i'm not the only dtrace4linux user
21:56:11  * paddybyersquit (Ping timeout: 246 seconds)
22:02:22  <tjfontaine>bnoordhuis: well I didn't actually play with dtrace4linux yet, just systemtap, my goal would be that they both expose the same interfaces
22:03:42  <tjfontaine>I didn't realize systemtap was going to distribute a dtrace binary fo rme
22:03:46  <mmalecki>https://github.com/mmalecki/saneopt/blob/master/include/saneopt.h#L44 - is this API nice for getting command line arguments?
22:03:49  <bnoordhuis>tjfontaine: dtrace4linux doesn't support userspace probes yet AFAIK
22:04:01  <tjfontaine>bnoordhuis: lame
22:04:44  <mmalecki>bnoordhuis: you happen to be an API genius, mind taking a look?
22:05:11  <tjfontaine>so many levels of indirection there :)
22:07:39  <mmalecki>tjfontaine: arguments has to be a pointer to an array of strings here
22:07:59  <tjfontaine>nod
22:08:11  <bnoordhuis>mmalecki: it's not clear to me if arguments is an in, out or in/out argument
22:08:22  <tjfontaine>I took it to mean &char**
22:08:27  <bnoordhuis>also, what is the return code if e.g. ENOMEM happens?
22:08:32  <mmalecki>bnoordhuis: it's out. what tjfontaine said.
22:08:46  <mmalecki>bnoordhuis: this is a good question
22:09:20  <mmalecki>bnoordhuis: so you're suggesting int as a return code?
22:09:34  <bnoordhuis>hm, depends
22:09:48  <bnoordhuis>if callers won't care about the actual error
22:10:08  <bnoordhuis>use e.g. const char** parseopts(...)
22:10:14  <bnoordhuis>and return NULL on error
22:10:50  <bnoordhuis>if callers do care, maybe int parseopts(char*** out)
22:10:55  <bnoordhuis>return 0 on success, -1 on error
22:11:04  <bnoordhuis>set *out = NULL on error
22:11:13  <bnoordhuis>and make it so that free(out) frees all the memory
22:11:27  <bnoordhuis>i.e. it should be a single, contiguous chunk of memory
22:11:58  <mmalecki>bnoordhuis: so when returning an array like that, set last item to NULL, correct?
22:12:08  <bnoordhuis>yes
22:12:27  <mmalecki>okay
22:12:38  <bnoordhuis>unless you're returning arrays so big that O(n) behavior becomes objectionable
22:12:42  <mmalecki>yeah, that return thing seems like a better choice actually
22:12:46  <bnoordhuis>but that's probably not the case here
22:12:56  <mmalecki>bnoordhuis: not really, shell would freak out :)
22:15:42  * AvianFluquit (Read error: Connection reset by peer)
22:15:59  * AvianFlujoined
22:16:18  * rendarquit
22:17:31  <mmalecki>bnoordhuis: thanks :)
22:19:28  <bnoordhuis>mmalecki: np
22:40:05  * verdagonjoined
22:40:33  <verdagon>hey, has anyone gotten libuv to work on android? i'm considering using it for my android game.
22:41:01  <bnoordhuis>verdagon: yes, but with caveats
22:41:08  <verdagon>oo
22:41:11  <bnoordhuis>people have got it to work on android in the past
22:41:13  <verdagon>where can i read up on these caveats?
22:41:19  <bnoordhuis>but it's not a tier 1 platform for us so YMMV
22:41:35  <bnoordhuis>best advice i can give you is try it and report issues :)
22:41:46  <bnoordhuis>or better yet, fix said issues and send us the patch
22:42:51  <verdagon>lol alright. know of anyone who is using it for their android app right now?
22:43:23  <bnoordhuis>verdagon: not by name but if you search the issue tracker, you'll find a few people
22:43:32  <verdagon>alright ill take a look, thanks m8
22:43:39  <bnoordhuis>np
22:49:09  <mmalecki>making libraries usable is damn hard
22:50:38  <bnoordhuis>you tell me
22:51:07  <bnoordhuis>the key is KISS
22:51:24  <verdagon>nonsense
22:51:26  <verdagon>we are ENGINEERS
22:51:32  <verdagon>simplicity is the enemy
22:51:45  <bnoordhuis>i use the inebriated litmus test
22:51:47  <indutny>troll is in studio
22:51:47  <mmalecki>verdagon: last time I said this, I ended up shooting to a big brick of ice
22:51:55  <bnoordhuis>if i can't use it while drunk, it's not a good api
22:51:58  <verdagon>lol
22:52:11  <mmalecki>I decided not to use this phrase anymore.
22:52:25  <verdagon>what did you shoot into a big brick of ice?
22:52:30  <verdagon>a gun?
22:52:32  <verdagon>an exception?
22:52:46  <bnoordhuis>indutny: are you convinced i'm right yet?
22:52:51  <indutny>bnoordhuis: nope
22:52:51  <bnoordhuis>indutny: that's re: tls btw
22:52:55  <indutny>its like
22:52:57  <bnoordhuis>indutny: okay, give it time
22:52:58  <indutny>yeah, it'll be fast
22:53:08  <indutny>but - no I don't like this in core
22:53:23  <indutny>deduplication - ftw
22:53:29  <indutny>simplictity - ftw
22:53:35  <bnoordhuis>yes and no
22:53:38  <indutny>separate networking layer - no
22:53:42  <indutny>s/no/fail/
22:53:43  <bnoordhuis>simplicity is good obviously
22:54:11  <bnoordhuis>but tls is currently layered on top of too many other things
22:54:19  <mmalecki>verdagon: a gun
22:54:22  <mmalecki>https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/382447_105534479590768_1072672192_n.jpg
22:54:22  <bnoordhuis>and that costs us, performance wise
22:54:55  <bnoordhuis>abstraction and separation of concerns are nice concepts in abstract
22:55:02  <bnoordhuis>but they get in the way when things need to be fast
22:55:03  <verdagon>lol so you said "we are engineers!" and shot some ice. that makes perfect sense
22:55:15  <indutny>bnoordhuis: its like you're sure about it, isn't it? :)
22:55:25  <indutny>I mean that we're loosing time in js-land
22:55:30  <indutny>dealing with abstractions
22:55:32  <bnoordhuis>yes
22:55:40  <bnoordhuis>quite obviously and provably
22:55:51  <indutny>and where is the proof?
22:55:58  <mmalecki>verdagon: it all started with finding a way to make lots of ice real quick
22:56:08  <verdagon>ROFL
22:56:20  <bnoordhuis>indutny: i don't mind profiling a few benchmarks and slapping you around the ears with the numbers :)
22:56:32  <indutny>bnoordhuis: sure, I'll be there
22:56:36  <indutny>just ping me when you'll be ready ;)
22:56:38  <bnoordhuis>with red ears
22:56:58  <bnoordhuis>but i assume you've done it yourself when you were benchmarkings tlsnappy
22:57:02  <bnoordhuis>that is
22:57:06  <indutny>exactly
22:57:18  <bnoordhuis>did you benchmark with aNULL+eNULL ciphers?
22:57:20  <indutny>I haven't proved it
22:57:25  <indutny>bnoordhuis: no
22:57:26  <bnoordhuis>that is, no auth, no encryption
22:57:35  <indutny>please continue
22:57:39  <bnoordhuis>right
22:58:01  <bnoordhuis>so you didn't actually benchmark the overhead of node's tls implementation then, did you?
22:58:28  * toothrotquit (Read error: Connection reset by peer)
22:59:40  <bnoordhuis>aside: standups, poisonous or not?
22:59:43  <indutny>bnoordhuis: looks like so
22:59:46  <indutny>bnoordhuis: did you?
22:59:54  <bnoordhuis>indutny: yes
23:00:06  <indutny>but benchmarking aNULL+eNULL is not the same as benchmarking overhead, right? ;)
23:00:17  <bnoordhuis>though admittedly i don't trust this MBA enough to be certain :)
23:00:25  <mmalecki>bnoordhuis: poisonous
23:00:46  <bnoordhuis>indutny: no? then what is?
23:00:47  <bnoordhuis>mmalecki: why?
23:01:51  <mmalecki>bnoordhuis: needing to be somewhere, everyday, at a certain time always disturbed my productivity. different timezones just make it worse.
23:02:01  <mmalecki>also skype call when I'm coding is the worst thing ever
23:02:20  <bnoordhuis>mmalecki: oh, like that. doesn't have to be daily
23:02:22  * toothrjoined
23:02:32  <bnoordhuis>at SL, we have one "standup" a week, i think
23:02:35  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:02:42  <bnoordhuis>and one optional mid-week call
23:03:04  <indutny>bnoordhuis: well
23:03:11  <indutny>its nothing :)
23:03:14  <indutny>but still interesting too se
23:03:16  <indutny>s/se/see
23:03:19  * TooTallNatejoined
23:03:20  <indutny>so basically
23:03:20  <mmalecki>bnoordhuis: weekly is fine, probably, but tends to be a bit long, I guess? why not email?
23:03:28  <indutny>my idea is that with improved load-balancing
23:03:29  <mmalecki>or IRC?
23:03:36  <indutny>tlsnappy+cluster will either outperform
23:03:44  <indutny>or perform nearly as better
23:03:56  <indutny>as popular tls terminators/servers
23:03:56  <bnoordhuis>mmalecki: agreed about the email thing. i guess we have the standup so people see each other in the flesh
23:04:02  <bnoordhuis>well, digitized flesh anyway
23:04:10  <indutny>bnoordhuis: so lets fix clustering first ;)
23:04:17  <indutny>benchmark tlsnappy and fix tls if its required
23:04:34  <mmalecki>bnoordhuis: heh. we only had voice calls, so no flesh
23:04:43  * verdagonquit (Quit: Page closed)
23:04:45  <indutny>my general idea is that cipher/decipher inside event-loops is harmful
23:04:47  * toothrchanged nick to toothrot
23:04:55  <bnoordhuis>indutny: when you have the chance, run a few benchmarks with null ciphers
23:05:00  <mmalecki>but now, no standups or unecessary meetings
23:05:06  <bnoordhuis>most of your performance loss comes from copying around data a lot
23:05:10  <indutny>bnoordhuis: on both tls and tlsnappy?
23:05:22  <indutny>bnoordhuis: that would surprise me a lot
23:05:24  <bnoordhuis>i'm talking about tls, didn't benchmarks tlsnappy
23:05:39  <indutny>but I believe its possible
23:05:46  <mmalecki>bnoordhuis: in general, I like what github does - minimize number of meetings
23:05:48  <indutny>ok, time to sleep
23:05:53  <bnoordhuis>maybe, just maybe, we could improve the current implementation by introducing non-stupid BIOs
23:05:56  <indutny>will keep it in mind hile lseeping
23:06:03  <indutny>ttyl
23:06:05  * indutny&
23:06:09  <bnoordhuis>sleep tight, fedor
23:06:26  <bnoordhuis>mmalecki: yeah, i'm no fan of meetings either
23:06:36  <bnoordhuis>i try to push back on that in SL
23:06:47  <bnoordhuis>but some of our coworkers have an enterprise background
23:07:03  <mmalecki>bnoordhuis: I push the 'no meetings' policy by not appearing on them
23:07:21  <mmalecki>I rarely even have to push anymore tho
23:07:37  <bnoordhuis>yeah? well, it's hard
23:07:51  <bnoordhuis>you don't want to miss out on meetings that are really relevant
23:07:59  <mmalecki>yeah, those I don't miss
23:08:13  <bnoordhuis>but that means you're often sitting in on meetings that are only partially relevant
23:08:16  <bnoordhuis>just in case
23:15:32  <ryah>f/names
23:19:06  <mmalecki>bnoordhuis: right, right. I try to push for those partially relevant meetings to be turned into an email thread
23:19:10  <mmalecki>this is easier to manage
23:19:20  <mmalecki>and involves less work to participate in
23:19:25  <mmalecki>hi ryah :)
23:32:06  * verdagonjoined
23:32:42  <verdagon>hey guys, quick question: is libuv's event loop based on a select() call? does it just wait for activity on the various FDs like STDIN_FILENO, sockets, etc?
23:32:58  <verdagon>and if so, what is uv_async_t? is that a pipe or something?
23:33:13  <bnoordhuis>verdagon: not quite select
23:33:22  <verdagon>ooo then what?
23:33:26  <bnoordhuis>but it uses epoll_wait/kevent/port_getn
23:33:48  <verdagon>hmmm... does it busywait, and keep checking those things?
23:33:55  <verdagon>or is it completely poll-less?
23:33:55  <bnoordhuis>no and no
23:34:10  <bnoordhuis>when you call uv_run, it calls epoll_wait/etc. in turn
23:34:34  <bnoordhuis>on windows, it uses iocp - but i assume you're not interested in that
23:35:30  <verdagon>awesome, thanks a bunch
23:36:50  * defunctzombie_zzchanged nick to defunctzombie
23:41:02  * verdagonquit (Quit: Page closed)