00:16:00  * mikealjoined
00:48:52  * mikealquit (Quit: Leaving.)
00:49:54  * loladiroquit (Quit: loladiro)
00:53:21  * ericktquit (Quit: erickt)
00:53:41  * mikealjoined
00:58:41  * \toothrotjoined
01:00:10  * toothrquit (Ping timeout: 246 seconds)
01:00:55  * mcavagejoined
01:01:20  * mcavagequit (Client Quit)
01:03:41  * toothrjoined
01:04:24  * \toothrotquit (Ping timeout: 240 seconds)
01:05:22  <AvianFlu>TooTallNate, did you mention something recently about the version of ab that's bundled with osx being broken?
01:05:41  <TooTallNate>AvianFlu: i didn't mention it, but i know of that being the case at least
01:06:13  <AvianFlu>I started to look into the strange failing test case I've been seeing, and I keep getting
01:06:14  <AvianFlu>Error: Command failed: apr_socket_recv: Connection reset by peer (54)
01:06:21  <AvianFlu>from the ab child the test uses
01:06:30  <AvianFlu>which made me remember the broken osx ab stuff
01:06:46  <TooTallNate>well try installing from homebrew
01:06:51  <TooTallNate>or whatever you use
01:07:00  <AvianFlu>yep� let me see what happens
01:09:36  <AvianFlu>gotta love googling stuff https://gist.github.com/1724673
01:12:02  <AvianFlu>bad link though
01:12:59  <isaacs>AvianFlu: aooohhhh...
01:13:07  <isaacs>AvianFlu: is that why your'e seeing that failure?
01:13:13  <isaacs>AvianFlu: the one that no one else sees?
01:13:15  <AvianFlu>looks like it
01:13:18  <AvianFlu>yep
01:13:22  <AvianFlu>cause I didn't bother installing ab
01:13:24  <isaacs>also, why do we have a test case that calls ab?
01:13:29  <isaacs>that sounds bad.
01:13:30  <AvianFlu>well that was my second question
01:13:34  <AvianFlu>cause� yeah.
01:16:00  * brsonquit (Ping timeout: 244 seconds)
01:16:08  * mikealquit (Quit: Leaving.)
01:20:53  * mikealjoined
01:20:58  * mikealquit (Client Quit)
01:23:02  * brsonjoined
01:29:17  <isaacs>AvianFlu: Aha, right. we do have some 'ab' requiring tests.
01:29:21  <isaacs>AvianFlu: i forgot about that.
01:29:26  <isaacs>including the one you're hitting.
01:29:50  <AvianFlu>well, it passes now
01:30:18  <isaacs>ah, sweet
01:30:28  <isaacs>it'd be nice to maybe have it check for a modern version of ab or something
01:30:56  <AvianFlu>it skips itself if there's no ab, could make it check the version pretty easily
01:31:06  <isaacs>yeah
01:31:33  <isaacs>hm, no easy way to make ab tell you what version it is, though
01:38:09  <AvianFlu>how much do we care about errors from the spawned ab processes?
01:40:40  <AvianFlu>actually, maybe we just check for 'apr' as well as 'ab' in the stderr from the child, and skip if it fails?
01:46:30  * TooTallNatequit (Ping timeout: 245 seconds)
01:47:59  * mikealjoined
01:48:33  <isaacs>AvianFlu: yeah, that's a good point. if ab crashes, the test is borked, so just nix it. patch welcome.
01:50:23  * isaacschanged nick to isaacs[away]
02:06:51  <AvianFlu>isaacs[away], https://github.com/joyent/node/pull/3453
02:08:46  * c4milojoined
02:13:15  * ericktjoined
02:16:06  * mikealquit (Quit: Leaving.)
02:29:16  * mikealjoined
02:33:42  * piscisaureus_joined
02:34:39  * bnoordhuisjoined
02:36:15  <piscisaureus_>bnoordhuis: hi
02:36:22  <bnoordhuis>piscisaureus_: ho
02:38:47  * isaacs[away]changed nick to isaacs
02:38:51  <isaacs>hola
02:42:41  * piscisaureus_quit (Ping timeout: 244 seconds)
02:43:46  * brsonquit (Ping timeout: 260 seconds)
02:47:33  * mikealquit (Quit: Leaving.)
02:48:01  * mikealjoined
02:48:31  * bnoordhuisquit (Remote host closed the connection)
02:54:09  * mikealquit (Quit: Leaving.)
02:59:23  * c4miloquit (Remote host closed the connection)
03:11:22  * brsonjoined
03:15:48  * isaacschanged nick to isaacs[away]
04:06:23  * pfox__quit (Ping timeout: 244 seconds)
04:53:34  * indexzerojoined
05:03:20  * TooTallNatejoined
05:05:04  * ericktquit (Quit: erickt)
05:24:04  * TooTallNatequit (Quit: Textual IRC Client: www.textualapp.com)
06:16:32  * indexzeroquit (Quit: indexzero)
06:57:02  * hij1nxquit (Quit: hij1nx)
06:57:30  * rendarjoined
07:10:03  * paddybyersjoined
07:10:16  * indexzerojoined
07:30:13  * paddybyersquit (Quit: paddybyers)
07:38:47  * dshaw_joined
08:05:42  * TheJHjoined
08:12:56  * hij1nxjoined
08:13:48  * hzjoined
08:15:02  * hij1nx_joined
08:15:59  * hij1nxquit (Read error: Connection reset by peer)
08:16:00  * hij1nx_changed nick to hij1nx
08:16:54  * TheJHquit (Ping timeout: 240 seconds)
08:37:42  * mmaleckijoined
08:48:57  * paddybyersjoined
08:53:15  * paddybyersquit (Client Quit)
09:03:59  * TheJHjoined
09:32:35  * indexzeroquit (Quit: indexzero)
09:45:33  * brsonquit (Remote host closed the connection)
10:08:24  * mmaleckichanged nick to mmalecki[hair]
10:22:14  * hij1nxquit (Quit: hij1nx)
10:36:03  * hij1nxjoined
10:45:13  * hij1nxquit (Quit: hij1nx)
11:11:29  * hij1nxjoined
11:35:56  * dshaw_quit (Quit: Leaving.)
12:28:02  * travis-cijoined
12:28:02  <travis-ci>[travis-ci] Skomski/node#13 (issue-3118 - e19dde6 : Karl Skomski): The build failed.
12:28:02  <travis-ci>[travis-ci] Change view : https://github.com/Skomski/node/compare/1ac05cc5ad6d^...e19dde6119bd
12:28:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/Skomski/node/builds/1634681
12:28:02  * travis-cipart
12:29:34  * travis-cijoined
12:29:34  <travis-ci>[travis-ci] Skomski/node#14 (master - c49f3b5 : isaacs): The build is still failing.
12:29:34  <travis-ci>[travis-ci] Change view : https://github.com/Skomski/node/compare/6f82b9f482f5...c49f3b5df691
12:29:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/Skomski/node/builds/1634683
12:29:34  * travis-cipart
12:59:07  * hzquit
13:21:46  <hij1nx>does SMF run on smarts?
13:21:55  <hij1nx>s/smarts/smartos/
13:22:28  <hij1nx>oops, wrong room =)
13:34:13  * c4milojoined
13:48:55  * hij1nxquit (Quit: hij1nx)
13:51:12  * hij1nxjoined
14:23:15  * loladirojoined
14:29:05  * c4miloquit (Remote host closed the connection)
14:38:11  * paddybyersjoined
14:50:35  * paddybyersquit (Quit: paddybyers)
15:00:04  * c4milojoined
15:03:25  * mmalecki[hair]changed nick to mmalecki
15:04:21  <mmalecki>hij1nx: yeah, it does
15:05:07  <hij1nx>mmalecki: ugh, yeah, i just realized how dumb that question was about 10 seconds after just checking for it myself ;)
15:05:30  * hzjoined
15:05:37  <mmalecki>lol
15:08:24  * isaacs[away]changed nick to isaacs
15:10:07  * piscisaureus_joined
15:26:03  <isaacs>piscisaureus_: mornin
15:26:27  <piscisaureus_>hello, isaacs
15:39:24  * indexzerojoined
15:41:17  * hij1nxquit (Quit: hij1nx)
15:46:27  * hij1nxjoined
15:52:29  <CIA-108>node: Charlie McConnell master * r145612c / test/simple/test-http-full-response.js : test: skip test-http-full-response on ab errors - http://git.io/kbtorQ
15:52:30  <CIA-108>node: isaacs master * rbdd57f0 / Makefile : Makefile: Refuse to build release from unclean repo - http://git.io/uAMwtQ
15:57:02  * paddybyersjoined
16:01:41  <CIA-108>node: Karl Skomski master * r8d5c120 / (src/stream_wrap.cc test/simple/test-net-resume-pause.js): Check if a stream has a valid fd before read_start - http://git.io/Nm4fDw
16:03:01  <AvianFlu>isaacs, I think I figured out #3449, too
16:03:06  <AvianFlu>!gh joyent/node#3449
16:03:07  <kohai>AvianFlu, https://github.com/joyent/node/issues/3449
16:03:22  <isaacs>AvianFlu: ORLY?
16:03:31  <AvianFlu>I wasn't able to reproduce the failure at all, but that seems like an obvious culprit
16:03:32  <isaacs>you're going for the cake, i see
16:03:35  <AvianFlu>(commit on issue)
16:03:55  <isaacs>AvianFlu: that does seem obvious. i admit i did not investigate even a little
16:03:56  <isaacs>i'll test that
16:04:11  <isaacs>thanks
16:06:53  <CIA-108>node: isaacs master * rbc18bf4 / test/simple/test-stdin-pause-resume-sync.js : Add test-stdin-pause-resume-sync - http://git.io/yYReCw
16:09:39  <isaacs>AvianFlu: whoops. i busted my root access to my centosdrone
16:09:42  <isaacs>crap.
16:10:13  <isaacs>oh well, destroy and set up a new one, i guess :)
16:10:28  <AvianFlu>I actually might have an old centos box lying around� I'll try it there if I can remember the ip XD
16:15:40  * \toothrotjoined
16:16:54  * toothrquit (Ping timeout: 240 seconds)
16:22:02  <isaacs>man, provisioning new linux boxes is soooo slllooowwwww
16:22:17  * isaacsis so spoiled by zfs zones
16:28:46  <AvianFlu>hahahahaha I found my centOS box, but I remember why I don't use it for testing normally
16:28:50  <AvianFlu>it doesn't have git, and neither does whatever yum repo it points to >.<
16:29:49  * piscisaureus_quit (Ping timeout: 245 seconds)
16:36:31  <isaacs>ok, actually building node now
16:36:48  <isaacs>this part is fast. many big strong cpus.
16:39:41  <AvianFlu>yeah git won't even compile on my centOS box because of an incompatible libcurl, so you're on your own with that XD
16:40:21  <isaacs>damn, now the test is passing for me on master.
16:40:34  <isaacs>oh, maybe it only fails when run in the `make test`
16:41:07  <AvianFlu>well it's fundamentally a race condition anyway
16:41:12  <AvianFlu>and I never saw it fail when I tested it
16:42:04  * hzquit
16:42:51  <isaacs>yeah.
16:43:01  <isaacs>it was failing for me very consistently on that machine that i inadvertently destroyed.
16:43:11  <isaacs>oh well. your patch is correct, i'm going to land it.
16:43:15  <isaacs>AvianFlu: thanks.
16:43:34  <AvianFlu>np
16:44:04  <CIA-108>node: Charlie McConnell master * r8a068ce / test/simple/test-child-process-stdout-flush.js : s/exit/close/ in test-child-process-stdout-flush, fixes #3449 - http://git.io/sYQqcw
16:44:22  <isaacs>two dgram failures on centos now, though
16:44:37  <isaacs>https://gist.github.com/2941897
16:45:06  <AvianFlu>I've seen those sometimes on debian and ubuntu, but not that recently
16:45:10  * toothrjoined
16:47:54  * \toothrotquit (Ping timeout: 240 seconds)
16:52:08  <isaacs>AvianFlu: if you want another race to hunt down, test/simple/test-regress-GH-1697.js has some issues.
16:52:35  <isaacs>oh, wait, this is so obvious.
16:52:38  <isaacs>no listen cb
16:53:26  <AvianFlu>glad I could help XD
17:00:44  * loladiro_joined
17:04:46  * loladiroquit (Ping timeout: 260 seconds)
17:04:46  * loladiro_changed nick to loladiro
17:06:18  * indexzeroquit (Quit: indexzero)
17:09:40  * \toothrotjoined
17:10:41  * toothrquit (Ping timeout: 244 seconds)
17:17:10  * hij1nxquit (Quit: hij1nx)
17:19:51  * piscisaureus_joined
17:20:29  <CIA-108>node: isaacs master * re74a733 / test/simple/test-regress-GH-1697.js : Fix #3448 Use listen callback in test-regress-GH-1697 - http://git.io/rKU5DA
17:21:02  <isaacs>only 5 more issues until delicious cake! https://github.com/joyent/node/issues?milestone=10&state=open
17:32:43  * loladiroquit (Ping timeout: 246 seconds)
17:33:28  <piscisaureus_>isaacs: hey
17:34:35  <isaacs>piscisaureus_: yo
17:35:06  <piscisaureus_>isaacs: I m having a problem... test-cluster-http-pipe is giving me headache
17:35:23  <piscisaureus_>isaacs: the problem is that uv-win cannot send pipe ends through the ipc channel atm
17:35:31  <piscisaureus_>isaacs: and it is quite a lot of work to fix that
17:35:42  <isaacs>whoa... isn't that like... all that cluster does?
17:35:55  <piscisaureus_>isaacs: well, tcp ends work great :-)
17:36:00  <isaacs>oh, oh, righ
17:36:20  <isaacs>piscisaureus_: i'm fine with a documentation patch and skipping the test.
17:36:38  <piscisaureus_>isaacs: so the problem is that this:
17:36:38  <piscisaureus_>net.createServer(...).listen("//./pipe/hello")
17:36:45  <piscisaureus_>just cannot work in a cluster scenario
17:36:47  <isaacs>piscisaureus_: right
17:37:03  <piscisaureus_>but I prefer to just skip the test
17:37:09  <isaacs>we should ENOTSUP right away in net.js as well.
17:37:20  <piscisaureus_>yeah, it does that actually
17:37:28  <isaacs>like, in the bit that has the cluster message the parent, before it even asks
17:37:50  <piscisaureus_>isaacs: oh, yeah that doesn't work
17:37:55  <piscisaureus_>I can make that happen
17:38:09  <isaacs>that sounds a lot easier than enabling pipes to be sent over ipc in uv-win
17:38:11  <isaacs>:)
17:38:25  <piscisaureus_>isaacs: eventually this is of course fixable - but I want to rework some of the pipe bits in windows anyway
17:38:42  <piscisaureus_>because we also need better queueing and fix julia's problems
17:40:07  <isaacs>right
17:40:11  <isaacs>that is SO not going to happen in 0.8
17:40:12  <piscisaureus_>isaacs: the only downside is... it won't be possible to solve this until 0.10 then :-(
17:40:12  <isaacs>:)
17:40:30  <piscisaureus_>isaacs: since to fix this I need to change the protocol
17:40:38  <isaacs>piscisaureus_: we should reduce the distance between stable releases.
17:40:41  <isaacs>like, dramatically
17:40:56  <piscisaureus_>yeah
17:40:58  <piscisaureus_>well
17:41:00  <isaacs>i'm thinking, maybe even have 0.9 be a month or less. just clean up some APIs, and that's it.
17:41:05  <isaacs>then 0.11 can be other things
17:41:06  <isaacs>etc.
17:41:21  <piscisaureus_>otoh, if you wait long enough a release becomes a party :-p
17:41:23  <isaacs>a month is probably not enough
17:41:29  <isaacs>hahah
17:41:31  <isaacs>true that
17:41:38  <isaacs>but at this rate, we won't be to 0.10 until next year
17:41:41  <piscisaureus_>yeah
17:41:45  <piscisaureus_>that wouldn't be good
17:42:01  * isaacsdramatically underestimated the required effort and how long everything would take
17:42:27  <piscisaureus_>that's how it works
17:42:29  <isaacs>which is a bit shameful, because ryah was very adamant about this. "It will take much longer than you think. Release 0.8 by the end of March."
17:42:33  * paddybyersquit (Quit: paddybyers)
17:42:49  <piscisaureus_>there are just very few people working on stuff :-)
17:42:55  <isaacs>of course, that was in february and we were still deciding what to do with isolates, and no one really knew what domains would be.
17:43:17  <piscisaureus_>yes
17:44:01  <piscisaureus_>I think in order to make an at least somewhat reasonable estimate you have to know exactly what will go into each release
17:44:28  <piscisaureus_>so, e.g. if we can make a list of stuff that we do for 0.10 we should not publish it :-)
17:44:34  <CIA-108>node: Felix Böhm master * r3a5798b / lib/querystring.js : querystring: improved speed and code cleanup - http://git.io/3lmUDQ
17:44:45  <piscisaureus_>and then have a deadline and just leave out the things that don't make the cut
17:45:49  <isaacs>piscisaureus_: yeah
17:46:03  <isaacs>piscisaureus_: also, we should be trying to maintain high-quality at all times.
17:46:25  <isaacs>i think a lot of stuff fell by the wayside in the shift to libuv in 0.6
17:46:42  <piscisaureus_>isaacs: I think 0.6.low were not very good indeed
17:46:54  <isaacs>once we get to all our tests passing in master, we should treat failing tests like an urgent issue, even in "unstable" branches
17:47:16  <isaacs>ie, unstable should mean "the api will change", not "the program is broken probably"
17:47:22  <isaacs>then it would be easier to get people to actually use it
17:48:10  <isaacs>part of the problem is that we only learn about most of the issues right at the start of the "stable" version, because no one wants to use the "unstable" one
17:49:54  <piscisaureus_>yeah
17:49:59  <piscisaureus_>which is unwarranted
17:50:10  <piscisaureus_>I think at this point master is actually better than 0.6
17:50:21  <piscisaureus_>but that wasn't always the case
17:50:38  <piscisaureus_>it would also be nice to actually put all api changes in the changelog
17:50:43  <piscisaureus_>insofar we didn't already
17:51:08  <isaacs>yeah, the changelog is a bit of a tricky one.
17:51:18  <isaacs>it's almost like you want a change-tree or something
17:51:33  <isaacs>like, at one level, you have "These modules were added, these modules changed, click here for details"
17:51:38  <isaacs>at the lowest level, you have the git log
17:52:05  <isaacs>my rule of thumb with the changelog is that it should capture the issues that "most people" care about.
17:52:12  <isaacs>like, noisy bugs and the like
17:52:47  <isaacs>features that people are waiting on
17:52:57  <piscisaureus_>yes
17:53:14  <piscisaureus_>I think API changes that are not backward compatible should also be in there
17:53:39  <piscisaureus_>the only thing is that it may be hard to track them down
17:54:15  <isaacs>One of my tasks for this weekend is to write a high-level summary detailing all these things.
17:57:57  <CIA-108>node: ssuda master * r91bf18f / (lib/dns.js src/cares_wrap.cc test/internet/test-dns.js): DNS: Support NAPTR queries - http://git.io/ZssuRw
18:01:13  <isaacs>oh, whoops. naptr is not in our cares.
18:01:14  <isaacs>crap.
18:02:33  * dshaw_joined
18:03:53  <CIA-108>node: isaacs master * ra90bc78 / (lib/dns.js src/cares_wrap.cc test/internet/test-dns.js): Revert "DNS: Support NAPTR queries" - http://git.io/Oa7s7w
18:06:20  <piscisaureus_>isaacs: generally I prefer force pushes in these situations :-)
18:06:44  <isaacs>piscisaureus_: me too, but it was past the 30-second-rule
18:06:55  <piscisaureus_>isaacs: ah, ok
18:06:57  <isaacs>i guess on saturday it could be a 5-minute-rule ;)
18:08:37  <piscisaureus_>isaacs: :-)
18:08:45  <isaacs>indutny: ping
18:09:12  <isaacs>indutny: if you're awake and around, are you working on this? https://github.com/joyent/node/issues/3372 or was that assignment merely wishful thinking on my part at some point?
18:11:32  <indutny>isaacs: it was wishful on my part
18:11:36  <indutny>:)
18:11:58  <indutny>but I may look at it later today or tomorrow
18:12:27  <piscisaureus_>hmm
18:12:30  <piscisaureus_>master is broken
18:13:06  <isaacs>piscisaureus_: broken how?
18:13:15  <piscisaureus_>isaacs: as in, doesn't compile
18:13:22  <isaacs>piscisaureus_: where?
18:13:24  <piscisaureus_>some node code is using uv_stream_wrap.fs
18:13:55  <piscisaureus_>. // Probably the user did .pause() and then an immediate .resume()
18:13:55  <piscisaureus_>. // before the fd had been set up. Don't even try to set up.
18:13:55  <piscisaureus_>. if (wrap->stream_->fd < 0) return scope.Close(Integer::New(1));
18:14:11  <isaacs>yes, i landed that as it made some tests pass.
18:14:25  <isaacs>but it is failing in windows.
18:14:36  <piscisaureus_>isaacs: yes, but that is not the way to go. That commit has to be backed out
18:15:10  <indutny>pquerna: yt?
18:15:11  * toothrjoined
18:15:12  <isaacs>ok. do you have a better suggestion to make it not choke on calling .resume() before it's been set up?
18:15:20  <isaacs>i mean, i can do some JS tricks
18:15:34  <isaacs>but it seemed wise to avoid at the source
18:15:43  <indutny>pquerna: is it mandatory to call SSL_accept/SSL_connect, or SSL_read/SSL_write will do the same automatically
18:16:07  <piscisaureus_>isaacs: I will think about it
18:16:26  <piscisaureus_>isaacs: should not be that hard
18:16:49  * \toothrotquit (Ping timeout: 246 seconds)
18:17:03  <isaacs>k. i'll be bakc in 20 minutes or so.
18:17:08  <piscisaureus_>me too
18:17:09  * isaacschanged nick to isaacs[away]
18:17:18  <piscisaureus_>isaacs: do you recall which were the tests that it fixed?
18:17:44  <CIA-108>node: Bert Belder master * r55ef9ef / (src/stream_wrap.cc test/simple/test-net-resume-pause.js): Revert "Check if a stream has a valid fd before read_start" - http://git.io/NPnKxQ
18:20:37  * `3rdEdenjoined
18:24:31  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:25:54  * hzjoined
18:26:28  * loladirojoined
18:26:34  * loladiropart
18:33:49  <isaacs[away]>ircretary: tell piscisaureus_ The test was included in the commit
18:33:49  <ircretary>isaacs[away]: I'll be sure to tell piscisaureus_
18:33:54  * isaacs[away]changed nick to isaacs
18:35:22  * isaacsinvestigating GH-3447
18:40:52  * japjjoined
18:54:11  * paddybyersjoined
18:54:58  <isaacs>Hm, seems like server.emit('close') is happening before the close() is actually complete
19:04:04  * AndreasMadsenjoined
19:05:51  * stephankquit (Quit: *Poof!*)
19:07:36  * ericktjoined
19:16:42  * mikealjoined
19:21:33  <indutny>isaacs: ok, so there're a couple of problems with async handshake
19:21:43  <indutny>isaacs: atm I found one
19:22:06  <isaacs>indutny: this is on the new tls stuff your'e doing?
19:22:17  <indutny>isaacs: sni callback will be called in another thread. That means that we cannot provide this API to userland
19:22:19  <isaacs>indutny: or something else?
19:22:48  <indutny>isaacs: yes, I'm trying to speedup tls server's handshake performance by moveing handshake initiation code to threads
19:23:12  <isaacs>ok
19:24:29  * stephankjoined
19:25:43  <indutny>oh, debugging multithreaded programs with gdb is a hell
19:25:53  <indutny>better go play Civilization
19:26:17  <isaacs>hahah
19:26:34  <isaacs>indutny: you can check out that diffie helman bug if you're bored
19:26:36  <isaacs>;)
19:26:45  <isaacs>indutny: you have no idea how delicious this cake will be
19:27:11  <indutny>hahaha
19:32:05  * ericktquit (Quit: erickt)
19:32:55  <japj>isaacs: is something like os.homeDir() that works on windows and unix something that would be accepted as patch?
19:33:21  <japj>i.e. use HOME or HOMEDRIVE HOMEPATH if on windows
19:33:26  <indutny>oh, and NPN stuff too
19:33:36  <indutny>I'm really disappointed
19:34:09  <indutny>ircretary: tell piscisaureus_ that I'm really disappointed in async TLS handshake stuff
19:34:10  <ircretary>indutny: I'll be sure to tell piscisaureus_
19:35:31  * indexzerojoined
19:36:57  <indutny>in case if anyone is interested: https://github.com/indutny/node/compare/feature-ssl-handshake-workers
19:39:26  <indutny>stupid f*cking openssl, why are your callbacks are so dumb
19:40:52  <isaacs>japj: starting to regret doing os.tmpDir() :)
19:41:13  * indexzeroquit (Quit: indexzero)
19:41:17  <isaacs>japj: actually, what i'd really love to see (not for v0.8) is a way to actually make the appropriate os-specific calls to get passwd data
19:41:25  <isaacs>japj: like getpwnam etc.
19:41:51  <japj>password? what has that to do with dirs?
19:41:57  <isaacs>that's the only way we can ever parse paths in node programs 100% conforming to the shell style, with ~user/path/etc
19:42:07  <isaacs>japj: not password data. /etc/passwd data
19:42:11  <isaacs>user metainfo
19:42:19  <japj>ah
19:42:26  <japj>ok, that makes sense
19:42:40  <isaacs>you can parse /etc/passwd on some systems quite easily, but on mac it's a lie, and on windows, it's not there.
19:42:59  <isaacs>even on linux and smartos, it's somewhat suspect at times
19:51:56  * indexzerojoined
20:00:04  * stephankquit (Quit: *Poof!*)
20:01:27  * perezdjoined
20:03:56  * stephankjoined
20:09:44  * stephankquit (Quit: *Poof!*)
20:09:58  * AvianFluquit (Ping timeout: 244 seconds)
20:12:25  * AvianFlujoined
20:14:24  * brsonjoined
20:15:08  * bnoordhuisjoined
20:17:04  * `3rdEdenquit (Quit: Leaving...)
20:24:10  <indutny>isaacs: did you know that I proposed creating Buffer.concat years ago? :)
20:24:21  <indutny>isaacs: even implemented it (probably PR is somewhere in closed)
20:24:40  <indutny>it was too highlevel that days
20:27:31  * stephankjoined
20:28:13  * bnoordhuisquit (Remote host closed the connection)
20:31:23  * `3rdEdenjoined
20:33:20  <CIA-108>libuv: Ben Noordhuis master * r6d67cf1 / (5 files in 4 dirs): unix, windows: update uv_fs_poll API - http://git.io/uk_Ezw
20:35:15  * travis-cijoined
20:35:15  <travis-ci>[travis-ci] joyent/libuv#422 (master - 6d67cf1 : Ben Noordhuis): The build passed.
20:35:15  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7ca524e133b1...6d67cf1952d5
20:35:15  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1637068
20:35:15  * travis-cipart
20:36:52  * ryahjoined
20:37:10  * ryahtopic: wtf https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md
20:37:22  * ryahquit (Client Quit)
20:39:16  * AndreasMadsenquit (Remote host closed the connection)
20:39:52  <indutny>I like how ryah is warning us
20:39:53  <indutny>:)
20:42:12  * paddybyersquit (Quit: paddybyers)
20:45:10  * bnoordhuisjoined
20:46:35  <indutny>bnoordhuis: hey man
20:46:44  <bnoordhuis>indutny: ho man
20:47:22  <CIA-108>node: Ben Noordhuis reviewme * ree6e933 / (16 files in 7 dirs): deps: upgrade libuv to 6d67cf1 - http://git.io/muVDCw
20:47:23  <CIA-108>node: Ben Noordhuis reviewme * ra4983cf / (5 files in 3 dirs): fs: make fs.watchFile() work on windows - http://git.io/zMZhzQ
20:47:27  <indutny>bnoordhuis: I'm in trouble with debugging my tls threading stuff, do you have a free time to help me on that thing: https://github.com/indutny/node/compare/feature-ssl-handshake-workers (I'm talking mostly on the code review)
20:47:28  * kolektivquit (Remote host closed the connection)
20:47:31  <bnoordhuis>^ anyone want to review that?
20:47:32  <indutny>s/on/about
20:47:43  <tjfontaine>watchFile woo
20:47:50  <bnoordhuis>indutny: what kind of trouble?
20:47:52  <indutny>bnoordhuis: https://github.com/joyent/node/commit/a4983cf4740e431127e548b486f616788874aff5#L0R880 ?
20:48:00  <indutny>bnoordhuis: it doesn't work and often crashes inside uv
20:48:12  <indutny>bnoordhuis: I suppose there is some concurrent access to structure
20:48:15  <indutny>or use after free
20:49:18  <bnoordhuis>okay, let me take a look
20:49:29  <bnoordhuis>meanwhile, you can review my code :)
20:50:20  <indutny>bnoordhuis: I'm doing that :)
20:51:24  * `3rdEdenquit (Quit: Leaving...)
20:52:07  <indutny>bnoordhuis: lgtm
20:52:30  <bnoordhuis>indutny: thanks
20:54:08  <isaacs>bnoordhuis: what's with the ignored third argument?
20:54:53  <bnoordhuis>isaacs: node now knows what error it was that happened, the old impl didn't
20:55:08  <bnoordhuis>only i didn't want to change the old interface too much, hence it's not used
20:55:39  <isaacs>i see
20:56:29  <bnoordhuis>indutny: SSLInfoCallback() runs in the main thread, right?
20:56:40  * paddybyersjoined
20:57:00  <bnoordhuis>isaacs: i wouldn't mind changing the API, it could be improved
20:57:03  <indutny>bnoordhuis: not anymore
20:57:17  <isaacs>i dunno. fs.watchFile isn't really that great.
20:57:28  <indutny>bnoordhuis: which function are you talking about (I created another one with the same name and different interface)
20:57:31  <isaacs>i think a better stat poller could be done in userland all in JS quite easily
20:57:48  <bnoordhuis>indutny: the one that calls uv_async_send
20:58:34  <indutny>bnoordhuis: no
20:58:45  <indutny>bnoordhuis: it's running in the same thread where SSL_accept was called
20:58:48  <bnoordhuis>indutny: okay, good
21:00:00  * piscisaureus_joined
21:00:01  <hz>libuv gyp file is hard to track
21:00:02  <hz>gh
21:00:12  <hz>im trying to port it to cmake
21:00:40  <piscisaureus_>bnoordhuis: don't you think 333ms is a little short for a poll interval?
21:00:52  <piscisaureus_>bnoordhuis: iirc libev did 4s
21:01:16  <bnoordhuis>piscisaureus_: could be. i remember it being too long :)
21:01:20  <piscisaureus_>bnoordhuis: (had a good day sleep btw? :-p)
21:01:27  <hz>you define _GNU_SOURCE if windows, do you confirm?
21:01:48  <hz>uv.gyp:129
21:02:12  <piscisaureus_>bnoordhuis: maybe we could make the interval configurable
21:02:20  <bnoordhuis>piscisaureus_: yeah, for all five hours or so :)
21:02:27  <bnoordhuis>piscisaureus_: it already is, that's just the default
21:02:37  <bnoordhuis>i don't mind bumping it to 4s or something
21:03:34  <piscisaureus_>bnoordhuis: i think it would be good to not change the interval
21:03:44  <piscisaureus_>bnoordhuis: maybe we can make it configurable for the node user too
21:03:45  <piscisaureus_>hz: yes
21:03:51  <isaacs>#3447 is very interesting. it seems like on sunos, the close callback is fired before the port is actually available to listen on again
21:03:51  <hz>ok
21:03:56  <piscisaureus_>hz: and why are you porting it to cmake?
21:03:59  <bnoordhuis>#define DEF_STAT_INTERVAL 5.0074891
21:04:01  <bnoordhuis>#define NFS_STAT_INTERVAL 30.1074891 /* for filesystems potentially failing inotify */
21:04:01  <bnoordhuis>#define MIN_STAT_INTERVAL 0.1074891
21:04:01  <bnoordhuis>piscisaureus_: ^
21:04:27  <hz>i want to build it my self and make some manipulation
21:04:30  <piscisaureus_>hz: it's fine of course if you need it yourself - but I don't see us taking cmake patches
21:05:16  <piscisaureus_>hz: sure. You could consider using gyp or the makefile to build the thing.
21:05:23  <hz>its for my self
21:05:35  <hz>already done
21:05:56  <hz>but want to integrate it in my cmake build system
21:06:13  <piscisaureus_>hz: GNU_SOURCE is only needed for mingw builds
21:06:17  * c4milo_joined
21:06:28  <piscisaureus_>or it may even unnecessary at all
21:06:31  <hz>yes but it ends up to msvc too
21:06:33  <hz>:)
21:06:46  <hz>btw nothing changes
21:06:53  <isaacs>bnoordhuis, piscisaureus_: Does this sound reasonable to you? Should libuv guarantee that handle->close_cb is only called once the port is ready for listening again?
21:07:04  * c4miloquit (Ping timeout: 245 seconds)
21:07:24  <isaacs>bnoordhuis, piscisaureus_: If not, then we ought to document it, and not enforce it in tests.
21:07:28  <piscisaureus_>isaacs: hrm, I don't know what you mean
21:07:59  <isaacs>piscisaureus_: s = net.createServer(fn); s.listen(1234); s.on('close', function() { s.listen(1243) }); s.close()
21:08:22  <isaacs>piscisaureus_: that seems to work fine on os x, linux, and windows, but on sunos, the listen() fails with eaddrinuse for about 70ms
21:08:46  <isaacs>actually, i don't think it'd fail if you did it right away like that
21:09:01  <isaacs>s = net.createServer(fn); s.listen(1234, function() { s.on('close', function() { s.listen(1243) }); s.close() })
21:09:10  <piscisaureus_>isaacs: that's funny, in libuv listen() doesn't take a callback
21:09:20  <isaacs>piscisaureus_: right, but close does
21:09:28  <isaacs>and we don't actually use it to do the close callback in node.
21:09:35  <isaacs>in node, listen takes a cb
21:09:52  <piscisaureus_>yes, I think that's for cluster
21:09:56  * c4milojoined
21:10:22  <isaacs>but what i'm seeing is that the close callback gets called before the port is available to be listened on again
21:10:32  <piscisaureus_>oh, aha
21:10:47  <piscisaureus_>now I understand
21:10:49  * c4milo_quit (Ping timeout: 245 seconds)
21:11:01  <isaacs>if that's just an OS peculiarity that we've decided libuv isn't going to paper over, then that's fine, but if so, we need to change the test and document the disparity
21:11:08  <isaacs>but it smells to me like a bug
21:11:10  <piscisaureus_>umm, the close callback should guarantee that the socket is closed
21:11:18  <piscisaureus_>and I am pretty sure it does
21:11:43  <piscisaureus_>so if node makes the close callback before libuv does, that that could be the cause of the bug
21:13:02  <isaacs>piscisaureus_: well, i made node not do that, and it's still calling the OnClose function in node before it's available to be listened on again
21:13:15  * paddybyersquit (Quit: paddybyers)
21:13:24  <piscisaureus_>isaacs: in that case it's probably a platform peculiary :-)
21:13:35  <piscisaureus_>isaacs: can I log in to that machine or something?
21:13:39  <isaacs>piscisaureus_: of course
21:13:55  <isaacs>piscisaureus_: ssh root@
21:13:57  <piscisaureus_>isaacs: umcats? smartosdron?
21:13:59  <isaacs>your key should be there already
21:14:01  <isaacs>smartosdrone
21:14:28  <isaacs>i'm in there as isaacs, but there's a relatively recent git checkout in /root/node as well, i believe
21:14:58  * c4miloquit (Ping timeout: 246 seconds)
21:15:33  <piscisaureus_>isaacs: oh my you have a colorful bash
21:15:38  <isaacs>piscisaureus_: haha
21:15:40  <isaacs>indeed./.
21:15:50  <piscisaureus_>isaacs: ok, which test?
21:15:54  <isaacs>i can rip that crap out. i didn't mean to push that as root@
21:16:03  <hz>EIO_STACKSIZE is for mingw too?
21:16:10  <isaacs>test-child-process-fork-net
21:16:11  <piscisaureus_>no
21:16:28  <isaacs>piscisaureus_: you might not approve of the .vimrc, though
21:16:30  <piscisaureus_>isaacs: aah, I have a suspicion
21:16:33  <isaacs>k
21:17:16  <piscisaureus_>isaacs: I do not approve of vim at all
21:17:34  <isaacs>haha, ok
21:17:39  <isaacs>what's your suspicion?
21:18:16  <piscisaureus_>isaacs: a sec
21:18:28  * isaacsrapt with anticipation
21:19:11  <japj>isaacs: I have a suspicion piscisaureus does not like vim
21:20:03  <piscisaureus_>let me read that test carefully with notepad++
21:20:08  <japj>lol
21:22:41  <japj>piscisaureus_: btw, with the node 0.7 MSI it is now possible to specify APPLICATIONROOTDIRECTORY argument to msiexec to install to a different path. do we want to make a 'shorter' name for that or do we want to release 0.8 with that?
21:23:04  <japj>ah wait
21:23:47  <japj>reminds me of other stuff aswell
21:26:31  <japj>I'd like to be able to install as a non-admin user at some point in the future, but I think that might require rewriting the installer a bit, so maybe that's something for 0.9 or later
21:26:54  <piscisaureus_>isaacs: I don't think either of those snippets you pasted would fail on smartos
21:28:25  <isaacs>hmm... indeed, that seems to work
21:28:31  <isaacs>of course, there's no connections, etc.
21:28:43  <isaacs>so... why is it taking longer to close in the test case?
21:29:13  <piscisaureus_>isaacs: I think the problem is that the test does this:
21:29:13  <piscisaureus_>1. create a server
21:29:13  <piscisaureus_>2. send it to the child
21:29:13  <piscisaureus_>3. connect to it
21:29:13  <piscisaureus_>4. close the server
21:29:13  <piscisaureus_>5a. send a message to the child telling it to close the server }
21:29:13  <piscisaureus_>5b. create a new server } <-- race condition
21:29:14  <piscisaureus_>5c. listen() }
21:29:18  * paddybyersjoined
21:30:09  <isaacs>i see.
21:30:16  <piscisaureus_>isaacs: the child should send a message back to the parent when it has closed the server. the parent should wait for that, before it creates a new server
21:30:23  <isaacs>right.
21:30:29  <isaacs>because the child's close is not synchronous
21:30:42  <hz>hard but maybe it will work
21:30:49  <hz>lets try cmake script :)
21:31:03  <piscisaureus_>isaacs: well, the close itself is practically synchronous (but not guaranteed, no)
21:31:03  <piscisaureus_>isaacs: but the message that gets send to the child is definitely async
21:31:31  <isaacs>right
21:31:32  * japjquit (Read error: Connection reset by peer)
21:31:48  <isaacs>hm. i see. so i cut out one race condition, but not the other.
21:31:59  <isaacs>thanks, good read :)
21:32:06  <piscisaureus_>isaacs: I think you could cut out both
21:32:22  <isaacs>well, in net.js, we are definitely not calling the close() cb at the right time
21:32:33  <isaacs>we're using process.nextTick instead of attaching an actual on_close callback function
21:32:35  <piscisaureus_>isaacs: if you just send a message back to the parent from the childs close cb
21:32:45  <isaacs>right
21:32:47  <piscisaureus_>isaacs: well, that's definitely not good
21:32:47  <isaacs>that'll fix the test
21:32:57  <piscisaureus_>isaacs: although, theres a risk here
21:32:58  <isaacs>but this nextTick emit('close') thing is bs.
21:33:21  <piscisaureus_>isaacs: it is not legal to invoke methods on a closing uv handle so node should prevent that
21:33:40  <isaacs>right
21:33:55  * paddybyersquit (Client Quit)
21:33:59  <isaacs>we could probably just avoid that pretty easily. net's .close() could set ._closing = true even.
21:34:36  <isaacs>so, first, the test, then the nextTick
21:34:41  <piscisaureus_>isaacs: kewl
21:35:46  <hz>piscisaureus_ strange thing
21:36:11  <hz>in uv.gyp for target run-tests
21:36:22  * mikealquit (Quit: Leaving.)
21:36:41  <hz>_GNU_SOURCE is defined only for non windows
21:37:26  <piscisaureus_>hz: *shrug*
21:37:36  <piscisaureus_>who cares? it's just a define
21:37:41  <hz>dont you use _GNU_SOURCE-enabled symbols?
21:37:47  <hz>*on mingw
21:37:58  <piscisaureus_>well, apparently no
21:37:59  <piscisaureus_>t
21:38:03  <hz>:)
21:42:23  <bnoordhuis>indutny: sorry, forgot to reply. i don't see anything obviously wrong with your ssl code
21:44:32  * bnoordhuis_joined
21:45:04  <indutny>bnoordhuis: cool
21:45:08  <indutny>bnoordhuis: thanks for reviewing
21:46:24  * bnoordhuisquit (Ping timeout: 240 seconds)
21:46:30  <isaacs>bnoordhuis: any thoughts about hiding ev_* from prying eyes? will you have any time tonight to put it into an issue, and perhaps close that issue?
21:48:19  <isaacs>review, please? https://github.com/isaacs/node/compare/close-cb-timing
21:48:58  * mralephjoined
21:49:42  <isaacs>oh, wait, for some reason this is causing much mayhem on os x...
21:49:54  <bnoordhuis_>isaacs: i'm at my parents-in-law now. no time for an all-nighter, i'm afraid. :)
21:50:04  <isaacs>ok, kewl.
21:50:05  <bnoordhuis_>but i'll have time to work on it tomorrow
21:50:10  <isaacs>bnoordhuis_: tomorrow \o/ :D
21:50:20  * indexzeroquit (Quit: indexzero)
21:50:21  * c4milojoined
21:50:21  <isaacs>enjoy your family time :)
21:50:29  <mraleph>so how come when somebody publishes scary benchmark the life on #libuv/#nodejs just continues as is? I see no screams and people running around trying to fix it :-)
21:50:44  <bnoordhuis_>will try to. :) back to being social
21:51:02  <isaacs>mraleph: we're busy running around trying to fix other things
21:51:23  <isaacs>mraleph: any insights into what that code is doing?
21:52:15  <mraleph>websockety stuff?
21:53:06  * paddybyersjoined
21:53:12  <isaacs>heh, i mean, where it's getting slow
21:54:16  <piscisaureus_>mraleph: these benchmarks are very tiring
21:54:26  <mraleph>tell me about it :-)
21:54:32  <piscisaureus_>mraleph: it is a very easy way to draw attention to oneself
21:54:52  * bnoordhuis_quit (Ping timeout: 246 seconds)
21:55:07  * AndreasMadsenjoined
21:55:14  <mraleph>yeah but if you start beating everybody down everytime they try to draw attention that will teach them a lesson.
21:55:21  <mraleph>also sometimes there is a real problem.
21:55:25  <piscisaureus_>yes
21:55:32  <mraleph>like event loop starvation or whatever.
21:55:41  <piscisaureus_>for example, vert.x beats node in the fs department
21:55:53  <mraleph>I am just always surprised how stoic you are.
21:55:59  <isaacs>piscisaureus_: they also beat us beause their client does http pipelining
21:56:03  <mraleph>y u no fixing it?
21:56:12  <isaacs>unlike any web client anywhere, except java and couchdb
21:56:27  <mraleph>or y u not demonstrating that it is flawed etc.
21:56:48  <mraleph>nobody loudly talked about sunspider and look where we are now.
21:56:50  <piscisaureus_>isaacs: oh, I didn't realize they did that. node is also much faster if you use keepalibe
21:57:01  <isaacs>so, basically, it just dumps a 40MB chunk of http parsing tasks on the VM, and repeats over it in a tight loop
21:57:11  <piscisaureus_>mraleph: sure. fs work is slated for 0.9
21:57:15  <isaacs>which jvm hotspot is designed for.
21:57:31  <piscisaureus_>mraleph: but we're about to do a release and that has priority now
21:57:34  <isaacs>piscisaureus_: the "real problem" that vert.x highlighted is already fixed in 0.8
21:57:50  <piscisaureus_>isaacs: orly? y u no tell me :-)
21:57:57  <piscisaureus_>isaacs: which was that, btw
21:58:08  <isaacs>hm. scrap that onclose cb issue. it's breaking a bunch of other stuff, not sure why.
21:58:21  <isaacs>piscisaureus_: we use an fs.ReadStream for fs.readFile
21:58:36  <piscisaureus_>mraleph: ah, yeah, thats sort of backward indeed
21:58:40  <piscisaureus_>er, *isaacs
21:58:51  <isaacs>but ReadStream assumes that the file is big, and it sets up a lot of extra machinery, and events, and a slab allocation thingie and so on
21:59:05  <isaacs>especially for a small file, it's super ridiculous
21:59:13  * paddybyersquit (Quit: paddybyers)
21:59:18  <piscisaureus_>isaacs: yeah, it's probably better to just fstat and read the entire thing into a buffer
21:59:22  <isaacs>so i changed it to to a stat, alloc the size of the file, and keep trying to read the whole thing
21:59:25  <isaacs>yes, exactly
21:59:47  <isaacs>which caused a bug on files that lie about their size, which i fixed, causing a bug with files that are actually size=0, which shigeki and bnoordhuis fixed.
21:59:50  <isaacs>i think we're good now :)
22:00:00  <piscisaureus_>isaacs: in fact, part of the fs work should be that we get the length in the same pass as open. That should save some latency
22:00:20  <piscisaureus_>isaacs: I think that even Dart:io does that (ugh)
22:00:33  <isaacs>piscisaureus_: i also tried an enhancement that would see that youer' trying to read a file that is currently trying to be read by another call, and then just piggieback your callback onto it
22:00:57  <piscisaureus_>isaacs: hmm that would except that we don't have copy on write buffers
22:01:02  <isaacs>if you set the concurrency high enough, the fs-readfile benchmark showed reading a 1MB file in a few ns
22:01:05  <piscisaureus_>*would work
22:01:08  <isaacs>right
22:01:16  <isaacs>but it was sooooo faasssttt!!!
22:01:21  <piscisaureus_>haha
22:01:23  <isaacs>actualy, it was slightly slower
22:01:33  <isaacs>it would *only* be good in the worst sorts of benchmarks, and we don't do that.
22:02:03  <isaacs>ok, i'm just gonna fix the test so that it doens't have the race condition.
22:02:14  <isaacs>i'll post an issue for the onclose thing. it doesnt' have to be a v0.8 blocker
22:02:30  <piscisaureus_>mraleph: but I think it eventually boils down to, we're only 2 and a half men here so we have to be selective with what to spend time on
22:02:44  <piscisaureus_>hmm 3,5 men would be more realistic tho
22:03:13  <isaacs>piscisaureus_: who you callin half a man, huh?
22:03:15  <mraleph>piscisaureus_: when did you manage to hire Charlie Sheen?
22:03:33  <isaacs>mraleph: we tried, but he was too busy winning.
22:03:35  <piscisaureus_>mraleph: Oh you didn't know yet?
22:05:18  * charlie_winingjoined
22:05:28  * charlie_winingchanged nick to charlie_winning
22:05:54  * AndreasMadsenquit (Remote host closed the connection)
22:05:56  <charlie_winning>Hello mraleph, did you manage to speed up try...catch already?
22:06:34  * charlie_winning<3 speed
22:07:01  <isaacs>piscisaureus_: oh, wait, no the test does have the child send a message when it's done closing.
22:07:43  <mraleph>charlie_winning: it will be fast, someday :-)
22:11:41  * charlie_winningquit (Quit: Page closed)
22:12:25  <piscisaureus_>mraleph: not that we have to complain btw... mstartzinger fixed a 3.10 perf regression within one day for us last week
22:13:05  <mraleph>hehe
22:13:11  <isaacs>piscisaureus_: so, that 5a/b/c race condition is not real
22:13:20  <piscisaureus_>isaacs: oh hmm
22:14:17  <piscisaureus_>isaacs: ok, lemme dig further then
22:18:09  <piscisaureus_>isaacs: hmm, not the test suddenly passes for me
22:18:21  <isaacs>!!?!?!@$@#$!#$!$
22:18:29  <isaacs>piscisaureus_: are you in my node folder?
22:18:32  <isaacs>because i put a setTimeout in it
22:18:34  <isaacs>:)
22:18:36  <piscisaureus_>isaacs: yes
22:18:46  <isaacs>ok, that explains it :)
22:18:57  <isaacs>try now
22:18:58  <isaacs>w
22:19:12  <piscisaureus_>isaacs: ok
22:19:42  <piscisaureus_>isaacs: ok, don't overwrite the file now :-)
22:22:36  <piscisaureus_>isaacs: I don't know - it doesn't seem that the child ever hits the serverScope.close callback
22:23:42  <isaacs>yeah, it hits that
22:23:46  <isaacs>that's this bit: https://gist.github.com/2942674
22:23:58  <isaacs>This is the serverScope.close callback
22:23:58  <isaacs>Parent <-- Child {"what":"close"}
22:23:59  <isaacs>got a close message from child { what: 'close' }
22:25:48  <isaacs>so, the parent does server.closE()
22:25:55  <isaacs>the parent does child.send({what:'close'})
22:26:02  <isaacs>the child gets that message, and does serverScope.close()
22:26:12  <isaacs>then the child does process.send({what:'close'})
22:26:16  * sh1mmerquit (Quit: sh1mmer)
22:26:37  <isaacs>at which point, both the parent and teh child's 'close' callbacks have fired.
22:26:54  <isaacs>then the parent does server = net.createServer(); server.listen(), and boom
22:27:02  <isaacs>(in testSocket)
22:27:52  <isaacs>you are editing the file?
22:27:56  <isaacs>piscisaureus_: ^
22:28:03  <piscisaureus_>isaacs: yes
22:28:09  <isaacs>k
22:29:49  <isaacs>ooh, you're adding logging in node's guts, too, i see.
22:29:51  <isaacs>how exciting
22:34:59  * sh1mmerjoined
22:35:53  * loladirojoined
22:37:51  * mmaleckiquit (Quit: leaving)
22:39:27  <piscisaureus_>isaacs: hmm, it really looks like a smartos issue
22:39:54  <piscisaureus_>isaacs: I can clearly see that both the child and the parent's server FD are closed before the new server is created
22:40:04  <isaacs>piscisaureus_: yep
22:41:12  * mralephquit (Quit: Leaving.)
22:41:18  <isaacs>piscisaureus_: ok, so... we can either skip this test on smartos, or i can put a timeout in it.
22:41:36  <piscisaureus_>isaacs: or use a different port :-p
22:41:38  * mralephjoined
22:41:48  <isaacs>even better idea
22:41:51  <isaacs>k, i'll just do that
22:42:31  * loladiroquit (Ping timeout: 260 seconds)
22:43:43  <piscisaureus_>isaacs: it's odd tho - I can't really reproduce it with a single js file
22:43:59  <isaacs>yeah, me neither
22:44:10  <isaacs>and when i have it listen on a different port, it seems to not get the 'echo' message
22:44:18  <isaacs>AssertionError: "" == "echo"
22:44:20  * rendarquit
22:44:40  <isaacs>oh, only changed it in one place.
22:44:40  <isaacs>derp
22:44:56  <isaacs>yeah, that passes
22:44:56  <isaacs>great
22:45:35  <isaacs>piscisaureus_: i'm gonna stash our changes
22:45:54  <isaacs>btw, this is only the second time in my life that pair programming has actually been useful, and it's ironic since you're in a different continent
22:46:06  * loladirojoined
22:46:20  <piscisaureus_>isaacs: haha
22:46:27  * mralephquit (Client Quit)
22:46:41  <piscisaureus_>isaacs: it's all a marketing ploy tho, I work for a company that tries to sell pair programming you see.
22:46:55  <isaacs>brilliant!
22:47:16  <isaacs>i work for a company that tries to sell sunos, see how well that's working out, i just convinced you it doesn't know how to close fd's
22:47:34  <piscisaureus_>isaacs: hehe
22:47:55  <piscisaureus_>isaacs: it may be a little more complicated than that :-)
22:48:01  <isaacs>mnost likely
22:48:24  <piscisaureus_>isaacs: maybe we are supposed to set SO_REUSEADDR on the socket when it comes off the unix socket, something like that
22:48:36  <piscisaureus_>that would be a little surprising
22:48:42  <isaacs>yeah, i don't knowp
22:49:08  <piscisaureus_>isaacs: but since you work at this particular company that creates smartos, you might have good resources to figure it out :-)
22:49:29  <isaacs>piscisaureus_: yes
22:49:36  <piscisaureus_>(I may be very naive. At some point the best answer Igor got came from stack overflow)
22:49:38  <isaacs>i will use this to shame some people into helping.
22:49:44  <piscisaureus_>hehe
22:50:06  * ryahjoined
22:50:14  <ryah>"The real loser here is Node.js. Nearly as long as the Java example, but the worst performer in the real metrics. So much for "making concurrency easy."
22:50:22  <ryah>http://news.ycombinator.com/item?id=4121174
22:50:27  <ryah>ANGER
22:50:55  <piscisaureus_>ryah: go go
22:51:25  <piscisaureus_>ryah: you should team up with mraleph, he had the same emotion
22:56:50  <isaacs>we've been probably focusing too much on http, and not enough on ws
22:56:54  <isaacs>otoh, people actually are using http.
22:57:13  <ryah>who owns the "ws" library?
22:57:20  <isaacs>oh, this is a different thing
22:57:53  <isaacs>$ npm owner ls ws -q
22:57:53  <isaacs>einaros <einaros@gmail.com>
22:57:56  <isaacs>$ npm owner ls ws -q
22:57:56  <isaacs>einaros <einaros@gmail.com>
22:58:32  * loladiro_joined
22:59:15  <ryah>https://github.com/einaros/ws/issues/85
22:59:57  <ryah>sigh. i hate benchmarks
23:00:21  <piscisaureus_>ryah: you know that einaros actually hangs out here don't you?
23:00:29  <ryah>einaros: --^
23:00:29  <kohai>einaros has -1 beer
23:00:36  * loladiroquit (Ping timeout: 260 seconds)
23:00:37  * loladiro_changed nick to loladiro
23:01:47  <ryah>i just hate fucking losers talking shit about node
23:01:51  <isaacs>yep.
23:01:53  <isaacs>we all hate that.
23:02:21  <isaacs>it sucks, too, because people hear 3 bad things and 3 good things, but the 3 good things are like people who know what the fuck they're talking about, and the 3 bad things got upvoted a bunch on HN
23:03:13  <isaacs>i think this is probably how chefs feel reading yelp reviews giving them 1* for not having ketchup at a chinese food restaurant
23:03:36  <ryah>kirindave isn't fit to tongue my balls. if begged me to do it, i would deny him.
23:04:00  <ryah>and i have super low standards for having my balls tongued
23:04:00  <piscisaureus_>ryah: actually, I don't think ws is to blame
23:04:12  <piscisaureus_>ryah: the tests were not run with ws
23:04:17  <piscisaureus_>ryah: https://github.com/ericmoritz/wsdemo/pull/2
23:04:27  <isaacs>yeah, it looks like the tests are just doing res.end('echo')
23:04:41  <isaacs>anyway.. someone wanna gimme a +1 on https://github.com/isaacs/node/compare/GH-3447?
23:05:11  <ryah>piscisaureus_: ah, okay
23:05:43  <isaacs>yeah, if anything ws's poor performance is our fault.
23:06:00  <piscisaureus_>ryah: as far as I can tell from https://github.com/ericmoritz/wsdemo/commits/master the test results were not updated after the ws PR was merged
23:07:04  <ryah>piscisaureus_: this is the one being run https://github.com/ericmoritz/wsdemo/blob/master/competition/wsdemo.js ?
23:07:09  <ryah>in the tests?
23:07:35  <piscisaureus_>ryah: I think so
23:07:38  <ryah>hm okay
23:07:55  <ryah>i don't see how node can be this bad
23:08:00  <ryah>it seems very unlikely
23:09:21  <AvianFlu>did it say which node version he was using for the test? I didn't see it when I looked earlier
23:09:52  <ryah>isaacs: why not have listenFD call listen?
23:10:17  <isaacs>ryah: because the semantics of listenFD were a little different, weren't they? You'd call listenFD with the fd from a handle.
23:10:26  <isaacs>if you're using that function, then your code is almost certainly wrong anyway
23:10:40  <isaacs>but i suppose we could still just make it work.
23:10:44  * isaacsshrug
23:11:10  <ryah>AvianFlu: no, fucking benchmark is super sloppy
23:11:58  * mmaleckijoined
23:12:13  * TheJHquit (Ping timeout: 246 seconds)
23:14:59  <isaacs>ryah: DTRT listenFD pushed to that branch
23:15:07  <isaacs>that increasingly inappropriately named branch :)
23:18:30  * c4miloquit (Remote host closed the connection)
23:24:15  * piscisaureus_is too tired.
23:24:33  <piscisaureus_>isaacs: I'll continue working on that skomski test tomorrow
23:24:39  <isaacs>piscisaureus_: thanks.
23:24:52  <isaacs>it's not a blocker if it doesn't land.
23:24:55  <piscisaureus_>but the cake has to be good
23:24:57  <piscisaureus_>:-p
23:24:57  <piscisaureus_>ah
23:25:00  <isaacs>oh, you have no idea.
23:25:00  * sh1mmerquit (Quit: sh1mmer)
23:25:02  <piscisaureus_>I can also work on failing tests
23:25:09  <isaacs>yes, that's probably more useful.
23:25:21  <isaacs>but first you need to +1 my GH-3447 branch, and then get some sleep :)
23:25:21  <piscisaureus_>but apart from the http-cluster-pipe thing that I am going to skip
23:25:35  <piscisaureus_>... there are no real bugs in there any more
23:25:37  <piscisaureus_>\o/
23:25:42  <isaacs>sweet!
23:26:02  <piscisaureus_>only less than a handful of tests that need minor changes
23:26:07  <piscisaureus_>so
23:26:13  <ryah>isaacs: you should probably have AndreasMadsen review patch - but looks okay to me...
23:26:15  <piscisaureus_>ok, where's that branch?
23:26:34  <isaacs>https://github.com/isaacs/node/compare/GH-3447
23:26:40  <isaacs>i'm gonna squash the two listenFD updates.
23:26:54  <isaacs>but the diff is the same
23:27:30  <piscisaureus_>isaacs: 4a1ebc745157305b1e +1
23:27:46  <piscisaureus_>oh, wait, that already landed :-p
23:27:54  <isaacs>huh?
23:28:05  <isaacs>in joyent/master, or in my master?
23:28:18  <ryah>v0.8 on monday?
23:28:37  <isaacs>ryah: not likely. my guess is wednesday.
23:28:44  <ryah>k
23:28:47  <ryah>holding my breath
23:28:52  <isaacs>if it happens this week.
23:28:58  <ryah>very excited about it
23:29:02  <isaacs>yes, me too
23:29:44  <piscisaureus_>isaacs: yes, lgtm if you can squash that stuff
23:29:46  <CIA-108>node: isaacs master * r41421ff / lib/net.js : Make listenFD just DTRT after warning - http://git.io/6AiUoA
23:29:46  <CIA-108>node: isaacs master * rd614d16 / test/simple/test-child-process-fork-net.js : test: Don't reuse common.PORT in test-child-process-fork-net - http://git.io/aYfa7A
23:29:52  <piscisaureus_>oh
23:29:53  <piscisaureus_>ok
23:29:54  <isaacs>piscisaureus_: done :)
23:30:46  <piscisaureus_>cool
23:30:56  <piscisaureus_>I don't believe in wednesday
23:31:01  <piscisaureus_>when are we having 7.11 ?
23:31:07  <isaacs>piscisaureus_: 7.11 is out, man
23:31:11  <isaacs>piscisaureus_: you mean 7.12?
23:31:37  <piscisaureus_>isaacs: oh, you released that yesterday
23:31:47  <isaacs>eah
23:31:48  <piscisaureus_>I suppose that was when I was drinking
23:31:54  <hz>i succeded at compile it on msvc9 mingw linux gcc
23:31:55  <piscisaureus_>ah, right
23:31:56  <hz>:)
23:32:16  <isaacs>ryah: hey, i noticed there's a whole bunch of tail -f processes on nodejs.org, from like 0.5 version numbered folderes
23:32:33  <isaacs>ryah: 15229 tail -f /home/ryan/node-v0.5.5-rc1/test/tmp/GH-814_test.txt <-- like that
23:33:05  <ryah>isaacs: are they mine?
23:33:06  <hz>n8
23:33:16  <isaacs>ryah: well, they're in your home dir, i assume so :)
23:33:20  <ryah>hehe :)
23:33:26  * hzquit
23:33:27  <isaacs>ryah: i'd go killing them, but i know you have a bunch of screen sessions running production websites.
23:33:30  <isaacs>;P
23:33:35  <piscisaureus_>isaacs: very cook
23:33:47  <ryah>true. let me kill them
23:33:47  <piscisaureus_>isaacs: *cool. You're very fast these days.
23:34:04  <piscisaureus_>isaacs: still, we have to fix the child_process.stdio[2] thing...
23:34:15  <isaacs>piscisaureus_: oh, that was actually done by indutny already
23:34:22  <piscisaureus_>w00t
23:34:32  <isaacs>i think you and i were just on the pot or something
23:34:53  <isaacs>because we both totally believed that had to be done. i sat down to do it, and was shocked that the code was already there.
23:36:43  <piscisaureus_>isaacs: ghe lol
23:36:50  <piscisaureus_>isaacs: yeah, it seems so.
23:39:02  <piscisaureus_>isaacs: somewhat surprising tho. I am pretty sure it came up thursday and indutny didn't say a word...
23:39:08  <piscisaureus_>isaacs: but yeah, cool
23:39:09  <piscisaureus_>ok
23:39:12  <piscisaureus_>I am gone
23:39:24  <ryah>me too
23:39:25  * ryahquit (Quit: leaving)
23:40:01  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:44:26  * sh1mmerjoined
23:54:45  <einaros>so you guys noticed that faulty benchmark from yesterday
23:54:49  <einaros>:P
23:57:28  * sh1mmerquit (Quit: sh1mmer)
23:58:06  <einaros>I have no idea how ws will match up in that benchmark, when it is actually tested
23:58:10  <isaacs>einaros: well, we're not entirely sure it's faulty yet
23:58:20  <einaros>the results were faulty
23:58:22  <isaacs>oh, you mean the ws one
23:58:24  <isaacs>yeah
23:58:28  <einaros>and the client they tested with were faulty
23:58:46  <einaros>their erlang websocket client expected all bytes of a frame to be delivered at once
23:58:56  <einaros>which isn't necessarily the case, and will have shown failures for several implementations
23:59:12  <einaros>in addition to other faults pointed out elsewhere
23:59:13  <isaacs>interesting
23:59:39  <isaacs>in general, it's a huge red flag if the client in a benchmark is written by the same person who wrote one of the servers being tested.
23:59:51  <isaacs>it is virtually impossible to get away from the giant bias goober that introduces
23:59:59  <einaros>yeah