00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:13  * ircretaryjoined
00:04:22  * robertkowalskiquit (Ping timeout: 250 seconds)
00:06:20  * robertkowalskijoined
00:06:36  <chrisdickinson>summarized: https://github.com/joyent/node/pull/8666#issuecomment-62989820 cc trevnorris jgi -- please lemme know if I'm wildly off here.
00:06:47  <jgi>chrisdickinson: great thanks!
00:07:22  <jgi>chrisdickinson: Regarding “The behavior prior to V8's removal of the --abort-on-uncaught-exception flag was:”, the proposed patch does not remove the —abort-on-uncaught-exception flag
00:08:15  <chrisdickinson>yes -- i'll note that this patch re-introduces `--abort-on-uncaught-exception` flag
00:08:59  <jgi>chrisdickinson: but was the code that supports this flag ever removed since it’s been added a long time ago?
00:09:05  * thlorenzjoined
00:09:19  <chrisdickinson>hm?
00:09:36  <chrisdickinson>the problem is that the flag belonged to v8, as I understood it
00:09:51  <chrisdickinson>and v8 removed the flag
00:10:07  <chrisdickinson>or, more specifically,
00:10:19  * iarnaquit (Remote host closed the connection)
00:11:36  <chrisdickinson>that v8 used to use --abort-on-uncaught-exception to determine whether to OS::Abort() in Isolate::DoThrow, and that V8 dropped the flag and the check
00:11:40  <chrisdickinson>i appear to be wrong :)
00:12:39  <jgi>chrisdickinson: yes, I don’t think that has been removed from v8
00:12:48  * robertkowalskiquit (Ping timeout: 255 seconds)
00:13:21  <chrisdickinson>jgi: the problem being fixed is that abort-on-uncaught was too eager, preventing the domain code from running?
00:13:30  <jgi>chrisdickinson: exactly
00:13:35  <chrisdickinson>cool, thanks!
00:13:50  * M28quit (Read error: Connection reset by peer)
00:14:10  * M28joined
00:14:39  * robertkowalskijoined
00:14:48  <jgi>also, when you mention the behavior of each solution, I think it would probably be clearer to mention the behavior when —abort-on-uncaught-exception is passed, and when it’s not
00:15:00  <jgi>chrisdickinson: otherwise it ends up being very confusing
00:18:59  * iarnajoined
00:20:24  * robertkowalskiquit (Ping timeout: 250 seconds)
00:21:35  <trevnorris>chrisdickinson, jgi: also, you don't want to check if --abort-on-uncaught-exception works in test/simple. for those of us who automatically save all core files, running a bunch of tests will create quite a few of those.
00:21:36  * robertkowalskijoined
00:23:23  * iarnaquit (Remote host closed the connection)
00:23:41  * iarnajoined
00:23:49  <jgi>trevnorris: good point, thanks
00:23:52  <trevnorris>:)
00:26:45  * avalanche123joined
00:28:13  * chris_99quit (Remote host closed the connection)
00:30:52  <trevnorris>chrisdickinson / jgi: Here's a very ugly patch showing what I mean: https://gist.github.com/trevnorris/be1dee9d3fb4bc467b1c
00:31:03  <trevnorris>can you try that out and tell me if it gives what you're expecting?
00:32:50  <jgi>trevnorris: I think that this patch would still have the problem I mentioned earlier:
00:32:52  <jgi>“if I remember correctly, there’s also this call: https://github.com/joyent/node/blob/v0.10/lib/domain.js#L183 where, within a domain, if something is thrown, then passing —abort-on-uncaught-exception would always make node abort and dump core”
00:33:40  * robertkowalskiquit (Ping timeout: 258 seconds)
00:33:56  <trevnorris>jgi: sorry, there's so many issues here... so you're saying if the cb.apply() throws?
00:34:04  <jgi>yes
00:34:17  <trevnorris>wtf is cb() in that case?
00:34:29  <jgi>trevnorris: the code run within the domain if I remember correctly
00:34:42  <trevnorris>oy, have an example on hand to show me?
00:35:34  <jgi>trevnorris: just a sec, I’m going to apply your patch first and then run the test I’m talking about
00:35:50  * Fishrock123joined
00:36:15  <trevnorris>thanks.
00:36:21  * M28quit (Ping timeout: 250 seconds)
00:36:31  * M28joined
00:38:16  * iarnaquit (Remote host closed the connection)
00:38:24  <trevnorris>wtf. I ran gdb --args ./node_g --abort-on-uncaught-exception script.js and the stupid thing exited normally...
00:40:54  <jgi>trevnorris: https://gist.github.com/misterdjules/a89e3e844106fe0f273a
00:41:29  <trevnorris>tjfontaine: ping
00:41:47  <tjfontaine>pong
00:42:25  * iarnajoined
00:43:05  <trevnorris>tjfontaine: re AL patch. I've been cleaning up the commits, which are looking pretty good, and found there's a strange architectural issue that's preventing some of the things I wanted to do (e.g. asyncId())
00:43:14  <tjfontaine>for instance?
00:43:16  <trevnorris>and wanted to bounce some things against your head.
00:43:32  <trevnorris>so. we manually deconstruct the class attached to an object once the request is complete.
00:43:35  <tjfontaine>ok my head is nice and hard
00:43:38  <trevnorris>heh
00:43:53  <tjfontaine>it is in need of caffeine but that's a different problem
00:43:58  <trevnorris>and the asyncId() call was to C++ to return AsyncWrap::id()
00:44:09  * jgiquit (Quit: jgi)
00:44:19  <trevnorris>but since the class is no longer there, it returns gibberish.
00:44:40  * jgijoined
00:44:40  * iarnaquit (Remote host closed the connection)
00:45:03  <trevnorris>one thing I wanted to throw in (because I figured it'd be very useful and the code was trivial) was to attach parent requests together for, say, fs.readFile().
00:45:14  <tjfontaine>you mean we explicitly call the destructor of an object, or we're calling delete?
00:45:31  <trevnorris>so from the callback you could do req.preq and get the preceding request (e.g. fs.open() needs to run before fs.read())
00:45:43  <trevnorris>we're calling delete on the class once the request is done.
00:45:46  <tjfontaine>ok
00:45:55  <trevnorris>instead of allowing GC to cleanup the class once the object has left scope.
00:46:01  <tjfontaine>nod
00:46:48  <trevnorris>we've skirted this by simply setting req._handle = null where applicable, but if we're going to be attaching actual useful information for debugging and the like then it leaves the API in a pickle.
00:47:10  <trevnorris>jgi: thanks. I can fix that.
00:47:32  <tjfontaine>so can we go back a tick, and I want to make sure I'm on the right page here
00:47:38  * robertkowalskijoined
00:48:23  <tjfontaine>user does fs.readFile, and we want to associate the parent wrap (if there is on) with the cb that will fire ultimately saying we have all the data
00:48:23  <trevnorris>sure thing
00:48:59  <trevnorris>the context of the callback is that in which the callback is run (e.g. if there's an error while opening the file then the open req is the context)
00:49:27  <trevnorris>if the completes successfully then it will be the close req (I think)
00:49:56  <trevnorris>either way, they can basically do a while (req.preq) { } and get info about the entire call chain of the request.
00:50:18  <tjfontaine>so today as it is, fs.readFile is not covered discretely by AL, only the composable pieces of open and read are, and the chain isn't useful for that
00:51:02  <trevnorris>yes, yes, you mean the chain isn't useful today? there isn't one right now.
00:51:19  <tjfontaine>ight, because it's not covered
00:51:28  <tjfontaine>is it covered by domains today?
00:51:51  <tjfontaine>doesnt' really seem like it
00:52:01  * Fishrock123quit (Quit: Leaving...)
00:52:31  <trevnorris>no.
00:52:37  * iarnajoined
00:52:45  <trevnorris>right now the internals of fs are completely obscured to the users.
00:52:56  <tjfontaine>right, which is slightly the point of that api
00:53:08  <tjfontaine>it's a nice clear point to show taht we still need *way* more test coverage
00:53:40  <trevnorris>yeah
00:53:41  <tjfontaine>ok so the reason I wanted to know that, is if it doesn't work today, I don't really want to delay the AL stuff to try and get this to work
00:53:56  <tjfontaine>because right now, I don't see an easy way to do what you're trying to do
00:54:12  <tjfontaine>a nice way to say, these are the composable pieces that represent this thing
00:54:22  <tjfontaine>mostly because there's not a "handle" here that we can abuse for that mechanism
00:54:28  <trevnorris>the crux is the fact we're delete'ing the C++ class before the JS object is cleaned up.
00:54:39  <tjfontaine>we could delay that
00:55:07  <tjfontaine>which delete are we talking about, can you link that one to me?
00:55:39  <trevnorris>tjfontaine: actually, everything does now have an actual request handle: https://github.com/trevnorris/node/commit/9739b78
00:55:54  <trevnorris>sure. sec.
00:56:08  <trevnorris>tjfontaine: here: https://github.com/joyent/node/blob/master/src/node_file.cc#L239
00:56:20  <tjfontaine>I mean that the readFile call itself doesn't have a resource associated with it
00:56:29  <trevnorris>no. it doesn't.
00:57:02  <trevnorris>but now that every request has a real handle I want to give those back to the user for debugging, etc.
00:57:08  <trevnorris>guess that can wait.
00:57:14  <tjfontaine>and because it doesn't transition itself through MakeCallback it also avoids some of these same benefits where we can consolidate logic for it
00:57:47  <trevnorris>elaborate please
00:58:22  <tjfontaine>for the way AW works, if readFile actually had a single HandleWrap or ReqWrap associated with the *whole* thing, you could just piggy back off of that
00:58:51  <tjfontaine>and if its finish transitioned through MakeCallback things would just work without interaction or changing the way AL works to make this useful
00:59:28  <trevnorris>true. I mean, it is possible to simply create an FSReqWrap() when the function runs as a pseudo req to contain the entirety of the request.
00:59:28  <tjfontaine>similar in the way that timers and nextticks need js help because they don't have underlying 1:1 AW mappings
00:59:48  <trevnorris>I did that early and it worked fine.
01:00:06  <tjfontaine>I mean, it would be nice if we didn't have to modify the js portion to make it work
01:00:19  <tjfontaine>so
01:00:50  <tjfontaine>I really think to do this composable piece, you really want/need a real resource to exist for the readFile
01:02:19  <trevnorris>okay.
01:02:21  <trevnorris>brb
01:08:30  * robertkowalskiquit (Ping timeout: 250 seconds)
01:11:00  * avalanche123quit (Remote host closed the connection)
01:13:38  * iarnaquit (Remote host closed the connection)
01:14:39  * iarnajoined
01:15:31  * iarnaquit (Remote host closed the connection)
01:16:54  * iarnajoined
01:18:46  * iarnaquit (Remote host closed the connection)
01:18:55  * iarnajoined
01:19:44  * avalanche123joined
01:19:59  * robertkowalskijoined
01:21:13  * stagasquit (Ping timeout: 265 seconds)
01:21:44  * avalanche123quit (Remote host closed the connection)
01:23:22  <Wraithan>rvagg, chrisdickinson: you both brought up the same point, and hayes is in this channel who did the actual fix
01:23:30  <chrisdickinson>o/
01:24:10  <rvagg>Yo
01:24:28  <chrisdickinson>seems odd that buffering in a closure would be faster than the writerequests
01:24:56  <chrisdickinson>i suspected the `.slice` in clearBuffer, but even with a ton of items, it's still fast
01:25:05  * robertkowalskiquit (Ping timeout: 265 seconds)
01:25:35  * inolenquit (Quit: Leaving.)
01:25:56  <chrisdickinson>and looking at the process + threads with `ps -p<pid> -M` it looked like the main thread was chewing on all of the CPU (admittedly I might be looking at the wrong thing, there)
01:27:34  <Wraithan>my understanding is that it causes a ton of queuing and async roundtrips to happen, which is the source of the slow down, but I'm not the one who researched it
01:28:18  <chrisdickinson>i hadn't quite gotten to the point of throwing dtrace at it, but that sounds feasible
01:28:26  * avalanche123joined
01:29:47  <Wraithan>I guess hayes is about to head home but I'll let him explain his findings when he gets back online
01:29:56  <Wraithan>I just built the tools he used to profile the agent
01:30:08  <hayes>I'm still here, digging into stream code again
01:30:19  * avalanche123quit (Remote host closed the connection)
01:30:32  <hayes>some of my initial assumptions from yesterday were a bit off
01:30:43  <rvagg>if that is true, and fs.createWriteStream() does some additional work that's causing the problem then perhaps just piping bunyan to a PassThrough so it could do the buffering as an intermediate -- also setting a larger highWaterMark on that might make a difference
01:31:02  <rvagg>not sure what additional work fs.createWriteStream() would be doing that's causing problems here though
01:32:32  * iarnaquit (Remote host closed the connection)
01:33:34  <chrisdickinson>against v0.12 rss pingpongs between 113336320 and 310722560 bytes, so GC seems to be okay. I'm not seeing a lot of gc activity to speak of
01:36:59  <chrisdickinson>errr,
01:37:07  <chrisdickinson>at least i wasn't last time. this time i am.
01:37:17  * kenperkins_quit (Quit: Computer has gone to sleep.)
01:38:22  * kenperkinsjoined
01:38:30  <hayes>so what stuck out to me was that when you buffer in js you are just doing some simple string concatenation (which if I recall correctly is pretty fast, and doesn't actually do any coppies) and then you create a single writereq for a couple thousands logs statements. in the case where you buffer in fs writeStream, you are are looping over all the buffered chunks the first one you write, which will do an fs.write with an async callback and sets wri
01:38:30  <hayes>ting to true, you then return to the loop, break out of it, wait for the callback and start looping over the chunks again
01:38:48  <hayes>I might be misinterpreting, I have not actually stepped though in a debugger
01:39:47  <chrisdickinson>hayes: where's the string concatenation happening?
01:40:02  <chrisdickinson>ah
01:40:05  <chrisdickinson>sorry, misread
01:40:07  <hayes>oh, in my gist when I am just concatenating stuff outside
01:41:59  * thlorenzquit (Remote host closed the connection)
01:42:32  * thlorenzjoined
01:42:33  <hayes>still not sure how we get 100% cpu though, I would expect lower performance, but with the writes going through fs.write there should be some idle time
01:43:05  <chrisdickinson>hayes: try it with --trace-gc
01:43:29  * kenperkinsquit (Quit: Computer has gone to sleep.)
01:44:13  <chrisdickinson>its got to discard that buffer of writereqs every time it clearBuffers, I think
01:44:21  <chrisdickinson>so it's building up a *lot* of trash
01:44:50  * inolenjoined
01:45:15  <chrisdickinson>trying something out
01:45:59  <chrisdickinson>hm, nope.
01:47:19  * thlorenzquit (Ping timeout: 265 seconds)
01:50:11  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:51:21  * brsonquit (Quit: leaving)
01:51:22  * inolenquit (Quit: Leaving.)
01:51:25  * kazuponjoined
01:53:19  <hayes>h
01:53:45  <hayes>I'm heading home, might look at this a bit more later tonight
02:02:45  * abraxas_joined
02:04:44  * stagasjoined
02:04:54  * robertkowalskijoined
02:07:24  * iarnajoined
02:08:02  * abraxas_quit (Ping timeout: 265 seconds)
02:10:05  * abraxas_joined
02:11:46  * robertkowalskiquit (Ping timeout: 250 seconds)
02:11:59  * robertkowalskijoined
02:18:42  * robertkowalskiquit (Ping timeout: 250 seconds)
02:27:24  * robertkowalskijoined
02:32:02  * dap_quit (Quit: Leaving.)
02:34:13  * robertkowalskiquit (Ping timeout: 250 seconds)
02:36:43  * jgiquit (Quit: jgi)
02:40:52  * robertkowalskijoined
02:47:20  * Ralithquit (Ping timeout: 256 seconds)
02:47:53  * robertkowalskiquit (Ping timeout: 264 seconds)
02:50:00  * robertkowalskijoined
02:50:04  * robertkowalskiquit (Signing in (robertkowalski))
02:50:04  * robertkowalskijoined
02:57:42  * robertkowalskiquit (Ping timeout: 250 seconds)
02:57:52  * robertkowalskijoined
03:00:49  * iarna_joined
03:02:00  * iarnaquit (Ping timeout: 255 seconds)
03:04:52  * iarna_quit (Read error: Connection reset by peer)
03:05:10  * iarnajoined
03:07:14  * robertkowalskiquit (Ping timeout: 250 seconds)
03:07:42  * thlorenzjoined
03:12:50  * Ralithjoined
03:13:13  * thlorenzquit (Remote host closed the connection)
03:14:17  * robertkowalskijoined
03:15:44  * thlorenzjoined
03:20:05  * iarnaquit (Remote host closed the connection)
03:20:09  * thlorenzquit (Ping timeout: 250 seconds)
03:23:17  * iarnajoined
03:23:42  * iarnaquit (Remote host closed the connection)
03:27:36  * robertkowalskiquit (Ping timeout: 250 seconds)
03:29:32  * robertkowalskijoined
03:35:00  * kazuponquit (Remote host closed the connection)
03:36:16  * robertkowalskiquit (Ping timeout: 250 seconds)
03:36:24  * robertkowalskijoined
03:43:12  * robertkowalskiquit (Ping timeout: 250 seconds)
03:44:27  * robertkowalskijoined
03:45:51  * rmgquit (Remote host closed the connection)
03:47:11  * pquernaquit (Ping timeout: 265 seconds)
03:47:40  * pquernajoined
03:51:47  * octetcloudquit (Ping timeout: 250 seconds)
03:55:28  * robertkowalskiquit (Ping timeout: 255 seconds)
03:56:08  * robertkowalskijoined
04:00:53  <MI6>joyent/node: haoxin v0.12 * 00d7b13 : module: correct the order of the assertions - http://git.io/nFsD1A
04:03:08  * robertkowalskiquit (Ping timeout: 250 seconds)
04:05:25  * robertkowalskijoined
04:07:54  * toothrotquit (Ping timeout: 250 seconds)
04:10:48  * Left_Turnquit (Remote host closed the connection)
04:13:05  * robertkowalskiquit (Ping timeout: 244 seconds)
04:14:16  * robertkowalskijoined
04:14:27  * AvianFlujoined
04:20:28  * robertkowalskiquit (Ping timeout: 265 seconds)
04:20:56  * robertkowalskijoined
04:25:45  * kazuponjoined
04:27:50  * robertkowalskiquit (Ping timeout: 250 seconds)
04:28:01  * robertkowalskijoined
04:31:06  * avalanche123joined
04:33:29  * robertkowalskiquit (Ping timeout: 264 seconds)
04:33:43  * robertkowalskijoined
04:35:36  * avalanche123quit (Ping timeout: 244 seconds)
04:42:17  * robertkowalskiquit (Ping timeout: 265 seconds)
04:42:43  * robertkowalskijoined
04:46:25  * rmgjoined
04:51:37  * skebcioquit (Ping timeout: 240 seconds)
04:51:57  * rmgquit (Ping timeout: 265 seconds)
04:52:26  * robertkowalskiquit (Ping timeout: 265 seconds)
04:52:57  * robertkowalskijoined
05:01:33  * jreyno40joined
05:01:38  * robertkowalskiquit (Ping timeout: 250 seconds)
05:05:10  * jreyno40part
05:36:16  * robertkowalskijoined
05:43:11  * robertkowalskiquit (Ping timeout: 265 seconds)
05:51:30  * AvianFluquit (Ping timeout: 256 seconds)
05:57:13  * janjongboomjoined
06:19:37  * inolenjoined
06:24:13  * iarnajoined
06:28:41  * iarnaquit (Ping timeout: 264 seconds)
06:46:37  * kazuponquit (Remote host closed the connection)
06:52:14  * bajtosjoined
06:54:45  * robertkowalskijoined
07:01:27  * kazuponjoined
07:01:31  * robertkowalskiquit (Ping timeout: 244 seconds)
07:22:54  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:47:34  * Ldxngxjoined
07:57:00  * rendarjoined
08:02:51  * jreyno40joined
08:19:53  * stagasquit (Ping timeout: 240 seconds)
08:35:37  * janjongboomjoined
08:44:31  * kazuponquit (Remote host closed the connection)
08:45:52  * kazuponjoined
09:05:00  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:06:53  * inolenquit (Quit: Leaving.)
09:07:00  * janjongboomjoined
09:10:03  * janjongboomquit (Client Quit)
09:18:29  * janjongboomjoined
09:25:27  * kellabytequit (Quit: Connection closed for inactivity)
09:38:47  * kazuponquit (Remote host closed the connection)
09:41:38  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:43:47  * kazuponjoined
09:50:58  * SergeiRNDjoined
09:53:48  * janjongboomjoined
09:55:13  * bajtosquit (Quit: bajtos)
09:58:44  * bajtosjoined
09:59:06  * SergeiRND1joined
10:01:39  * jreyno40quit (Quit: jreyno40)
10:02:53  * SergeiRNDquit (Ping timeout: 264 seconds)
10:11:43  * kazuponquit (Remote host closed the connection)
10:12:24  * kazuponjoined
10:20:46  * SergeiRND1quit (Quit: Leaving.)
10:21:25  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:25:08  * janjongboomjoined
10:27:48  * seishunjoined
10:33:04  * Dijoined
10:44:59  * kazuponquit (Remote host closed the connection)
10:45:44  * kazuponjoined
10:45:55  * kazuponquit (Remote host closed the connection)
10:46:03  * kazuponjoined
10:53:26  * Left_Turnjoined
10:55:23  * bajtosquit (Quit: bajtos)
10:57:05  * robertkowalskijoined
11:05:10  * kazuponquit (Remote host closed the connection)
11:11:40  * AlexisMochaquit (Ping timeout: 256 seconds)
11:11:59  * stagasjoined
11:16:11  * SergeiRNDjoined
11:17:47  * SergeiRND1joined
11:20:53  * SergeiRNDquit (Ping timeout: 264 seconds)
11:30:29  * seishunquit (Read error: Connection reset by peer)
11:31:04  * seishunjoined
11:54:13  * SergeiRND1quit (Quit: Leaving.)
11:54:32  * Diquit (Quit: Leaving.)
12:05:35  * jas-_joined
12:07:32  * iarnajoined
12:15:47  * AvianFlujoined
12:16:02  * kazuponjoined
12:20:45  * kazuponquit (Ping timeout: 272 seconds)
12:29:49  * SergeiRNDjoined
12:30:46  * Dijoined
12:31:16  * iarnaquit (Remote host closed the connection)
12:34:12  * kellabytejoined
12:38:03  * bajtosjoined
12:45:42  * AlexisMochajoined
12:47:32  * iarnajoined
12:49:29  * AlexisMochaquit (Read error: Connection reset by peer)
12:50:12  * AlexisMochajoined
13:04:07  * AlexisMochaquit (Read error: Connection reset by peer)
13:06:14  * AlexisMochajoined
13:09:00  * nickleeflyjoined
13:11:30  * iarnaquit (Read error: Connection reset by peer)
13:11:36  * iarna_joined
13:14:21  * importantshockjoined
13:20:00  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:20:50  * mmaleckiquit (Ping timeout: 265 seconds)
13:27:15  * kazuponjoined
13:33:30  * iarna_quit (Read error: Connection reset by peer)
13:33:44  * iarnajoined
13:36:43  * iarnaquit (Remote host closed the connection)
13:38:36  * mmaleckijoined
13:38:48  * iarnajoined
13:42:56  * iarnaquit (Remote host closed the connection)
13:42:56  * AlexisMochaquit (Read error: Connection reset by peer)
13:46:30  * AlexisMochajoined
13:47:31  * AlexisMochaquit (Read error: Connection reset by peer)
13:49:51  * janjongboomjoined
13:50:19  * AlexisMochajoined
13:51:15  * Fishrock123joined
13:52:29  * janjongboomquit (Client Quit)
13:53:48  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
13:54:29  * Ldxngxjoined
13:54:30  * AlexisMochaquit (Read error: Connection reset by peer)
13:56:08  * Ldxngxquit (Client Quit)
13:56:37  * janjongboomjoined
13:58:23  * Ldxngxjoined
13:58:25  * AlexisMochajoined
13:59:37  * Ldxngxquit (Client Quit)
14:00:27  * janjongboomquit (Client Quit)
14:00:27  * AlexisMochaquit (Read error: Connection reset by peer)
14:00:53  * janjongboomjoined
14:01:47  * janjongboomquit (Read error: Connection reset by peer)
14:01:52  * janjongb_joined
14:02:52  * kazuponquit
14:04:11  * kazuponjoined
14:04:24  * AlexisMochajoined
14:06:04  * Fishrock123quit (Remote host closed the connection)
14:06:05  * AlexisMochaquit (Read error: Connection reset by peer)
14:06:34  * janjongb_quit (Ping timeout: 255 seconds)
14:14:02  * janjongboomjoined
14:14:25  * janjongboomquit (Client Quit)
14:20:32  * Fishrock123joined
14:23:09  * lance|afkchanged nick to lanceball
14:41:01  * kazuponquit (Remote host closed the connection)
14:42:23  * kazuponjoined
14:46:20  * davijoined
14:51:11  * bajtosquit (Quit: bajtos)
14:51:13  * SergeiRNDquit (Quit: Leaving.)
14:54:10  * Diquit (Quit: Leaving.)
14:56:25  * kazuponquit (Remote host closed the connection)
14:59:59  * stagasquit (Ping timeout: 265 seconds)
15:00:02  * bajtosjoined
15:07:10  * piscisaureusquit (Ping timeout: 265 seconds)
15:12:33  * bajtosquit (Quit: bajtos)
15:20:23  * nickleeflyquit (Quit: Connection closed for inactivity)
15:21:11  * rmgjoined
15:26:19  * rmgquit (Ping timeout: 272 seconds)
15:48:43  * rmgjoined
15:55:36  * brsonjoined
16:00:29  * thlorenzjoined
16:01:57  * thlorenzquit (Remote host closed the connection)
16:02:29  * thlorenzjoined
16:07:05  * thlorenzquit (Ping timeout: 264 seconds)
16:20:36  * avalanche123joined
16:23:19  * avalanche123quit (Remote host closed the connection)
16:25:41  * janjongboomjoined
16:30:54  * iarnajoined
16:32:34  * thlorenzjoined
16:33:08  * iarnaquit (Remote host closed the connection)
16:33:40  * iarnajoined
16:37:57  * iarnaquit (Ping timeout: 240 seconds)
16:56:59  * bajtosjoined
16:58:53  * inolenjoined
17:11:21  * octetcloudjoined
17:12:16  * jgijoined
17:23:42  * avalanche123joined
17:28:15  * avalanche123quit (Ping timeout: 255 seconds)
17:33:54  * dap_joined
17:34:59  * jas-_quit (Ping timeout: 255 seconds)
17:39:10  * lanceballchanged nick to lance|afk
17:50:57  * thlorenz_joined
17:54:16  * yunongquit
17:56:05  * yunongjoined
17:57:37  * thlorenz_quit (Remote host closed the connection)
17:57:44  * thlorenzquit (Remote host closed the connection)
17:58:16  * thlorenzjoined
18:02:49  * thlorenz_joined
18:02:51  * thlorenzquit (Ping timeout: 244 seconds)
18:03:01  * thlorenz_quit (Remote host closed the connection)
18:03:18  * thlorenzjoined
18:06:06  * thlorenzquit (Client Quit)
18:23:07  * stagasjoined
18:28:18  * avalanche123joined
18:29:48  * avalanche123quit (Remote host closed the connection)
18:30:33  * avalanche123joined
18:31:02  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:46:29  <zj99f_>should it be possible to receive a SIGPIPE when calling uv_write? would that be a bug in libuv or how I'm using it?
18:50:03  * bajtosquit (Quit: bajtos)
18:53:58  <zj99f_>even if I use sigaction to ignore SIGPIPE, I still receive a SIGPIPE somehow
18:55:16  * janjongboomjoined
18:56:36  * thlorenzjoined
18:58:34  * inolenquit (Quit: Leaving.)
18:59:09  * piscisaureusjoined
19:07:21  * rmg_joined
19:08:22  * rmgquit (Ping timeout: 250 seconds)
19:12:27  <zj99f_>Okay, I just added a uv_signal_t to trap and ignore SIGPIPE, and everything works as expected now. I'm still not sure if ignoring SIGPIPEs like that could be dangerous though. Anyone know?
19:12:53  * daviquit (Ping timeout: 240 seconds)
19:13:26  <zj99f_>My ignore_sigpipe_callback is definitely being called, but rarely
19:17:40  * thlorenzquit (Remote host closed the connection)
19:18:15  * thlorenzjoined
19:22:43  * thlorenzquit (Ping timeout: 244 seconds)
19:23:21  * avalanch_joined
19:24:31  * lance|afkchanged nick to lanceball
19:27:04  * avalanche123quit (Ping timeout: 244 seconds)
19:31:45  * rmgjoined
19:34:17  * iarnajoined
19:34:48  * rmg_quit (Ping timeout: 250 seconds)
19:37:24  * rmgquit (Ping timeout: 255 seconds)
19:38:26  * iarnaquit (Ping timeout: 244 seconds)
19:38:30  * jgiquit (Quit: jgi)
19:38:59  * rmgjoined
19:51:37  * jgijoined
19:57:34  * rendar_joined
19:59:11  <Ralith>zj99f_: if you're getting SIGPIPE your application probably has a bug.
19:59:22  <Ralith>(or is being used incorrectly)
19:59:35  * rendarquit (Ping timeout: 265 seconds)
20:01:42  <chrisdickinson>tjfontaine: does node support windows XP? or is it vista+ now?
20:02:36  * piscisaureusquit (Ping timeout: 255 seconds)
20:03:07  <jgi>cjihrig: Hi! ping?
20:04:02  <cjihrig>jgi: hi!
20:04:43  <jgi>cjihrig: thanks for taking the time to review my doc changes :) I’m not a native english speaker, so that helps a lot.
20:05:22  <cjihrig>jgi: no problem. i thought it was mostly good. and more importantly, will remove confusion
20:06:01  * chrisdickinsonlooks
20:06:02  <jgi>cjihrig: regarding your proposition of using “As a result, only dns.lookup is guaranteed to behave like other programs running on the same system regarding name resolution.”, I’m not too keen on using the word “guaranteed”, since that’s a strong commitment to make dns.lookup behave like programs that potentially do different things regarding name resolution.
20:06:18  <jgi>cjihrig: what do you think of “As a result, __only `dns.lookup` should be expected to behave like other programs running on the same system regarding name resolution.”?
20:06:41  <cjihrig>jgi: that sounds good. you're right, a guarantee is a strong promise
20:07:04  <jgi>cjihrig: ok, then I’ll update the PR, and please feel free to add other comments
20:07:33  <cjihrig>jgi: sure thing. i think it should be good IMO anyway
20:09:32  * kriskowalquit (Quit: kriskowal)
20:10:05  <jgi>chrisdickinson: just saw your comment about the link to a manpage. Are there other places in the documentation where we do that? The only problem I have with linking to a specific manpage is that they’re different depending on which system the manpage covers.
20:10:25  <chrisdickinson>yeah :\ I had attempted to do this with the error documentation PR
20:10:38  <chrisdickinson>(which I should revisit)
20:10:54  <jgi>chrisdickinson: so what’s your opinion, should we link to a specific manpage or not?
20:11:35  <chrisdickinson>alternatively we could link to http://en.wikipedia.org/wiki/Getaddrinfo
20:14:26  <jgi>chrisdickinson: yes, that seems better, however there’s also the concern about broken links if the URL changes (although maybe unlikely with WikiPedia?). In other words, could you please add your suggestion to the PR’s comments so that it doesn’t get lost in the “outdated diff” comments? I feel very underqualified to make such a decision :)
20:21:02  * Dijoined
20:22:15  * avalanch_quit (Remote host closed the connection)
20:23:24  <chrisdickinson>jgi: great work! I added the external url concerns to the PR, am merging it now.
20:23:56  * avalanche123joined
20:25:11  <chrisdickinson>trevnorris: if a commit is merged to v0.10 with the intent of it going into v0.12 as well, what's the desired process for getting it into both branches?
20:31:24  * avalanch_joined
20:33:23  * iarnajoined
20:34:13  <MI6>joyent/node: Julien Gilli v0.10 * 5ff5945 : doc: clarify dns.lookup vs dns.resolve - http://git.io/l8qm1w
20:34:24  * avalanche123quit (Ping timeout: 245 seconds)
20:36:42  * ZenWraithBotjoined
20:42:51  * SergeiRNDjoined
20:54:33  * piscisaureusjoined
20:57:34  * iarna_joined
20:58:09  * iarnaquit (Ping timeout: 245 seconds)
21:01:13  * inolenjoined
21:01:16  * inolenquit (Client Quit)
21:02:30  * iarna_quit (Remote host closed the connection)
21:03:04  * iarnajoined
21:07:30  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:07:48  * iarnaquit (Ping timeout: 256 seconds)
21:08:55  <chrisdickinson>tjfontaine: sorry about jumping the gun a bit on https://github.com/joyent/node/pull/8726
21:11:42  <chrisdickinson>I haven't closed the issue yet as I was looking into the process of porting it to the v0.12 branch as well
21:15:52  * iarnajoined
21:19:22  * Diquit (Quit: Leaving.)
21:24:15  * jgiquit (Quit: jgi)
21:25:33  * kriskowaljoined
21:35:03  * Dijoined
21:41:57  * iarna_joined
21:42:27  * iarnaquit (Read error: Connection reset by peer)
21:52:19  * Ralithquit (Ping timeout: 255 seconds)
21:54:52  * dshaw_joined
21:55:30  * iarna_quit (Read error: Connection reset by peer)
21:55:59  * iarnajoined
21:59:29  * iarnaquit (Read error: Connection reset by peer)
22:02:07  * Ralithjoined
22:05:53  * Fishrock123quit (Remote host closed the connection)
22:14:35  * dshaw_quit (Remote host closed the connection)
22:14:57  * dshaw_joined
22:21:08  * jgijoined
22:26:36  * kriskowalquit (Quit: kriskowal)
22:27:15  * dshaw_quit (Remote host closed the connection)
22:27:37  * dshaw_joined
22:31:02  * jgiquit (Quit: jgi)
22:31:04  * Fishrock123joined
22:32:58  * jgijoined
22:33:53  * dshaw_quit (Read error: Connection reset by peer)
22:34:18  * dshaw_joined
22:35:03  * kriskowaljoined
22:46:43  * SergeiRNDquit (Quit: Leaving.)
22:47:01  * SergeiRNDjoined
22:47:05  * SergeiRNDquit (Client Quit)
23:00:05  * dshaw_quit (Remote host closed the connection)
23:00:29  * Fishrock123quit (Remote host closed the connection)
23:00:29  * dshaw_joined
23:06:34  * importantshockquit (Remote host closed the connection)
23:10:58  <trevnorris>chrisdickinson: we usually do a merge from v0.10 into v0.12, then v0.12 into master.
23:11:08  <trevnorris>though the v0.10 to v0.12 merges can be a bitch
23:11:13  <trevnorris>tjfontaine: ping
23:18:57  * piscisaureusquit (Ping timeout: 240 seconds)
23:19:09  * Fishrock123joined
23:21:26  * iarnajoined
23:27:37  * dshaw_quit (Remote host closed the connection)
23:28:01  * dshaw_joined
23:28:04  * dshaw_quit (Client Quit)
23:32:42  * kriskowalquit (Quit: kriskowal)
23:32:47  * sblomjoined
23:39:00  * iarnaquit (Remote host closed the connection)
23:41:41  * dap_quit (Quit: Leaving.)
23:47:32  * EhevuTovjoined
23:47:43  * toothrotjoined
23:55:20  * iarnajoined
23:59:22  * iarnaquit (Ping timeout: 240 seconds)
23:59:27  * dshaw_joined