00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:03  * benoitcquit (Excess Flood)
00:01:19  * indexzerojoined
00:01:58  * indexzeroquit (Client Quit)
00:04:43  * benoitcjoined
00:05:03  <isaacs>piscisaureus_: ++
00:05:09  <isaacs>piscisaureus_: i'll test this evening
00:05:17  * bradleymeckjoined
00:07:57  * kazuponjoined
00:08:46  <piscisaureus_>txdv: is there an issue for this? I want ben's opinion too
00:08:57  <piscisaureus_>txdv: ideally I think the API would look like:
00:09:26  <piscisaureus_>uv_ip_bind(uv_stream_t* handle, int flags)
00:09:37  <piscisaureus_>uv_ip_bind(uv_stream_t* handle, struct sockaddr* addr, int flags)
00:09:51  <piscisaureus_>and it would operate on both tcp and udp handles
00:09:56  <piscisaureus_>but this requires streams refactor
00:10:05  <piscisaureus_>for which we have great ideas and zero implementation
00:12:03  * kazuponquit (Ping timeout: 244 seconds)
00:16:53  <piscisaureus_>I have to give up for the day
00:16:54  <piscisaureus_>ttyl
00:16:57  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:35:30  * warzquit
00:38:25  <txdv>xD
00:38:26  <txdv>no
00:40:49  <txdv>udp is not a stream
00:40:52  <txdv>this doesn't make sense
00:40:57  * sgallaghjoined
01:05:49  * benoitcquit (Excess Flood)
01:08:18  * kazuponjoined
01:13:14  * kazuponquit (Ping timeout: 255 seconds)
01:13:15  * benoitcjoined
01:15:40  * skebcio_joined
01:18:17  * MI6quit (Ping timeout: 264 seconds)
01:18:17  * skebcioquit (Ping timeout: 264 seconds)
01:26:59  * bradleymeckquit (Quit: bradleymeck)
01:30:47  * joshthecoderjoined
01:34:43  * sgallaghquit (Remote host closed the connection)
01:36:40  * abraxasjoined
01:53:39  * jmar777quit (Ping timeout: 260 seconds)
01:55:17  * hzquit
02:05:34  * jmar777joined
02:06:12  * benoitcquit (Excess Flood)
02:14:45  * benoitcjoined
02:44:21  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:06:33  * benoitcquit (Excess Flood)
03:09:46  * benoitcjoined
03:11:44  * jmar777quit (Remote host closed the connection)
03:24:27  * benoitcquit (Excess Flood)
03:30:15  * benoitcjoined
03:42:53  * kazuponjoined
03:50:48  * TooTallNatejoined
03:50:55  * TooTallNatequit (Client Quit)
03:57:10  * brsonquit (Quit: leaving)
03:59:18  * jmar777joined
04:03:31  * jmar777quit (Remote host closed the connection)
06:29:34  * stagasjoined
06:44:18  * stagasquit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204])
06:55:05  * stagasjoined
07:05:42  <abraxas>Hi
07:05:53  <abraxas>Is there a good reason why signal handlers don't reveal their source? (pid, etc)
07:06:10  * benoitcquit (Excess Flood)
07:06:17  <indutny>erm
07:06:25  <abraxas>sigaction seems to contain a lot of useful information
07:06:39  <abraxas>(sorry, siginfo)
07:08:20  * benoitcjoined
07:09:21  <indutny>abraxas: actually, I don't really know
07:09:28  <indutny>abraxas: it seems to be present on all unixes
07:09:32  <indutny>probably that's because of windows
07:09:38  <indutny>better ask bnoordhuis later today
07:09:40  <abraxas>I guess so :)
07:09:44  <indutny>or piscisaureus
07:09:50  <abraxas>okay, I'll try that
07:14:59  * rendarjoined
07:26:39  * loladiroquit (Quit: loladiro)
07:33:11  * `3rdEdenjoined
07:41:00  * loladirojoined
08:13:12  * Raltjoined
08:20:52  * joshthecoderquit (Quit: Linkinus - http://linkinus.com)
08:43:08  * AvianFluquit (Remote host closed the connection)
08:54:33  * stagas_joined
08:56:23  * stagasquit (Read error: Connection reset by peer)
08:56:27  * stagas_changed nick to stagas
09:04:35  * bnoordhuisjoined
09:06:59  <bnoordhuis>morning
09:09:37  <indutny>morning
09:09:45  <bnoordhuis>morning fedor
09:09:48  <bnoordhuis>brett_: ping
09:19:17  <indutny>bnoordhuis: apache benchmark scaries me
09:19:23  <bnoordhuis>indutny: how so?
09:19:31  <bnoordhuis>you mean ab, right?
09:19:33  <indutny>yes
09:19:55  <indutny>one sec
09:20:00  <indutny>I'll post pic somewhere
09:20:32  <indutny>bnoordhuis: http://twitpic.com/bljls5
09:20:48  <indutny>bnoordhuis: you know what's interesting
09:20:55  <indutny>ab -n 2 -c 2 https://127.0.0.1:44300/
09:21:00  <indutny>this is the command I've used
09:21:11  <indutny>and ab does a lot of requests
09:21:20  <indutny>let me try the latest version
09:21:26  <indutny>I've often heard that default one is borked
09:21:33  <bnoordhuis>on os x, yes
09:22:02  <bnoordhuis>but what's so scary? the fact that it uses http 1.0?
09:22:10  <indutny>haha
09:22:10  <indutny>no
09:22:17  <indutny>it pipelines a lot of requests in one connection
09:22:22  <indutny>I suppose it's just a bug
09:22:27  <indutny>because latest version works properly
09:22:35  <indutny>bnoordhuis: a lot is like ~30
09:22:56  <bnoordhuis>oh, that. yes, that could be the os x ab bug
09:23:03  <bnoordhuis>though i think apple fixed that in 10.8
09:23:15  <indutny>nope
09:23:23  <indutny>10.8 is even more f*cked than 10.6
09:23:29  <indutny>I'm really sad that I've upgraded
09:23:35  <indutny>nothing works well there
09:23:44  <bnoordhuis>so when are you switching to a real OS?
09:23:47  <indutny>idk
09:23:56  <indutny>I want to use MBP anyway
09:24:07  <indutny>probably I just need to replace OSX with ubuntu
09:24:10  <indutny>of fedora
09:24:15  <indutny>I like fedora
09:24:19  <bnoordhuis>fedora is pretty nice
09:24:20  <indutny>everything, except gui
09:24:23  <bnoordhuis>i've been thinking of switching
09:24:32  <bnoordhuis>gui? you mean kde?
09:24:39  <indutny>ain't they using gnome 3?
09:24:53  <indutny>last time I've used fedora it was on it
09:24:59  <bnoordhuis>maybe gnome's the default
09:25:14  <bnoordhuis>but who cares? the gui is just for opening a xterm
09:25:14  <indutny>indeed it is
09:25:18  <indutny>haha
09:25:21  <indutny>well, not only
09:25:32  <indutny>I watch films and play games, sometimes
09:25:45  <indutny>but last one is not about linux
09:25:46  <indutny>not yet
09:25:58  <bnoordhuis>valve's got your back
09:28:09  * loladiroquit (Quit: loladiro)
09:29:16  <indutny>bnoordhuis: yeah, that's why I said "not yet"
09:29:40  <indutny>bnoordhuis: I wonder when everyone will start doing laptops like apple does
09:29:54  <indutny>have you seen retina mbp?
09:29:55  <bnoordhuis>probably when the patents expires :/
09:29:58  <indutny>it looks ultimately good
09:30:00  <indutny>bnoordhuis: ++
09:30:03  <bnoordhuis>seen it? i have one
09:30:08  <indutny>ah, you're working on it?
09:30:16  <bnoordhuis>that i only use to test node on os x on
09:30:21  <indutny>shit, I should buy it once I'll get to USA again
09:30:41  <indutny>buying it in russia is such a waste of money
09:30:44  <bnoordhuis>i had a great time at the apple store that day
09:30:47  <indutny>:)
09:31:04  <bnoordhuis>because i consistently called it a "macbook retsina", to the great annoyance of the apple store employees
09:31:30  <bnoordhuis>(in case you don't know what retsina is, it's a greek wine)
09:31:31  <indutny>hahaha
09:31:39  <indutny>great
09:31:41  * kazuponquit (Remote host closed the connection)
09:32:54  <indutny>so looks like that tlsnappy bug wasn't really a tlsnappy bug
09:33:02  <indutny>know I need to get shutdown working properly
09:33:19  <bnoordhuis>tcp or tls shutdown?
09:33:23  <indutny>which remind me about the same patch in node
09:33:25  <indutny>bnoordhuis: tls one
09:33:28  <bnoordhuis>right
09:33:36  <indutny>bnoordhuis: have you got a chance to look at this PR?
09:33:43  <bnoordhuis>i have and i will
09:33:47  <indutny>ok
09:33:49  <bnoordhuis>but do you have a test case i can try?
09:33:50  <indutny>thank you
09:34:05  <indutny>how do you think one can test it? :)
09:34:07  <indutny>just curious
09:34:13  <indutny>I've tested in in following way
09:34:17  <indutny>start https server
09:34:24  <indutny>ab -v 3 -c 1 -n 1 addr
09:34:32  <indutny>and look at ssl alert
09:34:52  <bnoordhuis>okay, i'll try that
09:35:25  <bnoordhuis>first have to catch up on my email backlog though :(
09:35:29  <indutny>oooh
09:35:32  <indutny>that's a big problem for me too
09:35:43  <indutny>I've 28 emails that're waiting for reply
09:35:50  <indutny>or for action
09:36:01  <indutny>btw, just FYI
09:36:08  <indutny>mbp 15'' retina is 2700 $ in russia
09:36:15  <indutny>actually, it's 2770$
09:36:18  <indutny>so more like 2800$
09:36:41  <bnoordhuis>i think i paid 3k euros for mine
09:36:49  <bnoordhuis>that's what 20% VAT does to you
09:37:11  <indutny>oh
09:37:15  <bnoordhuis>it's a 17" though
09:37:16  <indutny>it's even more expensive in europ
09:37:19  <indutny>europe*
09:37:22  <indutny>ok :)
09:37:29  <indutny>we've 13% VAT
09:37:33  <indutny>and it's included in price
09:37:45  <indutny>actually, I like your taxes
09:37:56  <indutny>you guys pay almost half of your salary to the government
09:37:57  <bnoordhuis>so does our government
09:38:02  <bnoordhuis>exactly :)
09:38:10  <indutny>that's pretty nice :)
09:38:18  <indutny>we pay only 13%
09:38:34  <indutny>well, firm is paying some percents too
09:38:45  <indutny>but it's less than 20% in total
09:39:32  <bnoordhuis>i considered moving to austria at one time
09:39:35  <indutny>haha
09:39:45  <bnoordhuis>because of the effective tax rate of 13%
09:39:54  <bnoordhuis>other things are way more expensive though
09:40:07  <indutny>that's the price to pay
09:40:08  <bnoordhuis>i guess on the whole it balances out in western europe
09:45:05  <indutny>bnoordhuis: do you know any simple way to get list of requests and their sizes in wireshark?
09:45:16  <indutny>I've like 3 length errors on 100000
09:45:30  <indutny>with correct SSL_shutdown approach
09:45:33  <indutny>in tlsnappy
09:45:39  <bnoordhuis>indutny: i don't use wireshark all that much, usually just tcpdump
09:45:47  <indutny>eh
09:45:49  <indutny>ok
09:50:36  * bnoordhuisis biab
09:55:02  * hzjoined
10:09:41  * benoitcquit (Excess Flood)
10:15:50  * benoitcjoined
10:26:57  * AvianFlujoined
10:52:19  * abraxasquit (Remote host closed the connection)
10:56:19  * stagasquit (Ping timeout: 256 seconds)
11:37:39  * kazuponjoined
11:39:37  * [mlg]d30xx4[mlg]changed nick to zX360Shotz420Xz
11:41:50  * kazuponquit (Read error: Connection reset by peer)
11:42:43  * kazuponjoined
11:57:17  * kazupon_joined
11:57:17  * hzquit (Read error: Connection reset by peer)
11:57:30  * hzjoined
11:58:04  * kazuponquit (Read error: Connection reset by peer)
12:18:49  * zX360Shotz420Xzchanged nick to deoxxa
12:29:38  * sgallaghjoined
12:31:11  * kazupon_quit (Read error: Connection reset by peer)
12:43:46  * kuebkjoined
12:43:53  <kuebk>j0
12:44:10  <kuebk>i'm debugging a nodejs module with gdb
12:44:15  <kuebk>and found out something like this
12:44:20  <kuebk>url = {str_ = 0x95c4ea0 "//urbanmarek", length_ = 13}
12:45:08  <kuebk>and i don't know why there is a difference between actual string length (at least visible one) and the length_ property
12:45:48  <kuebk>url is done like this v8::String::AsciiValue url (args[0]->ToString());
12:46:26  * jmar777joined
12:47:29  * MI6joined
12:47:55  * jmar777quit (Remote host closed the connection)
12:48:06  <bnoordhuis>kuebk: a js string can contain nul bytes
12:48:37  <bnoordhuis>it's possible someone's requesting "//urbanmarek\u0000"
12:48:58  <kuebk>yes it is
12:49:01  <kuebk>but http_parsers
12:49:02  * travis-cijoined
12:49:02  <travis-ci>[travis-ci] joyent/libuv#950 (master - 92fb84b : Ben Noordhuis): The build passed.
12:49:02  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/731adacad242...92fb84b751e1
12:49:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3645032
12:49:02  * travis-cipart
12:49:06  <kuebk>doesn't allow you to send null byte
12:49:23  <bnoordhuis>kuebk: no, but you can request e.g. /foo/bar/baz%00
12:49:58  <kuebk>tried that
12:50:45  <bnoordhuis>kuebk: btw, is that from src/node_http_parser.cc?
12:50:51  <kuebk>nope
12:50:53  <kuebk>it's from my code
12:51:06  <bnoordhuis>okay, nvm then
12:51:06  <kuebk>which uses the IncomingMessage.url
12:51:40  <kuebk>btw %00 in url doesnt make anything bad
12:53:34  <bnoordhuis>not itself, not until you start unescaping it
12:53:38  <bnoordhuis>*not in itself
12:53:48  * stagasjoined
12:54:21  * jmar777joined
12:58:14  <kuebk>the problem is i'm not escaping it
12:58:43  <kuebk>i'm just calling a method from module and as argument I pass IncomingMessage.url
13:09:22  * sgallaghquit (Remote host closed the connection)
13:10:33  * sgallaghjoined
13:27:18  <brett_>@bnoordhuis: hi
13:27:56  * philips_quit (Excess Flood)
13:29:36  <bnoordhuis>brett_: just replied on #3241
13:30:08  <bnoordhuis>the tl;dr is that i'm seeing reasonably balanced numbers
13:30:13  * philips_joined
13:33:42  <bnoordhuis>brett_: you're testing without -b, aren't you?
13:34:42  * jmar777quit (Remote host closed the connection)
13:34:43  <brett_>yes, no -b in our tests
13:35:04  <brett_>so it's running with delay
13:35:08  <bnoordhuis>right
13:35:15  <bnoordhuis>i included a test run without -b
13:35:35  <bnoordhuis>much lower numbers of course but still distributed fairly okay
13:37:23  <brett_>which seems more germane to our situation, where we're not just slamming it with a bunch of new connections, but where there coming in at maybe a few hundred per second, then hanging out a long time
13:37:47  * hzquit (Disconnected by services)
13:37:51  * hzjoined
13:38:13  <bnoordhuis>brett_: you mentioned you tried 3.7?
13:38:13  <brett_>sven build at 3.7 kernel last night and we're seeing a pretty good balance there (at least like a 3-to-1 imbalance rather than a 10-to-1 or worse)
13:38:20  <bnoordhuis>okay, good
13:38:40  <bnoordhuis>there were some posts on the lkml a while ago about problems with tcp port allocation
13:38:43  <brett_>he now has results from 3.6.10, which is not terrible either
13:38:53  <bnoordhuis>that may (or may not have been) related
13:39:19  <brett_>so we're pursuing the kernel route
13:39:38  <brett_>if you happen to remember some good search terms for finding those, i'd love to have a look
13:39:49  <bnoordhuis>yeah, i've been looking myself...
13:39:52  <brett_>otherwise i'll try to find them myself
13:39:59  <brett_>the mailing list messages, that is
13:40:05  <bnoordhuis>it was probably from last year
13:40:12  <bnoordhuis>but that doesn't really help, i assume
13:40:53  <brett_>we'll post on that bug and on the stack overflow question if we find anything convincing
13:41:20  <brett_>so i think we're going to be okay without adding another proxy layer, which is good news, and thank you for all of your help
13:41:28  <bnoordhuis>my pleasure :)
13:42:29  <bnoordhuis>iirc it was fixed in 3.4 so that'd probably mean it got fixed in the first four months of this year
13:42:58  <brett_>i think round-robin would be a great mode for Cluster to support independent of OS scheduling (since it's probably what the user wants for a lot of applications of Node), for the same reason that you tend to round-robin amongst servers with HAProxy rather than doing something fancier
13:43:29  <bnoordhuis>we've been considering that
13:43:32  <brett_>but i think i understand the approach you're taking, and of course that would be more to support
13:44:01  <brett_>anyway, short-term, thanks again and we'll post again when we know more.
13:44:02  <bnoordhuis>the main reason for doing it like we do now is that the OS scheduler is supposed to have a better overview of the system load
13:44:16  <bnoordhuis>okay, cool :)
13:44:53  <brett_>got it. thanks!
13:48:59  * tristrampart ("WeeChat 0.3.7")
13:49:41  * benoitcquit (Excess Flood)
13:56:21  * benoitcjoined
13:58:00  * piscisaureus_joined
13:58:25  <piscisaureus_>hello
13:59:46  <bnoordhuis>sup bertje
14:00:05  <piscisaureus_>it's cold here
14:00:10  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/pull/653
14:00:20  <bnoordhuis>i was just looking at it
14:03:43  <bnoordhuis>piscisaureus_: uv__io_feed() would not update the pending events masked to include
14:03:46  <bnoordhuis>UV__POLLOUT, so a subsequent uv__io_stop() call to remove the
14:03:49  <bnoordhuis>UV__POLLIN event would cause the pevents mask to become zero
14:03:59  <bnoordhuis>that's how it's supposed to work
14:04:16  <piscisaureus_>bnoordhuis: I know
14:04:21  <piscisaureus_>bnoordhuis: BUT what happens is
14:04:29  * jmar777joined
14:04:33  <piscisaureus_>uv__io_feed adds the watcher to the pending list
14:04:41  <bnoordhuis>yes, and uv__io_stop removes it
14:04:44  <piscisaureus_>(because a write has completed)
14:04:59  <piscisaureus_>and then uv__io_stop removes it, even when the intention was to stop *reading*
14:05:59  <bnoordhuis>the problem i see with your PR is that it sets UV__POLLOUT but doesn't clear it afterwards
14:06:29  <bnoordhuis>to complicate matters, it should only do that if UV__POLLOUT wasn't already set and doesn't get set in the mean time
14:06:34  <bnoordhuis>maybe a new flag is in order
14:06:46  <piscisaureus_>bnoordhuis: maybe UV__FED ?
14:06:51  <bnoordhuis>something like that
14:07:21  <piscisaureus_>bnoordhuis: so why does pevents not get cleared?
14:07:50  <bnoordhuis>piscisaureus_: why/when exactly?
14:07:53  <piscisaureus_>I mean, it also needs to be cleared when these events originate from epoll_wait right?
14:08:32  <piscisaureus_>bnoordhuis: the UV__POLLOUT flag does not need to be cleared immediately. The callback needs to clear it (in the current situation)
14:08:35  <bnoordhuis>no, it's not cleared until you call uv__io_stop
14:08:43  <piscisaureus_>ah
14:08:53  <piscisaureus_>bnoordhuis: this is pevents right?
14:08:56  <bnoordhuis>yes
14:09:22  <piscisaureus_>bnoordhuis: so once a sockets becomes writable, it will remain writable until uv__io_stop is calle
14:09:23  <piscisaureus_>d
14:09:25  <piscisaureus_>that seems weird
14:09:46  <bnoordhuis>that's not quite what happens
14:10:08  <bnoordhuis>pevents is the event mask of what the user is interested in
14:10:22  <bnoordhuis>oh wait, no - you said it right
14:10:22  <piscisaureus_>ah, I see
14:10:33  <piscisaureus_>no that would be events
14:11:51  <bnoordhuis>pevents gets modified by uv__io_start and uv__io_stop
14:12:02  <piscisaureus_>bnoordhuis: you are right I think
14:12:04  <bnoordhuis>once the actual update (e.g. epoll_ctl) has taken place, pevents == events
14:12:19  <piscisaureus_>bnoordhuis: this is where a queue of reqs is much easier than a queue of watchers :-)
14:12:29  <bnoordhuis>heh, no doubt
14:12:40  <piscisaureus_>bnoordhuis: I do that in windows but (unfortunately) it creates other problems :-)
14:12:46  <piscisaureus_>so I would not suggest to change this
14:13:07  <piscisaureus_>but maybe set UV__IO_FED and clear it in uv__run_pending
14:13:14  <bnoordhuis>yep, something like that
14:13:21  <bnoordhuis>a test case would be nice (hint, hint)
14:13:37  <piscisaureus_>well there is a test case for node
14:14:00  <piscisaureus_>it's also possible for libuv, I'll see if I can make time
14:29:35  <bnoordhuis>i'l see if i can get one working
14:34:01  * EhevuTovjoined
14:40:47  * roxlujoined
14:41:08  <roxlu>hi, what's the correct way of destorying/free-ing a client connection?
14:41:24  <indutny>close it
14:41:28  <indutny>and then free it
14:41:37  <roxlu>do I handle on_read() and if nread < 0, then uv_shutdown then uv_clos e?
14:41:39  <indutny>but you may want to call shutdown before close
14:41:47  <indutny>erm
14:41:53  <indutny>what's client connection?
14:41:54  <indutny>tcp?
14:41:57  <roxlu>yes
14:42:05  <indutny>well, -1 should never happen...
14:42:12  <indutny>if you expect eof here
14:42:22  <indutny>it'll happen only if client has shutdown it's side
14:42:27  <roxlu>yes
14:42:33  <indutny>that's what you need?
14:42:35  <roxlu>I want to handle the situation where the client closes
14:42:36  <indutny>ok, then do it on -1
14:42:57  <roxlu>ok so nread < 0, then uv_shutdown, then uv_close ?
14:43:08  <indutny>yes
14:43:33  <roxlu>thanks
14:46:13  * peterrsjoined
14:52:34  <piscisaureus_>indutny: roxlu: when you get a -1 there's no need to shutdown
14:52:44  <indutny>piscisaureus_: isn't it unidirectional?
14:53:06  <piscisaureus_>indutny: roxlu: but you have to be careful not to call uv_close() before your own writes have finished
14:54:05  <indutny>piscisaureus_: i.e. connection will become half-open
14:54:15  <indutny>piscisaureus_: and still needs to be shutdown properly, for graceful disconnection
14:54:39  <roxlu>piscisaureus_: I've got a std::vector<Conneciton*> where I store connections; this Connection type has a uv_tcp_t member.. I need to "delete" this Connection element when it disconnects but if I "delete" the object in my on_read callback I get a SEGFAULT
14:54:41  <piscisaureus_>indutny: if the other side already half-closed it there's not need to
14:54:57  <piscisaureus_>indutny: it doesn't hurt much tho - it's just a little slower
14:56:01  <indutny>piscisaureus_: it does hurt
14:56:04  <piscisaureus_>roxlu: yes, you cannot free handles until they are properly closed, e.g. when the close callback is called
14:56:07  <indutny>piscisaureus_: if other side is expecting RST
14:56:51  <indutny>so it's graceful
14:56:59  <indutny>only if both sides has agreed on it
14:57:01  <indutny>:)
14:57:16  <indutny>otherwise it should be called dictatorial
14:58:42  * jmar777quit (Read error: Connection reset by peer)
14:59:10  * jmar777joined
15:00:29  <indutny>isaacs: yt?
15:02:15  * AvianFluquit (Remote host closed the connection)
15:06:34  <indutny>hm...
15:06:40  <indutny>why 24 core smartos machine can be slow...
15:06:42  <indutny>as hell
15:07:11  <indutny>it's like I can get more than 10% of CPU
15:07:27  <indutny>does anyone know if there're some sort of quotes on them?
15:10:25  <bnoordhuis>indutny: there can be but it usually manifests itself as your ssh session getting killed
15:10:36  <indutny>haha
15:10:36  <bnoordhuis>IME anyway
15:10:37  <indutny>nice
15:11:02  <indutny>that's what I call "graceful"
15:11:05  <bnoordhuis>hah
15:11:23  <indutny>interesting
15:11:30  <indutny>load average is 16
15:11:54  <indutny>but rps is much lower than on ubuntu
15:12:43  * piscisaureus_quit (Read error: Connection reset by peer)
15:13:13  * piscisaureus_joined
15:17:55  <peterrs>ircretary, tell TooTallNate got pseudo terminals working on windows: http://imgur.com/Ksy7w,BgR8u http://imgur.com/Ksy7w,BgR8u#1
15:17:56  <ircretary>peterrs: I'll be sure to tell tootallnate
15:19:42  <roxlu>it seems my shutdown isn't called, I've got this basic setup: https://gist.github.com/aeb1b70da52f60082c5b
15:20:44  * stagasquit (Read error: Connection reset by peer)
15:21:08  <piscisaureus_>peterrs: what technology are you using? scraping?
15:21:15  * stagasjoined
15:21:32  <peterrs>piscisaureus_, scraping (winpty)
15:21:36  <roxlu>I'm using the correct calls right?
15:23:06  * EhevuTov_joined
15:23:16  * EhevuTovquit (Ping timeout: 252 seconds)
15:23:57  <bnoordhuis>roxlu: you call uv_shutdown() from your read_cb when status=01
15:24:01  <bnoordhuis>*status=-1
15:24:03  * felixgejoined
15:24:03  * felixgequit (Client Quit)
15:24:07  <bnoordhuis>(bloody keyboard)
15:24:30  <bnoordhuis>but by that time the other end has already gone away
15:25:11  * EhevuTov__joined
15:26:16  <roxlu>bnoordhuis: thanks, do you mean when nread == -1? I'm doing that now... but my shutdown callback isn't called
15:26:58  <indutny>piscisaureus_: see, ben agrees with me
15:27:35  <bnoordhuis>indutny: i do? only by accident then :)
15:28:08  * EhevuTov_quit (Ping timeout: 255 seconds)
15:28:23  <bnoordhuis>roxlu: sorry, my answer is somewhat incomplete
15:28:43  <bnoordhuis>roxlu: if status == -1 and uv_last_error(loop).code == UV_EOF, there's no point in calling uv_shutdown()
15:29:06  <roxlu>ok
15:29:21  <roxlu>but still when I free the related uv_tcp_t I get a segfault
15:30:21  <indutny>bnoordhuis: yes, coincidence
15:30:28  <bnoordhuis>roxlu: it's probably not it but you call delete when e.g. uv_accept() returns -1
15:30:41  <bnoordhuis>that's bad, you still need to call uv_close() on the handle first
15:30:54  <roxlu>hmm
15:31:05  * EhevuTovjoined
15:31:24  <roxlu>so, when uv_last_error(loop).code == UV_EOF, I can call uv_close() and in the callback I can delete my reference?
15:31:30  <indutny>ok, it seems that ssl is ultimately slow on that smartos machine...
15:31:33  <bnoordhuis>roxlu: ABC: Always Be Closing
15:31:52  <bnoordhuis>(i'm perverting sales droid speech here)
15:32:08  <bnoordhuis>roxlu: re UV_EOF, yes
15:33:12  * EhevuTov__quit (Ping timeout: 264 seconds)
15:33:25  * indutnysales_droid
15:33:30  <indutny>oh
15:33:30  <indutny>not this
15:33:34  * indutnychanged nick to sales_droid
15:33:35  <sales_droid>this
15:33:43  <sales_droid>my speech is ultimate
15:33:52  <roxlu>bnoordhuis: so like this: https://gist.github.com/aeb1b70da52f60082c5b (line 34)
15:33:54  <sales_droid>all hail to the sales droid
15:34:14  <sales_droid>roxlu: you've library called potator?
15:34:22  <roxlu>haha
15:34:34  <roxlu>sales_droid: yes :)
15:34:35  <sales_droid>i think it's winning libuv in my stupid names list
15:34:41  <sales_droid>and it's now #1
15:34:56  <roxlu>sales_droid: helping someone with a project which he called potator)
15:35:09  <roxlu>awesome
15:35:16  * sales_droidchanged nick to indutny
15:35:24  <indutny>roxlu: I think it's too late to help him :)
15:35:28  <indutny>(just kidding)
15:35:48  * EhevuTovquit (Ping timeout: 248 seconds)
15:36:04  <roxlu>I still a bit confused why my close callback isnt called here https://gist.github.com/aeb1b70da52f60082c5b
15:36:16  <isaacs>indutny: pong
15:36:23  <bnoordhuis>roxlu: lgtm at a quick glance
15:36:31  * EhevuTovjoined
15:36:41  <indutny>isaacs: I can't get more than 700 rps on that big smartos drone :(
15:36:42  <indutny>isaacs: hi
15:37:04  <indutny>isaacs: though I'm using siege... probably, ab will perform better.
15:37:10  <indutny>but siege was much faster anywhere elase
15:37:14  <indutny>s/elase/else
15:37:25  <isaacs>indutny: that's weird
15:37:35  <indutny>indeed it is
15:39:09  <roxlu>indutny: when a client disconneccts, my after_write callback gets called all the time
15:39:15  <roxlu>with status 0
15:39:23  <indutny>hm...
15:39:37  <indutny>well, that's expected :)
15:39:45  <indutny>if you did writes
15:39:50  <indutny>did you?
15:40:00  <roxlu>no continuously, but I did a write yes
15:40:27  <roxlu>I would expect one after_write callback for each uv_write
15:40:52  <indutny>and you get more?
15:41:07  <roxlu>yes it never stops till I stop the app
15:41:27  <indutny>this looks like a bug to me
15:41:31  <indutny>bnoordhuis: ^
15:42:07  <bnoordhuis>reduced test case please
15:42:34  <roxlu>yes, thinking how I can make that quickl
15:43:57  <bnoordhuis>s
15:44:05  <bnoordhuis>(wrong window)
15:44:45  <isaacs>call in 0:14 (bnoordhuis, piscisaureus_, sblom, TooTallNate, indutny)
15:44:52  <indutny>oh call
15:44:59  <bnoordhuis>aye aye
15:45:18  <roxlu>I'll try to find where it crashes first; making a clean test case may take some time
15:45:30  <roxlu>but this is a gdb bt, https://gist.github.com/6a187b09de13c3055878
15:47:18  <bnoordhuis>roxlu: are you sure you're not clobbering memory somewhere?
15:47:53  <roxlu>bnoordhuis: I get that crash when I delete/free the uv_tcp_t of the closed connection
15:48:03  * warzjoined
15:48:03  * warzquit (Changing host)
15:48:03  * warzjoined
15:48:30  <roxlu>when I don't delete/free it, it doesn't crash, but it means that I'm leaking memory there
15:49:07  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/87c8cf1 <- i'd expect that test case to fail if your description of the issue is correct, but it doesn't
15:50:05  <roxlu>oh hang on... do I need to create a uv_write_t for each client connection?
15:51:45  * peterrsquit (Remote host closed the connection)
15:51:47  <bnoordhuis>roxlu: yes, you can't share it concurrently
15:51:58  <roxlu>ok
15:52:01  <roxlu>that might b eit
15:52:03  <roxlu>be it
15:59:09  <roxlu>that wasn't it
15:59:28  <roxlu>I am running doing uv_run() in a thread I spawned
15:59:45  <roxlu>do i need to create a new loop or can I use the default one?
16:00:07  <bnoordhuis>roxlu: you can use the default one iff that's the only thread using it
16:00:20  <roxlu>ok
16:00:25  <roxlu>it is
16:00:28  <indutny>isaacs: call time?
16:00:33  <indutny>bnoordhuis: piscisaureus_ ^
16:00:49  <bnoordhuis>i'm logged in
16:01:34  <bnoordhuis>piscisaureus_: hurry up
16:02:03  <isaacs>piscisaureus_: we eagerly await your long yellow face
16:04:25  * bnoordhu1sjoined
16:04:35  * bnoordhu1squit (Client Quit)
16:05:03  * kuebkpart
16:12:51  <indutny>piscisaureus_: ?
16:16:36  <indutny>bnoordhuis: so have you came closer to reviewing my graceful patch?
16:16:59  <bnoordhuis>indutny: no, but i'll probably get around to it later tonight
16:17:05  <indutny>ok
16:17:08  <indutny>thank you
16:17:15  <bnoordhuis>if you're impatient, ask bert to review it
16:17:21  <bnoordhuis>provided he's around, of course
16:17:51  <roxlu>ok, it was a bug in the version of libuv I was using
16:18:08  <roxlu>just recompiled with the current github version and everthing works as I would expect it to work
16:18:13  <isaacs>ircretary: tell sblom I'm still seeing this in 0.8, was it fixed in master and just not backported? https://gist.github.com/4277559
16:18:13  <ircretary>isaacs: I'll be sure to tell sblom
16:18:22  <isaacs>ircretary: tell piscisaureus I'm still seeing this in 0.8, was it fixed in master and just not backported? https://gist.github.com/4277559
16:18:23  <ircretary>isaacs: I'll be sure to tell piscisaureus
16:18:26  <isaacs>ircretary: thanks
16:18:27  <ircretary>isaacs: You're welcome :)
16:20:25  <piscisaureus_>hello
16:20:25  <piscisaureus_>shit
16:20:55  <piscisaureus_>isaacs: is there anything I should know. I had 6pm in mind, forgot about our activisms against time zones
16:21:27  <isaacs>piscisaureus_: so, sblom is getting recruited to help with the npm binaries project.
16:21:40  <piscisaureus_>is sblom okay with that?
16:21:43  <piscisaureus_>I think that's a good plan
16:21:46  <isaacs>piscisaureus_: kewl.
16:22:00  <isaacs>he seemed to not be complaining :)
16:22:40  <isaacs>i also have an email from Claudio and and reply from Glenn asking about this.
16:23:06  <isaacs>so i'll reply with some suggested direction and overview of the pieces we need built, and include sblom on that.
16:23:12  <piscisaureus_>bnoordhuis: we have another call in 1,5 hours
16:23:14  <isaacs>piscisaureus_: are you still interested in being involved with this?
16:23:30  <bnoordhuis>piscisaureus_: aww...
16:23:33  <piscisaureus_>isaacs: yeah keep me in the loop
16:23:37  <isaacs>kk
16:23:56  <piscisaureus_>bnoordhuis: so your test. I would read_start in the connect cb
16:24:13  <piscisaureus_>bnoordhuis: then after 50ms call uv_write and read_stop both in the timer_cb
16:39:50  * dapjoined
16:44:50  * AvianFlujoined
16:47:16  * dapquit (Quit: Leaving.)
16:47:36  * tomshredsjoined
17:02:08  * roxluquit (Ping timeout: 245 seconds)
17:06:43  * indexzerojoined
17:08:20  * `3rdEdenquit (Remote host closed the connection)
17:17:17  * tomshredsquit (Quit: Linkinus - http://linkinus.com)
17:19:26  * bradleymeckjoined
17:25:05  <piscisaureus_>isaacs: no libuv upgrade in 0.8.16?
17:25:30  <isaacs>piscisaureus_: oh, no, there wasn't one.
17:25:33  <piscisaureus_>isaacs: https://github.com/joyent/libuv/commits/v0.8
17:25:38  <isaacs>yeah
17:25:39  <isaacs>i see it
17:25:41  <isaacs>there's a few things
17:26:00  <indutny>not that important though :)
17:26:11  <isaacs>* 527a10f Bert Belder (HEAD, ry/v0.8, v0.8) windows: improve / fix uv_interface_addresses (9 days ago)
17:26:14  <isaacs>* c7fca7a Bert Belder windows: add some error code mappings (9 days ago)
17:26:15  <isaacs>we can do a 0.8.16 :)
17:26:18  <isaacs>* deb1c34 Ben Noordhuis sunos: fix uv_getaddrinfo() NULL pointer dereference (2 weeks ago)
17:26:31  <piscisaureus_>0.8.17 I suppose
17:26:31  <isaacs>maybe tomorrow
17:26:35  <isaacs>er, 0.8.17, right
17:30:25  <indutny>bnoordhuis: hm... looks like my patch needs some updates
17:30:31  <indutny>bnoordhuis: I'm almost done with them
17:32:21  <indutny>bnoordhuis: updated
17:42:20  * peterrsjoined
17:46:43  * brett_quit (Ping timeout: 245 seconds)
17:52:28  * `3rdEdenjoined
18:03:47  <bnoordhuis>piscisaureus_: https://github.com/nrcmedia/nrc-zoekt-developer/commit/c131b51ee583f93aadfca2b99e53052e9982cc99#commitcomment-2304053
18:04:05  * EhevuTovquit (Quit: This computer has gone to sleep)
18:19:20  * EhevuTovjoined
18:22:02  * `3rdEdenquit (Remote host closed the connection)
18:24:58  <indutny>bnoordhuis: nice
18:25:28  <bnoordhuis>indutny: is your dutch good enough to follow that? :)
18:25:39  <indutny>my google translate is good enough
18:26:06  <bnoordhuis>ah right, pesky special purpose AI
18:26:12  <indutny>yes
18:26:18  <indutny>that's me
18:26:25  <indutny>thank you for offence
18:26:59  <bnoordhuis>no, i mean google translate
18:27:38  <bnoordhuis>unless you think i've hurt google translate's feelings
18:27:56  <bnoordhuis>don't want to offend our future overlords
18:28:08  <sgallagh>bnoordhuis: I'm pretty sure that Google services are closer to sentience than many of my former coworkers.
18:28:17  <bnoordhuis>haha
18:28:47  * TooTallNatejoined
18:32:29  * `3rdEdenjoined
18:33:32  <piscisaureus_>sgallagh: hahaha. So you are saying red hat is exceptional?
18:38:34  * dapjoined
18:40:52  * peterrsquit
18:45:13  <sgallagh>piscisaureus_: So far, it's proven to be, yes.
18:45:28  <sgallagh>(And also, I don't make a habit of insulting people I have to continue working with :) )
18:47:04  <piscisaureus_>hahaha
18:48:10  <indutny>:)
18:56:48  * brsonjoined
19:06:57  * mjr_joined
19:12:04  * joshthecoderjoined
19:17:49  * EhevuTovquit (Quit: This computer has gone to sleep)
19:18:39  <indutny>isaacs: http://nodejs.org/api/
19:18:42  <indutny>isaacs: update please
19:19:42  <isaacs>indutny: what do you mean?
19:19:53  <indutny>isaacs: ah, my bad
19:19:55  <indutny>cache
19:19:55  <indutny>nvm
19:19:58  <isaacs>:D
19:20:34  <indutny>yeah yeah laugh at me
19:22:19  * Ralt_joined
19:23:32  <MI6>joyent/libuv: bnoordhuis created branch libuv-streams2-fix - http://git.io/v-pUhg
19:23:46  <MI6>joyent/node: bnoordhuis created branch libuv-streams2-fix - http://git.io/OKyJGg
19:23:55  <bnoordhuis>isaacs, piscisaureus_: ^
19:24:21  <bnoordhuis>for you to review while i spend some quality time with my SO. biab
19:24:41  <bnoordhuis>passes all libuv and node master tests btw
19:29:06  * EhevuTovjoined
19:32:44  * jmar777quit (Remote host closed the connection)
19:33:03  <TooTallNate>isaacs: what's your gripe with null-terminated strings? out of curiosity‚Ķ
19:33:17  * jmar777joined
19:33:40  <isaacs>bnoordhuis: \o/
19:33:44  <isaacs>bnoordhuis: thanks, enjoy
19:34:07  <isaacs>TooTallNate: It's caused more financial harm than any other mistake in the history of computing.
19:34:29  <indutny>isaacs: do you need any material help man?
19:34:30  <isaacs>TooTallNate: imagine, if you will, a world in which C strings have a single byte at the start which specifies the length.
19:34:34  <indutny>that sounds pretty sad
19:34:56  <isaacs>entire classes of bugs simply can't happen
19:35:05  <TooTallNate>isaacs: ya it seems safer for sure
19:35:11  <TooTallNate>if it were that way
19:35:17  <isaacs>of course, now strings are limited to 256 characters, which is not so great.
19:35:22  <indutny>haha
19:35:24  <TooTallNate>hahah
19:35:29  <indutny>so you need one bit
19:35:32  <isaacs>so, just like we do with ints, you define progressively larger ones.
19:35:37  <indutny>to indicate that length will use next byte
19:35:48  <isaacs>indutny: or that
19:35:57  <indutny>but it's actually much worse
19:36:01  <indutny>than null-byte termination
19:36:02  <isaacs>or we could just have string8, string16, string64
19:36:03  <indutny>sometimes
19:36:30  <isaacs>this was actually on the table back in the day.
19:36:32  <indutny>especially when accessing memory junk
19:36:46  <indutny>use after free, or anything
19:36:50  <TooTallNate>isaacs: so what's the "financial" loss then?
19:36:58  <isaacs>but it was discarded, because a) that's an extra bytes, and those are expensive, and b) we null out all our data all the time anyway
19:37:11  <isaacs>TooTallNate: the financial loss is in developer hours chasing down bugs
19:37:23  <TooTallNate>i see
19:37:32  <isaacs>TooTallNate: resulting from using strcpy instead of strncpy etc.
19:37:33  <warz>couldnt people still incorrectly specify string length?
19:37:40  <warz>which is the same concept as not being null terminated?
19:37:41  <isaacs>warz: yeah, but they do that already.
19:37:41  <indutny>warz: that's what I'm talking about
19:37:47  * jmar777quit (Ping timeout: 260 seconds)
19:37:52  <indutny>it's absolutely the same
19:38:02  <indutny>if you can't pass one additional byte
19:38:02  <warz>just shuffles around the issue, imo
19:38:05  <isaacs>warz: in practice, in a world where we *don't* null all our data on startup, you have to have an extra byte for the terminator anyway
19:38:20  <indutny>isaacs: and you need to put length anyway
19:38:21  <indutny>:)
19:38:25  <isaacs>indutny: exactly
19:38:33  <indutny>two sides of a coin
19:38:37  <isaacs>so, now we have *both* classes of bugs, instead of just one
19:38:43  <indutny>indeed
19:38:45  <indutny>:)
19:38:53  <isaacs>of course, the downside is that C doesn't really know what a string is, so that makes the language strictly larger.
19:38:55  <TooTallNate>isaacs: there's null-terminated arrays of other types out there too
19:38:56  <indutny>I think the only way to make it work properly
19:39:00  <TooTallNate>similarly dangerous
19:39:05  <isaacs>TooTallNate: yep. similarly stupid.
19:39:07  <isaacs>:)
19:39:08  <indutny>is dynamic languages :)
19:39:43  <indutny>there're so many ways of optimization
19:39:53  <indutny>eventually js will run at the same speed as C
19:40:01  <indutny>there're nothing that can prevent it
19:40:12  <indutny>when your program already looks like a C
19:41:03  * travis-cijoined
19:41:03  <travis-ci>[travis-ci] joyent/libuv#951 (libuv-streams2-fix - e079a99 : Ben Noordhuis): The build passed.
19:41:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/e079a99abddb
19:41:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3651012
19:41:03  * travis-cipart
19:46:54  * Ralt_quit (Ping timeout: 276 seconds)
19:48:32  <TooTallNate>isaacs: i think you need to push the v0.8.16 tag to GH
19:48:42  <TooTallNate>i can do it
19:48:50  <isaacs>oh, right, just a sec
19:49:26  * TooTallNatecan't wait for streams2 to be merged into master!
19:49:31  * indutnytoo
19:49:48  <indutny>me can't wait to rewrite all his stuff to streams2
19:49:58  <indutny>eh
19:50:03  * indutnycan't wait to rewrite all his stuff to streams2
19:50:08  <TooTallNate>indutny: i've been doing a lot of it already
19:50:19  <indutny>I'm too lazy for that :)
19:50:23  <indutny>I need some push from core
19:51:08  <MI6>joyent/node: isaacs v0.8 * 45cdb0e : blog: Post for 0.8.16 (+4 more commits) - http://git.io/_LEYmw
19:51:10  <isaacs>thanks
19:51:11  <MI6>joyent/node: isaacs created tag v0.8.16 - http://git.io/Gxm9WQ
19:51:14  <isaacs>i knew i was forgetting something..
19:51:42  <TooTallNate>isaacs: it's been a while, haha
19:51:45  * isaacsgetting senile
19:52:21  <TooTallNate>isaacs: you didn't happen to update node-gyp in this release did you?
19:52:24  * TooTallNatechecking
19:52:44  <TooTallNate>oh 0.7.3
19:52:50  <TooTallNate>better than nothing
19:54:15  <isaacs>oh, no, i didn't
19:55:21  <isaacs>whoops. the package.json excluded it
19:55:31  <isaacs>changed to ~0.8 and it's picking it up
19:57:02  * dapquit (Quit: Leaving.)
19:57:33  * dapjoined
20:12:58  * stagasquit (Ping timeout: 252 seconds)
20:13:15  <isaacs>bnoordhuis: did the signature for uv_work change?
20:13:40  <isaacs>bnoordhuis: i'm getting compile errors with the latest libuv@master. doing distclean rebuild now
20:14:48  * stagasjoined
20:17:10  <isaacs>piscisaureus_: do you know? ^
20:21:32  <isaacs>oh, i see, ther's a node change as well
20:25:53  * bradleymeck_joined
20:27:12  * V1joined
20:30:21  <MI6>joyent/node: isaacs streams2 * bad29ed : streams2: Remove extraneous bufferSize setting - http://git.io/Xozpaw
20:30:24  <MI6>joyent/node: isaacs streams2-net * 27d69b8 : test updates for streams2 (+68 more commits) - http://git.io/UladJA
20:30:28  <isaacs>hm. should probably just merge streams2-net into streams2 at this point
20:30:48  <MI6>joyent/node: isaacs streams2 * 27d69b8 : test updates for streams2 (+8 more commits) - http://git.io/zF_rHA
20:31:30  * loladirojoined
20:32:00  * hzquit (Ping timeout: 264 seconds)
20:32:10  * hzjoined
20:34:43  * `3rdEdenquit (*.net *.split)
20:34:44  * bradleymeckquit (*.net *.split)
20:34:45  * bradleymeck_changed nick to bradleymeck
20:36:50  * stagasquit (Ping timeout: 255 seconds)
20:38:52  * piscisaureus__joined
20:39:56  * mmalecki_joined
20:43:24  * jce-joined
20:44:18  * isaacs_joined
20:44:21  * brson_joined
20:46:39  * niska`joined
20:46:54  * isaacsquit (Disconnected by services)
20:46:57  * isaacs_changed nick to isaacs
20:47:31  * brsonquit (*.net *.split)
20:47:31  * piscisaureus_quit (*.net *.split)
20:47:31  * bnoordhuisquit (*.net *.split)
20:47:32  * joclekquit (*.net *.split)
20:47:32  * russell_hquit (*.net *.split)
20:47:32  * mmaleckiquit (*.net *.split)
20:47:32  * niskaquit (*.net *.split)
20:47:32  * deoxxaquit (*.net *.split)
20:47:58  * bnoordhuisjoined
20:49:04  * russell_hjoined
20:50:46  * hzquit (Disconnected by services)
20:50:50  * hzjoined
20:52:07  * deoxxajoined
20:58:15  * sgallaghquit (Ping timeout: 244 seconds)
21:01:49  * V1changed nick to `3rdEden
21:05:18  * jmar777joined
21:17:31  * `3rdEdenquit (Remote host closed the connection)
21:30:14  <txdv>bnoordhuis
21:30:36  <bnoordhuis>txdv: that's me
21:30:40  <bnoordhuis>i'm on my way out though
21:30:44  <txdv>goodbye
21:31:15  <bnoordhuis>you have a quick question?
21:31:25  <txdv>i want dual stack for tcp
21:31:26  <txdv>so no
21:31:35  <bnoordhuis>right
21:31:40  <bnoordhuis>tomorrow :)
21:31:48  <txdv>see you!
21:32:47  * indexzeroquit (Quit: indexzero)
21:34:04  <tjfontaine>txdv: this is old, and didn't make it back up stream, but https://github.com/oftc/libuv/commit/89651fe958aa1b1f042c4a6a3cd90878e2e92347 and https://github.com/oftc/libuv/commit/2fddea6f661dafea8611754f9823649fe12285b9
21:34:38  <txdv>v6only
21:41:04  <isaacs>bnoordhuis: lgtm
21:41:24  <isaacs>bnoordhuis: re the uv_work change, i guess i just have to sigh and look forward to the cursing :)
21:41:59  <isaacs>bnoordhuis: a lot of node users don't know anything about libuv except uv_work
21:43:08  * TooTallNatequit (Ping timeout: 252 seconds)
21:43:22  * isaacsaway for a bit
21:45:11  * TooTallNatejoined
21:46:01  * EhevuTovquit (Quit: Leaving)
21:49:58  * jce-changed nick to joclek
21:53:56  <txdv>tjfontaine: that option is stupid, the problem is that if dualstack is present on the system on unix, it is turned on by default
21:54:05  <txdv>and they copied that behaviour over to windows
21:56:23  * bnoordhuisquit (Ping timeout: 260 seconds)
22:06:59  * dapquit (Quit: Leaving.)
22:07:22  * dapjoined
22:10:11  * mmalecki_changed nick to mmalecki
22:12:37  * loladiroquit (Quit: loladiro)
22:22:15  * rendarquit
22:22:39  * hzquit
22:37:58  * jmar777quit (Remote host closed the connection)
22:38:33  * jmar777joined
22:42:32  * jmar777quit (Ping timeout: 244 seconds)
22:44:46  * joclekpart
22:45:20  * warzquit
23:07:30  * jmar777joined
23:15:13  * jmar777quit (Remote host closed the connection)
23:15:49  * jmar777joined
23:17:49  * loladirojoined
23:19:49  * jmar777quit (Ping timeout: 244 seconds)
23:31:50  * jmar777joined
23:33:38  * jmar777quit (Remote host closed the connection)
23:34:11  * jmar777joined
23:38:25  * jmar777quit (Ping timeout: 244 seconds)
23:40:20  * c4milojoined
23:42:14  * EhevuTovjoined
23:58:34  <piscisaureus__>execSync
23:58:41  <piscisaureus__>I totally forgot that we need this for 0.10
23:58:47  * piscisaureus__freaks out
23:59:12  * piscisaureus__changed nick to piscisaureus