00:00:13  <isaacs>igorzi: that's awesome.
00:00:19  <bnoordhuis>piscisaureus_: storedBytes[n] = new Array(n + 1).join('C'); <- doesn't that change the underlying strings? they're no longer cons strings now
00:00:37  <piscisaureus_>bnoordhuis: They still are.
00:00:51  <piscisaureus_>bnoordhuis: I think. lemme check to be sure
00:06:11  * theColejoined
00:06:50  <piscisaureus_>bnoordhuis: hmm I am not so sure they will be cons strings. Lemme change it back
00:07:09  <bnoordhuis>piscisaureus_: void* operator new (size_t size) { assert(0); } <- private and no body?
00:07:17  <bnoordhuis>or was that an issue with msvc?
00:08:17  * theColequit (Client Quit)
00:08:41  <piscisaureus_>bnoordhuis: trying if it compiles again.
00:08:53  <piscisaureus_>bnoordhuis: I think I had protected and no body before.
00:10:24  * mikealjoined
00:10:43  <piscisaureus_>bnoordhuis: I am going to change the Array join back. I think it *might* run through https://github.com/v8/v8/blob/master/src/ia32/full-codegen-ia32.cc#L3630 which generates flat strings
00:10:52  <piscisaureus_>bnoordhuis: so let's just revert to be sure
00:12:10  * c4miloquit (Quit: leaving)
00:12:32  * perezdquit (Quit: perezd)
00:12:53  <isaacs>i want to rewrite lib/http.js so bad.
00:13:15  <isaacs>it should be lib/http-server.js and lib/http-client.js, for starters
00:13:20  <piscisaureus_>yeah
00:13:27  <piscisaureus_>I cannot agree more :-)
00:13:36  * c4milojoined
00:13:40  <piscisaureus_>isaacs: but I fear that a rewrite will introduce another 1000 bugs
00:14:26  <isaacs>piscisaureus_: i know, i know
00:14:29  <isaacs>it's just so awful.
00:14:36  * c4miloquit (Client Quit)
00:14:37  <isaacs>it doesn't need to be *this* awful
00:15:01  * c4milojoined
00:15:02  <isaacs>mjr_: you still arouhnd?
00:15:06  <mjr_>isaacs: yes
00:15:14  <mjr_>Did you see my latest observation from the scrollback?
00:15:18  <isaacs>mjr_: !!!
00:15:20  <isaacs>mjr_: no, i dind't
00:15:48  <mjr_>https://gist.github.com/2638935
00:16:02  * dapquit (Quit: Leaving.)
00:16:04  * mikealquit (Quit: Leaving.)
00:16:05  <piscisaureus_>bnoordhuis: private and no body seems to work
00:16:11  <mjr_>We have both of those exceptions happening, and piscisaureus_ can sort of make one of them happen.
00:17:04  <isaacs>oh, hey, there was a bunch of conversation i missed.
00:17:05  <isaacs>nice
00:17:19  * dapjoined
00:18:24  * mikealjoined
00:19:01  <piscisaureus_>isaacs: https://github.com/joyent/node/issues/3239
00:21:37  <piscisaureus_>heh https://github.com/piscisaureus/node is still at my pre-uv iocp branch
00:21:53  <piscisaureus_>no wonder that recruiters don't like me :-p
00:22:37  <piscisaureus_>^-- that was kidding btw
00:22:50  <piscisaureus_>bnoordhuis: what's wrong with the get_uv_max_buf thing as it is?
00:23:20  <bnoordhuis>piscisaureus_: it's kind of pointless, you can't do large writes like that anyway :)
00:23:30  <piscisaureus_>bnoordhuis: what will happen on unix?
00:23:53  <piscisaureus_>bnoordhuis: I suppose on unix it'll just work
00:24:05  <bnoordhuis>piscisaureus_: yes, but v8 won't have it anyway
00:24:11  <bnoordhuis>try to alloc a 2 GB buffer, doesn't work
00:24:18  <piscisaureus_>bnoordhuis: that's because of the heap cap
00:24:24  <piscisaureus_>bnoordhuis: it can be overridden
00:24:31  <piscisaureus_>bnoordhuis: I think I will just use INT_MAX as the cap
00:24:36  <piscisaureus_>ok with you?
00:24:38  <isaacs>there we go: https://gist.github.com/2640679
00:24:45  <bnoordhuis>yeah, that was more or less what i was proposing :)
00:25:00  <piscisaureus_>bnoordhuis: UV_BUF_MAX_LEN it will be, one day
00:25:18  <bnoordhuis>piscisaureus_: why is it different on windows btw?
00:25:27  <isaacs>agent doesn't do anything with its errors.
00:25:36  <piscisaureus_>bnoordhuis: because uv_buf_t is an alias for the native struct iov
00:25:48  <piscisaureus_>bnoordhuis: so no conversion is needed
00:25:53  <bnoordhuis>right
00:26:05  <piscisaureus_>bnoordhuis: the order of the fields is also "reversed" on windows
00:27:03  <bnoordhuis>piscisaureus_: re WriteWrap, use placement new, then char* data = reinterpret_cast<char*>(wrap + 1)
00:27:15  <bnoordhuis>that's all you need, really
00:27:33  <piscisaureus_>bnoordhuis: well, that won't work, because I need to compute the offset before I can use placement new
00:27:49  <bnoordhuis>how's that?
00:28:09  <bnoordhuis>you want to alloc sizeof(WriteWrap) + n bytes, right?
00:28:28  <piscisaureus_>bnoordhuis: I want alloc(WriteWrap) + alignment + n, yes
00:28:51  <piscisaureus_>bnoordhuis: so how do I compute the alignment if I am not allowed to do this stuff.
00:29:42  <bnoordhuis>piscisaureus_: what alignment do you need?
00:29:49  <bnoordhuis>*do* you need alignment?
00:30:43  <piscisaureus_>bnoordhuis: well it's x86 and I'm not trying to lock cmpxchg, so, no, I don't need alignment
00:30:51  <piscisaureus_>bnoordhuis: but it seems rather dumb to not do it
00:31:11  <piscisaureus_>since it takes at most 3 bytes, and the os will try to memcpy the buffer to [somewhere[
00:31:25  * indexzerojoined
00:31:56  * indexzeroquit (Client Quit)
00:32:13  <bnoordhuis>piscisaureus_: i mean, writewrap itself is aligned to a 4 or 8 byte boundary
00:32:25  <bnoordhuis>you probably don't need to add any yourself
00:32:33  * indexzerojoined
00:33:09  <piscisaureus_>bnoordhuis: yes, but is sizeof(writewrap) also aligned?
00:33:15  <isaacs>ah, no, it was newListener tripping me up ;)
00:33:22  <piscisaureus_>bnoordhuis: or, divisiable by 4
00:33:30  <piscisaureus_>*dividable
00:33:30  <bnoordhuis>piscisaureus_: yes, insofar that new() will align it
00:33:50  <piscisaureus_>bnoordhuis: can you read my question again and then answer that?
00:34:14  <bnoordhuis>piscisaureus_: the simple answer is yes
00:34:31  <bnoordhuis>but if you want to take special care, use e.g. ROUND_UP(sizeof(WriteWrap), 8)
00:35:00  <piscisaureus_>bnoordhuis: so that's what I had, and then you were complaining it was not good ...
00:35:08  * orlandovftwquit (Quit: leaving)
00:37:43  <piscisaureus_>bnoordhuis: so what's there is not correct indeed.
00:39:13  <bnoordhuis>piscisaureus_: re sizeof(WriteWrap), it will always be a multiple of 4 (unless it contained a single char)
00:39:54  <bnoordhuis>it's because the compiler needs to guarantee suitable alignment for the types it contains
00:41:47  <piscisaureus_>bnoordhuis: I tried with char[3] and it showed that the sizeof is 3
00:42:03  <piscisaureus_>but i am going to assume here that you are right, because this code review is getting out of hand
00:42:43  <bnoordhuis>well, use ROUND_UP() if you want to be sure
00:43:01  <bnoordhuis>aligning on 16 bytes might not be a bad idea if you expect to do lots of copies
00:43:02  <piscisaureus_>let's just drop it
00:43:13  <piscisaureus_>alright, 16 bytes is also fine
00:43:38  <bnoordhuis>unless, of course, new() returns a pointers that's a multiple of 8
00:43:55  <bnoordhuis>in that case, ptr + 16 is not aligned on a 16 byte boundary :)
00:43:56  <piscisaureus_>which might very well be the case
00:44:04  <piscisaureus_>bnoordhuis: but if the data is long then it will just malloc
00:44:04  * c4miloquit (Remote host closed the connection)
00:44:13  <piscisaureus_>so it's going to be aligned to 16 bytes
00:45:23  <piscisaureus_>bnoordhuis: hmm
00:45:24  <piscisaureus_>stream_wrap.obj : error LNK2001: unresolved external symbol "private: static vo
00:45:24  <piscisaureus_>id __cdecl node::WriteWrap::operator delete(void *)" (??3WriteWrap@node@@CAXPAX
00:45:24  <piscisaureus_>@Z) [D:\node4\node.vcxproj]
00:45:24  <piscisaureus_>D:\node4\Release\node.exe : fatal error LNK1120: 1 unresolved externals [D:\nod
00:45:24  <piscisaureus_>e4\node.vcxproj]
00:45:43  <piscisaureus_>^-- private and no body not working
00:45:49  <bnoordhuis>msvc--
00:45:50  <kohai>msvc has -1 beer
00:49:03  <bnoordhuis>piscisaureus_: what you could do is char* p = new char[sizeof(WriteWrap) + n + 16], then char* data = reinterpret_cast<char*>((uintptr_t) p & ~(uintptr_t)15)
00:51:06  <bnoordhuis>piscisaureus_: req_wrap->object_->Set(bytes_sym, Number::New((uint32_t) data_size)); <- why not Integer::NewFromUnsigned()?
00:51:27  <bnoordhuis>(i would comment inline but it's kind of hard to match lines to commits)
00:51:31  <piscisaureus_>Umm, I wasn't arare that it existed
00:51:42  <piscisaureus_>I looked for Integer::NewUInt
00:54:22  * brsonquit (Ping timeout: 244 seconds)
00:59:28  * ericktquit (Quit: erickt)
01:00:08  <piscisaureus_>bnoordhuis: https://github.com/piscisaureus/node/commit/674c406daa1d968bc8bf40a2b9fc3e22893666c9
01:00:48  * c4milojoined
01:01:34  * theColejoined
01:04:21  <bnoordhuis>piscisaureus_: lgtm
01:05:33  <piscisaureus_>bnoordhuis: I will change http_simple
01:05:49  <piscisaureus_>and fix the space... (sigh)
01:06:10  <bnoordhuis>good :)
01:09:25  <piscisaureus_>bnoordhuis: what name would you suggest for _bytesWrittenSubmitted ?
01:09:37  <piscisaureus_>_bytesWrittenAndSubmitted?
01:09:47  <piscisaureus_>_bytesDispatched?
01:10:51  <bnoordhuis>meh... i'd probably pick _bytesDispatched or just _bytesWritten
01:13:11  * seebees1joined
01:14:36  * mikealquit (Quit: Leaving.)
01:15:48  <isaacs>piscisaureus_: this: http.get(options, onResponse, onError); should be: http.get(options, onResponse).on('error', onError);
01:16:02  <piscisaureus_>isaacs: I was just following the node docs....
01:16:10  <bnoordhuis>never trust the docs
01:16:28  <isaacs>piscisaureus_: orly? where'd you see that in the docs?
01:16:37  <isaacs>piscisaureus_: because http.request does not take a third argument
01:16:38  <bnoordhuis>i don't see it
01:16:55  <piscisaureus_>hmm
01:17:16  <piscisaureus_>Let's just say I copy pasted from the docs and I splitted out the onError and onResponse functions later
01:17:41  <piscisaureus_>apparently my delete key got stuck _p
01:18:00  <piscisaureus_>isaacs: so the test doesn't catch anything meaningful?
01:18:06  * piscisaureus_goes back to the drawing board
01:18:37  * perezdjoined
01:18:38  <isaacs>piscisaureus_: i DO have a test that finds a spot where we don't assign an error handler.
01:19:28  <isaacs>piscisaureus_: https://gist.github.com/2640940
01:20:00  <isaacs>piscisaureus_: fixed by: https://gist.github.com/2640942
01:21:25  <piscisaureus_>isaacs: I don't understand that patch tbh
01:21:32  <piscisaureus_>+ } else if (this.listeners('error').length === 1) {
01:21:32  <piscisaureus_>+ throw er;
01:21:35  <piscisaureus_>why is that?
01:23:12  <isaacs>piscisaureus_: oh, right...
01:23:16  <isaacs>i guess the whole point is to NOT throw.
01:23:20  <isaacs>heh
01:23:48  <isaacs>oh, right, i remember
01:24:08  <isaacs>because if you dont' have an httpMessage right now, then it means that somehow there was a socket somewhere in some unknown place, and the error would be otherwise lost.
01:24:35  <isaacs>i guess the thing to do in that case is to emit it on the Agent object, since that's right there.
01:24:58  <isaacs> var onError = function(er) {
01:24:58  <isaacs> if (this._httpMessage) {
01:24:58  <isaacs> this._httpMessage.emit('error', er);
01:24:59  <isaacs> } else {
01:25:01  <isaacs> self.emit('error', er);
01:25:03  <isaacs> }
01:25:05  <isaacs> };
01:28:52  <piscisaureus_>isaacs: I suppose it's not so bad to ignore an error that nobody cares about
01:29:05  <piscisaureus_>isaacs: unless, under some circumstances, someone could care about it
01:30:43  <isaacs>piscisaureus_: you should really not have sockets just randomly dying.
01:30:52  <isaacs>at the very least, the agent should know to remove it.
01:31:18  * mikealjoined
01:32:11  * dshaw_quit (Quit: Leaving.)
01:32:30  * seebees1part
01:33:08  * c4miloquit (Remote host closed the connection)
01:33:16  <isaacs>piscisaureus_: maybe this?
01:33:18  <isaacs> } else {
01:33:18  <isaacs> onRemove();
01:33:38  <piscisaureus_>yeah, why not?
01:33:53  <piscisaureus_>isaacs: would people care if they created an Agent manually?
01:33:59  * c4milojoined
01:34:02  <piscisaureus_>isaacs: about the error?
01:34:21  <mjr_>We do create Agents manually, in case that's useful information.
01:34:43  <isaacs>oh, no, should be onClose();
01:34:52  <bnoordhuis>http.js is getting way too complex...
01:35:01  <isaacs>bnoordhuis: that's why i'm going to rewrite it in 0.9
01:35:18  <bnoordhuis>good idea
01:35:28  <isaacs>the more i look at this thing, the more the rage swells.
01:35:31  <mjr_>That'd be a good time to make sure that keepalive works like people expect.
01:35:37  <isaacs>mjr_: yes.
01:35:41  <mjr_>And by people, I mean me.
01:35:52  <isaacs>i think now we know what features node's http lib should have, and what should be done in something like request
01:36:15  <isaacs>also: client and server should be separate. this code-sharing stuff makes it impossible to find anythign.
01:36:26  <isaacs>1600 lines? srsly!??!
01:36:31  <mjr_>We just started to look at hacking together client keep alive agent magic like request.forever, and it really bothers me.
01:36:32  <isaacs>a js file should be like 1/10th of that.
01:36:54  <mjr_>I mean, it's already unstable enough, and this change is likely to create even more impossible chaos.
01:37:19  <mjr_>But hey guys, look over here, it's a memory leak / uncaught exception crash in production.
01:37:58  * mikealquit (Quit: Leaving.)
01:38:26  <isaacs>mjr_: yeah, we cannot even realistically contemplate your desired keepalive magic in the current grimy state.
01:38:40  <mjr_>yeah, please don't
01:38:54  <mjr_>Let's just get this working solidly and apply more magic in future versions.
01:39:04  <mjr_>I say, as if I get to vote.
01:39:18  <isaacs>mjr_: you definitely are a significant vip
01:39:19  <mjr_>By which I mean, "please"
01:39:58  <isaacs>i think a good first step will be to rip out http-parser.c and replace it with a js thing so we can throw away parser objects instead of keeping them around.
01:40:13  <isaacs>also, that might eventually shut zed shaw up about how we stole his parser.
01:40:38  * abraxasjoined
01:40:44  <mjr_>But dear god, the hello world benchmark performance
01:40:46  <isaacs>but i might just be frustrated and fantasizing right now.
01:40:51  <isaacs>mjr_: IT WILL IMPROVE!
01:40:55  <isaacs>mjr_: regressions are still not allowed.
01:41:08  * isaacsputtin all the features in the vaporware
01:42:02  <isaacs>ok, commute time.
01:42:30  <isaacs>have a good evening, heroes.
01:42:32  * perezd_joined
01:42:35  * isaacsquit (Remote host closed the connection)
01:42:48  * perezdquit (Ping timeout: 272 seconds)
01:42:49  * perezd_changed nick to perezd
01:54:35  * perezd_joined
01:54:43  * perezd_quit (Client Quit)
01:57:55  * perezdquit (Ping timeout: 244 seconds)
02:03:01  * theColequit (Quit: theCole)
02:04:25  * perezdjoined
02:08:51  * c4miloquit (Remote host closed the connection)
02:18:13  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:22:26  * loladiropart
02:23:58  <CIA-155>node: Bert Belder master * r27ddd14 / lib/net.js :
02:23:58  <CIA-155>node: net.js: make Socket.bytesWritten work again
02:23:58  <CIA-155>node: (+6 more commits...) - http://git.io/TbxgKg
02:27:56  * loladirojoined
02:35:31  <CIA-155>node: Bert Belder master * r4624cf1 / src/stream_wrap.cc : stream_wrap.cc: fix typo - http://git.io/j13uuw
02:39:10  * indexzeroquit (Ping timeout: 272 seconds)
02:42:50  * ericktjoined
02:47:04  * isaacsjoined
02:51:09  <CIA-155>node: Ben Noordhuis v0.6 * ree437c0 / (4 files in 3 dirs):
02:51:09  <CIA-155>node: zlib: fix error reporting
02:51:09  <CIA-155>node: - http://git.io/q3OM8w
02:51:27  * ericktquit (Ping timeout: 260 seconds)
02:52:57  <piscisaureus_>bnoordhuis: ouch. found a bad bug
02:53:04  * piscisaureus_blames the reviewer
02:53:11  <bnoordhuis>piscisaureus_: what / where?
02:53:20  <bnoordhuis>oh, you merged it?
02:53:58  <piscisaureus_>bnoordhuis: require('net').createConnection(80, "www.google.com").write("hey", "ucs2")
02:54:57  <bnoordhuis>of course v8 wants to recompile first...
02:55:12  <piscisaureus_>haha
02:55:29  <piscisaureus_>bnoordhuis: nvm. I just have an error in method names, that's all
02:55:33  <piscisaureus_>don't bother to recompile
02:55:49  <bnoordhuis>well, i'll have to eventually, might as well do it now
02:59:47  <CIA-155>node: Bert Belder master * rb673d06 / (src/pipe_wrap.cc src/tcp_wrap.cc src/tty_wrap.cc): Net.js: fix UCS2 write crash due to inconsistent naming - http://git.io/IsBlJg
02:59:58  <piscisaureus_>bnoordhuis: ^-- fixed
03:04:33  <bnoordhuis>piscisaureus_: did you add tests?
03:05:03  <piscisaureus_>bnoordhuis: tests for what?
03:05:27  <bnoordhuis>^ that
03:05:33  <piscisaureus_>bnoordhuis: you see any?
03:05:36  <piscisaureus_>bnoordhuis: nopew
03:05:46  <piscisaureus_>bnoordhuis: maybe, when I'm in the mood
03:05:53  <piscisaureus_>bnoordhuis: but right now I am going to sleep
03:07:46  <piscisaureus_>bnoordhuis: when are you coming to the office? Or, not at all?
03:08:00  <bnoordhuis>dunno, feeling a bit under the weather lately
03:08:09  <bnoordhuis>don't want to infect you all
03:08:22  <piscisaureus_>hmm
03:08:23  <piscisaureus_>yeah
03:08:25  <piscisaureus_>sergi had that too
03:08:32  <piscisaureus_>we had to let him go
03:08:54  <bnoordhuis>poor thing
03:09:13  <piscisaureus_>so said how things sometimes end so early
03:09:39  * isaacsquit (Remote host closed the connection)
03:10:23  <piscisaureus_>je wenst het niemand toe
03:11:06  <bnoordhuis>zo is dat
03:11:14  <bnoordhuis>ga maar slapen, bertje, 's goed voor je
03:13:35  <piscisaureus_>tabee
03:14:18  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:19:18  * indexzerojoined
03:59:26  * ericktjoined
04:02:24  * loladiroquit (Quit: loladiro)
04:07:48  <CIA-155>node: Ben Noordhuis master * r7d2e68f / (src/stream_wrap.cc src/stream_wrap.h): stream_wrap: fix compilation errors - http://git.io/85Te6Q
04:13:17  * bnoordhuisquit (Ping timeout: 260 seconds)
04:38:20  * ericktquit (Quit: erickt)
05:11:40  * orlandovftwjoined
05:23:29  * perezdquit (Quit: perezd)
05:28:12  * paddybyersjoined
05:32:32  * isaacsjoined
05:44:24  * pfox__quit (Ping timeout: 245 seconds)
05:46:11  * pfox__joined
05:48:16  * mikealjoined
06:20:24  * mikealquit (Quit: Leaving.)
06:29:16  * mmaleckichanged nick to mmalecki[away]
06:34:07  * mmalecki[away]quit (Ping timeout: 252 seconds)
06:35:09  * mmalecki[away]joined
06:39:45  * mikealjoined
07:18:14  * AvianFluquit (Ping timeout: 250 seconds)
07:24:02  * AvianFlujoined
07:26:17  * rendarjoined
07:33:39  * avsejquit (Excess Flood)
07:35:10  * avsejjoined
07:43:32  * mmalecki[away]changed nick to mmalecki
07:43:46  * isaacsquit (Remote host closed the connection)
07:43:52  * mmaleckiquit (Quit: Reconnecting)
07:44:01  * mmalecki_joined
07:44:10  * mmalecki_quit (Client Quit)
07:44:30  * mmaleckijoined
08:27:21  * orlandovftwquit (Ping timeout: 256 seconds)
08:37:01  * mmaleckiquit (Ping timeout: 245 seconds)
08:55:54  * mmaleckijoined
09:08:05  * mmalecki_joined
09:09:48  * mmalecki_quit (Client Quit)
09:10:37  * mmaleckiquit (Ping timeout: 260 seconds)
09:16:26  * mmaleckijoined
09:42:17  * avalanche123quit (Ping timeout: 260 seconds)
09:45:44  * avalanche123joined
09:54:45  * theColejoined
10:16:49  * theColequit (Quit: theCole)
10:52:47  <indutny>heya
11:00:44  * luvit-irc-botquit (Remote host closed the connection)
11:32:37  <indutny>ircretary: please tell isaacs to ping me
11:32:37  <ircretary>indutny: I'll be sure to tell isaacs
11:38:29  * AlbireoX_joined
11:42:45  * AlbireoXquit (Remote host closed the connection)
12:00:11  * abraxasquit (Remote host closed the connection)
12:00:42  * abraxasjoined
12:05:04  * abraxasquit (Ping timeout: 255 seconds)
12:24:16  * loladirojoined
12:26:30  * loladiroquit (Client Quit)
12:29:02  * loladirojoined
12:46:06  * elijah-mbpquit (Remote host closed the connection)
12:48:19  * c4milojoined
13:17:05  * piscisaureus_joined
13:20:36  * bnoordhuisjoined
13:28:21  * ljacksonquit (Ping timeout: 255 seconds)
13:30:53  <indutny>oh oh
13:30:59  <indutny>bnoordhuis: piscisaureus_ hoya
13:31:05  <piscisaureus_>allo allo
13:31:09  <bnoordhuis>indutny: olla
13:31:11  <indutny>guys, I hardly need some feedback on that https://github.com/joyent/libuv/pull/413
13:31:20  <indutny>sorry, hadn't got a chance to do it before
13:31:21  <bnoordhuis>you hardly need some feedback? okay
13:31:23  * bnoordhuisleans back
13:31:24  <indutny>hahaha
13:31:33  <indutny>sorry for engrish
13:33:22  <bnoordhuis>indutny: reviewing
13:33:39  <piscisaureus_>indutny:
13:33:39  <piscisaureus_>uv_stdio_container_t stdio[3];
13:33:39  <piscisaureus_>int stdio_count;
13:33:50  <indutny>yep
13:33:54  <piscisaureus_>indutny: so how would you do 4 stdios?
13:34:03  <indutny>piscisaureus_: that's another question
13:34:08  <indutny>I can't get how it'll work
13:34:21  <indutny>what is a forth stdio supposed to be used for?
13:34:38  <piscisaureus_>indutny: ben knows that. I think, sendmail etc ?
13:34:44  <piscisaureus_>indutny: systemd
13:35:04  <indutny>so it's like fd=3 ?
13:35:12  <piscisaureus_>yes
13:35:24  <piscisaureus_>if you set 4 stdio fds then fd3 will be something
13:35:27  <indutny>piscisaureus_: so it should be remapped in child
13:35:33  <indutny>piscisaureus_: with dup2
13:36:10  <bnoordhuis>yes
13:36:58  <bnoordhuis>indutny: i can live with always using socketpairs instead of either socketpairs or pipes
13:37:18  <bnoordhuis>that division was introduced when ryan added ipc pipes but it's an unnecessary division afaict
13:38:04  <indutny>well, I don't mind too
13:38:17  <indutny>but it doesn't add a lot of complexity too
13:39:14  <bnoordhuis>no, that's true
13:39:20  <bnoordhuis>but it doesn't add anything of value either
13:39:34  <indutny>ok, I'll remove IPC flag
13:39:38  <indutny>and use socketpairs then
13:39:56  <indutny>brb
13:40:41  <bnoordhuis>piscisaureus_: what do you think?
13:40:58  <bnoordhuis>uv_stdio_container_t stdio[3] needs to be of arbitrary size but apart from that
13:42:30  <indutny>yep
13:42:37  <indutny>can I use uv_stdio_container_t stdio[] ?
13:42:44  <indutny>(w/o exact size)
13:43:19  <bnoordhuis>indutny: no, it would have to be a pointer
13:43:29  <indutny>oh, so one should allocate it and destroy it
13:43:35  <indutny>one who'll use APi, of course
13:43:51  <indutny>that's a PITA
13:44:58  <bnoordhuis>yeah, but there's no way around that
13:46:47  * ljacksonjoined
13:59:57  <indutny>ok
14:00:01  <indutny>sounds good
14:07:56  * c4milochanged nick to c4milo|breakfast
14:12:05  <indutny>ok, gtg
14:12:10  <indutny>should be back in 3 hours
14:13:44  * mmaleckichanged nick to mmalecki[away]
14:21:07  * c4milo|breakfastchanged nick to c4milo
14:32:45  * loladiroquit (Quit: loladiro)
14:37:33  * elijah-mbpjoined
14:41:10  * loladirojoined
14:44:56  * loladiroquit (Client Quit)
14:47:46  <CIA-155>node: Alex Kocharin master * re859271 / (lib/util.js test/simple/test-util-inspect.js): util: handle non-string return value in .inspect() - http://git.io/s-NDnA
14:53:12  <piscisaureus_>bnoordhuis: can we make part of the handle flags field shared?
14:54:36  <bnoordhuis>piscisaureus_: sorry, back in a bit - gotta pick up mees from the kinderdagverblijf
14:54:55  * TheJHjoined
15:11:34  <piscisaureus_>ah, fun
15:11:42  <piscisaureus_>node-fibers on windows uses native fibers
15:12:14  <piscisaureus_>I wonder how many random errors that will summon, considering that we're compiling with fiber-safe off
15:13:03  <pfox__>:(
15:13:15  <pfox__>its sad how much energy goes into the windows version. and for what?
15:14:16  <piscisaureus_>pfox__: for world domination?
15:15:00  <pfox__>i suppose i have a more caustic view, heh.
15:18:21  * loladirojoined
15:18:21  * loladiroquit (Client Quit)
15:27:16  * isaacsjoined
15:28:32  * loladirojoined
15:33:17  <bnoordhuis>piscisaureus_: back
15:33:23  <bnoordhuis>handle flags shared? why?
15:33:38  <piscisaureus_>bnoordhuis: well you basically did that in your refcount refactor patch
15:33:50  <piscisaureus_>but you said UV_HANDLE_ACTIVE = 0x800
15:33:59  <piscisaureus_>but that clashes very badly with the flags windows uses internally
15:34:32  <piscisaureus_>bnoordhuis: the values don't have to be shared, as long as the symbols match
15:35:01  * mmalecki[away]changed nick to mmalecki
15:35:12  <bnoordhuis>sure. i can live with the values being shared too, actually
15:35:30  <bnoordhuis>less divide between uv-unix and uv-win == better
15:35:33  <piscisaureus_>bnoordhuis: yeah, I could live with that too, but it takes work
15:35:44  <piscisaureus_>bnoordhuis: we are using #defines for one, and you are using an enum
15:35:51  <bnoordhuis>piscisaureus_: nobody said your internship was going to be easy
15:36:00  <tjfontaine>heh
15:36:19  <bnoordhuis>i prefer enums or enums + defines
15:36:23  <bnoordhuis>enums are convenient when debugging
15:36:39  <piscisaureus_>bnoordhuis: how was it to be hired by an intern?
15:36:46  <piscisaureus_>bnoordhuis: must suck heh
15:36:59  <piscisaureus_>bnoordhuis: anyway, I prefer #defines for flag fields
15:37:24  <bnoordhuis>piscisaureus_: why?
15:37:37  <bnoordhuis>we can do both btw, #define UV_FOO_FLAG UV_FOO_FLAG
15:37:48  <bnoordhuis>defines + nice symbolic names in the debugger
15:43:54  <isaacs>indutny: ping
15:46:06  * loladiroquit (Quit: loladiro)
15:46:46  <piscisaureus_>http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/ <-- someone doing benchmarks w/o reading the manual again
15:47:29  <bnoordhuis>yeah, i saw that
15:47:40  <piscisaureus_>I mean, fs.readFile("foo.html", "binary", function(err, file) {
15:47:41  <piscisaureus_>srsly
15:47:54  * dshaw_joined
15:47:55  <piscisaureus_>although it seems we really have to fix the cluster load balancing issue
15:49:18  <bnoordhuis>open an issue so we don't forget about it
15:50:13  <piscisaureus_>bnoordhuis: we gotta fix it quickly
15:51:00  <bnoordhuis>yeah, but it's not like it's the only bug that needs fixing :/
16:03:58  * bnoordhuisis off to dinner
16:04:16  <bnoordhuis>ps, i'm working on reproducing https://github.com/joyent/node/issues/3236
16:04:32  <bnoordhuis>input appreciated
16:05:32  * loladirojoined
16:10:14  * perezdjoined
16:17:12  * orlandovftwjoined
16:20:08  * loladiroquit (Quit: loladiro)
16:23:10  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:25:06  * piscisaureus_joined
16:28:22  <isaacs>bnoordhuis: reproduction would be good, but i think i have a fix forthat.
16:31:48  <isaacs>mjr_: any way you could test this out? https://github.com/isaacs/node/commit/d6d592ab101ca07a8b3a29ca3887621b46974529
16:34:41  <isaacs>piscisaureus_: http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/#comment-14
16:36:58  <piscisaureus_>isaacs: http://news.ycombinator.com/item?id=3949187
16:37:04  <piscisaureus_>isaacs: but your comment is probably more effective
16:37:28  * elijah-m_joined
16:37:28  <isaacs>i don't understand how vert.x can possibly be 10x more effecie.
16:37:31  <isaacs>*effective
16:37:38  <isaacs>it has to be caching the file.
16:38:48  * mikealquit (Quit: Leaving.)
16:39:19  <isaacs>piscisaureus_: even the "binary" vs buffers approach is not such a big deal on my machine
16:39:31  <mmalecki>wait, so that's the code for the benchmark? https://github.com/purplefox/vert.x/blob/master/src/examples/java/httpperf/nodejs-server.js
16:39:34  <piscisaureus_>isaacs: if you use createReadStream?
16:39:41  <isaacs>piscisaureus_: roughly the same
16:39:52  <AvianFlu>mmalecki, yes, lol
16:39:53  <isaacs>piscisaureus_: the fastest is doing readFile up front, and sending the buffer as res.end(data)
16:40:07  * elijah-m_changed nick to elijah-mbp_
16:40:12  <isaacs>piscisaureus_: that yields about a 2x - 5x performance improvement.
16:40:24  <piscisaureus_>isaacs: and then, run using cluster?
16:40:35  <isaacs>piscisaureus_: this wasn't via cluster, hold on a sec...
16:40:39  <piscisaureus_>isaacs: does that actually saturate the cores
16:40:44  <mmalecki>I lol'd
16:40:49  <piscisaureus_>isaacs: because cluster load balancing is pretty poor
16:40:56  * elijah-mbpquit (Ping timeout: 260 seconds)
16:44:02  <isaacs>yeah, the lb is shit
16:44:13  <isaacs>with cluster, it's still only maxing out 2 cores.
16:44:21  <isaacs>of course, this is ab on
16:44:33  <isaacs>so basically, what's happening is ab is taking one, the server is taking the other, and there's no load balancing happening
16:45:00  <isaacs>with ab -c50 -n10000, it was roughly the same performance
16:45:03  * ericktjoined
16:45:11  <isaacs>with ab -c50 -n100000, it was significantly worse
16:45:34  <isaacs>but this of course is not a rigorous benchmark, so don't read into it.
16:45:42  <isaacs>but i think the numbers speak for themselves.
16:51:35  <indutny>pong
16:51:46  <indutny>isaacs: ^
16:52:01  <indutny>aaah
16:52:22  <indutny>sorry, everything is fine now
16:52:37  <indutny>I wanted to ask you a few questions about stdio+spawn API
16:52:42  <indutny>but it's clear to me now
16:53:43  <indutny>:)
16:56:50  <isaacs>great!
16:56:51  <isaacs>:)
16:59:01  <indutny>bnoordhuis: yt?
16:59:19  <indutny>bnoordhuis: can you please tell me, what's the difference between pipe and socketpair?
16:59:30  <indutny>bnoordhuis: one is half-duplex and other is full-duplex, right?
17:02:39  <piscisaureus_>indutny: that's the difference
17:02:47  <indutny>piscisaureus_: ok then
17:03:02  <indutny>btw, does anyone see glamoruous boxes on github?
17:03:08  <AvianFlu>yes
17:03:17  <indutny>oh, their fonts are dead
17:03:54  <piscisaureus_>indutny: but the catch is that it's not possible for the write end of the pipe to detect a pipe being closed
17:04:06  <indutny>piscisaureus_: yep, I know
17:04:12  <indutny>piscisaureus_: how are things going with socketpair?
17:04:12  <piscisaureus_>indutny: so probably it's also okay to stick to socketpairs
17:04:44  <indutny>I mean, is there any close notification?
17:05:03  <piscisaureus_>indutny: well you can just read
17:05:17  <piscisaureus_>indutny: and then if the pipe is closed you'll get EPIPE or 0
17:05:31  <indutny>so it's exactly the same behaviour as pipes
17:06:27  <indutny>oh, boxes just fixed
17:06:50  <piscisaureus_>indutny: well you can't read the write end of a pipe, so you can't know if it has been closed
17:07:16  <indutny>yep, but with socketpair both ends are writable
17:08:40  <piscisaureus_>yep, and readable, that's more important :-)
17:09:10  <indutny>hahaha
17:09:21  <indutny>socketcloak
17:09:40  <indutny>creates two identical indistinguishable sockets, which are both writeable, but not readable
17:12:57  <piscisaureus_>isaacs: hey. Will the new npm website track downloads?
17:13:11  <isaacs>piscisaureus_: yeah, i'm going to work with JasonSmith on that.
17:13:51  <isaacs>piscisaureus_: he's working on some new magic for downloads to be out of the couchdb itself
17:13:57  <indutny>wow
17:14:03  * hij1nxjoined
17:14:05  <isaacs>so that'll make replication WAAAAYYY faster
17:14:22  <isaacs>and the couch itself will go from being like 12gb down to a few hundred mb, maybe
17:14:57  <mmalecki>isaacs: hm, but how will people be able to replicat tarballs then?
17:15:14  <isaacs>mmalecki: we'll point the dist.tarball url to just point somewhere else.
17:15:33  <isaacs>mmalecki: so... you won't replicate the tarballs, you'll replicate teh metadata, including the tarball location and shasum
17:15:41  * mikealjoined
17:15:43  <isaacs>then you'll fetch the tarball from somewhere, compare the shasum, etc.
17:15:47  <mmalecki>that'll greatly increase complexity
17:15:49  <indutny>isaacs: well, that's not good
17:16:00  <indutny>more failure points
17:16:15  <isaacs>mmalecki: also, the actual tarball data will be edge-cached, and almost certainly faster, especially if you're many hops from the registry couchdb
17:16:29  <isaacs>CDN-style
17:16:36  <isaacs>at least, that's the vision. we'll see how it works out :)
17:16:48  <isaacs>but it'll be transparent, i believe.
17:16:49  <indutny>isaacs: that may be good for npm itself
17:16:56  <isaacs>indutny: it'll be good for the vast majority of npm users.
17:17:06  <isaacs>and for the majority of npm replicators as well.
17:17:14  <isaacs>we *will* have to have some way to replicate the full thing with attachments.
17:17:16  <indutny>what about private repos?
17:17:23  <isaacs>indutny: it won't change the client.
17:17:31  <isaacs>it'll just be magic that moves the attachments out of the couchdb on the server-side.
17:17:39  <isaacs>if you dont do that to your couchdb, then it won't matter.
17:17:47  <indutny>ok, so the only real concern for me is a replication
17:18:01  <mmalecki>yeah, same here
17:18:03  <isaacs>indutny: right, and replication is a huge pita right now, in large part because of the size of the db and the number of attachments.
17:18:11  <isaacs>so, we'll be making that work a lot better.
17:18:34  <indutny>piscisaureus_: do we need UV_DUPLEX_PIPE option then?
17:18:37  <mmalecki>ok, so the world is safe
17:18:39  <isaacs>jason has some good stuff planned for npm registries.
17:18:43  <indutny>piscisaureus_: it is essentially the same as socketpair or IPC
17:18:44  <isaacs>i'm really excited.
17:18:59  <isaacs>and it's gonna make iriscouch the (even more) obvious place to do your couchdb stuff.
17:19:03  <piscisaureus_>indutny: yeah please hang on to the flag.
17:19:13  <piscisaureus_>indutny: just ignore the flag for the moment
17:19:19  <indutny>piscisaureus_: ah, ok
17:19:32  <indutny>piscisaureus_: should I keep IPC flag too?
17:19:54  <piscisaureus_>indutny: yes. On windows IPC some special protocol is used that only libuv understands
17:20:09  <piscisaureus_>indutny: so if you are talking to non-node you dont want to set the IPC flag
17:20:22  <indutny>isaacs: I was really excited about couchdb 2 years ago, but after working for half of year with it
17:20:30  <indutny>isaacs: I got to say that it's quite retarded
17:20:32  * theColejoined
17:20:51  <indutny>isaacs: especially when dealing with a lot of simultaneous requests and complex views
17:20:52  <piscisaureus_>indutny: (windows whas the sole reason for having the ipc flag)
17:20:53  <mmalecki>indutny: it saved my ass few times :)
17:21:01  <indutny>piscisaureus_: ok ok :)
17:21:10  <indutny>piscisaureus_: cool
17:23:45  * hij1nxquit (Quit: hij1nx)
17:24:05  * loladirojoined
17:28:30  * mmaleckichanged nick to mmalecki[away]
17:29:27  * loladiroquit (Remote host closed the connection)
17:29:44  * loladirojoined
17:36:34  * mikealquit (Quit: Leaving.)
17:37:57  * loladiro_joined
17:40:12  * dshaw_quit (Quit: Leaving.)
17:41:57  * mikealjoined
17:42:20  * loladiroquit (Ping timeout: 265 seconds)
17:42:20  * loladiro_changed nick to loladiro
17:43:50  <dap>bnoordhuis: hi :)
17:45:03  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:45:13  * mikealquit (Client Quit)
17:46:09  * mikealjoined
17:47:54  <dap>I just upgraded to 0.6.17, which includes the fix for the libuv bug you helped me with last week. Unfortunately, it just pushed the assertion failure here:
17:47:54  <dap>https://github.com/joyent/node/blob/master/src/pipe_wrap.cc#L207
17:50:08  * avalanch_joined
17:51:48  * TooTallNatejoined
17:53:23  * elijah-mbpjoined
17:53:36  * avalanch_changed nick to avalanche123|w
17:53:53  <dap>We may want to have libuv just swallow the "accept" error just like it does in uv__server_io. I don't think there's any point in propagating EAGAIN
17:54:24  * paddybyersquit (Ping timeout: 255 seconds)
17:54:49  * elijah-m_joined
17:55:46  * elijah-mbp_quit (Ping timeout: 260 seconds)
17:55:48  * piscisaureus_joined
17:55:53  <bnoordhuis>dap: hey
17:56:38  <bnoordhuis>was it actually EAGAIN that you got?
17:56:47  * elijah-__joined
17:56:59  <bnoordhuis>if so, i don't know why we pass that up :)
17:57:50  * hij1nxjoined
17:57:53  <dap>EAGAIN == EWOULDBLOCK, on illumos anyway
17:58:06  * elijah-mbpquit (Ping timeout: 260 seconds)
17:58:38  <piscisaureus_>igorzi: are you still working on the symlink stuff or did you exceed your node quota for this week?
17:58:43  <dap>oh, I see. I'm rereading the code now.
17:59:11  <bnoordhuis>dap: hm, v0.6 works differently than master
17:59:22  <igorzi>piscisaureus_: still working
17:59:30  <piscisaureus_>igorzi: cool
17:59:33  <igorzi>piscisaureus_: should have another patch in a few hours
17:59:48  <bnoordhuis>but not that differently - EAGAIN isn't passed on to the cb
18:00:26  * elijah-m_quit (Ping timeout: 260 seconds)
18:00:34  <dap>yeah, I'm trying to see what it actually is now.
18:01:17  <dap>oh, it was EINVAL
18:02:11  <dap>well, that's the current value, but that's not even documented to be returned by accept. Let me see if I can dig it out of the structure.
18:03:59  * orlandovftwquit (Ping timeout: 245 seconds)
18:05:33  <indutny>bnoordhuis: do we have some sort of EALLOC error?
18:05:43  <bnoordhuis>indutny: ENOMEM
18:05:57  <indutny>nice
18:05:58  <bnoordhuis>dap: i guess you get EINVAL if you call accept() on a socket that's not listening
18:06:41  <bnoordhuis>at least, that what accept() on linux does
18:06:52  * bnoordhuishas been staring at the kernel impl of accept() a lot lately
18:07:21  * loladiroquit (Quit: loladiro)
18:08:14  * theColequit (Quit: theCole)
18:08:41  <dap>I'll see if I can reproduce it with a DTrace script that shows exactly what errno was so we can be sure.
18:11:15  * avalanche123quit (Ping timeout: 240 seconds)
18:11:15  * avalanche123|wchanged nick to avalanche123
18:12:15  <dap>yeah, it's definitely accept returning EINVAL
18:14:06  <bnoordhuis>dap: what kind of socket is it? tcp, udp?
18:14:19  <dap>I think it's UDS
18:15:06  <bnoordhuis>what does the code look like that creates/binds the socket?
18:15:12  * bulatshakirzyanojoined
18:17:50  <dap>https://github.com/mcavage/node-zsock/blob/master/lib/zsock.js
18:19:44  * felixgejoined
18:19:44  * felixgequit (Changing host)
18:19:44  * felixgejoined
18:20:24  <bnoordhuis>dap: you're using an awful lot of internals...
18:21:09  <dap>?
18:21:31  * pieternjoined
18:22:00  <bnoordhuis>dap: using pipe_wrap directly
18:22:26  <felixge>isaacs: hi
18:22:26  <bnoordhuis>+like that
18:22:31  <bnoordhuis>voids the warranty
18:22:42  <dap>what can we be doing instead?
18:23:08  <dap>and is that what's causing the core dump?
18:23:34  <bnoordhuis>probably yes
18:23:50  <bnoordhuis>what are you using listenFD for?
18:24:18  <dap>Can you tell which change caused the change in behavior? (This was working on 0.6.12, modulo the EAGAIN issues.)
18:24:35  <bnoordhuis>don't know, could be a number of things
18:25:21  <dap>Effectively, we have a UDS fd that has state associated with it, and we want to create an HTTP server on top of it.
18:26:13  <felixge>isaacs: ping me when you want to finish discussing the error reporting things
18:27:26  <dap>bnoordhuis: I think the history here is that we were using listenFD before it was ripped out, and isaacs suggested that we use a pipe to implement something that looks like listenFD but shuffles the data back and forth. But I wasn't actually there for those discussions.
18:27:47  <isaacs>felixge: yo
18:27:55  <isaacs>felixge: oh, right, you had another patch
18:28:00  <isaacs>lemme go review that ;)
18:28:09  <indutny>bnoordhuis: piscisaureus_: https://github.com/joyent/libuv/pull/413 <- done
18:28:16  <indutny>I mean finished unix support
18:28:52  <mjr_>isaacs: I can try that. Is that patch already on the v0.6 branch?
18:29:05  <isaacs>mjr_: yeah
18:29:14  <felixge>isaacs: https://github.com/joyent/node/pull/3238/commits
18:29:20  <isaacs>felixge: yeah, reading it now
18:29:29  <isaacs>felixge: i actually prefer reading git diff
18:29:30  <indutny>piscisaureus_: I'll definitely need your assistance for win support
18:29:32  <isaacs>git show, etc.
18:29:38  <bnoordhuis>dap: okay. it's not really supported right now (will be again in v0.8)
18:29:49  <bnoordhuis>there's no good story except tread carefully
18:30:11  <isaacs>felixge: i freaking <3 this.
18:30:14  <isaacs>felixge: it's so much nicer.
18:30:15  <dap>Alright. I'll see if I can figure out which commit broke this behavior for us. Maybe that will shed some light on what we can do to avoid it.
18:31:28  <felixge>isaacs: I also think this patch looks interesting: https://github.com/joyent/node/commit/267c31f2a004444e7ff96430b74065e69b91d340
18:32:09  <isaacs>felixge: what's the point of that? i don't get it.
18:32:12  * Skomskijoined
18:32:13  * loladirojoined
18:32:42  <isaacs>felixge: so the name will be http_native instead of http.js?
18:33:09  <felixge>no
18:33:24  <felixge>it won't show the `throw` call site if the error is within a native module
18:33:35  <felixge>isaacs: https://github.com/joyent/node/pull/3238#issuecomment-5595217
18:33:39  <isaacs>oh, no, that's a bad idea.
18:33:51  <felixge>it's just meant to lessen the confusion for new users
18:34:13  <tjfontaine>I'm not sure it achieves taht
18:34:31  <felixge>so is anybody going to comment on this HN benchmark thing?
18:35:06  <bnoordhuis>lots of people already did
18:35:11  <isaacs>felixge: i commented on the blog post itself
18:37:54  <felixge>isaacs: reading that
18:39:18  <felixge>I guess no point in further commenting, the people who don't look at the benchmark code are a lost case anyway
18:39:19  <felixge>:)
18:39:27  <indutny>bnoordhuis: piscisaureus_: do you have gtalk accounts?
18:39:50  <bnoordhuis>indutny: yes, but i never use it
18:39:59  <piscisaureus_>indutny: i can give you windows support
18:40:14  <felixge>isaacs: let me know if you have more questions / concerns regarding my patches for 0.6.x
18:41:13  <indutny>piscisaureus_: that would be nice
18:42:59  <isaacs>felixge: i'm probably going to land this.
18:43:08  <isaacs>felixge: sorry, bunch of parallel conversations :)
18:43:18  <felixge>isaacs: take your time, I'll be around for a while
18:43:36  <isaacs>felixge: just trying to work out what the effects will be. changing semantics even slightly is very hazardous in the module system in general, especially in a stable branch.
18:43:57  <isaacs>felixge: but it looks like this has the same exact side effects of throwing, just without obscuring the source.
18:44:13  <piscisaureus_>indutny: if you can make it work with 3 fds on windows I am already very proud
18:44:26  <piscisaureus_>getting it to work with >3 is umm, hairy :-)
18:44:31  <indutny>piscisaureus_: hahahaha
18:44:40  <indutny>piscisaureus_: yep, w/o fork things get weird
18:44:45  <piscisaureus_>you have to use undocumented APIs for that
18:44:46  <felixge>isaacs: yeah, I agree, this needs careful review
18:44:53  <felixge>isaacs: but it shouldn't change any semantics at all
18:44:57  <felixge>at least that was the goal
18:44:57  <felixge>:)
18:44:59  <isaacs>felixge: and i think we can probably do this patch, and then just modify it slightly for domains in master, and add the 'scrub the loading cache as well' so that piscisaureus_'s forfelix test does the right thing.
18:45:00  <indutny>btw, what if I've a lot of io requests hanging in uv
18:45:11  <felixge>yeah
18:45:11  <indutny>piscisaureus_: all fds will be cloned to child process
18:45:20  <indutny>piscisaureus_: and never will be closed
18:45:25  <piscisaureus_>indutny: no, we sould set cloexec on all the FDs
18:45:32  <indutny>piscisaureus_: all FDs?
18:45:39  <indutny>piscisaureus_: ah, I got it
18:45:40  <isaacs>felixge: also, i'm a bit afraid that domains may sometimes cause nextTick errors to be obscured. my original rebase of your patch didn't preserve its intent properly, that's why i closed it.
18:45:46  <indutny>good
18:45:47  <piscisaureus_>indutny: we set cloexec when a handle is opened
18:45:56  <isaacs>felixge: i'll look into that
18:46:02  <felixge>isaacs: hm, should be solvable so
18:46:06  <indutny>yep, got it
18:46:07  <indutny>nice
18:46:22  <piscisaureus_>indutny: in windows, cloexec is set by default except for sockets, but we set it explicitly for sockets
18:46:48  <indutny>unix C apis are SO INTERESTING
18:46:49  <piscisaureus_>indutny: so on spawn() we should clear the cloexec flag for fds that are to be inherited
18:46:59  <indutny>piscisaureus_: yep, I got it
18:49:01  * Skomskiquit (Quit: Nettalk6 - www.ntalk.de)
18:49:18  * Skomskijoined
18:50:34  * isaacsquit (Ping timeout: 248 seconds)
18:51:54  <indutny>bnoordhuis: piscisaureus_: so what about PR for unix side?
18:52:05  <indutny>piscisaureus_: bnoordhuis : does it looks good to you?
18:52:10  <piscisaureus_>indutny: I'll take a look. I have to run now
18:52:16  <indutny>k, np
18:54:07  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:56:02  <CIA-155>node: Felix Geisendörfer v0.6 * r8140333 / (6 files in 2 dirs):
18:56:02  <CIA-155>node: Fix process.nextTick throw call sites
18:56:02  <CIA-155>node: - http://git.io/9e-7Hw
18:56:02  <CIA-155>node: Felix Geisendörfer v0.6 * rbf9d8e9 / (5 files in 2 dirs):
18:56:02  <CIA-155>node: Fix exception output for module load exceptions
18:56:02  <CIA-155>node: - http://git.io/eT3kUw
18:56:58  * isaacsjoined
19:02:35  <isaacs>felixge: ok, lgtm. landed on v0.6
19:02:52  <felixge>isaacs: :) sweet!
19:03:56  * brsonjoined
19:05:41  * mikealquit (Quit: Leaving.)
19:05:55  * mmalecki[away]changed nick to mmalecki
19:08:42  <indutny>:)
19:08:44  <indutny>felixge: ++
19:08:44  <kohai>felixge has 1 beer
19:14:52  * mikealjoined
19:15:23  * AvianFluquit (Ping timeout: 244 seconds)
19:16:16  <isaacs>when will i learn that hacker news commenters are incapable of basic mathematics.
19:17:34  <isaacs>"Herpdeederp! JVM is faster than V8, so it makes sense that a server serves 10x as many reqeusts! I put ketchup on my bananas! Where am I?" -- typical hacker news commenter
19:18:44  <mmalecki>this will happen everywhere humans are involved
19:18:54  * mikealquit (Client Quit)
19:19:04  <mmalecki>but in some communities it's easier to notice
19:19:11  <benvie>lol ketchup on bananas, that one I'm going to use
19:19:52  <benvie>I have a french second cousin who puts ketchup on waffles
19:19:55  <benvie>that's fucked
19:21:16  <isaacs>to be fair, i suppose, it *does* take a bit of practice to get used to saying, "Wait a second... these are numbers. I should probably do math, rather than try to use instinct here."
19:21:53  <mmalecki>I mean, these guys are programmers
19:22:00  <benvie>and humans
19:22:03  <benvie>which means dumb
19:22:09  <mmalecki>fair enough.
19:22:15  * AvianFlujoined
19:22:35  <mmalecki>I'm wondering if someone posted it to r/programming already
19:22:48  <CIA-155>node: isaacs master * r5979f09 / (doc/api/buffer.markdown lib/buffer.js src/node.cc): Fix #3242 Actually deprecate 'binary' buffer encoding - http://git.io/xAJSRg
19:22:51  <benvie>hail to our incoming Artifical General Intelligence overlords in the next decade or two
19:23:22  <mmalecki>hey, these guys are going to write code for my wheelchair.
19:23:41  <benvie>a wheelchair coded in Java
19:23:48  <mmalecki>please no
19:23:53  <benvie>that makes an awesome mental picture
19:24:11  <mmalecki>yeah, Java has memory problems too
19:24:50  <benvie>also adult diapers
19:25:15  <pfox__>hey guys.. where would i look for examples of using c-ares w/ libuv?
19:27:02  <tjfontaine>node/cares_wrap.cc?
19:27:45  * AvianFluquit (Ping timeout: 240 seconds)
19:29:54  <bnoordhuis>pfox__: also, test/test-gethostbyname.c
19:30:00  * AvianFlujoined
19:31:14  * AvianFluquit (Remote host closed the connection)
19:31:50  * AvianFlujoined
19:34:23  <indutny>bnoordhuis: review? https://github.com/joyent/libuv/pull/413
19:34:42  <pfox__>thanks
19:39:17  <saghul>pfox__ you may look here as well: https://github.com/saghul/pyuv/blob/master/src/dns.c
19:42:11  * Skomskiquit (Quit: Nettalk6 - www.ntalk.de)
19:45:21  * AvianFluquit (Ping timeout: 244 seconds)
19:58:43  * hij1nxquit (Quit: hij1nx)
19:59:51  <creationix>what causes a node stream to cancel? Support I fs.createReadFile("mymovie.mp4").pipe(httpResponse) and the browser cancels the download
19:59:58  <creationix>s/Support/Suppose/
20:00:27  <indutny>bnoordhuis: fixed issues in that PR
20:00:28  <mjr_>error event, which should turn into a call to destroy()
20:01:47  <creationix>mjr_, what kind of error
20:02:24  <creationix>my issue is I have proxied streams and the cancel isn't propagating
20:02:36  * creationixgoes to look for error and destroy in pipe()'s code...
20:03:37  <mjr_>I dunno. I never actually use pipe like that, because we always need to do other logic around cases like aborted, errors, back pressure, etc.
20:03:38  <creationix>hmm, doesn't seem to be part of pipe's logic
20:04:10  <mjr_>There's an "aborted" event on the response you can listen for, which you can explicitly convert into a destroy on the read stream.
20:04:51  <creationix>that's neat, I wonder why .pipe doesn't do that already
20:05:01  <isaacs>creationix: because it's a very inconsistent surface, unfortunately.
20:05:09  <isaacs>creationix: not all pipes have the same methods or events.
20:05:12  <creationix>my case I need to create a fake stream that can be piped to a http response
20:05:14  <isaacs>creationix: this is going ot be fixed in 0.9
20:05:25  <creationix>isaacs, sounds great
20:05:40  * orlandovftwjoined
20:06:20  <mjr_>Streams are great, but I find that anything interesting needs to deal with the events explicitly.
20:06:52  <creationix>indeed
20:06:54  <mjr_>It's really fun to stick stuff together with pipe though, especially if you can chain streams together. Man, that's neat looking.
20:07:15  <mjr_>All that power in one line of code.
20:07:22  <creationix>hmm, looks like pipe doesn't do much at all other than check the return value of write and call pause https://github.com/joyent/node/blob/master/lib/stream.js#L36-42
20:07:28  <creationix>(for write calls)
20:08:44  <creationix>here, I'm creating my proxy stream https://github.com/c9/vfs/blob/master/socket/consumer.js#L29-41
20:09:02  <creationix>remote.send write a rpc command to the underlaying pipe
20:09:17  <creationix>so backpressure is working
20:09:33  <creationix>but I seem to keep on writing data after the browser cancels the download
20:09:54  <creationix>err, that's the wrong end, sorry
20:10:01  <creationix>that's for the browser uploading data to the server
20:10:08  * AvianFlujoined
20:10:40  <creationix>here is data going to the browser https://github.com/c9/vfs/blob/master/socket/worker.js#L33-43
20:11:06  <creationix>and then the other end does https://github.com/c9/vfs/blob/master/socket/consumer.js#L69-78
20:11:39  <creationix>that `stream.emit("data", chunk);` is what stream.pipe(res) is picking up and sending to the browser.
20:11:50  <indutny>ok, I'm going to pass out
20:11:59  <indutny>ping me by email or on issue in any case
20:13:38  * hij1nxjoined
20:13:56  <indutny>ttyl guys, time to sleep
20:14:25  <creationix>g'night indutny
20:14:30  * mjr_part
20:15:09  <creationix>hmm, I'm not sure I can use .pipe as is
20:15:10  * mjr_joined
20:15:26  <creationix>.pipe simply ignores data events if the dest is not .writable
20:17:50  <creationix>hmm, and .pipe doesn't destroy the source on error or close
20:17:55  <creationix>it just stops listening
20:18:17  * hij1nx_joined
20:18:40  <creationix>isaacs, is there a document somewhere with the plans for streams on 0.9.x or is it still in various people's heads?
20:18:56  <isaacs>creationix: heads, mostluy.
20:19:02  <isaacs>creationix: the documented goal is "make it good"
20:19:13  <isaacs>but it's not much more fleshed out than that
20:19:24  * indexzeroquit (Ping timeout: 245 seconds)
20:19:25  <creationix>this will be hard
20:19:31  <isaacs>indeed.
20:19:38  * rendarquit
20:19:41  <creationix>I have lots of ideas and a few places where I disagree with mikeal
20:19:51  <isaacs>k
20:20:15  <isaacs>after we release 0.8, i'll be much more available to get down and dirty with that api.
20:20:26  <creationix>that's fine, get 0.8 out
20:20:27  <isaacs>but we have to get this done first.
20:20:40  <creationix>still, I need a way to make my code with with 0.6.x APis
20:20:50  <creationix>and I don't pipe gives me enough feedback
20:20:56  <creationix>*I don't think pipe...
20:21:31  * hij1nxquit (Ping timeout: 244 seconds)
20:21:32  * hij1nx_changed nick to hij1nx
20:21:34  <creationix>mjr_, I'm starting to see what you mean about pipe not being powerful enough
20:25:45  * elijah-mbpjoined
20:28:17  * indexzerojoined
20:28:25  <mjr_>I'm still a big fan of how you can do buffering and back pressure with node. write returning false, stream.pause(), stream.resume(). It's a nice low level API.
20:29:14  * orlandov1twjoined
20:29:34  * brson_joined
20:30:48  <felixge>making pipe universally awesome may be impossible
20:31:07  <mjr_>I suspect this is true.
20:31:07  <felixge>but IMO we can do a lot of things to the rest of the Stream API that makes life better
20:31:25  <felixge>which may or may not allow us to think about pipe() more clearly
20:31:36  <felixge>without being distracted by API warts all the time
20:31:39  <mjr_>Having used it for a while now, I can imagine a few things that we could do to make it better in the common cases.
20:31:46  <felixge>yeah
20:31:52  <felixge>and we can also give it more options
20:32:11  <felixge>or make a pipe module
20:32:15  <felixge>with all kinds of utility functions
20:32:18  <felixge>that can be combined
20:32:23  <felixge>(really just thinking out loud here)
20:33:23  <mjr_>Explicitly allowing some amount of buffering is the biggest reason we don't use pipe.
20:34:01  <mjr_>So if we could do a high / low water mark threshold on pause/resume, that would be an obvious win.
20:34:20  * AvianFluquit (Remote host closed the connection)
20:34:24  <felixge>mjr_: agreed, that seems like a no-brainer
20:34:25  <mjr_>Less obvious: number of buffered bytes, or number of buffered writes?
20:34:28  <creationix>hmm, I'm never getting aborted events
20:34:30  <felixge>it's just a performance optimization, right?
20:34:45  <felixge>mjr_: hmm, I'd say bytes
20:34:54  * orlandovftwquit (*.net *.split)
20:34:54  * brsonquit (*.net *.split)
20:34:54  * elijah-__quit (*.net *.split)
20:34:55  <felixge>but you deal with slow clients with lots of tiny data events sometimes, right?
20:35:07  <mjr_>felixge: you know, I thought that it was just an optimization too, but in our case the whole system wouldn't even work if we didn't tolerate at least some buffering.
20:35:41  <felixge>mjr_: I guess because you kill throughput if you apply back pressure too aggressively ?
20:36:06  <felixge>or can u explain/
20:36:11  <mjr_>Yes. And also there are these diabolical feedback cycles that can get started if you don't tolerate a lot of "slop" in the system.
20:36:29  <creationix>Mmmm feedback cycles
20:37:31  <mjr_>And by adding hysteresis through some amount of output buffering, you can break those cycles and get the system stable again.
20:38:50  <creationix>I
20:39:05  <creationix>I'll bet the joyent graphs help in debugging those issues ;)
20:40:30  <pquerna>mmm. raw sockets on win32, reasonable?
20:42:36  * chilts_joined
20:46:21  <creationix>mjr_, couldn't get aborted to work for me, but listening for "close" on the request worked great!
20:46:42  <creationix>https://github.com/c9/vfs/compare/e87b570c58...e3b37749b7
20:47:39  * chiltsquit (Write error: Broken pipe)
20:47:42  <mjr_>But it also destroys throughput in some cases, particularly sending to mobile devices, if you don't allow data to buffer up a bit.
20:47:42  <mjr_>Also applies to wifi devices if you live in any kind of dense wifi environment.
20:47:42  <mjr_>Also also, why do I sound like pedantic IETF guy?
20:47:42  <mjr_>Sometimes, yes.
20:47:43  <mjr_>Honestly, node_pcap was the only way to figure most of them out.
20:47:43  <mjr_>But the Joyent graphs are amazing.
20:47:45  <mjr_>I hope so. Somebody needs to write node ping already.
20:48:33  <creationix>yeah, node_pcap is very useful
20:48:39  <creationix>and pretty when used with http_tracer
20:50:38  <creationix>ok, tougher question, when I run a remote command using ssh, how do I ensure my remote process dies when I close the connection?
20:51:00  <creationix>`ssh creationix.com 'node server.js'`, then Control+C
22:35:53  <piscisaureus_>Slurp definitely needs better auto-reconnect logic
22:39:16  * iraquit (Quit: Leaving...)
22:42:43  <igorzi>piscisaureus_: hey
22:42:50  <igorzi>piscisaureus_: https://github.com/igorzi/libuv/compare/junctions
22:43:35  <piscisaureus_>igorzi: looking at it
22:43:54  <isaacs>igorzi: ++
22:43:55  <kohai>igorzi has 6 beers
22:44:12  <isaacs>indutny: ++ also
22:44:12  <kohai>indutny has 23 beers
22:44:19  <isaacs>stdio and symlinks and refcount oh my!
22:45:24  * mikealquit (Quit: Leaving.)
22:47:54  <piscisaureus_>isaacs: yeah I am still working on the refcount
22:48:07  <piscisaureus_>igorzi: weird question, but, does it work?
22:48:09  * mikealjoined
22:48:14  <piscisaureus_>igorzi: esp. lstat
22:48:34  <isaacs>piscisaureus_: awesome
22:49:00  <igorzi>piscisaureus_: it depends on what you mean by "work" :) did you look at the new test? that test works
22:49:42  <piscisaureus_>igorzi: ok so lstat() gives you the properties of the link and not the target, right?
22:50:01  <igorzi>piscisaureus_: correct
22:50:32  <igorzi>where st_size is the length of the target
22:50:38  <igorzi>piscisaureus_: ^
22:51:00  <piscisaureus_>igorzi: so, that actually surprises me
22:51:08  <piscisaureus_>igorzi: ah wait you do the size explicitly
22:51:12  <piscisaureus_>igorzi: ok, that's nice
22:51:21  <igorzi>piscisaureus_: yep
22:51:26  <piscisaureus_>igorzi: so the thing is: you resolve the symlink target in get_symlink
22:51:39  <piscisaureus_>igorzi: then you do CreateFileW to open the stat path
22:51:58  <piscisaureus_>igorzi: but the the CreateFileW call doesn't include the FILE_FLAG_OPEN_REPARSE_POINT flag
22:52:16  <piscisaureus_>igorzi: so that means that you're effectively stat()ing the target and not the link
22:52:26  <piscisaureus_>except for the size since you special case for that
22:53:00  <igorzi>piscisaureus_: the link is a directory in this case though, so we get properties for the directory
22:53:22  <igorzi>piscisaureus_: i don't resolve the symlink for lstat
22:53:25  <igorzi>piscisaureus_: only for stat
22:53:50  <igorzi>piscisaureus_: for lstat stat_path just points to path
22:53:53  <piscisaureus_>igorzi: you don't need to resolve the symlink. CreateFileW *always* resolves symlinks automatically unless you explicitly tell it not to
22:54:24  <igorzi>piscisaureus_: hmm.. i didn't know that
22:54:31  <piscisaureus_>igorzi: the flag you specify to not follow a link is FILE_FLAG_OPEN_REPARSE_POINT
22:54:47  <igorzi>piscisaureus_: actually, that makes complete sense
22:55:05  <igorzi>piscisaureus_: otherwise none of the other fs operations would work on symlinks :)
22:55:09  <piscisaureus_>igorzi: yep. otherwise symlinks would never work unless programs delt with them explicitly
22:55:17  <piscisaureus_>indeed :-)
22:55:35  <igorzi>piscisaureus_: ok, so I'll add FILE_FLAG_OPEN_REPARSE_POINT for lstat
22:55:42  <piscisaureus_>igorzi: ok
22:56:00  * bulatshakirzyanoquit (Read error: Connection reset by peer)
22:56:05  <piscisaureus_>igorzi: thanks
22:56:33  <piscisaureus_>igorzi: it would be nice if you could play with it a little bit and see whether it behaves as expected :-)
22:57:12  <piscisaureus_>bnoordhuis: any objections to floating http://codereview.chromium.org/download/issue8240004_1.diff ?
22:57:36  <igorzi>piscisaureus_: yeah.. will do
22:57:39  <igorzi>piscisaureus_: thanks
22:57:39  * hij1nxjoined
22:57:41  <piscisaureus_>bnoordhuis: it unbreaks =fibers and this other thing that shall not be named
22:57:57  <piscisaureus_>bnoordhuis: (you know I don't care about this other thing that shall not be named)
22:58:35  <piscisaureus_>igorzi: I am heading out in a bit. Please send me an email if you get it done, then I'll know to look at it tomorrow
22:59:03  <piscisaureus_>igorzi: if I find nits then I will probably just fix them myself, unless you don't want that.
22:59:29  <bnoordhuis>piscisaureus_: what does that patch do?
22:59:44  <piscisaureus_>bnoordhuis: fix a v8 bug, lemme look it up
23:00:09  <piscisaureus_>bnoordhuis: http://code.google.com/p/v8/issues/detail?id=1763
23:00:26  * mikealquit (Quit: Leaving.)
23:00:41  * bulatshakirzyanojoined
23:00:51  <igorzi>piscisaureus_: nah that's fine.. let me know if you find any nits, and i'll fix them.
23:01:17  <piscisaureus_>igorzi: alright
23:01:21  <bnoordhuis>piscisaureus_: looks okay to me
23:01:29  <piscisaureus_>to me too
23:01:33  <piscisaureus_>bnoordhuis: I am going to land it
23:03:27  * mikealjoined
23:05:58  <CIA-155>node: vegorov@chromium.org v0.6 * r52f0c37 / (3 files):
23:05:58  <CIA-155>node: Runtime_NotifyDeoptimized should search for function activation in all thread stacks.
23:05:58  <CIA-155>node: - http://git.io/XUBrSA
23:06:02  <piscisaureus_>^-- there
23:07:54  * mikealquit (Client Quit)
23:09:17  * mralephquit (Quit: Leaving.)
23:10:49  * chilts_changed nick to chilts