00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:30  * AvianFluquit (Remote host closed the connection)
00:12:07  * c4milojoined
00:16:38  * c4miloquit (Ping timeout: 252 seconds)
00:21:07  * dsantiag_changed nick to dsantiago
00:36:46  <Ralith>txdv: the uv.h comments claim that if your buffer is too small, the rest of the message is permanently lost
00:36:50  <Ralith>so that's not useful either
00:43:13  * indexzerojoined
00:43:13  * indexzeroquit (Client Quit)
00:45:44  * thlorenzquit (Remote host closed the connection)
01:19:46  * kazuponjoined
01:32:47  * mikealquit (Quit: Leaving.)
01:33:39  <felicity>Ralith: what's the problem?
01:34:26  <felicity>oh, i see, read scrollback
01:34:44  <felicity>yes, the github.io book is old and describes 0.10, 0.11 is quite different in some places
01:35:48  <Ralith>felicity: are the changes discussed/summarized anywhere? Also, what's the point of the UDP behavior we were discussing?
01:36:38  <felicity>Ralith: the second read with zero nread sounds like a bug to me, but i'll investigate a bit further.
01:36:56  <Ralith>thanks!
01:37:04  <felicity>Ralith: the recv code attempts to allocate a 64KB buffer, the maximum size of a UDP packet, so as long as your uv_alloc honours that request, you will receive the entire buffer
01:37:22  <Ralith>that was my suspicion; great
01:39:22  <felicity>okay, i think i see the reason
01:40:42  <felicity>libuv attempts to recv udp packets from the socket forever (*) until there's no more data. but it has to allocate a buffer to recv into before it can do the recv. so if there's only one packet pending, it receives one, calls your callback, allocates another buffer, tries to recv another, and sees there is no packet: so now it has to call the callback with nread==0 so you can free the buffer it was planning to read into.
01:40:52  <felicity>(*) actually it only reads 32 packets at once
01:41:38  <felicity>so it's somewhat inefficient to continuously allocate then free 64KB buffers, but given the limitations of libuv's current API, that's the only way it can work
01:41:49  <felicity>(I suppose a better way would be to cache the unused buffer and use it next time)
01:42:38  <felicity>(hmm... does FIONREAD work on SOCK_DGRAM sockets...?)
01:43:51  <Ralith>ah, that makes sense, thanks
01:44:55  <felicity>the good news is that when you have about efficiency (during high-traffic periods), there will be several packets in the buffer so it won't do the nread==0 every time. but, still, this seems like a trivial optimisation, perhaps i'll have a fiddle with it.
01:45:09  <felicity>s/have about/care about/
01:46:20  <oremore>http://www.reddit.com/r/TwoXChromosomes/comments/1twjbi/censorship_in_schools/
01:46:25  <oremore>What do you guys think of this?
01:46:39  <felicity>oremore: in general i think it's off-topic for this channel?
01:47:01  <Ralith>felicity: it's less bothersome now that I understand that it's not completely pointless, but a caching or FIONREAD solution would be pretty neat regardless.
01:47:20  <Ralith>(I'm actually using a static buffer, which is why that explanation didn't occur to me)
01:53:03  * kazuponquit (Ping timeout: 245 seconds)
02:00:24  * c4milojoined
02:05:01  * c4miloquit (Ping timeout: 246 seconds)
02:16:02  <felicity>Ralith: https://github.com/joyent/libuv/pull/1063
02:16:15  <felicity>unfortunately avoiding the nread==0 is more difficult than i thought
02:20:57  * thlorenzjoined
02:21:32  <Ralith>felicity: hm, do you actually need to allocate a buffer if the packet is of size zero?
02:22:17  <felicity>hmm, indeed there's no way for the libuv user to actually tell the difference, as nread==0 means nothing was read
02:22:31  <felicity>so in the zero case we can read and then discard the packet, avoiding the allocation
02:22:35  <Ralith>yeah
02:23:25  <Ralith>if you *do* read a zero-length packet the callback should still be invoked with nread=0, of course, but under no other circumstances.
02:24:06  <felicity>i'm not actually sure there's any point in doing that. with the current api you can't know that a zero-length packet was received
02:24:38  <Ralith>wouldn't these changes confer that capability
02:24:41  <Ralith>?
02:24:42  <felicity>(hmm: http://www.openssl.org/ ...)
02:24:49  <Ralith>hahaha
02:25:32  <felicity>Ralith: no, it would need an API change
02:25:46  <Ralith>why is that?
02:25:47  <felicity>the best we can do here is avoid worthless allocations
02:26:08  <felicity>Ralith: because the only way to indicate a zero-length packet is returning nread==0, but that already means 'no packet was received'
02:27:36  <Ralith>under what circumstances is that used? I thought the callback was only invoked on packet receipt. Or do you just mean it'd be a change in the semantics?
02:28:13  <felicity>Ralith: well, in general it's used in any case where libuv allocates a buffer then decides it doesn't need it, so it returns it to user to free it. it can't just call free() because it doesn't know how it was allocated to begin with
02:29:04  <felicity>perhaps that would be better as an error return (nread == UV_EIDONTACTUALLYNEEDTHISBUFFER) but that would alter the API
02:29:10  <Ralith>right. So the problem is that it would violate consistency with other similar callbacks?
02:29:48  <Ralith>oh, right
02:29:56  <Ralith>okay, that makes sense
02:30:20  <felicity>right now there's no way to receive a zero-length datagram at all with libuv
02:30:32  <felicity>so that needs to be fixed before anything else :)
02:30:37  <Ralith>I don't expect to ever need a 0-length datagram, so I'm happy just to see the unnecessary alloc go away, then.
02:31:03  <felicity>but i agree that we can optimise the FIONREAD==0 case by reading into a null buffer and returning nread==0, as we don't lose any functionality (you already can't ready a zero-length datagram, so...)
02:31:20  <felicity>s/ready/receive/
02:31:44  <felicity>hmm, Assertion failed: (handle->flags & UV_CLOSING), function uv__finish_close, file ../uv/src/core.c, line 168.
02:31:52  <felicity>wonder if that's my fault or a 0.11 bug
02:38:34  <felicity>Ralith: https://github.com/rtarnell/libuv/commit/8f8e43994c7e80e2e910a2e86c3a7195bd1eb1af
02:40:03  <Ralith>awesome, thanks!
02:44:05  <felicity>well, don't thank me yet, it still has to be accepted ;)
02:49:46  * kazuponjoined
02:59:34  * c4milojoined
03:02:33  * c4miloquit (Remote host closed the connection)
03:14:10  <Ralith>felicity: y'still wrote the code; I can thank the reviewer independently :p
03:16:31  * c4milojoined
03:23:53  * kazuponquit (Ping timeout: 272 seconds)
03:40:43  * inolenquit (Quit: Leaving.)
04:19:54  * kazuponjoined
04:24:29  * kazuponquit (Ping timeout: 246 seconds)
04:26:54  * abraxasjoined
04:31:29  * abraxasquit (Ping timeout: 246 seconds)
04:48:58  * brsonquit (Ping timeout: 241 seconds)
05:09:00  * inolenjoined
05:20:56  * kazuponjoined
05:25:33  * kazuponquit (Ping timeout: 252 seconds)
05:43:44  * defunctzombiechanged nick to defunctzombie_zz
05:50:45  * thlorenzquit (Remote host closed the connection)
05:51:18  * thlorenzjoined
05:55:33  * thlorenzquit (Ping timeout: 245 seconds)
05:58:53  * indexzerojoined
06:06:23  * m76joined
06:21:50  * kazuponjoined
06:28:27  * kazuponquit (Ping timeout: 272 seconds)
07:24:28  * kazuponjoined
07:28:12  * c4miloquit (Remote host closed the connection)
07:57:38  * kazuponquit (Ping timeout: 245 seconds)
07:58:42  * rendarjoined
08:02:49  * mikealjoined
08:08:07  * c4milojoined
08:12:41  * c4miloquit (Ping timeout: 246 seconds)
08:28:48  * abraxasjoined
08:32:59  * abraxasquit (Ping timeout: 246 seconds)
08:34:16  * kazuponjoined
08:40:17  * kazuponquit (Remote host closed the connection)
09:07:09  * inolenquit (Quit: Leaving.)
09:36:34  * hzjoined
09:41:01  * kazuponjoined
09:47:03  * kazuponquit (Ping timeout: 240 seconds)
09:50:07  <rendar>there is an enum for uv_status_t statuses somewhere?
09:50:12  <rendar>uv_stream_t* sorry
09:52:24  <Ralith>negations of uv_errno_t and '0' are some of them
09:53:08  <rendar>Ralith: i meant if there is something like UV_STREAM_STATUS_OPEN, etc
09:54:22  <Ralith>?
09:56:15  * c4milojoined
10:01:15  * c4miloquit (Ping timeout: 272 seconds)
10:29:35  * abraxasjoined
10:33:55  * abraxasquit (Ping timeout: 252 seconds)
10:41:08  <Ralith>is 0.11 adding a way to get error message strings from a failed IO operation?
10:43:34  * kazuponjoined
10:48:26  * kazuponquit (Ping timeout: 246 seconds)
11:24:13  * bajtosjoined
11:34:28  * kazuponjoined
11:40:33  * kazuponquit (Ping timeout: 245 seconds)
11:44:35  * c4milojoined
11:47:44  * m76quit (Read error: Connection reset by peer)
11:49:33  * c4miloquit (Ping timeout: 272 seconds)
11:52:03  * skypjackjoined
12:00:14  * bajtosquit (Quit: bajtos)
12:07:44  * indexzeroquit (Quit: indexzero)
12:14:14  <M28>getting "Broken pipe" when trying to write a message to a tcp socket... wat
12:24:37  <M28>oh
12:30:33  * abraxasjoined
12:35:47  * abraxasquit (Ping timeout: 272 seconds)
12:36:57  * kazuponjoined
13:05:05  * daviddiasjoined
13:10:22  * kazuponquit (Ping timeout: 246 seconds)
13:15:54  * m76joined
13:32:51  * c4milojoined
13:37:39  * c4miloquit (Ping timeout: 260 seconds)
13:46:24  * janjongboomjoined
13:53:46  <txdv>felicity: is it possible to send an udp message without data length = 0?
13:55:48  <txdv>Ralith: uv_strerror uv_err_name?
14:04:15  * AndreasMadsenjoined
14:06:58  * kazuponjoined
14:11:48  * kazuponquit (Ping timeout: 245 seconds)
14:21:52  <felicity>txdv: i've never actually had a need to do it (oddly though ;) but at a guess send(fd, NULL, 0) should work.
14:27:52  * kellabytequit (Quit: Quit)
14:40:39  <txdv>but the read callback will still get called
14:40:39  <txdv>right?
14:45:30  * defunctzombie_zzchanged nick to defunctzombie
14:47:46  <txdv>the read callback
14:47:50  <txdv>an event will be triggered
15:05:07  * kellabytejoined
15:07:45  <felicity>yes, but since nread==0 it won't know a packet was actually read
15:08:00  * kazuponjoined
15:12:35  * kazuponquit (Ping timeout: 252 seconds)
15:21:27  * c4milojoined
15:25:22  * AvianFlujoined
15:26:18  * SquirrelCZECH_joined
15:28:47  * CAPSLOCKBOT_joined
15:32:14  * creationix_joined
15:33:24  * c4miloquit (*.net *.split)
15:33:24  * kellabytequit (*.net *.split)
15:33:24  * CAPSLOCKBOTquit (*.net *.split)
15:33:25  * creationixquit (*.net *.split)
15:33:25  * rchquit (*.net *.split)
15:33:25  * SquirrelCZECHquit (*.net *.split)
15:33:44  * creationix_changed nick to creationix
15:34:07  * kellabytejoined
15:38:04  * AndreasMadsenquit (Remote host closed the connection)
15:38:58  * AndreasMadsenjoined
16:00:15  * AlexisMochaquit (Ping timeout: 240 seconds)
16:08:57  * kazuponjoined
16:09:18  * AvianFluquit (Remote host closed the connection)
16:10:56  * mikealquit (Quit: Leaving.)
16:15:00  * kazuponquit (Ping timeout: 245 seconds)
16:18:58  * inolenjoined
16:21:27  * kellabytequit (Changing host)
16:21:27  * kellabytejoined
16:21:27  * kellabytequit (Changing host)
16:21:27  * kellabytejoined
16:32:16  * abraxasjoined
16:32:45  * inolenquit (Quit: Leaving.)
16:36:55  * abraxasquit (Ping timeout: 252 seconds)
16:44:14  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:09:39  * c4milojoined
17:11:36  * kazuponjoined
17:13:25  * swajquit (*.net *.split)
17:14:18  * c4miloquit (Ping timeout: 245 seconds)
17:15:48  * swajjoined
17:20:45  * thlorenzjoined
17:25:07  * rchjoined
17:31:18  * AndreasMadsenquit (Remote host closed the connection)
17:45:07  * kazuponquit (Ping timeout: 252 seconds)
17:54:09  * rmgjoined
17:54:21  * inolenjoined
17:56:50  * AvianFlujoined
18:02:04  * AndreasMadsenjoined
18:08:47  * AndreasMadsenquit (Ping timeout: 260 seconds)
18:08:48  * AvianFluquit (Remote host closed the connection)
18:11:55  * toothrchanged nick to toothrot
18:12:33  * rmgquit (Remote host closed the connection)
18:25:27  * AndreasMadsenjoined
18:38:37  * kazuponjoined
19:03:40  * AlexisMochajoined
19:06:07  * piscisaureusjoined
19:12:14  * kazuponquit (Ping timeout: 265 seconds)
19:12:44  * AvianFlujoined
19:19:46  * skypjackquit (Quit: Sto andando via)
19:22:06  * inolenquit (Quit: Leaving.)
19:36:04  * AndreasMadsenquit (Remote host closed the connection)
19:56:01  * thlorenzquit (Remote host closed the connection)
20:08:34  * kazuponjoined
20:28:17  * mikealjoined
20:28:58  * mikealquit (Client Quit)
20:34:17  * AndreasMadsenjoined
20:35:59  * AndreasMadsenquit (Remote host closed the connection)
20:36:17  * AndreasMadsenjoined
20:41:48  * kazuponquit (Ping timeout: 245 seconds)
20:52:38  * rchquit (Ping timeout: 240 seconds)
20:56:51  * mikealjoined
20:57:45  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:06:45  * mikealquit (Quit: Leaving.)
21:07:15  * mikealjoined
21:08:39  * thlorenzjoined
21:12:09  * mikealquit (Quit: Leaving.)
21:14:37  * mikealjoined
21:20:08  * AndreasMadsenquit (Remote host closed the connection)
21:29:37  * AndreasMadsenjoined
21:34:38  * mikealquit (Quit: Leaving.)
21:38:35  * kazuponjoined
22:09:18  * rmgjoined
22:12:29  * kazuponquit (Ping timeout: 272 seconds)
22:13:40  * rmgquit (Ping timeout: 245 seconds)
22:14:15  * AndreasMadsenquit
22:43:22  * hzquit
22:52:08  * rchjoined
22:59:07  * janjongboomjoined
23:08:36  * kazuponjoined
23:13:17  * kazuponquit (Ping timeout: 252 seconds)
23:13:49  * rendarquit
23:19:48  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:28:32  * inolenjoined
23:38:17  * m76quit (Read error: Connection reset by peer)
23:39:17  * kenperkinsquit (Quit: Computer has gone to sleep.)
23:40:19  * kenperkinsjoined
23:43:26  * calvinfojoined
23:51:40  * inolenquit (Quit: Leaving.)
23:53:02  * daviddiasquit (Ping timeout: 240 seconds)
23:53:17  * inolenjoined