00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:00:31  <hueniverse>Other than the timer bug, hapi now passes all 700 tests on 0.11
00:00:47  <tjfontaine>excellent
00:00:51  <trevnorris>impressive
00:00:56  <hueniverse>we should be able to deploy one box on 0.11 as soon as the new build is out with the timer fix and confirm on regression
00:01:07  <trevnorris>tjfontaine: nope
00:01:13  <hueniverse>this was fun: https://github.com/spumko/hapi/pull/1037/files
00:01:22  <trevnorris>restarted, logged in with a new user, built from scratch
00:01:26  <trevnorris>still not defined
00:01:37  <hueniverse>making it work with both 0.10 and 0.11
00:04:10  <tjfontaine>trevnorris: new user won't help if it's something from your packaging
00:04:44  <trevnorris>oh well
00:04:48  <trevnorris>there's always tomorrow
00:05:40  <tjfontaine>hueniverse: do you build your own versions of node, or use what's in pkgsrc?
00:15:58  * dshaw_quit (Quit: Leaving.)
00:18:50  <MI6>libuv-master-gyp: #148 FAILURE windows-x64 (3/194) windows-ia32 (4/194) smartos-ia32 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/148/
00:19:59  <trevnorris>othiym23: holy shit, maybe you don't want to be alerted on every ReqWrap
00:21:16  <othiym23>trevnorris: before I was just looking for MakeCallback boundaries
00:21:53  <othiym23>and creationix wrapped a few other special cases, like net.Socket
00:22:03  <othiym23>is ReqWrap very high frequency?
00:22:26  <trevnorris>um, yeah. I almost have working code for the basic async listener (no domain stuff)
00:22:44  <trevnorris>i'll finish up tonight and you can throw some probes in there tomorrow
00:25:27  <othiym23>cool
00:30:00  <trevnorris>othiym23: so, ReqWrap runs 20k times just in test-net-pingpong.js
00:30:48  <trevnorris>tjfontaine: can you do something for me?
00:30:59  <trevnorris>run ./node test/simple/test-net-pingpong.js
00:31:02  <trevnorris>i'm getting a
00:31:09  <trevnorris>node: ../deps/uv/src/unix/loop.c:150: void uv__loop_delete(uv_loop_t *): Assertion `!((((*(&(loop)->active_reqs))[0]) == (&(loop)->active_reqs)) == 0)' failed.
00:31:14  <trevnorris>when it's done running
00:31:32  <tjfontaine>trevnorris: *that* is the loop.c:150
00:31:43  <trevnorris>tjfontaine: ahh. ok.
00:32:07  <tjfontaine>so ben feels like it's a valid assert that means as we're closing node down we're not adhering to it (always)
00:32:13  <tjfontaine>if
00:32:30  <trevnorris>well, whatever
00:33:06  <trevnorris>hopefully he's on tomorrow to fix it
00:33:08  * trevnorris&
00:33:38  <hueniverse>tjfontaine: typically whatever is in the joyent distro, but for this we will build it ourselves
00:33:46  <hueniverse>just one machine
00:34:01  <hueniverse>but I'm dying to see memory performance on the new branch
00:34:05  <hueniverse>compared to 0.10
00:36:02  <tjfontaine>right
00:46:18  * dapquit (Quit: Leaving.)
00:49:00  * ecrquit (Quit: ecr)
00:51:12  * amartensquit (Quit: Leaving.)
00:51:51  * groundwaterjoined
00:53:45  * EhevuTovquit (Quit: This computer has gone to sleep)
00:54:00  * TooTallNatejoined
00:55:17  * groundwaterquit (Client Quit)
01:01:56  * indexzerojoined
01:09:34  * abraxasjoined
01:14:44  * kazuponjoined
01:20:52  <trevnorris>tjfontaine: ok, that assert is bull shit
01:21:06  <trevnorris>tjfontaine: I can't console.log on process.on('exit' w/o the assert failing
01:21:33  <trevnorris>isaacs: ^
01:21:54  <isaacs>trevnorris: in master, i take it?
01:22:07  <trevnorris>isaacs: yeah
01:22:11  <trevnorris>from the 0.11.11 upgrade
01:22:21  <isaacs>oh, gotcha
01:22:43  <trevnorris>tjfontaine found it at: https://github.com/joyent/libuv/commit/3f2d4d535867a99170b4964f2e3db1ef70968c23
01:23:51  <isaacs>yeah, this is super busted.
01:23:55  <isaacs>breaks a boatload of tests.
01:24:22  <isaacs>$ cat c.js
01:24:22  <isaacs>process.on('exit', function() {
01:24:22  <isaacs> console.log('ok');
01:24:22  <isaacs>});
01:24:22  <isaacs>$ ./node c.js
01:24:25  <isaacs>ok
01:24:27  <isaacs>Assertion failed: (!uv__has_active_reqs(loop)), function uv__loop_delete, file ../deps/uv/src/unix/loop.c, line 150.
01:24:29  <trevnorris>yup
01:24:30  <isaacs>Abort trap: 6
01:24:52  <trevnorris>whether it's a valid assert or not, it should have been tested and fixed in core before being pushed to master.
01:24:52  <isaacs>oh, ok... this is weird... it actually DOESNT break tests, but only because they're pipes and not actually tty's, i guess?
01:24:55  <isaacs>seems oddball
01:25:06  <trevnorris>it's a race condition
01:25:10  <isaacs>trevnorris: sure, but i mean, we've all broken core at some point :)
01:25:14  <isaacs>er broken master.
01:25:31  <isaacs>i'm still catching up with the number of times ryah did, but i'm sure i'll get there one day
01:25:41  <trevnorris>whether the req can complete before the assert is checked.
01:25:46  <isaacs>right
01:26:16  <trevnorris>i'm trying to get that asyncListener patch ready for tomorrow, but this is making it a bit of a pain.
01:26:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:26:50  <trevnorris>whatevs. i'll just rebase and drop that commit for now.
01:30:20  <isaacs>yeah
01:30:27  <trevnorris>isaacs: good news. I can now add a callback and easily track every reqwrap. though I didn't realize how often it gets called.
01:30:32  <isaacs>hahaa
01:30:38  <isaacs>yeah, that's a hot path :)
01:33:12  * kazuponquit (Remote host closed the connection)
01:34:10  * dshaw_joined
01:37:00  <othiym23>is there any way to filter down the ReqWrap calls so the async listener isn't firing every single time?
01:37:22  <othiym23>because even if the functions are super fast, that's going to be a ton of overhead
01:49:53  <isaacs>tjfontaine: are you looking into a fix for the uv 0.11.11 breakage?
01:50:03  <isaacs>tjfontaine: just curious, not suggesting you should or ought to :)
01:52:16  * dshaw_quit (Quit: Leaving.)
01:57:30  * indexzeroquit (Quit: indexzero)
02:02:40  * pachetquit (Quit: [ +++ ])
02:07:48  * TooTallNatejoined
02:10:48  * indexzerojoined
02:13:22  <isaacs>hueniverse: whoa! was that a new version of node at the end there, or a new version of your stuff?
02:17:39  * AvianFluquit (Remote host closed the connection)
02:19:08  <hueniverse>isaacs: out shit
02:19:19  <isaacs>tjfontaine, trevnorris: I should win a prize for this bug id: https://github.com/joyent/libuv/issues/911
02:19:22  <hueniverse>of course, we forgot to gcore
02:19:32  <isaacs>it's really not as big an emergency as the url would have you believe :)
02:19:35  <hueniverse>so this shit is going back into rotation tomorrow on 1 server
02:19:46  * indexzeroquit (Quit: indexzero)
02:19:54  <isaacs>hueniverse: awww
02:20:01  <isaacs>hueniverse: hopefully it'll blow up again :)
02:20:13  <hueniverse>isaacs: yeah...
02:21:33  <hueniverse>these charts are not really useful but fun to share :-)
02:21:46  * indexzerojoined
02:27:21  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:27:41  * indexzeroquit (Quit: indexzero)
02:38:47  * wavdedjoined
02:43:36  * kazuponjoined
02:50:43  * kazuponquit (Ping timeout: 246 seconds)
03:02:15  * amartensjoined
03:21:07  <trevnorris>isaacs: heh, nice
03:23:01  * st_lukequit (Remote host closed the connection)
03:33:29  * indexzerojoined
03:36:00  <trevnorris>oh freak yeah
03:36:20  <trevnorris>isaacs: so with a super simple async listener the performance hit is within the margin of error
03:36:51  <trevnorris>isaacs: i have one just counting how many times it's hit on the http benchmark
03:37:52  <trevnorris>othiym23: ^
03:55:19  * indexzeroquit (Quit: indexzero)
03:57:55  * kazuponjoined
03:58:46  * indexzerojoined
04:02:02  * mikealjoined
04:17:40  * brsonquit (Quit: leaving)
04:33:35  * wavdedquit (Quit: Hasta la pasta)
04:33:57  * indexzeroquit (Quit: indexzero)
04:37:03  * groundwaterjoined
04:38:03  * mikealquit (Quit: Leaving.)
04:44:15  * mikealjoined
04:56:38  * julianduquequit (Quit: leaving)
05:08:21  * st_lukejoined
05:09:06  <tjfontaine>isaacs: I haven't actually looked into the specific case, I think the assert is probably valid, you're calling delete but haven't stopped all the things you have in flight
05:09:45  <tjfontaine>the best thing would be to break at that assert and then `call uv__print_handles` or whatever it is
05:10:25  * indexzerojoined
05:16:41  * ecrjoined
05:17:03  * ecrquit (Client Quit)
05:28:50  <mmalecki>a bit confused - I'm playing with uv's FS APIs for the first time and wondering why uv_fs_write isn't just uv_write?
05:32:46  <tjfontaine>I think it's mostly because of the positional writes, and the fact that there's really not a useful non-blocking api?
05:40:55  * piscisaureus_joined
05:42:23  * indexzeroquit (Quit: indexzero)
05:45:53  * inolenquit (Quit: Leaving.)
05:48:13  * indexzerojoined
05:49:03  <tjfontaine>piscisaureus_: er, well I guess "NDEBUG" in the sense of asserts enabled mode
05:49:15  <tjfontaine>which is how we fly in unix land
05:51:00  <mmalecki>tjfontaine: hmm, right
05:51:03  <mmalecki>tjfontaine: good point
05:51:17  <mmalecki>tjfontaine: would be cool to make uv_write work with that too
05:51:50  <tjfontaine>mmalecki: I think ben said in the past that it does work, by accident?
05:52:25  <tjfontaine>in so far as it will do something reasonably right
05:53:29  <piscisaureus_>tjfontaine: hi
05:54:19  <tjfontaine>hi
05:54:24  <mmalecki>tjfontaine: heh, the 'in so far as it will do something reasonably right' - how we all try to write software
05:54:50  <piscisaureus_>tjfontaine: you'er right about the NDEBUG
05:55:38  <piscisaureus_>tjfontaine: there's two ways to fix this:
05:55:38  <piscisaureus_>* ref() and uv_close() all handles, then call uv_run() again, before calling uv_loop_delete
05:55:45  * st_lukequit (Remote host closed the connection)
05:55:50  <piscisaureus_>* or: drop the uv_loop_delete
05:56:33  <piscisaureus_>the first option is the cleanest. However it's also the slowest and it requires extra work
05:56:35  <tjfontaine>ya, I am of the opinion the assert in uv is probably valid
05:56:47  <piscisaureus_>since calling uv_run() might lead to js callbacks being called
05:58:00  <tjfontaine>it seems reasonable to believe that if we're on the graceful path, to believe the assert should be valid
05:58:14  <tjfontaine>however in the process.exit() path, it almost certainly won't be valid
06:01:54  <tjfontaine>rvagg: if you don't have a JPC account, if you put that core somewhere I can get it I will take a look
06:02:06  * groundwaterquit (Quit: groundwater)
06:02:57  <piscisaureus_>tjfontaine: I would suggest to just remove the uv_loop_delete call as a fix
06:03:02  <piscisaureus_>versus removing the (valid!) assert
06:03:26  <piscisaureus_>tjfontaine: the reason this uv_loop_delete call doesn't make node crash is that it exits immediately thereafter
06:03:42  <tjfontaine>it is making node crash :)
06:04:52  <mmalecki>so I might be just dumb, but why do you have to pass both uv_fs_t and uv_file to all fs-related functions
06:11:51  * indexzeroquit (Quit: indexzero)
06:22:31  * defunctzombiechanged nick to defunctzombie_zz
06:30:44  <piscisaureus_>yes, nobody knows
06:31:06  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
06:32:31  * txdvquit (Ping timeout: 260 seconds)
06:39:17  * indexzerojoined
06:48:20  <MI6>nodejs-v0.10-windows: #183 UNSTABLE windows-x64 (7/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/183/
06:59:01  * indexzeroquit (Quit: indexzero)
06:59:58  * rendarjoined
07:01:20  * indexzerojoined
07:06:27  * amartensquit (Quit: Leaving.)
07:06:37  * indexzeroquit (Quit: indexzero)
07:11:26  * indexzerojoined
07:20:25  * defunctzombie_zzchanged nick to defunctzombie
07:21:12  * indexzeroquit (Quit: indexzero)
07:22:43  * indexzerojoined
07:26:10  * defunctzombiechanged nick to defunctzombie_zz
07:28:55  * hueniversequit (Read error: Connection reset by peer)
07:29:17  * hueniversejoined
07:29:33  * amartensjoined
07:34:00  * defunctzombie_zzchanged nick to defunctzombie
07:40:30  * piscisaureus_joined
07:42:39  <trevnorris>piscisaureus_: hey
07:42:47  <piscisaureus_>trevnorris: yo
07:45:30  * defunctzombiechanged nick to defunctzombie_zz
07:45:42  <trevnorris>piscisaureus_: so of the two issues, the one I tweeted was because, for some unknown reason, EAI_NODATA isn't defined because __USE_GNU isn't defined
07:45:54  <trevnorris>piscisaureus_: haven't been able to figure out what's up with that.
07:46:17  <trevnorris>piscisaureus_: the second crash issue from the upgrade, it's making it impossible to log anything on process.on('exit'
07:46:44  <piscisaureus_>trevnorris: ok, so to fix the latter remove the uv_loop_delete call from node.cc
07:47:00  <piscisaureus_>trevnorris: it's a node bug that got exposed by adding an assert to libuv
07:47:07  <piscisaureus_>(or comment it out and explain what's up)
07:47:58  <piscisaureus_>trevnorris: as for the EAI_NODATA issue, it's probably because of this -> https://github.com/joyent/libuv/commit/d6464c87bdd36a1c491a47fcc7ced214b751d955
07:48:16  <trevnorris>i noticed a comment about not running any more callbacks, in theory I can understand that, but when it prevents me from logging data on exit that's just a practical issue
07:48:22  <piscisaureus_>trevnorris: a solution would be I guess to add _GNU_SOURCE to node's common.gypi, or to revert that patch in loibuv
07:48:46  <piscisaureus_>but it'd be best to talk to ben about this
07:49:10  <trevnorris>sounds good. for now i'm just working from the previous commit since I can't get much done like this
07:49:22  <piscisaureus_>trevnorris: right, ok.
07:50:55  <trevnorris>piscisaureus_: thanks. i'm off to bed. as long as I can log data on exit and it doesn't abort on me i'm cool w/ any solution you come up with. :)
07:51:20  <piscisaureus_>trevnorris: sleep tight
07:51:23  <trevnorris>:)
07:51:25  * trevnorris&
08:15:59  * indexzeroquit (Quit: indexzero)
08:20:48  * amartensquit (Quit: Leaving.)
08:22:04  * indexzerojoined
08:50:43  * hzjoined
08:53:42  * indexzeroquit (Quit: indexzero)
08:55:25  * defunctzombie_zzchanged nick to defunctzombie
09:01:31  * Benviequit
09:05:10  * defunctzombiechanged nick to defunctzombie_zz
09:06:05  * indexzerojoined
09:07:38  * indexzeroquit (Client Quit)
09:13:23  * dominictarrjoined
09:15:46  * indexzerojoined
09:21:33  * indexzeroquit (Quit: indexzero)
09:25:52  * indexzerojoined
09:38:03  * kazupon_joined
09:38:55  * kazuponquit (Read error: Connection reset by peer)
09:44:10  * bnoordhuisjoined
09:58:50  * indexzeroquit (Quit: indexzero)
10:08:07  * indexzerojoined
10:32:54  * indexzeroquit (Quit: indexzero)
10:37:22  * kazupon_quit (Remote host closed the connection)
10:45:58  <MI6>nodejs-v0.10: #1455 UNSTABLE linux-x64 (1/598) smartos-x64 (2/598) linux-ia32 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1455/
10:57:50  * abraxasquit (Remote host closed the connection)
11:38:50  * Benviejoined
11:48:31  <bnoordhuis>piscisaureus_: ping
11:53:34  <piscisaureus_>bnoordhuis: hello
11:53:42  <piscisaureus_>bnoordhuis: is it a quick question?
11:54:43  <piscisaureus_>bnoordhuis: I'm AFK doing paperwork but try to talk to me async
11:59:08  <bnoordhuis>oh okay
11:59:33  <bnoordhuis>was just thinking through the ramifications of force-closing libuv handles on exit
12:00:34  * pachetjoined
12:00:41  <bnoordhuis>logically, when closing handles with a NULL close_cb, the only callbacks libuv will make are for cancelled requests
12:01:33  <bnoordhuis>and only for reqs associated with internal or unref'd handles because those are the only handles left at that point
12:02:02  <bnoordhuis>('internal' in the 'internal to node.js' sense, not internal to libuv)
12:04:27  <piscisaureus_>bnoordhuis: well - no - there is no guarantee that requests are cancelled when a handle is closed
12:04:33  <piscisaureus_>because this is inherently race-y
12:04:43  <piscisaureus_>also the user might have called process.exit()
12:04:58  <bnoordhuis>process.exit() calls exit(), there's no cleanup in that case
12:05:04  <piscisaureus_>ah
12:05:34  <piscisaureus_>I wonder why the process even gets to that point if a console write hasn't completed yet
12:06:07  <piscisaureus_>I mean, shouldn't the event loop keep running until all the write()s have called their callback (even if it's a bogus callback because stdout is sync)
12:06:09  <bnoordhuis>i suspect you're thinking of process.on('exit', ...)?
12:06:22  <bnoordhuis>because that's emitted once uv_run() returns
12:06:22  <piscisaureus_>No I'm thinking of trevnorris' test case
12:06:30  <bnoordhuis>what test case is that?
12:06:55  <piscisaureus_>process.on('exit', function() {
12:06:55  <piscisaureus_> console.log('bye'); // Asserts.
12:06:55  <piscisaureus_>});
12:07:06  <bnoordhuis>you mean isaac's test case?
12:07:07  <piscisaureus_>ah - ok
12:07:17  <piscisaureus_>oh trevnorris had the same problem
12:07:18  <piscisaureus_>sorry
12:07:22  <bnoordhuis>hah, okay :)
12:07:24  <piscisaureus_>anyway
12:07:44  <piscisaureus_>anything request that is created in the exit callback could be pending
12:07:59  <bnoordhuis>"shouldn't the event loop keep running until all the write()s have called their callback" <- maybe
12:08:14  <bnoordhuis>it kind of makes sense
12:08:18  <piscisaureus_>well yes- I didn't think of the exit callback "case"
12:09:14  <piscisaureus_>bnoordhuis: in fact if you could make node always close handles (so also in the process.exit case) you'd get an extra hug
12:09:27  <piscisaureus_>that'd solve the clipped stdout problem on windows
12:10:04  <bnoordhuis>hrm, okay. it's not hard to do
12:10:33  <piscisaureus_>although I suppose you'd want to uv_shutdown() pipes and not close them forcefully
12:10:40  <bnoordhuis>why not?
12:10:42  <piscisaureus_>because obviously closing would still cancel requests
12:10:43  <piscisaureus_>hmm
12:26:46  <piscisaureus_>have to reboot. bbiab
12:29:37  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
12:58:41  * piscisaureus_joined
12:59:48  <bnoordhuis>piscisaureus_: re: pipes and shutdown, when/why would you call uv_shutdown()?
13:00:07  <bnoordhuis>i ask because that seems like it could block for an extended period of time, right?
13:00:31  <piscisaureus_>bnoordhuis: well - I'd do something to avoid cancelling uv_write requests
13:02:25  <bnoordhuis>piscisaureus_: so... uv_shutdown() and then in your shutdown cb, uv_close()?
13:02:31  <piscisaureus_>bnoordhuis: yea
13:02:44  <bnoordhuis>okay. but what about unref'd pipe handles from the user?
13:03:07  <piscisaureus_>bnoordhuis: good question :)
13:03:27  <piscisaureus_>bnoordhuis: in fact this is one of the "open questions" I face with doing Task
13:03:48  <piscisaureus_>bnoordhuis: I'm gearing towards *in the general case* cancelling stuff
13:03:52  <piscisaureus_>but making an exception for writes
13:04:06  <piscisaureus_>users almost never want writes to be canceled
13:05:11  <piscisaureus_>bnoordhuis: but I don't have a strong opinion. If you could do it for stdout, stderr and the IPC pipe it'd be good enough for me.
13:05:57  <piscisaureus_>(btw - I've thought of secretly adding uv_flush for a long time)
13:13:43  <bnoordhuis>hrm, well, i'll see what i can do
13:13:53  <bnoordhuis>this is becoming heedlessly complex though
13:14:02  <bnoordhuis>for what started as such a small change, i mean
13:16:13  <bnoordhuis>apropos nothing, some of the tests in test/simple/ take way too long to run
13:16:27  <bnoordhuis>4-5 seconds is not acceptable >:(
13:19:22  <piscisaureus_>move them to pummel ?
13:20:25  <piscisaureus_>bnoordhuis: I agree about too complex
13:20:55  <piscisaureus_>bnoordhuis: you could also fix the immediate issue now and leave my demands for what they are
13:22:49  <bnoordhuis>i'm leaning towards that, yes :)
13:24:23  <piscisaureus_>bnoordhuis: it's not much more complicated than closing though
13:24:25  <piscisaureus_>I mean
13:25:14  <piscisaureus_>(if handle->type == UV_PIPE && uv_is_writable((uv_stream*t) handle) uv_shutdown(handle, shutdown_cb_that_closes);
13:25:14  <piscisaureus_>else uv_close(handle)
13:25:37  <piscisaureus_>the only thing is that the reinterpret_cast<uv_walk_cb>(uv_close) no longer works
13:26:13  <bnoordhuis>try it and see if that works
13:26:20  <bnoordhuis>(hint: it doesn't, it breaks a lot of tests)
13:27:34  <piscisaureus_>oh
13:27:38  <piscisaureus_>:)
13:27:45  <piscisaureus_>I suppose that's not what we want
13:28:02  <piscisaureus_>I guess you have no clear explanation why it makes tests fail
13:31:47  <bnoordhuis>didn't dive into it too deeply
13:39:19  <piscisaureus_>understood
13:46:36  <bnoordhuis>that reminds me that we should make node V8::TerminateExecution-safe someday
13:46:49  <bnoordhuis>right now, it will probably break hard in interesting ways
13:53:50  * hueniversequit (Quit: Leaving.)
14:05:31  * kevinswiberjoined
14:08:49  * jmar777joined
14:11:25  * kevinswiberquit (Remote host closed the connection)
14:14:43  * kevinswiberjoined
14:16:33  * c4milojoined
14:18:06  * kazuponjoined
14:20:41  <piscisaureus_>interesting has a positive vibe to it
14:21:58  * bnoordhuisquit (Ping timeout: 246 seconds)
14:26:47  * Benviequit (Ping timeout: 260 seconds)
14:34:56  * bnoordhuisjoined
14:38:50  * kenperkinsquit (Quit: Computer has gone to sleep.)
14:39:04  * c4miloquit (Remote host closed the connection)
14:39:30  * kenperkinsjoined
14:42:12  * c4milojoined
14:45:43  <piscisaureus_>bnoordhuis: nice!
14:46:02  <piscisaureus_>let's see what jenkins thinks of it.
14:46:54  <bnoordhuis>piscisaureus_: re UV_EPIPE, are there other errors i should expect to see?
14:47:18  <piscisaureus_>bnoordhuis: not sure TBH
14:47:31  <piscisaureus_>bnoordhuis: I forgot - you might also want to check for uv_is_writable before attempting to shutdown
14:48:08  <piscisaureus_>bnoordhuis: it could be already shut down, or read only (in the latter case uv_shutdown would fail with UV_EPERM I think)
14:48:28  <piscisaureus_>ERROR_ACCESS_DENIED or ntstatus == c0000005
14:49:18  <piscisaureus_>bnoordhuis: let's
14:49:24  <bnoordhuis>so... when it's read-only, just close it?
14:49:32  <piscisaureus_>yeah. Nothing to flush then right?
14:49:43  <bnoordhuis>yeah. just asking :)
14:50:05  <piscisaureus_>bnoordhuis: actually libuv had a couple of issues when dealing with half-duplex pipes but I just fixed them all yesterday
14:50:13  <piscisaureus_>would be sad to reintroduce bugs now :)
14:51:40  <indutny>piscisaureus_: hey man
14:51:59  <piscisaureus_>hi indutny
14:52:52  <indutny>piscisaureus_: just curious, what's a good time to visit AMS?
14:53:00  <piscisaureus_>indutny: the summer
14:53:03  <piscisaureus_>indutny: last month
14:53:22  <indutny>We're thinking about staying there for a xmas
14:53:26  <indutny>:)
14:53:31  <piscisaureus_>indutny: that's okay too
14:53:41  <piscisaureus_>indutny: but holland is rainy and sad in winter
14:53:47  <indutny>oh
14:53:56  <piscisaureus_>I guess it's not much worse that omsk though
14:54:02  <indutny>haha :)
14:54:08  <indutny>well, I'm living in moscow, you know
14:54:11  <indutny>so, well
14:54:11  <piscisaureus_>s/that/than/
14:54:13  <indutny>at least
14:54:35  <indutny>is there a time when everything in garlands and looks like a celebration?
14:54:35  <indutny>:)
14:54:45  <indutny>honestly, I don't care much
14:54:48  <indutny>my wife is asking
14:54:54  <piscisaureus_>haha
14:55:00  <indutny>she wants to pick the best date to visit netherlands
14:55:03  <piscisaureus_>christmas is okay
14:55:09  <indutny>to catch a christmas?
14:55:13  <indutny>err...
14:55:36  <piscisaureus_>I'd come in the summer but I guess christmas could be okay.
14:55:39  <indutny>so, when are you guys starting to prepare to it?
14:55:46  <indutny>xmas
14:56:03  <piscisaureus_>I'd stay out januari till april and october
14:56:16  <piscisaureus_>indutny: well depends on who you mean with "you guys"
14:56:32  <piscisaureus_>indutny: the shops will probably start late september
14:56:32  <indutny>dutch people :)
14:56:38  <indutny>oh gosh
14:56:46  * AvianFlujoined
14:56:48  <indutny>I guess I'm just tired and can't really ask what I want :D
14:56:53  <piscisaureus_>that's what dutch people say abot it
14:57:13  <bnoordhuis>indutny: you should come celebrate sinterklaas
14:57:27  <bnoordhuis>santa claus is just a cheap american knock-off
14:57:28  <piscisaureus_>that is december 5th, fyi
14:57:44  <indutny>thank you! :)
14:57:53  <indutny>ok, I'll think about visiting somewhere before dec 5
14:58:01  <piscisaureus_>yeah I guess that'd be good actually
14:58:17  <piscisaureus_>iff you are coming for christmas, come before sinterklaas
14:58:37  <piscisaureus_>and get the heck out of here just after new year at the latest
14:58:48  <indutny>:)
14:58:50  <indutny>ook
14:58:52  <indutny>thanks
14:59:01  <indutny>gtg
14:59:11  <piscisaureus_>nono wait until december
14:59:19  <bnoordhuis>yeah. january and february are the saddest months :-/
14:59:34  <bnoordhuis>i could live with just scrapping them
15:01:31  <piscisaureus_>Damn
15:01:47  <piscisaureus_>Who had the luminous idea to make 2gb usb2 hard drives
15:02:18  <bnoordhuis>someone with a ton of patience?
15:02:38  <piscisaureus_>I don't understand why they ever became so popular.
15:03:03  <piscisaureus_>The transfer speed / size balance is way off
15:11:29  * austo_joined
15:11:29  * austo_quit (Client Quit)
15:17:57  <MI6>nodejs-master: #508 UNSTABLE linux-ia32 (1/645) smartos-x64 (6/645) osx-ia32 (1/645) linux-x64 (1/645) http://jenkins.nodejs.org/job/nodejs-master/508/
15:19:03  * bnoordhuisquit (Ping timeout: 268 seconds)
15:26:45  * hueniversejoined
15:43:47  * hzquit (Read error: Connection reset by peer)
15:45:04  * kevinswiberquit (Remote host closed the connection)
15:45:40  * bnoordhuisjoined
15:49:36  * kevinswiberjoined
15:51:55  <tjfontaine>bnoordhuis: http://jenkins.nodejs.org/job/nodejs-master/508/DESTCPU=x64,label=linux/tapTestReport/test.tap-360/ <-- what trevnorris was hitting as well, with things like EAI_NODATA not being defined
15:53:11  * hzjoined
15:54:10  * bnoordhuisquit (Ping timeout: 245 seconds)
16:02:12  * CoverSli1joined
16:04:27  * kazuponquit (Remote host closed the connection)
16:07:57  * TooTallNatejoined
16:09:24  * groundwaterjoined
16:09:48  * dshaw_joined
16:10:33  * dapjoined
16:11:01  * kazuponjoined
16:13:37  <trevnorris>hey, someone reproduced my other error. yay!
16:18:04  * amartensjoined
16:18:17  * CoverSli1quit (Quit: CoverSli1)
16:18:52  * hzquit (Ping timeout: 268 seconds)
16:18:52  * kenperkinsquit (Quit: Computer has gone to sleep.)
16:20:31  * CoverSlide1joined
16:21:42  * hzjoined
16:22:27  <trevnorris>tjfontaine: I asked piscisaureus_ about that error last night/this morning and he seemed to know exactly why it was happening
16:22:59  <piscisaureus_>_GNU_SOURCE
16:23:48  <trevnorris>yeah, you pointed to libuv@d6464c8 as the culprit
16:23:53  <tjfontaine>trevnorris: ya, it's what we talked about last night
16:24:20  <tjfontaine>don't you remember seeing that?
16:24:59  <trevnorris>tjfontaine: don't remember too much. my mind has been so consumed w/ the asyn listeners that my mind is melting
16:25:10  <tjfontaine>we can add it to node.gyp or common, just a matter of where the right place is
16:25:35  <trevnorris>good news though, adding an async listener to do something as simple as counting has practically zero cost on performance :) (at the macro level)
16:26:22  <trevnorris>tested it out on benchmark/tls/thoughput.js, that thing is calling nextTick over 100k/sec
16:45:51  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:49:44  * dominictarrquit (Quit: dominictarr)
17:02:42  * TooTallNatejoined
17:03:37  * AvianFluquit (Remote host closed the connection)
17:08:55  * defunctzombie_zzchanged nick to defunctzombie
17:10:57  * defunctzombiechanged nick to defunctzombie_zz
17:12:29  * bnoordhuisjoined
17:16:15  * mikealquit (Quit: Leaving.)
17:19:16  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:22:31  * kazuponquit (Remote host closed the connection)
17:24:28  * dshaw_quit (Quit: Leaving.)
17:24:34  * jmar777quit (Read error: Connection reset by peer)
17:24:56  * kazuponjoined
17:25:02  * jmar777joined
17:26:55  * kevinswiberquit (Remote host closed the connection)
17:28:12  * defunctzombie_zzchanged nick to defunctzombie
17:30:51  * kevinswiberjoined
17:31:46  * dshaw_joined
17:33:58  * AvianFlujoined
17:35:31  * kevinswiberquit (Remote host closed the connection)
17:43:21  * AvianFluquit (Ping timeout: 268 seconds)
17:46:26  * c4miloquit (Remote host closed the connection)
17:50:48  * mikealjoined
17:52:10  * dshaw_quit (Quit: Leaving.)
17:52:49  <othiym23>I'd be interested to see what IRHydra makes of that simple counter, trevnorris
17:52:53  <othiym23>is it getting inlined somehow?
17:53:07  <othiym23>creationix: you around?
17:53:29  <trevnorris>othiym23: not sure. have a little more work to do on it, but i'll do some of that analysis as well.
17:53:44  <trevnorris>honestly I was surprised it has so little performance impact at the macro level
17:53:46  <MI6>libuv-master: #209 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/209/
17:53:57  <trevnorris>even when it was getting called 100k+/sec
17:54:11  <othiym23>that's what makes me think some kind of optimization is triggering
17:54:14  <othiym23>NOT that I'm complaining ;)
17:56:00  <MI6>joyent/node: Ben Noordhuis master * 9b98417 : src: close libuv handles on exit - http://git.io/Dh-8DQ
18:04:10  * AvianFlujoined
18:05:50  * dshaw_joined
18:06:30  <MI6>nodejs-master-windows: #301 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/301/
18:09:19  * dominictarrjoined
18:10:05  <MI6>nodejs-master: #509 UNSTABLE linux-ia32 (2/646) smartos-x64 (6/646) osx-ia32 (7/646) smartos-ia32 (4/646) osx-x64 (10/646) linux-x64 (2/646) http://jenkins.nodejs.org/job/nodejs-master/509/
18:13:13  * dshaw_quit (Quit: Leaving.)
18:13:22  * brsonjoined
18:14:06  <MI6>libuv-node-integration: #193 UNSTABLE smartos-x64 (7/645) smartos-ia32 (1/645) linux-x64 (1/645) linux-ia32 (2/645) http://jenkins.nodejs.org/job/libuv-node-integration/193/
18:21:31  * kazuponquit (Remote host closed the connection)
18:25:26  * rendarquit (Ping timeout: 245 seconds)
18:26:15  * hzquit
18:28:39  * c4milojoined
18:33:47  * julianduquejoined
18:35:00  * julianduquequit (Client Quit)
18:35:40  * julianduquejoined
18:35:59  <MI6>nodejs-master-windows: #302 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/302/
18:37:42  <bnoordhuis>src\node.cc(2946): error C2660: 'node::CloseHandle' : function does not take 1 arguments [g:\jenkins\workspace\nodejs-master-windows\eec653f3\node.vcxproj] <- waah?
18:38:00  <tjfontaine>hehe I was just about to paste that
18:38:56  <bnoordhuis>what the hell is wrong with msvs? it doesn't support unnamed parameters?
18:40:50  <MI6>joyent/node: bnoordhuis created branch jenkins-msvs-workaround - http://git.io/kOjIkQ
18:41:17  <bnoordhuis>ah, son of a bitch
18:41:25  <bnoordhuis>CloseHandle is a windows api function
18:41:35  <tjfontaine>oh
18:41:36  <tjfontaine>heh
18:42:34  <MI6>joyent/node: Ben Noordhuis master * 4915884 : src: close libuv handles on exit - http://git.io/QR0EAg
18:42:39  <bnoordhuis>sigh
18:42:49  <tjfontaine>was that a force?
18:43:05  <bnoordhuis>yes
18:43:09  <tjfontaine>double sigh
18:43:18  <bnoordhuis>oh? does it break jenkins?
18:43:41  <tjfontaine>not this time since it was clear, but it could have
18:45:23  * julianduquequit (Quit: leaving)
18:46:08  * julianduquejoined
18:51:03  * dominictarrquit (Quit: dominictarr)
18:57:46  <MI6>nodejs-master: #510 UNSTABLE linux-ia32 (2/646) smartos-x64 (6/646) osx-ia32 (9/646) smartos-ia32 (4/646) osx-x64 (7/646) linux-x64 (1/646) http://jenkins.nodejs.org/job/nodejs-master/510/
18:58:01  <MI6>node-review: #81 FAILURE smartos-ia32 (5/646) osx-ia32 (8/646) linux-ia32 (4/646) linux-x64 (2/646) smartos-x64 (7/646) osx-x64 (8/646) centos-ia32 (2/646) centos-x64 (3/646) http://jenkins.nodejs.org/job/node-review/81/
18:58:37  <tjfontaine>bnoordhuis: # Assertion failed: (status == 0), function MaybeCloseNamedPipe, file ../src/node.cc, line 1738.
18:58:50  <tjfontaine>lets not do another force to fix this one though
18:59:01  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-master/510/DESTCPU=ia32,label=osx/tapTestReport/test.tap-484/
19:00:53  * dshaw_joined
19:03:30  <creationix>othiym23, sorry, my irc client didn't notify me
19:03:33  * kevinswiberjoined
19:04:12  <bnoordhuis>tjfontaine: i won't, that looks like a legitimate issue
19:04:19  <bnoordhuis>i blame bert, personally
19:06:14  <bnoordhuis>that is to say, a legitimate issue if i could reproduce it
19:06:34  <bnoordhuis>tjfontaine: is there anything unusual about the way jenkins runs tests on that machine?
19:08:42  * dominictarrjoined
19:09:26  <tjfontaine>bnoordhuis: they're run in screen, from node, with python tools/test.py simple message
19:10:04  <bnoordhuis>hrm, that's pretty much how i run tests on os x
19:10:18  <tjfontaine>because there are other pipe and tty concerns that we need to keep the jenkins test runner happy
19:10:24  <tjfontaine>brb lunch
19:14:31  <trevnorris>bnoordhuis: when/if you have a sec. can you just tell me if the way I did this looks ok: https://github.com/trevnorris/node/commit/79e7aaf
19:14:43  <trevnorris>just realized we don't have to share state on kLastThrew
19:15:21  <trevnorris>because we'll enter the try/catch in C++ anyways
19:15:33  <bnoordhuis>tjfontaine: i have two confirmed failures on os x, simple/test-cluster-master-error and simple/test-stream2-stderr-sync. everything else works
19:15:48  <bnoordhuis>it's curious that everything passes on linux
19:15:54  * dshaw_quit (Quit: Leaving.)
19:17:32  <bnoordhuis>trevnorris: yeah, looks okay to me
19:17:39  * LOUDBOTjoined
19:17:44  * CAPSLOCKBOTjoined
19:24:20  * LOUDBOTquit (Remote host closed the connection)
19:24:20  * CAPSLOCKBOTquit (Remote host closed the connection)
19:24:40  * LOUDBOTjoined
19:24:40  * CAPSLOCKBOTjoined
19:25:42  * st_lukejoined
19:26:41  * hzjoined
19:36:32  * Damn3djoined
19:38:47  <MI6>nodejs-master-windows: #303 UNSTABLE windows-x64 (49/646) windows-ia32 (50/646) http://jenkins.nodejs.org/job/nodejs-master-windows/303/
19:40:37  * tjholowaychukjoined
19:45:54  * Damn3dquit (Quit: cu)
19:48:31  * Damn3djoined
19:49:31  * kenperkinsjoined
19:51:09  * dominictarrquit (Quit: dominictarr)
19:56:54  * st_lukequit (Read error: Connection reset by peer)
19:57:22  * st_lukejoined
20:00:22  * EhevuTovjoined
20:00:55  * c4miloquit (Remote host closed the connection)
20:02:23  <tjfontaine>ruth roh, 50 failures on windows
20:03:09  <tjfontaine>it would seem like gracefully closing the loop on windows is causing all sorts of timeouts to occur
20:04:34  <tjfontaine>all seem to be relating to timeouts so I'm guess we for whatever reason can't close some handles
20:08:15  * EhevuTovquit (Quit: This computer has gone to sleep)
20:08:48  * EhevuTovjoined
20:09:22  * dshaw_joined
20:15:18  * dominictarrjoined
20:15:43  * kevinswiberquit (Remote host closed the connection)
20:17:11  <bnoordhuis>tjfontaine: hrm. guess i'll revert it and let bert figure it out
20:17:35  <bnoordhuis>i know what the issue on os x is btw, it doesn't like it when you call shutdown() on something that's not a socket
20:21:08  <bnoordhuis>istm that's actually a bug in node - you can create a PipeWrap for something that's not a real named pipe / unix socket
20:21:37  <bnoordhuis>maybe i should say "buglet"
20:22:46  <tjfontaine>hm, interesting
20:22:58  <tjfontaine>is that an abuse of people using the fd open mechanism?
20:23:47  <bnoordhuis>yes
20:24:03  <bnoordhuis>it's not the worst thing in the world
20:24:15  <bnoordhuis>but now you can call shutdown() on a non-socket fd
20:25:19  <bnoordhuis>also, i wonder if the hangs on windows are caused by the fact that node won't close the pipe if shutdown fails with UV_EPIPE
20:35:24  * defunctzombiechanged nick to defunctzombie_zz
20:35:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:41:21  <trevnorris>bnoordhuis: look at what that one little assert is causing. ;)
20:42:12  <bnoordhuis>yeah. maybe i'll revert the whole thing and call it a day
20:42:25  <tjfontaine>the assert is right, I mean we shouldn't be asking to delete the loop if we still have things in flight
20:42:37  <trevnorris>heh, well it sounds like the assert is correct. it's just that too much is broken to allow it :P
20:43:01  <tjfontaine>we could alternatively just not call uv_delete_loop
20:43:10  <tjfontaine>or loop_delete which ever way round it is
20:43:58  * dapquit (Quit: Leaving.)
20:44:00  <bnoordhuis>yeah. i added that to expose bugs actually
20:44:08  <bnoordhuis>the call to uv_loop_delete() that is
20:44:13  <bnoordhuis>hey, it works
20:46:28  <trevnorris>othiym23: ping
20:49:11  <othiym23>trevnorris: pong
20:49:17  * TooTallNatejoined
20:50:07  * jmar777quit (Remote host closed the connection)
20:50:11  <TooTallNate>just got bit by an annoying bug
20:50:18  <TooTallNate>net.Socket#bufferSize
20:50:20  <TooTallNate>returns undefined
20:50:23  <TooTallNate>instead of 0
20:50:27  <TooTallNate>when there's nothing buffered
20:51:17  <trevnorris>othiym23: so... (brain fart), oh yeah. working in the ability to call async listeners from callbacks that also had listeners w/o wrecking every aspect of performance hasn't been trivial.
20:51:41  <trevnorris>othiym23: being that, it's even more invasive then domains are (basically giving full access to everything internally)
20:52:21  <trevnorris>othiym23: i'm going to work on this over the weekend and hopefully have something by monday
20:52:35  <othiym23>trevnorris: I'll be around the weekend if you want to bounce builds off me
20:52:47  <trevnorris>othiym23: thanks. just might do that.
20:53:49  <trevnorris>bnoordhuis: oh, meant to tell you, the test-smalloc*segfault.js tests can be moved into pummel, want me to take care of that ?
20:53:59  <trevnorris>there's three of them that take a while
20:54:35  <bnoordhuis>trevnorris: sure
20:55:07  <trevnorris>coolio. feel like this little issue is giving you hell. think it's time for your bowl of cereal. ;)
20:57:00  <bnoordhuis>heh :)
20:57:36  <othiym23>trevnorris: are we talking about setImmediate(function () { process.nextTick() }) type stuff here?
20:58:54  <trevnorris>othiym23: basically. i want you to be able to just call add/remove before/after the call to setImmediate, but then the async listeners will also trigger for any async callbacks within that callback
20:59:41  * jmar777joined
21:00:08  <MI6>joyent/node: Trevor Norris master * 8a272ca : test: move smalloc segfault tests to pummel - http://git.io/9VZQ8Q
21:01:07  * jmar777quit (Remote host closed the connection)
21:01:14  <othiym23>yeah
21:02:38  * dapjoined
21:09:56  <MI6>nodejs-master: #511 UNSTABLE linux-ia32 (1/643) smartos-x64 (7/643) osx-ia32 (7/643) smartos-ia32 (4/643) osx-x64 (8/643) linux-x64 (1/643) http://jenkins.nodejs.org/job/nodejs-master/511/
21:18:40  <othiym23>trevnorris: are you still passing the calling this in to onAsync, or did you decide that was exposing too much internal state?
21:22:00  <trevnorris>othiym23: depends on the case. if it's an event or timer it'll pass the context. if it's a ReqWrap then it'll pass the instance object, and nextTick will pass the callback object
21:22:11  <trevnorris>the later two don't have a context to be passed
21:22:35  <trevnorris>it's was a trivial addition, and figured would be useful to someone
21:23:20  <othiym23>if you're reworking domains, won't the nextTick callback object just be the function itself?
21:23:30  <othiym23>do you still need all that tock craziness with domains based on async listeners?
21:24:15  <trevnorris>we'll need even more craziness. because each listener has it's own "domain" object that can be returned, which needs to propagate with that specific listener.
21:25:07  <trevnorris>see, with domains you simply .run() a function. but with async listeners you start/stop them at arbitrary points.
21:25:39  <othiym23>yeah, CLS itself has a very similar issue, although the contexts are stored separately from the callbacks themselves (because we're using closures for everything)
21:25:42  <othiym23>that makes sense
21:26:00  <othiym23>oh man, I hadn't really thought about the start / stoppiness of it all
21:26:09  <othiym23>that gives me the ability to time exactly how long callbacks spend running
21:26:25  <trevnorris>yup
21:26:29  <othiym23>super useful for execution tracing / tracking exclusive time
21:26:31  * mikealquit (Quit: Leaving.)
21:26:40  <creationix>trevnorris, wait, so what's hard to optimize?
21:26:44  <creationix>not sure I quite understand
21:27:03  <trevnorris>all the thingz
21:27:08  <creationix>:P
21:27:22  * defunctzombie_zzchanged nick to defunctzombie
21:27:44  <trevnorris>when you add/remove a listener you can return an object, and you can have multiple listeners each returning their own objects
21:27:57  * dapquit (Quit: Leaving.)
21:27:58  * mikealjoined
21:27:58  <trevnorris>each of those objects needs to reach their own before/after/etc methods
21:28:18  <trevnorris>and they need to be attached to the callback itself in case the callback also calls any asynchronous methods
21:28:43  <trevnorris>so there's a ton of state that needs to be propagated through N deep asynchronous calls
21:29:37  <trevnorris>because not only are we running a function when the asynchronous operation is queued, we're also running at least another 2 callbacks when the callback itself fires
21:30:06  <creationix>why do "they need to be attached to the callback itself in case the callback also calls any asynchronous methods"?
21:30:08  <trevnorris>that means we're at least tripling the number of functions calls
21:30:47  <creationix>can we just say these hooks aren't allowed to make async calls?
21:30:53  <creationix>or is that too crazy?
21:31:08  <MI6>joyent/node: Ben Noordhuis master * 10ccbd5 : Revert "src: call uv_loop_delete() on exit in debug mode" (+1 more commits) - http://git.io/-9LTKg
21:31:13  <bnoordhuis>tjfontaine: ^
21:31:13  * AvianFluquit (Remote host closed the connection)
21:31:27  <trevnorris>these are the tests that have to pass: https://github.com/trevnorris/node/blob/675d6d9
21:31:33  <trevnorris>for async listeners
21:31:36  <bnoordhuis>tjfontaine: it did catch a real bug in libuv btw. but i'll save that for tomorrow
21:32:11  <tjfontaine>bnoordhuis: like I said, I am in agreement they are bugs
21:32:29  <tjfontaine>it's just that currently the medicine is worse than the disease :P
21:38:35  * dapjoined
21:38:42  <bnoordhuis>yeah, i don't disagree. i'll revisit it later this week
21:40:30  <MI6>nodejs-master: #512 UNSTABLE linux-ia32 (1/642) smartos-x64 (6/642) osx-ia32 (1/642) linux-x64 (1/642) http://jenkins.nodejs.org/job/nodejs-master/512/
21:46:36  * mikealquit (Quit: Leaving.)
21:46:58  * dshaw_quit (Quit: Leaving.)
21:49:05  * dshaw_joined
21:50:29  <tjfontaine>bnoordhuis: btw, should we be defining _GNU_SOURCE in our build to fix these EAI errors?
21:50:42  <tjfontaine>or is there another define that is better to opt us into it
21:50:44  <MI6>nodejs-master-windows: #304 UNSTABLE windows-x64 (51/643) windows-ia32 (51/643) http://jenkins.nodejs.org/job/nodejs-master-windows/304/
21:52:18  <tjfontaine>btw, that's a commit behind, the fix for the 50 errors is still building
21:55:47  <bnoordhuis>tjfontaine: where/when are you getting those errors?
21:55:52  * hzquit
21:56:03  <indutny>heh
21:56:13  <indutny>it seems that I'll need to write http request library for libuv
21:56:22  <indutny>or.. just execute curl asynchronously
21:56:31  <indutny>I wonder what's really better
21:56:58  <tjfontaine>bnoordhuis: http://jenkins.nodejs.org/job/nodejs-master/lastCompletedBuild/DESTCPU=ia32,label=linux/tapTestReport/test.tap-360/
21:58:49  <bnoordhuis>tjfontaine: oh, that's possible. i removed the -D_GNU_SOURCE recently, actually
21:59:03  <bnoordhuis>kind of odd that it isn't an issue on my systems
22:00:36  * dshaw_quit (Quit: Leaving.)
22:01:30  <indutny>bnoordhuis: so what do you think about doing http requests with just plain libuv ? :)
22:01:41  <indutny>it seems that I'll need to implement my own cares bindings
22:02:21  <MI6>joyent/libuv: bnoordhuis created branch jenkins-getaddrinfo-test - http://git.io/YtQTYQ
22:02:24  <indutny>bnoordhuis: is there any better C libs for DNS stuff?
22:02:38  <bnoordhuis>better than c-ares? don't think so
22:02:40  * defunctzombiechanged nick to defunctzombie_zz
22:02:43  <bnoordhuis>dns is hard
22:02:48  <bnoordhuis>c-ares does it alright
22:02:57  <indutny>haha :)
22:03:06  <indutny>is getaddrinfo that bad?
22:03:26  <bnoordhuis>nah, apparently i broke something on one of the jenkins slaves
22:03:42  <bnoordhuis>or do you mean in general?
22:05:15  <indutny>bnoordhuis: in general
22:06:36  * defunctzombie_zzchanged nick to defunctzombie
22:09:24  <tjfontaine>bnoordhuis: it's not a special slave, it's just a pretty stock 12.04, trevnorris's is 12.10
22:09:41  <trevnorris>yup
22:10:08  <bnoordhuis>indutny: well, it's synchronous. the async variant, getaddrinfo_a, is glibc only and a pain to use (uses either signals or threads)
22:10:24  <indutny>well, but you can use it from other thread, right?
22:10:31  <bnoordhuis>yes. that's what libuv does
22:10:42  <indutny>oooh
22:10:46  <indutny>just noticed it has it :D
22:13:14  <indutny>ok, may be I don't need to write a lib for it
22:13:58  <bnoordhuis>the problem with uv_getaddrinfo() is that you won't be able to do 20k lookups/sec
22:14:11  <bnoordhuis>everything goes through the thread pool so that becomes a bottleneck fast
22:14:53  <MI6>nodejs-master-windows: #305 UNSTABLE windows-x64 (16/642) windows-ia32 (18/642) http://jenkins.nodejs.org/job/nodejs-master-windows/305/
22:15:45  <indutny>bnoordhuis: yeah, I see it...
22:16:01  <indutny>bnoordhuis: is it caching results?
22:17:45  <MI6>libuv-review: #57 UNSTABLE windows-x64 (3/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-review/57/
22:18:13  <bnoordhuis>indutny: getaddrinfo or uv_getaddrinfo? 'possibly' to the former, 'no' to the latter
22:18:22  <indutny>how so?
22:18:27  <indutny>why different?
22:19:32  <bnoordhuis>getaddrinfo is provided by the system - it may or may not cache the results of lookups
22:19:41  <indutny>ah
22:19:43  <bnoordhuis>libuv however never caches
22:19:54  <indutny>for consistency?
22:20:33  <indutny>ah, you mean not itself
22:20:36  <indutny>gotcha
22:20:43  <bnoordhuis>good :)
22:28:50  <kellabyte>bnoordhuis: trying out the TLS stuff (thanks again!) seems to work fine on OSX, just getting up to speed on how to use it, will test on windows this weekend :)
22:34:55  <bnoordhuis>kellabyte: okay, nice. hope i got the windows implementation right
22:35:29  <kellabyte>we'll find out!
22:36:06  * dshaw_joined
22:47:04  <kellabyte>bnoordhuis: what would be the easiest way for a timer to set a flag that each thread would see their own copy? I need to tell each thread to do something once per second
22:47:46  <bnoordhuis>kellabyte: hm, depends. maybe have the timer call uv_async_send() on a list of async handles, one for each thread?
22:48:05  <bnoordhuis>that will wake up the event loop of each thread once per second
22:48:23  <bnoordhuis>however, if the thread is already running then it won't see the async event right away
22:48:51  <kellabyte>doesn't have to be right away
22:50:50  * dshaw_quit (Ping timeout: 245 seconds)
22:51:42  <pfox__>hey suggested_size is the buffer-provider is still 512, right?
22:52:17  <pfox__>bleh, that was bad grammar.
22:52:23  <pfox__>is suggested_size still 512?
22:52:35  <tjfontaine>suggested size is always 64k but you can alloc whatever you want?
22:52:40  <bnoordhuis>^ that
22:52:46  <bnoordhuis>i don't think it ever was 512
22:52:58  <tjfontaine>as long as I can remember anyway
22:53:18  <pfox__>ty
22:53:32  <pfox__>yeah, im fine w/ chalking it up to faulty memory.
22:53:58  <kellabyte>bnoordhuis: I have 4 event loops, uv_async_send() doesn't seem to let you specify which?
22:54:21  <bnoordhuis>kellabyte: you create an async handle for each event loop
22:55:44  <kellabyte>ah
22:59:16  <bnoordhuis>okay, i'm off to bed. have a good night everyone
23:02:17  <kellabyte>night bnoordhuis!
23:03:54  * bnoordhuisquit (Ping timeout: 256 seconds)
23:07:26  * wolfeidauquit (Remote host closed the connection)
23:51:28  * EhevuTovquit (Quit: This computer has gone to sleep)
23:55:49  * kenperkinsquit (Quit: Computer has gone to sleep.)
23:59:53  <MI6>libuv-master-gyp: #149 UNSTABLE windows-x64 (3/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/149/