00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:41  <LeftWing>trevnorris: I started on adding it to libuv at some point ... https://github.com/jclulow/libuv/compare/crosscall
00:01:24  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:01:29  <trevnorris>ooh, nice.
00:04:20  * tumdedumquit (Ping timeout: 255 seconds)
00:11:58  * tumdedumjoined
00:13:48  * paulfryzeljoined
00:14:09  * seldoquit (Remote host closed the connection)
00:14:48  * seldojoined
00:16:35  * guybrushquit (Excess Flood)
00:16:35  * stephankjoined
00:17:04  * guybrushjoined
00:18:11  * paulfryzelquit (Ping timeout: 246 seconds)
00:18:18  * rosskquit (Ping timeout: 240 seconds)
00:25:05  * mikolalysenkoquit (Ping timeout: 250 seconds)
00:26:56  * paulfryzeljoined
00:33:24  * brunklequit (Quit: brunkle)
00:40:50  * dap_quit (Quit: Leaving.)
00:40:59  * wolfeidaujoined
00:41:07  * wolfeidauquit (Remote host closed the connection)
00:42:55  * seldoquit (Remote host closed the connection)
00:43:09  * benvie_joined
00:43:33  * seldojoined
00:44:35  * benviequit (Ping timeout: 250 seconds)
00:46:34  * inolenquit (Quit: Leaving.)
00:46:50  * inolenjoined
00:48:16  * calvinfoquit (Quit: Leaving.)
00:49:58  * calvinfojoined
00:51:23  * thlorenzjoined
00:51:58  * mikolalysenkojoined
00:52:13  * thlorenzquit (Remote host closed the connection)
00:53:29  <Dirkson>Hey all. So if I send a large amount of data via tcp, uv will break up the data into many separate sections for me, and will hand those sections to me one at a time, in order, in my tcp callback. So on the first run of the callback, I can read the first couple bytes of data, see my overall size, see what my data will be... How do I pass this information on to further calls of my receivetcp function?
00:57:46  * kazuponjoined
01:03:53  <tjfontaine>Dirkson: so -- tcp is a reliable in order transmission of what it's given
01:04:13  * sblomquit (Read error: Connection reset by peer)
01:04:14  <tjfontaine>it's not about what uv will or won't do
01:04:49  * thlorenzjoined
01:04:59  <tjfontaine>as far as sending lots of data -- http://linux.die.net/man/2/write
01:05:15  <tjfontaine>describes what the semantics are, not really about what libuv will do
01:05:20  <tjfontaine>and related to how tcp itself also works
01:06:42  * stephankquit (Ping timeout: 240 seconds)
01:08:58  * Qardquit (Ping timeout: 240 seconds)
01:11:09  * stephankjoined
01:14:54  <Dirkson>tjfontaine: Well, I might want to write the data, sure... But to know if I want to do that, I need to check the first few bytes of data I send.
01:16:14  <Dirkson>tjfontaine: And once the second callback happens, I lose access to the first bit of data in a particular stream.
01:17:18  * nifocquit (Quit: Quit)
01:17:33  * euoiajoined
01:17:35  * brunklejoined
01:18:08  <Dirkson>And even if I did write it, I'd want to write different data to different places... Which is really hard to do if I can't tell which bit of data a particular callback is intended to reference.
01:19:26  * cosnisjoined
01:22:48  * calvinfoquit (Quit: Leaving.)
01:22:56  * bradleymeckjoined
01:24:33  * cosnisquit (Quit: Textual IRC Client: www.textualapp.com)
01:25:49  * seldoquit (Remote host closed the connection)
01:27:49  * seldojoined
01:27:59  * seldoquit (Remote host closed the connection)
01:30:22  * nifocjoined
01:35:40  * brunklequit (Quit: brunkle)
01:38:18  * euoiaquit (Ping timeout: 240 seconds)
01:49:59  * daviddiasjoined
01:53:18  * calvinfojoined
01:54:26  * daviddiasquit (Ping timeout: 246 seconds)
01:55:03  <Dirkson>Am I expected to write a per-user state machine based on the incoming data?
01:57:35  * calvinfoquit (Ping timeout: 246 seconds)
01:57:38  <Orborde>Dirkson is writing a network protocol that runs over TCP. He wants to know how he is supposed to do the stateful bookkeeping involved in parsing protocol messages that are going to arrive over multiple callbacks.
01:57:39  <tjfontaine>yes, tcp doesn't really handle that for you, it's part of your application protocol
01:58:24  <tjfontaine>ip has some of those semantics (describing the size of the packet) and tcp enforces that packets will be received in order
01:58:44  <tjfontaine>but if you are abstracting data upon tcp, you will need to reconstruct that information on your own, through semantics you define
02:00:00  <tjfontaine>http://en.wikipedia.org/wiki/OSI_model#Layer_7:_application_layer
02:00:52  <Dirkson>It would be a lot easier if I could have access to a user data pointer in my receive TCP data function. Set it to be a pointer to a struct with information about what's going on. As-is, I think I need to make some sort of lookup table based on whatever value is in the uv_stream_t handed me?
02:01:16  <tjfontaine>you can set data on the tcp connection
02:01:36  <Orborde>Dirkson: Does uv_stream_t have some kind of "void* userdata" field?
02:01:43  <Orborde>That's how C libraries usually do this sort of thing.
02:01:47  <tjfontaine>yes it does
02:01:51  <tjfontaine>->data
02:01:54  <Dirkson>Huzzah! That'll solve it.
02:03:10  <Dirkson>Still way damn messier than I expected from libuv :-/
02:03:46  <tjfontaine>some of the api allows you to associated for *hint
02:04:12  <tjfontaine>another solution is to wrap your tcp connection in a struct and use OFFSETOF
02:04:34  <Dirkson>"associated for *hint" ? I don't follow
02:04:46  <tjfontaine>uv_something(foo, hint);
02:05:22  <Orborde>In related news, C is a ridiculous language.
02:05:51  <Orborde>Dirkson: This sort of crazy bookkeeping is why people often take the performance hit and use lots of threads.
02:06:02  <Orborde>I think
02:06:04  <Orborde>At least
02:06:16  <Orborde>I'm willing to sacrifice 100x performance not to have to deal with this ;-)
02:06:28  * m76quit (Read error: Connection reset by peer)
02:06:30  <tjfontaine>well in newer C or in apple land you can use blocks
02:06:53  <Orborde>tjfontaine: blocks?
02:07:12  <tjfontaine>http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
02:07:49  <Orborde>tjfontaine: Are these some kind of coroutine thing?
02:08:55  * brunklejoined
02:10:00  <Dirkson>If I send a hunk of tcp data < 64kb long, is there any reason to expect it will arrive in two separate callbacks?
02:11:48  <Dirkson>If it answer is "Yes, the data can come in separate callbacks", what is the size of data that /can't/ come in separate callbacks?
02:12:29  <Orborde>Dirkson: betcha the answer is "1 byte" because of the potential for IP-level fragmentation
02:13:06  * mikolalysenkoquit (Ping timeout: 240 seconds)
02:15:10  * thlorenzquit (Remote host closed the connection)
02:15:44  * thlorenzjoined
02:20:07  * thlorenzquit (Ping timeout: 240 seconds)
02:22:29  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:23:43  * brunklequit (Quit: brunkle)
02:27:09  * brunklejoined
02:42:09  * brunklequit (Quit: brunkle)
02:48:06  * stagasquit (Read error: Connection reset by peer)
02:51:18  * daviddiasjoined
02:53:27  * brsonquit (Quit: leaving)
02:53:44  * brsonjoined
02:54:06  * calvinfojoined
02:55:20  * daviddiasquit (Ping timeout: 246 seconds)
02:56:07  <Orborde>saghul_: Can you verify the above?
02:56:57  <Orborde>That libuv's TCP read handler callbacks could get called with arbitrarily small slices of incoming data, regardless of the size of the originating write() on the other end of the socket?
02:57:38  * paulfryz_joined
02:58:18  * calvinfoquit (Ping timeout: 240 seconds)
03:01:59  * paulfryz_quit (Ping timeout: 246 seconds)
03:02:18  * bradleymeckquit (Quit: bradleymeck)
03:09:15  * mikolalysenkojoined
03:11:59  <Orborde>Does libuv have a message-oriented transport protocol in it somewhere?
03:12:04  <Orborde>That runs over TCP?
03:13:58  * mikolalysenkoquit (Ping timeout: 240 seconds)
03:30:11  * rmgquit (Remote host closed the connection)
03:41:26  * eugenewarequit (Quit: Connection closed for inactivity)
03:42:17  * kazuponquit (Remote host closed the connection)
03:45:48  * calvinfojoined
03:51:43  * daviddiasjoined
03:51:58  * mikolalysenkojoined
03:54:08  * brsonquit (Ping timeout: 246 seconds)
03:55:30  * calvinfoquit (Quit: Leaving.)
03:55:54  * daviddiasquit (Ping timeout: 240 seconds)
03:56:35  * mikolalysenkoquit (Ping timeout: 246 seconds)
03:58:17  * paulfryz_joined
03:59:20  * brunklejoined
04:00:54  * WalrusPonyquit (Ping timeout: 240 seconds)
04:02:32  * c4milojoined
04:02:51  * paulfryz_quit (Ping timeout: 260 seconds)
04:08:27  * WalrusPonyjoined
04:21:45  * bradleymeckjoined
04:24:34  * seldojoined
04:28:58  * seldoquit (Ping timeout: 240 seconds)
04:31:30  * rmgjoined
04:35:43  * rmgquit (Ping timeout: 240 seconds)
04:53:15  * c4miloquit (Remote host closed the connection)
04:53:45  * c4milojoined
04:54:37  * c4miloquit (Remote host closed the connection)
04:56:25  * calvinfojoined
04:59:09  * paulfryz_joined
05:03:26  * paulfryz_quit (Ping timeout: 246 seconds)
05:07:09  * kazuponjoined
05:11:17  * paulfryzelquit (Remote host closed the connection)
05:13:57  * kenperkinsjoined
05:17:33  * mogillquit (Quit: mogill)
05:24:19  * mikealjoined
05:53:01  * daviddiasjoined
05:57:19  * daviddiasquit (Ping timeout: 240 seconds)
05:59:48  * paulfryzeljoined
06:03:54  * janjongboomjoined
06:03:59  * paulfryzelquit (Ping timeout: 246 seconds)
06:10:10  * AvianFluquit (Ping timeout: 265 seconds)
06:12:20  * paulfryzeljoined
06:13:19  * kazuponquit (Read error: Connection timed out)
06:14:07  * AvianFlujoined
06:14:54  * paulfryzelquit (Read error: No route to host)
06:15:31  * paulfryzeljoined
06:18:19  * kazuponjoined
06:19:44  * paulfryzelquit (Ping timeout: 246 seconds)
06:22:00  * hueniversequit (Quit: Leaving.)
06:22:44  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:31:19  * calvinfoquit (Ping timeout: 240 seconds)
06:31:37  <Dirkson>Say - Why is the suggestion for UDP allocation 64kbs, when the maximum mtu is something closer to 1600 bytes?
06:37:33  * calvinfojoined
06:39:56  * calvinfo1joined
06:39:56  * calvinfoquit (Read error: Connection reset by peer)
06:40:49  * hzjoined
06:54:53  <saghul_>Dirkson: it's just a suggestion ;-)
06:56:48  <Dirkson>saghul_: Right, but... What implodes if I ignore it? :D
06:56:58  <saghul_>Dirkson: nothing!
06:57:05  <Dirkson>saghul_: Great news! ^^
06:57:28  <saghul_>Dirkson: it just lets libuv know how big the buffer is when calling recvmsg
06:58:36  <Dirkson>saghul_: Also, while you're here - I think the way libuv's tcp wrapper is done, I have to assume that the blobs of data I send via tcp may arrive at the other end single, chopped in two, or even clumped together with other data I sent because of Nagle's algorithm. Is that correct?
06:59:10  <Dirkson>I.e. I can't assume that my 500-byte packet will show up on the other end as a single call of the tcp callback.
06:59:31  * seldojoined
07:00:38  * paulfryzeljoined
07:00:39  <saghul_>yeah, I don't think you can assume that
07:00:58  <saghul_>latest kernel even does some "autocork" thing
07:01:04  <Dirkson>Autocork?
07:01:26  <Dirkson>Well, drat. That ups the complexity of the bits I have to code a little. Not too bad - For small packets, I can just make a length-prepended thing without adding much overhead or difficulty.
07:02:16  <saghul_>http://kernelnewbies.org/LinuxChanges#head-0fece6c93790364927fae7c33249ad66ed748d41
07:02:22  <saghul_>checkout section 1.8
07:02:38  <saghul_>yeah
07:03:22  <Dirkson>saghul_: Hunh. I thought that WAS Nagle's algorithm
07:04:07  * seldoquit (Ping timeout: 240 seconds)
07:04:20  <Dirkson>saghul_: https://en.wikipedia.org/wiki/Nagle%27s_algorithm - Compare : )
07:04:28  <saghul_>if you use manual cork-ing, you can tell the kernel: "hey, wait to send these packets until I tell you so"
07:04:53  * paulfryzelquit (Ping timeout: 246 seconds)
07:04:55  <saghul_>now, if the kernel does it automagically I really don't know how it differs from Nagle indeed
07:05:11  <Dirkson>Right?
07:05:28  <saghul_>maybe ot's a dofferent algorithm or something
07:06:11  <Dirkson>Orborde: You were proved right about the tcp thing, but it seems like it's ok to shrink the udp allocater.
07:06:22  <Dirkson>saghul_: Thanks for the info, by the way : )
07:06:38  <saghul_>Dirkson: http://www.spinics.net/lists/netdev/msg260018.html
07:06:58  <saghul_>anytime :-)
07:08:02  <Dirkson>Interesting
07:11:19  * janjongboomjoined
07:16:19  * paulfryzeljoined
07:20:38  * paulfryzelquit (Ping timeout: 240 seconds)
07:20:46  * kazuponquit (Read error: Connection timed out)
07:21:42  * kevinsimperjoined
07:24:04  * calvinfo1quit (Quit: Leaving.)
07:24:45  * hzquit
07:30:18  * kazuponjoined
07:30:58  * sinclair|workjoined
07:32:43  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:38:58  * m76joined
07:40:13  * kazuponquit (Remote host closed the connection)
07:50:21  * janjongboomjoined
07:57:46  * daviddiasjoined
08:01:21  * paulfryzeljoined
08:05:47  * paulfryzelquit (Ping timeout: 246 seconds)
08:06:02  * kazuponjoined
08:12:29  * brunklequit (Quit: brunkle)
08:14:20  * WalrusPonyquit (Read error: Connection reset by peer)
08:14:23  * janjongboomquit (Ping timeout: 250 seconds)
08:15:23  * janjongboomjoined
08:17:00  * paulfryzeljoined
08:21:05  * daviddiasquit (Remote host closed the connection)
08:21:31  * daviddiasjoined
08:21:32  * paulfryzelquit (Ping timeout: 246 seconds)
08:25:44  * daviddiasquit (Ping timeout: 246 seconds)
08:44:04  * daviddiasjoined
08:56:29  <indutny>hey people
08:56:34  <indutny>how are you?
08:59:16  * kazuponquit (Remote host closed the connection)
09:00:18  * janjongboomquit (Ping timeout: 240 seconds)
09:00:53  * kazuponjoined
09:01:05  * eugenewarejoined
09:01:57  * janjongboomjoined
09:02:49  * seldojoined
09:03:14  * stagasjoined
09:03:45  * Kakerajoined
09:07:06  * seldoquit (Ping timeout: 240 seconds)
09:17:55  * paulfryzeljoined
09:19:08  * paulfryzelquit (Read error: No route to host)
09:19:45  * paulfryzeljoined
09:19:48  * daviddia_joined
09:20:35  * daviddiasquit (Read error: No route to host)
09:20:53  * daviddiasjoined
09:23:54  * daviddia_quit (Ping timeout: 240 seconds)
09:23:58  * paulfryzelquit (Ping timeout: 240 seconds)
09:32:38  * kazuponquit (Read error: Connection timed out)
09:33:13  * kazuponjoined
09:45:07  * karupanerurachanged nick to zz_karupanerura
09:45:23  * janjongboomquit (Ping timeout: 250 seconds)
09:46:31  * janjongboomjoined
09:51:15  * rmgjoined
09:55:43  * rmgquit (Ping timeout: 240 seconds)
10:02:51  * paulfryzeljoined
10:04:55  * Kakeraquit (Ping timeout: 240 seconds)
10:05:54  * guybrushquit (Excess Flood)
10:06:10  * guybrushjoined
10:07:14  * paulfryzelquit (Ping timeout: 246 seconds)
10:17:05  * Orbordequit (Quit: WeeChat 0.3.7)
10:20:21  * paulfryzeljoined
10:24:04  <saghul_>aloha
10:24:17  <saghul_>does anyone know if Bert is alive?
10:24:49  * paulfryzelquit (Ping timeout: 250 seconds)
10:25:50  <saghul_>WHERE ART THOU PISCI?
10:25:52  <LOUDBOT>WHICH IS KIND OF MORBID WHEN YOU THINK ABOUT IT.
10:27:02  * bajtosjoined
10:29:55  * AlexisMocha_joined
10:30:53  * AlexisMochaquit (Ping timeout: 264 seconds)
10:31:45  * bajtosquit (Ping timeout: 250 seconds)
10:49:19  * hzjoined
10:57:56  * petka_joined
11:03:42  * paulfryzeljoined
11:03:55  * Orbordejoined
11:08:09  * paulfryzelquit (Ping timeout: 246 seconds)
11:20:48  * daviddiasquit (Remote host closed the connection)
11:21:11  * paulfryzeljoined
11:21:14  * daviddiasjoined
11:22:09  * Tailorjoined
11:22:10  <Tailor>hi
11:22:27  <Tailor>How do I get the HTTP verb within node.native (libuv)? - https://github.com/d5/node.native/issues/37
11:25:19  * daviddiasquit (Ping timeout: 240 seconds)
11:25:30  * paulfryzelquit (Ping timeout: 240 seconds)
11:26:47  <saghul_>Tailor: libuv doesn't implement HTTP
11:26:59  <saghul_>you'll have to ask that to the node.native people
11:32:46  <Tailor>mmm
11:55:41  * Tailorquit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
12:03:02  * mikolalysenkojoined
12:04:24  * paulfryzeljoined
12:04:48  * seldojoined
12:07:22  * euoiajoined
12:08:41  * paulfryzelquit (Ping timeout: 246 seconds)
12:09:41  * seldoquit (Ping timeout: 250 seconds)
12:18:06  * kazuponquit (Remote host closed the connection)
12:18:33  * kazuponjoined
12:21:19  * mikolalysenkoquit (Ping timeout: 240 seconds)
12:21:52  * paulfryzeljoined
12:22:58  * kazuponquit (Ping timeout: 240 seconds)
12:24:17  * mikolalysenkojoined
12:26:07  * paulfryzelquit (Ping timeout: 240 seconds)
12:27:38  * euoiaquit (Ping timeout: 240 seconds)
12:30:12  * bradleymeckquit (Quit: bradleymeck)
12:38:48  * paulfryzeljoined
12:52:52  * daviddiasjoined
12:54:12  * paulfryzelquit (Remote host closed the connection)
12:57:21  * daviddiasquit (Ping timeout: 250 seconds)
13:04:22  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:04:56  * thlorenzjoined
13:05:15  * paulfryzeljoined
13:09:39  * paulfryzelquit (Ping timeout: 240 seconds)
13:18:43  * paulfryzeljoined
13:32:08  * bajtosjoined
13:35:51  * kevinsim_joined
13:35:58  * kevinsimperquit (Read error: Connection reset by peer)
13:36:18  * bajtosquit (Ping timeout: 240 seconds)
13:43:54  * sinclair|workquit (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140314220517])
13:46:31  * mikealquit (Quit: Leaving.)
13:49:13  * kazuponjoined
13:51:54  * trevnorrisquit (Ping timeout: 240 seconds)
13:53:33  * daviddiasjoined
13:53:58  * mikealjoined
13:54:13  * rmgjoined
13:55:13  * trevnorrisjoined
13:58:38  * rmgquit (Ping timeout: 240 seconds)
14:00:05  * bajtosjoined
14:02:30  * daviddiasquit (Remote host closed the connection)
14:02:59  * daviddiasjoined
14:06:02  * paulfryz_joined
14:07:18  * daviddiasquit (Ping timeout: 240 seconds)
14:07:39  * rphillips_quit
14:08:10  * rphillips_joined
14:10:30  * paulfryz_quit (Ping timeout: 246 seconds)
14:21:26  * stagasquit (Read error: Connection reset by peer)
14:26:14  * mikealquit (Quit: Leaving.)
14:27:46  * paulfryzelquit (Remote host closed the connection)
14:32:34  * thlorenzquit (Remote host closed the connection)
14:32:48  * thlorenzjoined
14:39:26  * bradleymeckjoined
15:02:16  * daviddiasjoined
15:07:14  * kevinsim_quit (Remote host closed the connection)
15:09:32  * daviddia_joined
15:11:19  * daviddiasquit (Ping timeout: 240 seconds)
15:11:37  * daviddiasjoined
15:14:38  * daviddia_quit (Ping timeout: 240 seconds)
15:14:57  * daviddiasquit (Client Quit)
15:15:03  * paulfryzeljoined
15:15:23  * bajtosquit (Quit: bajtos)
15:17:56  * mikealjoined
15:22:06  * Domenic___changed nick to Domenic_
15:27:29  * janjongboomjoined
15:31:23  * mikolalysenkoquit (Ping timeout: 240 seconds)
15:31:54  * kevinsimperjoined
15:38:00  * kevinsimperquit (Remote host closed the connection)
15:39:31  * kazuponquit (Remote host closed the connection)
15:39:58  * kazuponjoined
15:43:07  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:44:18  * kazuponquit (Ping timeout: 240 seconds)
15:47:50  * mikolalysenkojoined
15:49:48  * rmgjoined
15:55:22  * mogilljoined
15:59:20  * bajtosjoined
15:59:44  * janjongboomjoined
16:00:18  * Qardjoined
16:03:00  * kevinsimperjoined
16:06:43  * Qard1joined
16:06:55  * Qardquit (Ping timeout: 240 seconds)
16:09:20  <indutny>tjfontaine: hey hey hey
16:11:07  * brunklejoined
16:14:14  <bradleymeck>howdy howdy
16:17:17  * rendarjoined
16:18:33  * calvinfo1joined
16:20:39  * Kakerajoined
16:23:30  <indutny>bradleymeck: hey man
16:23:32  <indutny>bradleymeck: how are you?
16:23:48  <indutny>saghul_: yt?
16:24:19  <bradleymeck>fair, sleepy as per normal. working with a lot of odd web page abstractions at work today
16:24:40  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:25:55  <saghul_>indutny: sup?
16:26:15  <indutny>bradleymeck: interesting
16:26:27  <indutny>bradleymeck: who's your current employer, btw?
16:26:33  <indutny>saghul_: what do you think about ben's patch?
16:26:36  <indutny>I'd like to land it
16:26:43  <indutny>trying to keep backlog small
16:26:45  <bradleymeck>indutny: apple on contract
16:26:45  <saghul_>sure, go ahead
16:26:51  <indutny>bradleymeck: oh, neat
16:26:55  <indutny>saghul_: ok, thanks
16:27:31  <indutny>saghul_: how are you, btw? :)
16:28:04  <saghul_>indutny: good, I wish days had 48h though ;-)
16:28:09  <saghul_>indutny: you?
16:28:15  <indutny>great :)
16:28:22  <indutny>just returned from UAE
16:28:31  <indutny>the weather was much better than at Moscow
16:28:35  <bradleymeck>indutny: all I have to say is, never mix which framework is considered the authority on data
16:28:37  <indutny>but it is still kewl now
16:28:49  <saghul_>nice! never been to UAE myself
16:28:49  <indutny>bradleymeck: ha!
16:28:56  <indutny>saghul_: pretty nice experience
16:29:04  <saghul_>indutny: btw, do you know if Bert still lives?
16:29:11  <indutny>he is
16:29:23  <indutny>I think he is in Philadelphia
16:29:31  <saghul_>aha
16:29:37  <indutny>but his current commitment to libuv is rather questionable
16:29:38  <indutny>:)
16:29:46  <indutny>which is probably obvious for you :)
16:30:17  <saghul_>well, we are all busy from time to time :-)
16:30:34  <indutny>true
16:30:35  <saghul_>I wish I knew more about windows
16:30:42  <indutny>I'll figure out that PR
16:30:51  * brunklequit (Quit: brunkle)
16:30:55  <indutny>you already spent a lot of time on windows things :)
16:30:55  <saghul_>that one I do understand
16:31:00  <saghul_>but others are trickier
16:31:07  <indutny>ah
16:31:08  <indutny>ok
16:31:16  <indutny>I believe you
16:31:42  <saghul_>all are bugfixes, so we can land things later
16:32:01  <bradleymeck>saghul_: do you have a specific windows question?
16:32:03  * m76quit (Read error: Connection reset by peer)
16:32:13  <indutny>btw, that patch LGTM
16:32:15  * brunklejoined
16:32:15  <indutny>if it matters
16:32:32  <saghul_>bradleymeck: not a specific one, some PRs could use some help :-)
16:35:15  <MI6>joyent/libuv: Ben Noordhuis master * 86831fe : linux: reduce file descriptor count of async pipe - http://git.io/uEAbDw
16:37:02  * stagasjoined
16:42:04  <indutny>any node core team people here?
16:42:08  <indutny>tjfontaine: trevnorris : ^
16:42:11  <indutny>sleepies :)
16:43:07  * mikolalysenkoquit (Ping timeout: 250 seconds)
16:43:38  * mikolalysenkojoined
16:46:26  * mcavagejoined
16:50:58  * benvie_quit (Ping timeout: 240 seconds)
16:54:23  * benviejoined
16:57:23  * seldojoined
17:00:22  * paulfryzelquit (Remote host closed the connection)
17:00:51  * seldoquit (Remote host closed the connection)
17:01:06  * seldojoined
17:01:15  * paulfryzeljoined
17:02:55  * mikolalysenkoquit (Ping timeout: 240 seconds)
17:05:38  * paulfryzelquit (Ping timeout: 240 seconds)
17:08:19  * paulfryzeljoined
17:08:49  <bradleymeck>is there a big list of what people want to fix about the debugger in core anywhere?
17:12:48  * thlorenzquit (Remote host closed the connection)
17:17:38  <indutny>bradleymeck: hahaha
17:17:44  <indutny>bradleymeck: I'm trying to accumulate it
17:17:49  <indutny>see RFC email on nodejs mailing list
17:18:03  <indutny>it wasn't set by me, but the guy was interested in working on debugger
17:18:06  <indutny>so I asked him to do it
17:19:16  <bradleymeck>the mailing list… now theres a place I havent been to in a while
17:21:11  <bradleymeck>sounds pretty simple to fix some of those
17:22:23  * dap_joined
17:23:06  * TooTallNatejoined
17:24:39  * TooTallNatequit (Client Quit)
17:25:08  * TooTallNatejoined
17:25:49  * rosskjoined
17:28:36  <bajtos>speaking about the debugger. this is what would help Node Inspector a lot
17:28:48  <bajtos>a `require` function available on the global object
17:29:23  <bajtos>so that you can call V8 debugger command 'evaluate' with `require('/path/to/code/to/inject.js')` and it will inject Node Inspector's stuff into the debugged process
17:29:45  <bradleymeck>bajtos: not sure I understand
17:29:57  <bradleymeck>what would it be relative to
17:30:31  <bajtos>from the perspective of Node Inspector, it can be relative to anything or even nothing (what is the main app file relative to?)
17:30:38  <bradleymeck>bajtos: global.module.require ?
17:30:44  <bajtos>that does not work
17:31:01  <bajtos>it does not work when the process is running
17:31:23  <bajtos>as the global V8 object is different from what you see when you access "global" from within a node.js module
17:31:36  <bradleymeck>ah because v8 is paused I see
17:32:01  <bradleymeck>mmm, there are ways to do this, but injecting code by default in JS is dangerous and hard to undo
17:32:22  <bajtos>I am aware of that
17:32:45  <bajtos>but the same applies to running a debugger against an app, right
17:33:03  <bradleymeck>kind of not exactly
17:33:03  <bajtos>this is what we need it for:
17:33:19  <bajtos>- intercept console.log & friends so that they can be displayed in Node Inspector GUI
17:33:33  <bradleymeck>the debugger does not inject code into the script, it uses the VM to provide hooks
17:33:39  <bajtos>- install v8-profiler module and start/stop CPU profiler and Heap snapshots
17:33:39  * rmg_joined
17:33:50  <bajtos>that's not true
17:34:00  * rmgquit (Read error: Connection reset by peer)
17:34:02  <bajtos>for example Chrome DevTools are injecting a lot of javascript code
17:34:09  <bajtos>to inspect the debugged javascript
17:34:13  <bradleymeck>thats dev tools not the debugger
17:34:28  <bradleymeck>gotta keep the ideas separated
17:34:29  <bajtos>as a workaround for what V8 debugger protocol lacks
17:34:36  * janjongboomjoined
17:34:45  <bajtos>ok, let me put it another way
17:34:50  <bajtos>if you are running a debugger
17:35:02  <bajtos>you can call `evaluate` to run arbitrary code inside your app
17:35:20  <bajtos>that's fully supported by V8 debugger protocol
17:35:32  <bradleymeck>you can cause side effects via that yes
17:36:29  <bajtos>and if you try hard enough, you can eventually get hold of some "require" function
17:36:32  <bajtos>and then you can do whatever you want
17:37:01  <bajtos>but. the part about getting hold of some "require" function turns out to be difficult to implement reliably
17:37:55  <bajtos>so I am asking to make the life of Node Inspector easier, so that it does not have to use hacks to find a require function
17:38:03  <bajtos>but have one that it can use
17:38:27  <bradleymeck>we could provide one but I am unsure why global.module.require doesn’t always exist
17:38:56  <bajtos>yeah, that's difficult to understand, we had a nice argument about that with piscisareus
17:39:08  <bajtos>I don't fully understand it either
17:39:17  <bajtos>if you can install Node Inspector then try this:
17:39:51  <bradleymeck>bajtos: ill take a look at that if you can send me the talk w/ piscisareus as well at bradley.meck ala gmail
17:40:06  <bradleymeck>been digging through the loader code so I am surprised it is not always there
17:40:19  <bajtos>what talk do you mean?
17:40:53  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 2c02c4e : sunos: support IPv6 qualified link-local addresses - http://git.io/fT2w-w
17:40:57  <bradleymeck>the argument w/ pisc about why it does not always exist
17:41:17  <bradleymeck>I can make sure it always exists but want to know wtf reason it shouldn’t would be
17:41:35  * mikealquit (Quit: Leaving.)
17:41:48  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:42:34  <bajtos>we had it over a pint of beer
17:43:09  <bajtos>I'll try to gather as much information as I can and send it to you later today
17:43:10  <bradleymeck>any reason he wanted it not to exist (not reason why it is buggy right now, but why it would be a bad idea)
17:43:28  <bajtos>oh, I don't think we was against that
17:43:54  <bajtos>he was surprised the global object is different when you inspect it via V8 debugger protocol when the app is running
17:44:02  <bajtos>(and it does not contain global.module)
17:44:04  * seldoquit (Remote host closed the connection)
17:44:21  <bradleymeck>that one I can believe
17:45:02  <bajtos>Ben Noordhuis was against making that change on the grounds that it should be easy to find the require function once the debugged app is paused on a breakpoint
17:45:14  * seldojoined
17:45:28  <bajtos>which turned out to be more difficult, as the call stack does not necessarily has to contain a frame with a scope containing require
17:46:22  <bajtos>(in other words, he thought it would be easy to hack Node to find require, therefore it would be better to not add a new API)
17:46:28  * mikealjoined
17:46:37  <indutny>pquerna: hey man
17:46:42  <indutny>seems like you are working on https://github.com/pquerna/selene again
17:46:43  <indutny>:)
17:46:56  <bradleymeck>bajtos: ill look into this, but it is going to need me to look into security concerns
17:47:19  <bradleymeck>would prefer if we could wrap it into a custom message type for the v8 debugger somehow
17:47:28  <rendar>with an udp_t i can use both uv_read() (if i use uv_bind(), i guess?) and also uv_udp_recvfrom() ? (is uv_udp_recvfrom the correct name for that?)
17:48:14  <bajtos>bradleymeck: well, if there was an easy way how to extend V8 debugger, then that would be great
17:48:21  <bradleymeck>hah
17:48:57  <bradleymeck>we can do some voodoo if we use a port and forward messages but would prefer not to use 2 ports to debug
17:49:04  <bajtos>bradleymeck: because at the moment, Node Inspector has to open another TCP connection from the debugged process to the Node Inspector backend to send back data
17:49:39  <bradleymeck>yea
17:49:40  <bajtos>bradleymeck: yes, it's better to avoid message forwarding
17:49:58  * benviequit (Ping timeout: 240 seconds)
17:50:02  <bajtos>bradleymeck: ok. I'll figure out what's the best way of reproducing the problem and send you an e-mail
17:50:18  <bajtos>thank you for being cooperative.
17:50:19  * c4milojoined
17:51:02  * c4miloquit (Read error: Connection reset by peer)
17:53:12  <bradleymeck>bajtos: I’m thinking its possible with messagehandlers, but don’t have time to test
17:53:38  <bradleymeck>anytime you need random info feel free to ask
17:53:38  <pquerna>indutny: i dunno. its a.. deep project. and i was just enjoying coding go.
17:53:43  <pquerna>indutny: i'm forgetting ; all over.
17:55:03  <indutny>:)
17:55:14  <indutny>pquerna: I'm actually working on similar thing
17:55:27  <indutny>though, haven't even finished a handshake protocol support yet
17:55:38  <indutny>I'm totally busted at designing proper API for it
17:56:41  <indutny>I guess that the whole implementation should be a state machine
17:56:44  <indutny>with many small states
17:56:54  <indutny>and ability to add async hooks on transitions between them
17:56:59  <indutny>pquerna: is it what you do in selene?
17:57:38  <indutny>yeah
17:57:40  <indutny>seems like so
17:58:06  <indutny>damn, your API looks really good
18:01:13  * m76joined
18:02:31  * seldoquit (Remote host closed the connection)
18:03:45  * seldojoined
18:04:39  * seldoquit (Remote host closed the connection)
18:04:57  * thlorenzjoined
18:04:58  * seldojoined
18:06:10  <pquerna>indutny: yup, thats the idea with the api design in selene
18:06:19  <indutny>kewl
18:06:20  <pquerna>indutny: happy to review any api deisgns for it
18:06:36  <indutny>no, I kind of like it
18:06:45  <indutny>especially the `baton` thing
18:06:56  <pquerna>also would love to interate on selene api once i could get it hooked into a real webserver
18:06:58  <indutny>is it a your idea, or have you learned it from anywhere?
18:07:00  <pquerna>i'm sure its not awsome
18:07:04  <pquerna>having to hook it everywhere
18:07:11  * janjongboomjoined
18:07:17  <pquerna>'baton'? is just a term.... i dunno, apache uses it, subversion uses it
18:07:22  * brunklequit (Quit: brunkle)
18:07:22  <indutny>ok
18:07:25  <indutny>I meant the actual pointer
18:07:32  <rch>i kind of don't like the baton
18:07:50  <indutny>rch: good to know :)
18:08:06  <rch>;p heh
18:08:16  <indutny>pquerna: so, what really bothers me is a data IO api
18:08:25  <indutny>it seems like a streams1 in node.js
18:08:34  <indutny>but on other hand
18:08:44  <pquerna>heh
18:08:50  <indutny>it should minimize amount of allocations
18:08:53  * doypart ("WeeChat 0.4.3")
18:09:00  <pquerna>i mean, i prob wrote the header file when talking to people about streams in node
18:09:06  <indutny>haha
18:09:11  <pquerna>but yeah, it needs to be performance... sensitive in the end
18:09:19  <indutny>yeah, indeed
18:09:26  <indutny>that's where callbacks rocks, actually
18:09:34  <indutny>you don't need to buffer anything
18:09:44  <pquerna>yup, if you can avoid it.
18:09:56  <pquerna>i was thinking about adding a thing like how libuv makes you give it buffers
18:10:04  <pquerna>but wanted to get a working thing before getting too far
18:10:18  <pquerna>i think those apis can mutate without too much changes in the core
18:10:38  <indutny>yeah
18:10:42  <indutny>should not be important
18:10:49  <indutny>are you using openssl only for encryption?
18:10:53  <indutny>or for parsing/framing too?
18:11:00  <pquerna>just encrytion
18:11:17  <indutny>great
18:11:17  <pquerna>and some x509 utils, but would like to kill that if i had time or found an alternative
18:11:31  <indutny>heh
18:11:48  <pquerna>ideally it could run on osx using commoncrypto
18:11:50  <pquerna>for example
18:11:56  <indutny>yeah, engine should not matter
18:12:04  <indutny>its just a cryptography after all
18:12:08  <pquerna>right :)
18:12:18  <indutny>https://github.com/indutny/tls.js
18:12:26  <indutny>that's what I am up to right now
18:12:29  <pquerna>see the thing is
18:12:32  <pquerna>C ABIs matter
18:12:35  <indutny>though, I haven't even started working on the API
18:12:51  <indutny>pquerna: you have configuration struct, right?
18:12:57  <pquerna>i was talking with other channel earlier today, what if you did something crazy like still exposed a C ABI, still used zero copy buffers everywhere
18:13:04  <pquerna>but internally it was all luajit.
18:13:08  <indutny>hahaha
18:13:08  <pquerna>just a thought experiment
18:13:12  <pquerna>it would be neat though.
18:13:16  <indutny>interesting
18:13:21  <tjfontaine>hi, just got back to sf after meeting with isaacs for a bit :)
18:13:42  <bradleymeck>wb
18:13:46  <pquerna>indutny: https://github.com/pquerna/selene/blob/master/include/selene_conf.h
18:13:59  <pquerna>indutny: selene_conf_use_reasonable_defaults()
18:14:04  <pquerna>indutny: is the important bit
18:14:13  <indutny>tjfontaine: hey man
18:14:19  <indutny>tjfontaine: let's land PRs and do v0.11
18:14:34  <tjfontaine>well I think we need to do 0.10 first actually
18:14:40  <tjfontaine>other channel for a moment
18:16:07  * AlexisMocha_quit (Ping timeout: 240 seconds)
18:17:47  * paulfryzelquit (Remote host closed the connection)
18:18:28  * paulfryzeljoined
18:21:41  * paulfryz_joined
18:22:18  * paulfryzelquit (Ping timeout: 240 seconds)
18:22:29  * paulfryz_quit (Remote host closed the connection)
18:23:07  * paulfryzeljoined
18:26:03  * mikealquit (Quit: Leaving.)
18:26:39  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:27:23  * paulfryzelquit (Ping timeout: 246 seconds)
18:34:43  * kenperkinsquit (Remote host closed the connection)
18:35:22  * kenperkinsjoined
18:42:01  * benviejoined
18:44:52  * bajtosquit (Quit: bajtos)
18:52:04  * brunklejoined
18:53:01  * m76quit (Read error: Connection reset by peer)
18:55:18  * kenperkinsquit (Read error: Connection reset by peer)
18:55:47  * kenperkinsjoined
18:56:23  * paulfryzeljoined
18:58:34  * brunklequit (Quit: brunkle)
19:04:08  * mikealjoined
19:07:18  * brsonjoined
19:11:33  * c4milojoined
19:19:18  * rutejoined
19:20:27  * rutepart ("Leaving")
19:23:41  * c4milo_joined
19:24:45  * c4miloquit (Ping timeout: 250 seconds)
19:36:03  * kevinsimperquit (Remote host closed the connection)
19:37:52  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:39:52  * janjongboomjoined
19:41:21  * janjongboomquit (Client Quit)
19:43:43  * calvinfo1quit (Ping timeout: 240 seconds)
19:55:39  * mcavagequit
19:59:57  * WalrusPonyjoined
20:00:51  * bradleymeck_joined
20:08:03  * paulfryzelquit (Read error: Connection reset by peer)
20:08:24  * paulfryzeljoined
20:12:46  * TooTallNatejoined
20:15:22  * kevinsimperjoined
20:23:21  * Sonderbladejoined
20:38:59  * seldo_joined
20:39:20  * janjongboomjoined
20:41:53  * seldoquit (Ping timeout: 250 seconds)
20:43:05  <indutny>trevnorris: hey
20:43:06  <indutny>yt?
20:44:11  * bradleymeckquit (Quit: bradleymeck)
20:44:11  * bradleymeck_changed nick to bradleymeck
20:46:19  * thlorenzquit (Remote host closed the connection)
20:48:31  * bradleymeckquit (Quit: bradleymeck)
20:55:30  <indutny>wtf
20:55:32  <indutny>where are everyone
20:55:40  <tjfontaine>hi
21:05:10  * mikolalysenkojoined
21:20:19  * Sonderbladequit (Quit: L�mnar)
21:24:45  * c4milo_quit (Remote host closed the connection)
21:25:46  * mikealquit (Quit: Leaving.)
21:29:27  * inolenquit (Quit: Leaving.)
21:29:41  * inolenjoined
21:43:18  * brunklejoined
21:44:06  * rendarquit
21:51:41  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:53:22  * kevinsimperquit (Remote host closed the connection)
21:56:29  * mikealjoined
21:57:18  * euoiajoined
21:58:00  * WalrusPony1joined
21:59:53  * WalrusPonyquit (Ping timeout: 250 seconds)
22:02:26  * brunklequit (Quit: brunkle)
22:04:55  * mikealquit (Ping timeout: 240 seconds)
22:06:59  * thlorenzjoined
22:07:37  * thlorenzquit (Remote host closed the connection)
22:19:43  * paulfryzelquit (Read error: Connection reset by peer)
22:20:15  * paulfryzeljoined
22:22:48  * thlorenzjoined
22:24:13  * kevinsimperjoined
22:27:36  * paulfryzelquit (Remote host closed the connection)
22:28:14  * paulfryzeljoined
22:30:57  * mitsuhikoquit (Quit: ZNC - http://znc.sourceforge.net)
22:31:08  * thlorenzquit (Ping timeout: 252 seconds)
22:32:31  * paulfryzelquit (Ping timeout: 240 seconds)
22:33:06  * mitsuhikojoined
22:35:17  * mitsuhikoquit (Client Quit)
22:35:53  * thlorenzjoined
22:36:58  * tylerflintjoined
22:39:06  * hzquit
22:39:30  * Kakeraquit (Ping timeout: 240 seconds)
22:45:10  * brunklejoined
22:46:35  * mitsuhikojoined
22:54:22  * thlorenzquit (Remote host closed the connection)
22:57:08  * kevinsimperquit (Remote host closed the connection)
23:02:51  <trevnorris>indutny: sup. was up late last night.
23:10:04  * seldo_quit (Remote host closed the connection)
23:11:03  * seldojoined
23:13:42  * c4milojoined
23:14:40  <tylerflint>running into an issue with libuv: https://gist.github.com/notxarb/b06508bf606d2a46cae1
23:14:55  <tylerflint>it is possible I'm using the library incorrectly
23:15:20  <tylerflint>essentially I'm just trying to create a tcp client that will attempt to re-connect after a failed attempt
23:15:30  <tylerflint>after the first failed attempt, the process hangs
23:15:49  <tylerflint>using mbd, I'm able to see that libuv is stuck on _portfs
23:16:53  <tylerflint>the gist ^ is an extraction of the actually project, but with just enough to reproduce the failure
23:18:36  * c4miloquit (Ping timeout: 252 seconds)
23:21:36  <saghul_>tylerflint: are you reusing the tcp handle?
23:22:41  <saghul_>apparently yes.
23:22:57  <saghul_>you cannot do that, you need to create a new tcp handle every time you attempt to connet
23:23:05  <tjfontaine>ya he is
23:23:14  <tylerflint>saghul_: I am, yes. Each time I attempt to re-connect I use uv_tcp_init
23:23:42  <saghul_>you need to uv_close the previous one and create a new one
23:24:05  <saghul_>they are not reusable
23:24:11  * seldoquit (Remote host closed the connection)
23:24:31  <tylerflint>oh ok, so if it fails to connect, I still need to do uv_close?
23:24:39  <saghul_>yes
23:25:08  <saghul_>you always need to uv_close, and then in the cb you can free memory or whatever
23:25:21  <saghul_>libuv keeps track of its handles, until uv_close has finished
23:25:51  <tylerflint>if I'm not mallocing my handle, do I need to nullify or zero out the previous before calling tcp_init again?
23:26:29  <tylerflint>or does it matter at that point
23:27:00  <tylerflint>ok I see, you're saying the reason I need to uv_close is so that libuv doesn't track it anymore
23:27:07  <saghul_>exactly
23:30:36  * seldojoined
23:33:47  <tylerflint>saghul_: thanks, that did the trick
23:33:48  <tylerflint>awesome
23:39:43  * tylerflintquit (Ping timeout: 240 seconds)
23:47:21  * AlexisMochajoined
23:49:14  * brunklequit (Ping timeout: 252 seconds)
23:51:37  * stagasquit (Read error: Connection reset by peer)