00:18:44  <ryah>igorzi: punt for now i'd say - but let's think about how we could do allocs
02:13:41  * brsonquit (Quit: leaving)
03:55:25  * bnoordhuisquit (Ping timeout: 240 seconds)
04:28:33  * bentkusquit (Read error: Operation timed out)
04:36:08  * bentkusjoined
08:05:54  * mralephjoined
17:41:52  <pquerna>hrm, pulled in openssl eh
17:43:00  <pquerna>ah, has all the goog-feature patches in it, neat.
17:49:31  * bnoordhuisjoined
18:39:02  <bnoordhuis>ryah: any luck troubleshooting npm?
19:24:09  * piscisaureusjoined
19:24:35  <bnoordhuis>piscisaureus: heya homie
19:33:29  <piscisaureus>heya bnoordhuis
19:34:17  <bnoordhuis>piscisaureus: olla
19:34:27  <bnoordhuis>how was the gf?
19:34:37  <bnoordhuis>('willing')
19:35:23  <piscisaureus>"the gf"
19:35:27  <piscisaureus>we had fun
19:35:40  <piscisaureus>how was the wief?
19:35:51  <bnoordhuis>good, i had fun
19:35:58  <piscisaureus>and you gf?
19:36:03  <piscisaureus>*your
19:36:30  <bnoordhuis>she too :)
19:36:44  <DrPizza>man
19:36:51  <DrPizza>I am just a barrel of horniness right now
19:37:04  <bnoordhuis>yeah, that's what she said
19:37:19  <DrPizza>heh
19:37:19  <piscisaureus>Yeah I remember
19:38:40  <bnoordhuis>piscisaureus: but anyway, how is udp coming along?
19:39:08  <piscisaureus>bnoordhuis: didn't do anything since last friday
19:39:17  <piscisaureus>(you saw my branch?)
19:39:25  <piscisaureus>did you finish / land the unix part?
19:39:33  <bnoordhuis>piscisaureus: finish, yes. land, no
19:40:15  <bnoordhuis>i saw your branch btw
19:40:19  <bnoordhuis>right before i lost eye sight
19:40:49  <bnoordhuis>i don't know how ms does it
19:40:55  <bnoordhuis>even h.p. lovecraft couldn't have dreamt up the windows api
19:41:37  <piscisaureus>bnoordhuis: you rebased your udp branch?
19:42:31  <bnoordhuis>piscisaureus: against master, not yet against your branch
19:42:37  <bnoordhuis>didn't have a proper setup to test it on
19:42:48  <piscisaureus>bnoordhuis: you should not rebase against my branch
19:43:05  <piscisaureus>bnoordhuis: but now you have
19:43:05  <piscisaureus>d172caa WIP
19:43:05  <piscisaureus>30920c8 UDP doc comments
19:43:05  <piscisaureus>913b885 Add IPv6 bind test.
19:43:12  <piscisaureus>WIP -> you are going to rebase more?
19:43:24  <bnoordhuis>maybe
19:43:41  <bnoordhuis>i'm going to squash it into one or two commits eventually
19:44:01  <piscisaureus>ok
19:44:08  <piscisaureus>I am going to land the landable parts already
19:44:47  <bnoordhuis>rebase against my branch first
19:45:00  <piscisaureus>bnoordhuis: I am not landing any of your commits
19:45:21  <bnoordhuis>so what are you going to land?
19:46:33  <bnoordhuis>piscisaureus: ^
19:48:55  <CIA-75>libuv: Bert Belder master * r062af9f / src/win/tcp.c : win: fix buffer leak when using non-zero tcp reads (+5 more commits...) - http://git.io/MMTppw
19:49:05  <piscisaureus>bnoordhuis: ^-- that
19:49:50  <bnoordhuis>'Remove trailing whitespace' <- i like commits like that best
19:50:03  <piscisaureus>bnoordhuis: sorry about that
19:50:10  <piscisaureus>trailing whitespace annoys me
19:50:18  <piscisaureus>because git bitches me about it when I rebase
19:50:28  <bnoordhuis>--whitespace=fix
19:50:49  <piscisaureus>bnoordhuis: yeah but that only works if *I* put the trailing whitespace in there
19:52:14  <bnoordhuis>piscisaureus: no, you can have git auto-fix it with `git rebase --whitespace=fix origin/master`
19:53:01  <piscisaureus>yeah I know
19:53:01  <DrPizza>WIP should be banned as a commit message.
19:54:22  <bnoordhuis>DrPizza: won't help, i'd just switch to '.'
19:54:40  <DrPizza>doh.
20:01:32  <DrPizza>Maybe commit messages should use robot9000 logic.
20:02:30  <piscisaureus>We should sell ads in our commit messages
20:08:58  <bnoordhuis>i already hide subliminal messages in them
20:13:04  <piscisaureus>We could have targeted job ads in the commit messages
20:14:46  <piscisaureus>This is one if the ideas that you shouldn't share because other people may think it's a good idea
20:17:38  <DrPizza>I wonder if I can get paid to be a stalker
20:17:49  <piscisaureus>a stalker?
20:18:16  <DrPizza>yes
20:19:02  <DrPizza>not the creepy weirdo kind
20:19:03  <piscisaureus>who are you going to stalk, and for what?
20:19:23  <DrPizza>but one in a kind of romantic charming hollywood rom com sort of a vein
20:19:54  <piscisaureus>but why would anyone pay you for that?
20:19:58  <DrPizza>I don't know
20:20:02  <DrPizza>it seems unlikely, I admit
20:20:16  <piscisaureus>in that case, i think it's unlikel
20:20:17  <piscisaureus>y
20:20:48  <DrPizza>but man oh man
20:20:54  <piscisaureus>maybe someone will pay you for littering
20:20:54  <piscisaureus>maybe someone will pay you for child abuse
20:20:54  <piscisaureus>maybe someone will pay you for moonwalking
20:21:02  <DrPizza>lol
20:21:06  <DrPizza>I think he's dead
20:21:16  <DrPizza>one of the actresses in a film I was watching ticks all my boxes
20:21:25  <DrPizza>well, as much as you can tell from seeing someone in one film
20:23:18  <piscisaureus>http://www.flickr.com/photos/skyflash/76054061/lightbox/
20:23:57  <DrPizza>lol
20:24:02  <DrPizza>about right
20:54:54  * brsonjoined
21:07:34  <piscisaureus>bnoordhuis: hey
21:08:17  <bnoordhuis>piscisaureus: ho
21:08:46  <piscisaureus>bnoordhuis: you have EOF for udp?
21:09:18  <bnoordhuis>piscisaureus: obviously not
21:10:30  <piscisaureus>the tests you created seem to suggest otherwise
21:10:43  <piscisaureus>ASSERT(cl_send_cb_called == 1);
21:10:43  <piscisaureus> ASSERT(cl_recv_cb_called == 2); /* dgram + EOF == 2 */
21:10:43  <piscisaureus> ASSERT(sv_send_cb_called == 1);
21:10:43  <piscisaureus> ASSERT(sv_recv_cb_called == 1); /* dgram, no EOF == 1 */
21:10:51  <bnoordhuis>oh right
21:10:56  <bnoordhuis>that's not eof as such
21:11:19  <bnoordhuis>the callback gets called twice, normally, once with the datagram, once to return the buffer
21:12:05  <piscisaureus>confusing
21:12:12  <bnoordhuis>i'll update the comment tomorrow
21:33:55  <piscisaureus>bnoordhuis: test_udp_send_and_recv relies on implementation details
21:33:56  <piscisaureus>--
21:34:11  <bnoordhuis>bnoordhuis: go on
21:34:30  <piscisaureus>bnoordhuis: it closes the udp server / client when uv returns an unused buffer
21:34:37  <piscisaureus>but this is an implementation detail
21:35:01  <piscisaureus>applications should be ready to handle this at any time and should not tie any "meaning" to it
21:35:39  <bnoordhuis>well, fix it :)
21:51:42  * mralephquit (Quit: Leaving.)
22:00:42  * _jnejoined
22:27:15  * mralephjoined
22:32:38  <piscisaureus>ryah: bnoordhuis: igorzi: apparently the 0-read trick that we use for tcp does not work with udp
22:32:58  <piscisaureus>so we should preallocate all the buffers that udp uses
22:33:01  <piscisaureus>is this a problem?
22:34:31  <bnoordhuis>piscisaureus: yeah, that's not surprising
22:34:43  * piscisaureustopic: https://gist.github.com/1149993 ab.c | --use-uv default after v0.5.4 | v0.5.4 release manager bnoordhuis, UDP | logs at piscisaureus.no.de
22:34:53  <piscisaureus>bnoordhuis: well, it is kind of
22:34:55  <bnoordhuis>if by preallocate you mean call alloc_cb before calling recvmsg, sure, that's what unix does already
22:35:19  <bnoordhuis>god piscisaureus, can't you pick a handle that's not a pain to type?
22:35:41  <bnoordhuis>pica.no.de or something
22:35:56  <piscisaureus>bnoordhuis: for tcp on windows we "poll" the socket before actually reading data from it
22:36:20  <piscisaureus>bnoordhuis: this does not work for udp - it truncates the message even if I sent the MSG_PARTIAL flag :-/
22:36:35  <bnoordhuis>well, it doesn't surprise me
22:36:41  <bnoordhuis>that's how it works on unices
22:37:04  <piscisaureus>bnoordhuis: this has the same downside as preallocating tcp memory
22:37:26  <piscisaureus>bnoordhuis: although - I don't assume people will create 10K receiving udp ports
22:38:17  <bnoordhuis>piscisaureus: have you seen the udp_packet_storm_1000v1000 benchmark? :)
22:38:32  <piscisaureus>bnoordhuis: yeah that's crazy
22:38:39  <bnoordhuis>yet awesome
22:38:57  <bnoordhuis>post some numbers!
22:39:25  <piscisaureus>doesn't compile
22:39:32  <piscisaureus>(fix it yeah :-()
22:39:42  <bnoordhuis>whaa- i don't even-
22:39:49  <bnoordhuis>what's the issue?
22:47:45  <piscisaureus>bnoordhuisL: re pack a handle
22:47:45  <piscisaureus>smartmachines don't come by the pound
22:47:48  <piscisaureus>I can't switch handle
22:58:54  <piscisaureus>bnoordhuis: btw sending to 0.0.0.0 is not allowed on windows
22:59:27  <bnoordhuis>piscisaureus: windows :(
23:00:06  <piscisaureus>bnoordhuis: wut?
23:00:23  <piscisaureus>bnoordhuis: it seems kinda silly to make 0.0.0.0 an alias for loopback eh?
23:00:23  <bnoordhuis>piscisaureus: windows makes me sad face
23:00:54  <bnoordhuis>piscisaureus: for loopback yes, for 'listeners on any local interface' no
23:01:17  <piscisaureus>bnoordhuis: the first works
23:01:25  <piscisaureus>eh
23:01:32  <piscisaureus>bnoordhuis: you can listen on 0.0.0.0
23:01:41  <piscisaureus>but packet storm sends to 0.0.0.0
23:01:43  <piscisaureus>that's silly
23:02:05  * mralephquit (Quit: Leaving.)
23:10:01  * mralephjoined
23:23:39  <piscisaureus>udp_packet_storm_1v1: 2020/s received, 4040/s sent
23:23:39  <piscisaureus>udp_packet_storm_10v1: 2020/s received, 4040/s sent
23:23:39  <piscisaureus>udp_packet_storm_100v1: 2020/s received, 4040/s sent
23:23:39  <piscisaureus>udp_packet_storm_1000v1: 2020/s received, 4040/s sent
23:23:39  <piscisaureus>udp_packet_storm_10v10: 2022/s received, 4040/s sent
23:23:39  <piscisaureus>udp_packet_storm_100v10: 1012/s received, 3030/s sent
23:23:40  <piscisaureus>udp_packet_storm_1000v10: 1012/s received, 3030/s sent
23:23:40  <piscisaureus>udp_packet_storm_100v100: 1814/s received, 4266/s sent
23:23:41  <piscisaureus>udp_packet_storm_1000v100: 1814/s received, 4266/s sent
23:23:41  <piscisaureus>udp_packet_storm_1000v1000: 11720/s received, 24840/s sent
23:23:44  <piscisaureus>^-- something's wrong
23:25:04  <piscisaureus>bnoordhuis: I have found a few issues that I need to discuss with igorzi and ryah before I can finish udp
23:25:18  <piscisaureus>bnoordhuis: so I will not land udp tomorrow "daytime" here
23:25:49  <piscisaureus>note to self: udp 0-reads, windows/winsock errors, timer starvation
23:26:33  <bnoordhuis>piscisaureus: right
23:26:51  <bnoordhuis>maybe we should postpone the release for one or two days
23:27:03  <bnoordhuis>or do a 0.5.4.1 later this week :)
23:27:29  <piscisaureus>0.5.5.1 I assume?
23:27:51  <_jne>hey
23:27:51  <bnoordhuis>check the channel topic piscisaureus
23:28:01  <bnoordhuis>hey _jne
23:28:17  <_jne>thanks for libuv, really great with an all-in-one lib for cross platform async i/o
23:29:08  <bnoordhuis>it's not finished yet but thanks :)
23:29:30  <piscisaureus>bnoordhuis: muust.fiiniish.it
23:32:29  <piscisaureus>bnoordhuis: ah
23:32:36  <piscisaureus>reasonable benchmarks coming up
23:35:03  <piscisaureus>bnoordhuis:
23:35:03  <piscisaureus>udp_packet_storm_1v1: 114130/s received, 116150/s sent
23:35:03  <piscisaureus>udp_packet_storm_10v1: 112110/s received, 114130/s sent
23:35:03  <piscisaureus>udp_packet_storm_100v1: 114130/s received, 116150/s sent
23:35:03  <piscisaureus>udp_packet_storm_1000v1: 112110/s received, 114130/s sent
23:35:04  <piscisaureus>udp_packet_storm_10v10: 110092/s received, 112110/s sent
23:35:04  <piscisaureus>udp_packet_storm_100v10: 116152/s received, 118170/s sent
23:35:05  <piscisaureus>udp_packet_storm_1000v10: 116152/s received, 118170/s sent
23:35:05  <piscisaureus>udp_packet_storm_100v100: 104834/s received, 107286/s sent
23:35:06  <piscisaureus>udp_packet_storm_1000v100: 109881/s received, 112339/s sent
23:35:06  <piscisaureus>udp_packet_storm_1000v1000: 72273/s received, 85487/s sent
23:35:11  <piscisaureus>_jne: what are you using it for?
23:37:02  <bnoordhuis>numbers from my admittedly puny laptop
23:37:03  <bnoordhuis>udp_packet_storm_1v1: 96834/s received, 96834/s sent
23:37:03  <bnoordhuis>udp_packet_storm_10v1: 96616/s received, 96616/s sent
23:37:03  <bnoordhuis>udp_packet_storm_100v1: 96383/s received, 96383/s sent
23:37:03  <bnoordhuis>udp_packet_storm_1000v1: 96603/s received, 96604/s sent
23:37:03  <bnoordhuis>udp_packet_storm_10v10: 161788/s received, 161790/s sent
23:37:04  <bnoordhuis>udp_packet_storm_100v10: 160778/s received, 160780/s sent
23:37:08  <bnoordhuis>udp_packet_storm_1000v10: 158940/s received, 158942/s sent
23:37:10  <bnoordhuis>udp_packet_storm_100v100: 163853/s received, 163873/s sent
23:37:12  <bnoordhuis>udp_packet_storm_1000v100: 158113/s received, 158133/s sent
23:37:14  <bnoordhuis>udp_packet_storm_1000v1000: 104014/s received, 104214/s sent
23:37:29  <piscisaureus>os == ?
23:37:37  <bnoordhuis>linux of course >:(
23:37:46  <bnoordhuis>2.6.32-33
23:37:50  <piscisaureus>ah
23:38:04  <piscisaureus>bnoordhuis: windows numbers are not that terrible to be immediately worrying
23:38:24  <bnoordhuis>no, they're pretty good
23:38:26  <piscisaureus>bnoordhuis: there is one annoying issue
23:38:46  <piscisaureus>bnoordhuis: udp sends complete without blocking all the time
23:38:58  <bnoordhuis>meaning?
23:39:26  <piscisaureus>bnoordhuis: on windows we take a shortcut when that happens. So the loop never gets around to check for received packets or timers firing
23:39:50  <piscisaureus>I had to disable the shortcut to get the benchmark to work
23:40:07  <bnoordhuis>er, 'sends complete' == 'sends a complete packet'?
23:40:24  <piscisaureus>bnoordhuis: er
23:40:39  <piscisaureus>bnoordhuis: iocp operations may complete without actually using the iocp
23:41:02  <bnoordhuis>oh, the loop may starve?
23:41:08  <piscisaureus>bnoordhuis: yes
23:41:14  <bnoordhuis>right, that's a problem
23:41:28  <bnoordhuis>so what do you do about it?
23:41:35  <piscisaureus>bnoordhuis: er?
23:41:40  <piscisaureus>bnoordhuis: dunno
23:41:49  <bnoordhuis>you said you disabled the shortcut? what shortcut?
23:43:03  <piscisaureus>bnoordhuis: shortcut similar to https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L595-600
23:43:37  <bnoordhuis>right
23:43:44  <bnoordhuis>we have a similar thing on unix
23:43:57  <piscisaureus>what do you do about it?
23:44:00  <bnoordhuis>that has room for improvement still
23:44:27  <bnoordhuis>piscisaureus: schedule an event on the next tick
23:44:45  <bnoordhuis>or defer the operation rather
23:45:00  <piscisaureus>bnoordhuis: uv_insert_pending_reqs does schedule it for the next tick
23:45:12  <bnoordhuis>but that means there's still more performance to squeeze out
23:45:21  <piscisaureus>bnoordhuis: not really
23:45:46  <bnoordhuis>let me explain what i mean, maybe it's not *quite* the same thing
23:46:20  <bnoordhuis>a sendmsg() of localhost dgrams on linux always succeeds
23:46:26  <piscisaureus>bnoordhuis: as long as the pending_reqs queue is not empty, the current core will not dequeue new packets and it will not check for timeouts
23:46:55  <bnoordhuis>it's probably not the same thing after all :)
23:47:15  <bnoordhuis>my point still stands though, there's more performance to gain on the unices still
23:47:32  <piscisaureus>bnoordhuis: ah - yeah ok :-)
23:48:07  <piscisaureus>bnoordhuis: I think I should just enforce checking for timers and the such after the queue grows above 100 items
23:48:12  <piscisaureus>or some magic number
23:48:28  <bnoordhuis>42
23:48:31  <bnoordhuis>or 1337
23:48:55  <piscisaureus>yeah
23:49:57  <piscisaureus>bnoordhuis: ok. I am going to bed
23:50:05  <bnoordhuis>piscisaureus: me too
23:50:11  <bnoordhuis>sleep tight!
23:50:12  <piscisaureus>after all it's sunday
23:50:22  <bnoordhuis>well, not anymore
23:50:36  <piscisaureus>it's sunday in your timezone
23:50:59  <bnoordhuis>in delft+20m you mean :)
23:51:30  <piscisaureus>20m?
23:51:40  <bnoordhuis>20 minutes (by train)
23:51:43  <piscisaureus>oh
23:51:53  <piscisaureus>you wish
23:51:55  <bnoordhuis>i concur that it was a subtle joke
23:51:55  <piscisaureus>more like 40
23:52:01  <piscisaureus>yay
23:52:03  <piscisaureus>goodbye
23:52:08  <bnoordhuis>sleep tight :)