00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:05:43  * chris_99quit (Quit: Ex-Chat)
00:08:40  * thlorenzjoined
00:19:37  * Fishrock123joined
00:22:10  * iarnaquit (Remote host closed the connection)
00:22:39  * thlorenzquit (Ping timeout: 276 seconds)
00:23:06  * jasnelljoined
00:23:52  * wrljoined
00:24:03  * seldojoined
00:24:11  <wrl>hey, here's a question: i currently have some IPC messaging code that incrementally reads and writes messages from an FD
00:24:21  * Fishrock123quit (Ping timeout: 252 seconds)
00:24:29  <wrl>it reads the header and then decides how much more it needs to read past that, depending on the message type
00:24:36  <wrl>is there an easy way to accomplish this in libuv?
00:25:29  <wrl>i'm looking at the whole uv_stream stuff and i'm not seeing anything super straightforward -- seems to me that just getting a chunk of data read from a pipe in the read_cb would be complicated to process
00:26:12  <wrl>i mean, it would be potentially as easy as rewriting my IPC code to deal with having a chunk of data instead of reading it incrementally
00:26:42  <wrl>but even with large block sizes, i'm worried about messages getting cut off, and needing to store state between invocations of the read_cb
00:28:49  * seldoquit (Ping timeout: 264 seconds)
00:36:55  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:38:25  * ijrothquit (Quit: Leaving.)
00:40:07  * thlorenzjoined
00:45:50  * iarnajoined
00:46:43  * dshaw_joined
00:47:51  * ijrothjoined
00:48:29  * dap_1joined
00:48:30  * dap_quit (Read error: Connection reset by peer)
00:53:47  * dap_joined
00:53:48  * dap_1quit (Read error: Connection reset by peer)
01:02:38  * Fishrock123joined
01:02:53  * importantshockquit (Remote host closed the connection)
01:03:28  * importantshockjoined
01:07:47  * importantshockquit (Ping timeout: 245 seconds)
01:08:25  * dap_quit (Read error: Connection reset by peer)
01:08:38  * dap_joined
01:13:06  * jasnellquit (Remote host closed the connection)
01:13:38  * jasnelljoined
01:17:53  * jasnellquit (Ping timeout: 252 seconds)
01:21:11  * a_lequit (Remote host closed the connection)
01:24:27  * Ralithquit (Ping timeout: 245 seconds)
01:28:44  * qardquit (Quit: leaving)
01:31:07  * octetcloudquit (Ping timeout: 245 seconds)
01:35:48  * a_lejoined
01:36:54  * ijrothquit (Quit: Leaving.)
01:38:32  * ijrothjoined
01:44:40  * Ralithjoined
01:58:56  * ijrothquit (Quit: Leaving.)
02:03:15  * ijrothjoined
02:20:29  * ijrothquit (Quit: Leaving.)
02:20:47  * dap_quit (Quit: Leaving.)
02:29:50  * ijrothjoined
02:29:55  * jasnelljoined
02:33:59  * jasnellquit (Ping timeout: 245 seconds)
02:36:45  * seldojoined
02:43:17  * jasnelljoined
02:43:54  * ijrothquit (Quit: Leaving.)
02:47:23  * jgiquit (Quit: jgi)
02:59:21  * a_lequit (Remote host closed the connection)
03:00:11  * jasnellquit (Ping timeout: 252 seconds)
03:02:34  * seldoquit (Remote host closed the connection)
03:08:50  * SergeiRNDjoined
03:12:17  * jasnelljoined
03:30:57  * brsonquit (Quit: leaving)
03:31:05  * brsonjoined
03:31:29  * SergeiRNDquit (Quit: Leaving.)
03:33:40  * brsonquit (Client Quit)
03:33:48  * brsonjoined
03:34:40  * brsonquit (Client Quit)
03:38:18  * ijrothjoined
03:42:06  * ijrothquit (Client Quit)
03:42:38  * jasnellquit (Remote host closed the connection)
03:46:50  * thlorenzquit (Remote host closed the connection)
03:53:42  * seldojoined
03:59:11  * a_lejoined
04:02:49  * Left_Turnquit (Read error: Connection reset by peer)
04:03:29  * a_lequit (Ping timeout: 246 seconds)
04:04:04  * seldoquit (Remote host closed the connection)
04:06:05  * a_lejoined
04:10:09  * rmgquit (Remote host closed the connection)
04:12:07  * jasnelljoined
04:16:29  * dshaw_quit (Quit: Leaving.)
04:19:07  * seldojoined
04:23:04  * thlorenzjoined
04:25:15  * thlorenzquit (Remote host closed the connection)
04:27:56  * Fishrock123quit (Read error: Connection reset by peer)
04:28:37  * jasnellquit (Read error: Connection reset by peer)
04:29:17  * jasnelljoined
04:30:03  * dshaw_joined
04:30:56  * rmgjoined
04:38:02  * jasnellquit (Remote host closed the connection)
04:46:15  * az7ar_awayquit (Ping timeout: 264 seconds)
04:46:16  * rkowalskiquit (Ping timeout: 264 seconds)
04:50:04  * rkowalskijoined
04:50:23  * a_lequit (Ping timeout: 246 seconds)
04:54:47  * az7ar_awayjoined
04:54:51  * dshaw_quit (Ping timeout: 256 seconds)
04:59:44  * dshaw_joined
05:02:22  * sandr8quit (Read error: Connection timed out)
05:10:22  * seldoquit
05:16:02  * a_lejoined
05:21:27  * AvianFluquit (Quit: Leaving)
05:22:15  * sandr8joined
05:26:25  * thlorenzjoined
05:29:52  * brsonjoined
05:31:50  * thlorenzquit (Ping timeout: 264 seconds)
06:07:14  * jgijoined
06:18:29  * iarnaquit (Remote host closed the connection)
06:25:45  * iarnajoined
06:27:37  * thlorenzjoined
06:30:23  * iarnaquit (Read error: Connection reset by peer)
06:30:53  * iarnajoined
06:31:54  * thlorenzquit (Ping timeout: 245 seconds)
06:37:42  * dshaw_quit (Quit: Leaving.)
07:05:44  * jgiquit (Quit: jgi)
07:08:02  * SergeiRNDjoined
07:09:09  * iarnaquit (Ping timeout: 256 seconds)
07:26:43  * Rolinhquit (Quit: WeeChat 1.1.1)
07:28:22  * thlorenzjoined
07:32:51  * thlorenzquit (Ping timeout: 244 seconds)
07:37:19  * bajtosjoined
07:38:18  * Rolinhjoined
07:38:54  * jasnelljoined
07:43:22  * jasnellquit (Ping timeout: 240 seconds)
07:57:04  * Guest76317changed nick to bengl
08:17:32  * bajtosquit (Quit: bajtos)
08:19:56  * bajtosjoined
08:22:34  <saghul>wrl: you can shorten the data you get passing a lower value to aloc_cb
08:24:12  * ijrothjoined
08:29:16  * thlorenzjoined
08:30:25  * bajtosquit (Quit: bajtos)
08:31:45  * bajtosjoined
08:33:37  * thlorenzquit (Ping timeout: 245 seconds)
08:39:05  <normanm>hi there... is it possible to let libuv to run some function in the eventloop ?
08:39:51  <brucem>normanm: like an idle callback?
08:39:53  <normanm>so like if its blocking and waiting for epoll to wakup submit something that needs to get executed and it automatically unblock epoll_wait and execute it
08:40:14  <normanm>brucem, like what you would for example do eventfd and epoll_wait
08:40:32  * rmgquit (Remote host closed the connection)
08:41:29  <saghul>normanm: uv_async_send will wakeup the loop
08:41:49  <saghul>then you could run your code in a prepare or check handle
08:42:12  <normanm>awesome will try
08:42:13  <normanm>thanks
08:54:52  <normanm>btw anyone is aware of a benchmark comparing libuv against libev ?
08:59:08  <saghul>normanm: compare how? libev doesn't have an abstraction equivalent to uv_stream_t
08:59:29  <normanm>just compare for example an echo server written in both
08:59:33  <normanm>in terms of throughput/latency
08:59:51  <normanm>I know that the abstraction is different but still it's an event io lib
09:00:06  <saghul>but it wouldn't be an apples to apples comparison
09:00:19  <normanm>you mean apples to organges ?
09:00:51  <saghul>I mean, if you compare uv_stream_t vs ev_io that's not the same abstraction
09:00:53  <normanm>well not sure I would call it like that... the scope is a bit different but still both are frameworks that allow you to write network servers / clients
09:01:03  <saghul>sure
09:01:18  <normanm>sure it's not the same abstraction but still it's about sending/receving bytes
09:01:19  <saghul>I'm not aware of any benchmarks though
09:01:22  <brucem>normanm: Given what you work on ... have you compared libuv with Netty4?
09:01:52  <normanm>brucem, actually what I'm currently prototype is a jni based transport using libuv
09:02:12  <brucem>ah, interesting!
09:02:16  <normanm>brucem, ;)
09:02:43  <normanm>brucem, I have written an pure epoll based transport using jni and put netty on top of it
09:02:54  <normanm>but wanted to see how this compares with just using libuv under the hood
09:03:04  <normanm>as this would also work on non linux etc
09:03:42  <normanm>so just reading up on libuv a bit to get a better feeling about the api and how I could fit it in best
09:03:52  <brucem>normanm: NIO had some bad locking behavior that you wanted to get around, IIRC? or was it allocations?
09:04:06  <normanm>brucem, you mean the java nio stuff ?
09:04:12  <brucem>yeah
09:04:40  <brucem>Clearly you're unhappy with something if you're going to this effort .. and I remember reading something about unhappiness with NIO.
09:05:11  <normanm>multiple reasons... java nio produce too much objects and so GC pressure. Also because of how the threading works in netty we not need many guards that java.nio uses
09:05:46  <normanm>also how direct buffers are managed by java nio is not really good imho
09:06:20  <normanm>brucem, also I don't think it should be to hard to do this... like I said I wrote a pure epoll transport via jni before and it was not too hard either. Not saying that jni is fun but well
09:10:43  <brucem>normanm: It'll be interesting to hear how this goes. :)
09:10:49  <normanm>brucem, will report back for sure
09:11:09  <normanm>another question as I'm not able to find it in the api docs.
09:11:38  <normanm>is there a way to tell how long epoll_wait or similar calls should block before automatically unblock and call the idle callback ?
09:11:58  <brucem>rather than a 0 timeout like now?
09:12:03  <normanm>yes
09:14:42  <brucem>doesn't look like it from the source.
09:14:49  <normanm>bummer
09:15:33  <brucem>https://github.com/libuv/libuv/blob/f2bb8d394c06d06ee45e884600466321455751b6/src/unix/core.c#L320 and https://github.com/libuv/libuv/blob/f2bb8d394c06d06ee45e884600466321455751b6/src/unix/timer.c#L129
09:17:22  <normanm>seems like I could just use a timer for my use-case
09:18:16  <normanm>at the moment we allow to schedule tasks which are executed in the future. we do this by calculate the max time epoll_wait is allowed to block and then just pick them up once it unblocks
09:18:52  <normanm>so I guess I could create a timer handle for this
09:18:53  <brucem>or implement your timers using uv_timer_t
09:18:58  <normanm>yep
09:19:06  <normanm>that is what I was refer to
09:19:27  <normanm>I'm just a bit concerned about the overhead which is involved from calling back from jni code into java
09:19:39  <normanm>but I guess the only way to find out is to actual doing a poc
09:20:28  * chris_99joined
09:20:54  <normanm>brucem thanks for all the help btw
09:22:20  <brucem>normanm: np!
09:23:09  <brucem>normanm: I keep arguing with myself over how much code in the Dylan system libs I want to replace with libuv or not ... so this is interesting to me.
09:24:21  * roxlujoined
09:29:58  * thlorenzjoined
09:33:19  * brsonquit (Quit: leaving)
09:34:21  * thlorenzquit (Ping timeout: 252 seconds)
09:41:05  * rmgjoined
09:43:35  * SergeiRNDquit (Quit: Leaving.)
09:46:14  * rmgquit (Ping timeout: 264 seconds)
09:52:45  * a_lequit (Remote host closed the connection)
10:11:15  * iarnajoined
10:15:22  * iarnaquit (Ping timeout: 240 seconds)
10:19:50  * a_lejoined
10:30:30  * a_lequit (Remote host closed the connection)
10:30:48  * thlorenzjoined
10:31:09  * kkaeferjoined
10:35:36  * thlorenzquit (Ping timeout: 276 seconds)
10:35:52  <saghul>normanm: you cannot currently control that, it's based on the closest timer, the presence of idle handles, etc
10:36:25  <normanm>yep... brucem pointed me to the right code
10:36:26  <normanm>thanks
10:36:38  <saghul>normanm: it's described here: http://docs.libuv.org/en/v1.x/design.html#the-i-o-loop
10:37:08  <saghul>oh, yeah, code talks :-)
10:38:00  <normanm>yep
10:38:02  <normanm>:)
10:55:34  * Left_Turnjoined
11:14:02  * ijrothquit (Quit: Leaving.)
11:17:05  * seishunjoined
11:19:39  <normanm>saghul, what would be the best way to call one task everytime the eventloop finished processing io ?
11:20:19  * bajtosquit (Quit: bajtos)
11:24:14  <saghul>normanm: run it in a check handle, those chandles run right after i/o
11:24:37  <normanm>thanks!
11:31:36  * thlorenzjoined
11:35:05  * tarrudajoined
11:36:03  * thlorenzquit (Ping timeout: 256 seconds)
11:41:53  * bajtosjoined
11:44:22  * SergeiRNDjoined
12:28:05  * bajtosquit (Quit: bajtos)
12:32:25  * thlorenzjoined
12:36:35  * thlorenzquit (Ping timeout: 246 seconds)
12:53:40  * mmaleckiquit (Ping timeout: 272 seconds)
12:56:38  * gnosticationquit (Read error: Connection reset by peer)
12:57:51  * rmgjoined
13:02:13  * rmgquit (Ping timeout: 255 seconds)
13:11:55  * inolenquit (Quit: Leaving.)
13:33:15  * thlorenzjoined
13:37:05  <wrl>saghul: yeah, i thought about that
13:37:13  <wrl>i would ideally like to not have to suddenly write like
13:37:22  * thlorenzquit (Ping timeout: 240 seconds)
13:37:31  <wrl>or rather i would like to not double the LOC count in my IPC code just to deal with libuv
13:38:48  <wrl>honestly what i'm thinking i might do is just have my alloc_cb return 0, and then in the sucessive read_cb with the error, just get the file descriptor from the uv_stream_t and read() on that
13:52:40  * tarrudaquit (Quit: WeeChat 1.0.1)
14:03:00  * lance|afkchanged nick to lanceball
14:34:10  * thlorenzjoined
14:38:34  * thlorenzquit (Ping timeout: 245 seconds)
14:42:58  * Fishrock123joined
14:43:23  * thlorenzjoined
14:45:07  * thlorenzquit (Remote host closed the connection)
14:47:26  * SergeiRNDquit (Quit: Leaving.)
14:47:36  * thlorenzjoined
14:49:10  * thlorenzquit (Remote host closed the connection)
15:07:11  * piscisaureusjoined
15:10:55  <saghul>wrl: then maybe you are better off using a poll handle
15:11:26  <saghul>if the alloc_cb gets a 0 length it won't even attempt a read, you'll get ENOBUFS
15:11:34  <saghul>and the stream might not be readable
15:13:52  * thlorenzjoined
15:15:44  * AvianFlujoined
15:34:30  * tarrudajoined
15:39:19  * Fishrock123quit (Quit: Leaving...)
15:45:32  <wrl>saghul: oh, good call.
15:45:39  * Fishrock123joined
15:48:37  * jasnelljoined
15:50:12  * jasnell_joined
15:53:27  * jasnellquit (Ping timeout: 264 seconds)
15:53:38  * jasnelljoined
15:54:53  * jasnell__joined
15:56:18  * jasnel___joined
15:56:36  * jasnell_quit (Ping timeout: 244 seconds)
15:58:09  * jasnellquit (Ping timeout: 244 seconds)
15:59:57  * jasnell__quit (Ping timeout: 276 seconds)
16:07:38  * a_lejoined
16:11:26  * tarrudaquit (Quit: WeeChat 1.0.1)
16:21:44  * importan_joined
16:23:59  * AlexisMochaquit (Read error: Connection reset by peer)
16:29:03  <tjfontaine>robertkowalski: hey hey
16:29:58  * jasnel___changed nick to jasnell
16:48:35  * jgijoined
16:51:15  * iarnajoined
16:53:31  * octetcloudjoined
16:59:31  * ijrothjoined
16:59:36  * rmgjoined
17:00:14  <tjfontaine>https://plus.google.com/hangouts/_/calendar/dGpmb250YWluZUBub2RlanMub3Jn.7o3iugm5mbjqj81eb56fsoj118
17:03:05  * ijrothquit (Client Quit)
17:03:05  <tjfontaine>chrisdickinson, trevnorris
17:21:09  <wrl>yo, do i need to do anything with the return value of uv_setup_args() ?
17:24:15  <jgi>robertkowalski: cleared the cache and my browser is not redirected to https:// when pointing it to http://nodejs.org/api/
17:28:55  <tjfontaine>jgi: doc.nodejs.org does though
17:29:23  <jgi>tjfontaine: yes
17:29:34  <tjfontaine>doesn't seem like the main site redirect has been re-enabled yet
17:29:37  <tjfontaine>which is ok
17:29:45  <tjfontaine>we need to make sure that /dist is excluded
17:32:17  * dap_joined
17:37:15  * ijrothjoined
17:40:15  * jgiquit (Quit: jgi)
17:44:31  * qardjoined
17:46:58  * thlorenzquit (Remote host closed the connection)
17:48:42  * thlorenzjoined
17:49:50  * jasnellquit (Ping timeout: 265 seconds)
17:50:09  * ijrothquit (Quit: Leaving.)
17:52:52  * jasnelljoined
17:53:17  * ijrothjoined
17:53:21  * lanceballchanged nick to lance|afk
17:55:38  * SergeiRNDjoined
18:02:27  * thlorenzquit (Ping timeout: 264 seconds)
18:05:05  * ijrothquit (Quit: Leaving.)
18:05:06  * inolenjoined
18:05:19  * ijrothjoined
18:05:28  * SergeiRNDquit (Quit: Leaving.)
18:12:31  * jreyno40joined
18:13:18  <Wraithan>tjfontaine, jgi: Howdy, noticed the 0.11.16 is not released yet and lots of stuff in the milestone. We still thinking next week for 0.12? Looking at how much time I have to rewrite some stuff
18:14:16  <tjfontaine>Wraithan: we just discussed it on the call today -- 0.11.16 should be out today -- only changes are in url.path and assert's handling of objects
18:14:45  <tjfontaine>Wraithan: no particular reason you couldn't be testing against 0.11.15 unless your suite covers npm as well
18:14:51  <Wraithan>I'm testing against it
18:15:01  <Wraithan>Just wondering timeline to release all the stuff needed to make 0.12 work
18:15:16  <Wraithan>http agent changed enough that our proxy support is now busted
18:15:17  * thlorenzjoined
18:15:25  <Wraithan>along with a couple other little failing tests
18:15:36  <tjfontaine>the intent is to get 0.11.16 out today, nothing ont he milestones is particularly large, and saving anything huge happening over the weekend, 0.12.0 next week
18:15:46  <Wraithan>Ok, cool
18:15:59  <tjfontaine>if you need help with fixing your agent usage and proxy support, please let us know
18:16:05  <tjfontaine>we don't want you to be adversely affected
18:16:49  <Wraithan>tjfontaine: we may release without proxy support on 0.12 so we can come up with a better solution. Right now we are using a module for it: https://github.com/capriza/node-proxying-agent
18:17:04  * jgijoined
18:17:08  <tjfontaine>Wraithan: ok
18:17:18  <tjfontaine>Wraithan: whatever we can do to help
18:17:57  <Wraithan>we don't need the nltm stuff so we can probably write a more simple solution that has better compat (currently we don't support proxy on 0.8 because of that module but we've also had no support requests for it)
18:18:06  <Wraithan>tjfontaine: I appreciate it
18:18:22  <Wraithan>tjfontaine: Thanks for dealing with my constant proding about timeline
18:18:23  <Wraithan>:)
18:18:42  <tjfontaine>compared to the other voices on me about timeline -- this is nothing
18:19:07  <tjfontaine>I'm trying to keep everyone on the same page, while managing expectations that bugs can happen
18:19:14  <tjfontaine>you know -- the normal release nonsense
18:19:17  <Wraithan>exactly
18:24:34  * jasnell_joined
18:25:33  * jasnellquit (Ping timeout: 276 seconds)
18:28:25  * jasnelljoined
18:28:47  * ijrothquit (Quit: Leaving.)
18:28:59  * jasnell_quit (Ping timeout: 245 seconds)
18:29:44  * ijrothjoined
18:38:37  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:44:29  * lance|afkchanged nick to lanceball
18:59:58  * ijrothquit (Quit: Leaving.)
19:05:32  * roxlujoined
19:06:52  * ijrothjoined
19:22:58  * ijrothquit (Quit: Leaving.)
19:24:19  * ijrothjoined
19:27:02  * sblomjoined
19:27:23  * ijrothquit (Client Quit)
19:28:37  * brsonjoined
19:32:19  * ijrothjoined
19:41:40  * wwicks_quit
19:42:02  * wwicks_joined
19:42:35  * wwicks_changed nick to wwicks
19:45:03  * ijrothquit (Quit: Leaving.)
19:46:24  * ijrothjoined
19:48:25  * sandr8_joined
19:48:55  * ijrothquit (Client Quit)
19:49:57  * ijrothjoined
19:50:58  * ijrothquit (Client Quit)
19:51:17  * seishunquit (Disconnected by services)
19:51:25  * seishunjoined
19:56:37  * sandr8quit (Ping timeout: 264 seconds)
20:07:15  * dshaw_joined
20:08:29  * ijrothjoined
20:10:05  <MI6>joyent/node: Julien Gilli v0.12 * 3b392d3 : Revert "url: support `path` for url.format" - http://git.io/FKMr
20:11:26  * gnosticationjoined
20:16:26  * jasnell_joined
20:19:51  * jasnellquit (Ping timeout: 264 seconds)
20:20:42  * jasnell_quit (Ping timeout: 245 seconds)
20:22:23  * jreyno40part
20:23:25  * jasnelljoined
20:31:33  * jasnellquit (Ping timeout: 246 seconds)
20:32:15  * jasnelljoined
20:40:14  * dshaw_quit (Quit: Leaving.)
20:44:32  * dshaw_joined
20:49:52  * jgiquit (Quit: jgi)
20:57:31  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:08:12  * brsonquit (Quit: leaving)
21:08:20  * brsonjoined
21:11:46  * roxlujoined
21:14:14  * dsantiagoquit (Ping timeout: 246 seconds)
21:17:34  * dsantiagojoined
21:18:53  * dsantiagoquit (Max SendQ exceeded)
21:19:00  * dshaw_quit (Quit: Leaving.)
21:19:33  * dsantiagojoined
21:39:02  * jgijoined
21:40:54  * ijrothquit (Quit: Leaving.)
21:43:41  * ijrothjoined
21:50:54  * ijrothquit (Quit: Leaving.)
21:51:20  * Ralithquit (Ping timeout: 246 seconds)
21:51:37  * ijrothjoined
22:03:49  <jgi>cjihrig, tjfontaine: regarding https://github.com/joyent/node/pull/8734, is parsing parts of assertions messages with JSON.parse a common practice? Just asking since this change would break such code. I guess that’s why tjfontaine considered it as an API breaking change.
22:03:49  * ijrothquit (Quit: Leaving.)
22:07:08  <piscisaureus>Interesting how sblom is here. I thought you had moved on to greener pastures?
22:09:22  <cjihrig>jgi: i can't speak for the rest of the world, but i think it would be a bad idea. the current implementation uses a custom replacer function too
22:10:14  * Ralithjoined
22:10:18  <cjihrig>jgi: oh and it gets truncated :-)
22:10:20  * ijrothjoined
22:10:46  <jgi>cjihrig: ah right, that’s a very good point :)
22:10:56  <jgi>cjihrig: thanks!
22:11:04  <cjihrig>jgi: np
22:12:24  * ijrothquit (Client Quit)
22:13:39  * ijrothjoined
22:14:41  * jasnellquit (Ping timeout: 256 seconds)
22:15:43  * ijrothquit (Client Quit)
22:16:34  * ijrothjoined
22:21:19  <piscisaureus>+1 to 8734, this is a real issue
22:23:12  <robertkowalski>jgi: sorry i was a bit unprepared today and did not show the change: https://github.com/joyent/node-website/commit/0eac45544a3182827a260a6ab1862d19361c0977
22:23:27  * AvianFluquit (Remote host closed the connection)
22:23:55  <robertkowalski>jgi: it is just for api.nodejs.org and docs/doc.nodejs.org
22:24:54  <robertkowalski>as tjfontaine already mentioned, redirecting the whole site (including dist) is not possible yet because of /dist/
22:25:46  <robertkowalski>but after blog.nodejs.org is also working with the ssl certificate we can maybe do something like: all, except /dist/
22:25:51  <jgi>robertkowalski: ok, I thought we could redirect by matching paths within a given URL
22:27:27  <robertkowalski>jgi: yes that might be possible, but i am doing baby steps as i also test ever change a lot. the ticket is still open: https://github.com/joyent/node-website/issues/68
22:30:30  <jgi>robertkowalski: ok, that’s great! I just wanted to make sure that we were on the same page. Thank you for the clarifications!
22:33:30  * lanceballchanged nick to lance|afk
22:35:02  * ijroth1joined
22:37:36  * ijrothquit (Ping timeout: 272 seconds)
22:47:39  * AvianFlujoined
22:54:58  * ijroth1quit (Quit: Leaving.)
22:54:59  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:05:14  * ijrothjoined
23:23:36  <MI6>joyent/node: cjihrig v0.12 * bcff90e : assert: use util.inspect() to create error messages - http://git.io/Fiqj
23:29:57  * importan_quit (Read error: Connection reset by peer)
23:39:25  <jgi>cjihrig: regarding https://github.com/joyent/node/pull/8784, do the newly added tests actually test the bug? It seems these tests don’t involve the debugger, so they’re not regression tests for this issue right?
23:50:50  <wrl>is it possible that several writes to a uv_pipe will be read at the same time?
23:51:02  <wrl>i.e. write 5 bytes, write 5 bytes, and the read side reads 10?
23:51:21  <wrl>or do the writes stay separated
23:53:11  <robertkowalski>the documentation tool has basic tests now: https://github.com/joyent/node-documentation-generator/pull/2
23:58:34  <jgi>cjihrig: Ah ok, I hadn't seen the second part of the commit message, sorry.