00:00:22  <isaacs>bnoordhuis: any opportunity to look at the ev_* stuff, or will it be a bit longer? wondering if i should cut 0.7.10 now, or wait
00:00:44  <bnoordhuis>isaacs: it won't be tonight, i'm just checking my email
00:00:48  <isaacs>ok, kew
00:00:50  <isaacs>kewl
00:01:02  <isaacs>it can land in 0.7.11 (later this week)
00:01:27  <isaacs>i want to get 0.7.10 out tomorrow morning, though, so that we can have a big "0.8 is coming soon!" blog post with good benchmarks and a version that isn't horridly broken
00:03:37  * loladiroquit (Quit: loladiro)
00:03:49  * hij1nxjoined
00:15:15  <toothr>sahgul, like a subprocess?
00:15:43  <toothr>er, saghul
00:34:44  * loladirojoined
00:36:17  <bnoordhuis>emacs 24.1 elisp now has lexical closures
00:36:26  <bnoordhuis>it's the last omen, now i'm certain the end times are near
00:36:32  <bnoordhuis>someone hold me, i'm scared
00:42:20  * loladiroquit (Read error: Connection reset by peer)
00:49:12  * hij1nxquit (Quit: hij1nx)
00:49:22  <CIA-112>libuv: Ben Noordhuis master * rddb5f55 / (src/unix/internal.h src/unix/process.c): unix: simplify uv__make_pipe() and uv__make_socketpair() - http://git.io/DIkhTA
00:51:21  * travis-cijoined
00:51:21  <travis-ci>[travis-ci] joyent/libuv#402 (master - ddb5f55 : Ben Noordhuis): The build passed.
00:51:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/5c30443...ddb5f55
00:51:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1587885
00:51:21  * travis-cipart
01:05:21  <bnoordhuis>isaacs: https://github.com/joyent/node/pull/3398 <- i appreciate that guy's effort but there's a lot in there i don't want and i don't want to babysit him for the next two weeks...
01:05:52  <isaacs>bnoordhuis: i hear ya.
01:06:08  <isaacs>bnoordhuis: let's let it sit for now. i would like to get our C++ linting cleanly in v0.90
01:06:17  <isaacs>but it's certainly not urgent
01:06:47  <isaacs>in fact, we probably want to either do it in v0.8, or put it off until v0.8 is pretty much "done" like we did with the JS when v0.6 had settled.
01:06:57  <isaacs>i suspect we'll be back-porting fixes for a while, and we can't do this in a stable branch
01:07:22  <bnoordhuis>more or less my thoughts
01:07:58  <isaacs>when you have as many contributors as node does, linting IS valuable. but it's not valuable enough to justify jeopardizing other things, of course.
01:08:30  <isaacs>btw, i'm making good on this right now: https://twitter.com/izs/status/211609527995478017
01:08:34  <isaacs>speaking of lint and style and such
01:08:38  <isaacs>it's IN FUCKING SANE
01:08:49  <isaacs>omg, function, if, ACK! IM OUT OF ROOM
01:08:51  <bnoordhuis>hah
01:08:57  * loladirojoined
01:09:12  <isaacs>it's forcing a very high degree of discipline, though
01:09:22  <isaacs>and the code i'm refactoring into this style kinda needs ti
01:10:51  <bnoordhuis>i like what the linux kernel's style guide says about indenting
01:11:04  <bnoordhuis>if you need more than three or four levels of indent, you're probably doing it wrong
01:13:15  <isaacs>yep
01:13:27  <isaacs>8-space is a way to enforce this
01:13:36  <isaacs>i figure 16-space will be twice as enforceful
01:14:39  <bnoordhuis>16 spaces is brutal though - you'll get a neck cramp :)
01:19:18  <isaacs>also, colorcolumn at 80 chars
01:21:06  * brsonquit (Ping timeout: 248 seconds)
01:23:07  * brsonjoined
01:33:09  * brsonquit (Quit: leaving)
01:37:30  * loladiroquit (Quit: loladiro)
01:48:37  * abraxasjoined
02:13:57  * brsonjoined
02:13:57  * brsonquit (Client Quit)
02:14:09  * brsonjoined
02:21:25  <CIA-112>libuv: Ben Noordhuis master * r78bc0d6 / (3 files in 2 dirs): unix: implement async handles in libuv - http://git.io/3uaNWw
02:21:25  <CIA-112>libuv: Ben Noordhuis master * r3b417d1 / (src/unix/linux/syscalls.c src/unix/linux/syscalls.h): linux: add eventfd and eventfd2 syscalls - http://git.io/BzyItw
02:23:21  * travis-cijoined
02:23:21  <travis-ci>[travis-ci] joyent/libuv#403 (master - 3b417d1 : Ben Noordhuis): The build passed.
02:23:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ddb5f55...3b417d1
02:23:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1588246
02:23:21  * travis-cipart
02:47:05  * mikealjoined
03:07:11  * bnoordhuisquit (Ping timeout: 246 seconds)
03:13:48  * c4miloquit (Remote host closed the connection)
04:24:13  * mikealquit (Quit: Leaving.)
04:31:13  <CIA-112>node: isaacs v0.7.10-release * r7200bb8 / (172 files in 18 dirs): Upgrade npm to 1.1.25 - http://git.io/C6_6Aw
04:31:16  <CIA-112>node: isaacs v0.7.10-release * rc48999b / (AUTHORS ChangeLog src/node_version.h): 2012.06.11, Version 0.7.10 (unstable) - http://git.io/VOmUDQ
04:35:15  <isaacs>test, please: http://nodejs.org/dist/v0.7.10/
04:35:34  <isaacs>or: git checkout ry./v0.7.10-release
04:35:41  <isaacs>*git checkout ry/v0.7.10-release
04:36:06  * CIA-112quit (Ping timeout: 272 seconds)
04:41:33  * CIA-99joined
05:20:20  * ericktquit (Quit: erickt)
05:20:49  * ericktjoined
05:47:49  * isaacsquit (Remote host closed the connection)
05:48:58  * CIA-99quit
05:55:12  * mikealjoined
05:58:46  * mikealquit (Client Quit)
06:15:01  * CIA-108joined
06:43:59  * txdvquit (Read error: Connection reset by peer)
06:48:12  * stephankquit (Quit: *Poof!*)
06:56:08  <saghul>ircretary tell piscisaureus if this https://github.com/joyent/libuv/blob/master/include/uv.h#L961 still stands after some of his recent patches
06:56:08  <ircretary>saghul: I'll be sure to tell piscisaureus
06:56:12  <saghul>ircretary thanks
06:56:13  <ircretary>saghul: You're welcome :)
06:56:15  * dshaw_joined
07:20:05  * rendarjoined
08:22:08  * felixgejoined
08:22:08  * felixgequit (Changing host)
08:22:08  * felixgejoined
08:25:49  * dshaw_quit (Quit: Leaving.)
09:02:58  * brsonquit (Ping timeout: 245 seconds)
09:57:38  * theColejoined
10:38:46  * indutnyquit (Ping timeout: 244 seconds)
10:39:20  * Raynosquit (Ping timeout: 246 seconds)
10:39:40  * mrb_bkquit (Ping timeout: 260 seconds)
10:46:30  * hij1nxjoined
11:04:46  * hij1nxquit (Quit: hij1nx)
11:29:39  * hij1nxjoined
11:44:07  * felixgequit (Quit: felixge)
11:59:21  * einarosquit (Ping timeout: 244 seconds)
12:00:04  * einarosjoined
12:05:40  * irajoined
12:27:09  * felixgejoined
12:27:09  * felixgequit (Changing host)
12:27:10  * felixgejoined
12:33:29  * mmaleckijoined
12:50:45  * hij1nxquit (Quit: hij1nx)
12:56:29  * hij1nxjoined
12:59:43  * indutnyjoined
13:05:11  * bnoordhuisjoined
13:06:07  * piscisaureus_joined
13:06:52  <piscisaureus_>saghul: yes, that still stands
13:07:02  <indutny>piscisaureus_: hey man
13:07:19  <indutny>piscisaureus_: what do you think about https://github.com/joyent/libuv/pull/460
13:09:29  <piscisaureus_>saghul: there are two risks here;
13:09:29  <piscisaureus_>* on unix, if a fd is closed and subsequently gets reused, the fd may be reinserted in the poll set
13:09:29  <piscisaureus_>* on windows, when the slow (fallback) mechanism is used, closing a socket that is being polled can cause the select operation to never return. Currently I make the select() timeout after three minutes so at some point it will return anyway, but this is obviously not good.
13:10:21  <piscisaureus_>indutny: ok... I agree that this could be a good idea
13:10:29  <piscisaureus_>indutny: but if we start doing it here, we have to do it everywhere :-)
13:10:33  <indutny>well, it's quite consistent with other places
13:10:34  <piscisaureus_>indutny: do ou need it>?
13:10:43  <indutny>I don't
13:10:51  <indutny>he does https://github.com/joyent/node/issues/3402
13:10:53  <indutny>piscisaureus_: ^
13:11:03  <piscisaureus_>indutny: well, on windows we generally abort() when people do that
13:11:10  <piscisaureus_>indutny: so there would be a lot of work to be done there.
13:11:27  <indutny>piscisaureus_: well, the node's case is quite simplier
13:11:51  <saghul>thanks for explaining, piscisaureus_
13:11:59  <indutny>piscisaureus_: .connect() is doing dns lookup and until it finishes - _handle contains uninitialized uv_stream_t
13:12:35  <indutny>piscisaureus_: and it's not really bad, as you may initialize TCP options and do other nasty stuff
13:12:44  <indutny>piscisaureus_: i.e. setting flags
13:13:05  <indutny>piscisaureus_: so it's not really a good idea to fix it in node
13:13:46  <piscisaureus_>indutny: right. In the 0.9 timeline we want make libuv fully support this, read_start before connect etc
13:13:59  <piscisaureus_>indutny: but apparently node doesn't create a handle before the dns resolution is complete
13:14:03  <piscisaureus_>indutny: that's a node bug
13:14:18  <piscisaureus_>indutny: because people indeed may want to set socket options before the dns name is resolved
13:14:26  <indutny>piscisaureus_: so users should not be able to set flags before 'connect' event
13:14:29  <piscisaureus_>indutny: but right now, that can never work because no socket is created
13:14:36  <indutny>piscisaureus_: that works
13:14:51  <piscisaureus_>indutny: or - we just create the socket but we don't bind it
13:14:53  <indutny>piscisaureus_: uv API supports it (at least on unix)
13:15:21  <piscisaureus_>indutny: yes - well, uv-unix supports it but the api says it shouldn't work :_)
13:15:29  <indutny>ah, ok
13:15:36  <indutny>I'll fix that in node then
13:16:09  <piscisaureus_>hmm
13:16:09  <indutny>ah, another moment
13:16:20  <indutny>piscisaureus_: you won't be able to destroy socket before connection
13:16:40  <indutny>piscisaureus_: because I won't expose ._handle before dns lookup finish
13:16:49  <piscisaureus_>indutny: so, why not?
13:17:08  <indutny>piscisaureus_: this may broke existing code
13:17:08  <piscisaureus_>indutny: hmm this dns stuff is annoying :-)
13:17:13  <indutny>yeah
13:17:18  <indutny>:)
13:18:35  <indutny>piscisaureus_: probably we can start by making it work on unix
13:18:45  <indutny>piscisaureus_: and gradually move to windows support in 0.9.x branch
13:19:11  <piscisaureus_>indutny: it would be good to have tests for this
13:19:27  <indutny>piscisaureus_: yeah, you're right. I'll write some
13:19:34  <piscisaureus_>indutny: right now it's very difficult for me to remember all the edge cases tha tI have to fix
13:19:41  <piscisaureus_>and I'll probably forget a few :-)
13:19:46  <indutny>bnoordhuis: heh
13:19:51  <indutny>piscisaureus_: bnoordhuis just closed that PR
13:20:18  <indutny>well
13:20:23  <indutny>we can hotfix that in node than
13:20:31  <bnoordhuis>yes, it's a node bug
13:20:37  <indutny>like setting socket._dnsLookup = true and checking it in .resume and .pause methods
13:20:48  <indutny>ok?
13:21:03  <piscisaureus_>bnoordhuis: we were just considering that the user might want to set socket options before it is connected
13:21:18  <indutny>piscisaureus_: that hotfix won't block them
13:21:19  <piscisaureus_>bnoordhuis: would we support that? It seems that we have to create the handle a little earlier
13:21:25  <piscisaureus_>ok
13:21:33  <bnoordhuis>piscisaureus_: that's kind of supported for udp sockets in uv-unix
13:21:42  <piscisaureus_>oh
13:22:02  <piscisaureus_>yes, because socket creation is not lazy
13:22:09  * mmaleckiquit (Ping timeout: 245 seconds)
13:22:09  <bnoordhuis>no, it is
13:22:14  <indutny>hahaha
13:22:20  <indutny>well, uv_tcp_t contains flag field
13:22:24  <bnoordhuis>but uv-unix remembers the settings if the socket hasn't been created yet
13:22:31  <piscisaureus_>ah, haha
13:22:40  <indutny>s/flag/flags
13:22:42  <piscisaureus_>bnoordhuis: in uv-win we just create the socket
13:22:55  <bnoordhuis>piscisaureus_: ah, right. that's a discrepancy :)
13:22:56  <piscisaureus_>bnoordhuis: that is, if the user sets a sockopt. socket creation is indeed lazyh
13:23:13  <piscisaureus_>bnoordhuis: as long as it doesn't leak out to the user it doesn't matter
13:23:37  <piscisaureus_>bnoordhuis: so go ahead, write a test that shows that I am wrong :-)
13:23:48  <indutny>em.. so should I fix it in node?
13:23:59  <indutny>or wait for you guys to decide which choice is better :P
13:24:01  <piscisaureus_>indutny: +1
13:24:03  <bnoordhuis>oh wait, i lie - it's supported for tcp sockets (keepalive, nodelay), not udp sockets
13:24:10  <indutny>oh crap
13:24:14  <piscisaureus_>aah
13:24:14  <indutny>so we are borked
13:25:02  <bnoordhuis>i would like to do away with lazy socket creation eventually btw
13:25:11  <bnoordhuis>but that's something for 0.9 or later
13:25:29  <piscisaureus_>bnoordhuis: ah, it's supported on windows as well
13:25:38  <indutny>piscisaureus_: +1
13:25:44  <indutny>mooncoding
13:25:45  <piscisaureus_>bnoordhuis: someone apparently added this flags stuff
13:25:57  <piscisaureus_>I suspect igor did it
13:26:29  <piscisaureus_>bnoordhuis: yes, I want to do away with lazy socket creation as well
13:26:30  <bnoordhuis>or i did... i remember fixing that after the initial PR
13:26:39  <piscisaureus_>bnoordhuis: +1
13:26:55  <piscisaureus_>bnoordhuis: anyway, we have to change the api to support it
13:27:00  <bnoordhuis>yes
13:27:08  <piscisaureus_>bnoordhuis: because at uv_tcp_init time we don't know the AF
13:27:09  <bnoordhuis>it'd mean that uv_tcp_init and friends can now fail
13:27:15  <piscisaureus_>that, too
13:27:20  <piscisaureus_>but the api already supports that
13:27:37  <bnoordhuis>yeah, but we don't really in node :)
13:27:45  <piscisaureus_>ghe
13:28:01  <bnoordhuis>but that's something we can fix
13:28:06  <piscisaureus_>I wonder if we would want to change the node api for this
13:28:17  <piscisaureus_>but let's just do the right thing(tm) first in libuv
13:28:20  <bnoordhuis>yes
13:28:29  <bnoordhuis>and i don't think changing node's api is necessary
13:28:47  <bnoordhuis>lib/net.js and lib/dgram.js can still initialize the handle lazily
13:28:58  <piscisaureus_>indeed
13:29:02  <piscisaureus_>which they have to
13:29:08  <piscisaureus_>since node also doesn't know the AF
13:29:13  <piscisaureus_>when you create the socket
13:29:15  <bnoordhuis>indeed
13:29:22  <bnoordhuis>oh, lib/dgram.js does actually
13:29:28  <piscisaureus_>indeed
13:29:46  <piscisaureus_>I don't like that DGRAM has this api that is inconsistent with net
13:29:59  <piscisaureus_>but whatever, biggest fish first
13:30:01  <piscisaureus_>bff
13:30:03  <bnoordhuis>exactly :)
13:30:27  <indutny>so fix should be landed in uv
13:30:33  <indutny>bnoordhuis: piscisaureus_: ?
13:30:46  <bnoordhuis>indutny: no, node
13:30:57  <piscisaureus_>indutny: no... it'll take too long before we can fix this in libuv I think
13:31:05  <indutny>ok
13:31:06  <bnoordhuis>now to decide on what the proper node fix is
13:31:07  <piscisaureus_>indutny: wait
13:31:16  <piscisaureus_>indutny: it's just about read_start and read_stop right?
13:31:32  <bnoordhuis>yes
13:31:42  <piscisaureus_>indutny: I suppose I could fix up uv-win to support read_start and read_stop for unconnected sockets
13:31:53  <indutny>yeah, it's about it
13:31:55  <piscisaureus_>but node should create the handle earlier
13:32:23  <piscisaureus_>bnoordhuis: how difficult is it for you to fix uv-unix ?
13:32:30  <bnoordhuis>piscisaureus_: not difficult at all
13:32:36  <piscisaureus_>coo;
13:32:38  <piscisaureus_>let's do that
13:32:43  <indutny>hahahaha
13:32:52  <piscisaureus_>ghe
13:32:56  <piscisaureus_>sorry indutny
13:33:05  <indutny>np :)
13:33:09  <indutny>I knew I was right
13:33:53  <bnoordhuis>piscisaureus_, indutny: is that enough to fix the problem though? will .pause() and .resume() still do the right thing?
13:34:11  <indutny>bnoordhuis: well, it will do no effect, actually
13:34:15  <indutny>:P
13:34:31  <indutny>because it has nothing to pause
13:34:33  <indutny>or resume
13:34:34  <piscisaureus_>bnoordhuis: so currently fails uv_read_start when either of these is true:
13:34:35  <piscisaureus_>* the socket is not connected
13:34:35  <piscisaureus_>* the socket is listening
13:34:35  <piscisaureus_>* the socket has received a FIN packet
13:34:35  <piscisaureus_>* the socket is already reading
13:34:44  <piscisaureus_>which ones are valid, and which ones are not?
13:34:56  <piscisaureus_>I suppose read_start should just set the read_cb when it is already reading
13:35:19  <bnoordhuis>calling read_start when it's a listening socket is pointless
13:35:28  <bnoordhuis>so that should return EINVAL
13:35:48  <bnoordhuis>the others seem harmless to me
13:35:53  <piscisaureus_>right
13:36:28  <piscisaureus_>bnoordhuis: so iirc we decided that a failed uv_connect() does not automatically stop reading, right?
13:36:37  <bnoordhuis>piscisaureus_: correct
13:36:40  <piscisaureus_>ok
13:36:57  <piscisaureus_>that is still somewhat questionable to me, maar vooruit :-)
13:37:11  <bnoordhuis>side note, i wonder if a socket can both listen and be connected to somewhere else
13:37:24  <piscisaureus_>bnoordhuis: udp sockets can :-)
13:37:42  <bnoordhuis>yes, but udp sockets never call listen(), only bind()
13:37:47  <piscisaureus_>true
13:47:43  <bnoordhuis>connect(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EISCONN (Transport endpoint is already connected)
13:47:45  <bnoordhuis>sanity prevails
13:50:49  <bnoordhuis>but now for something that's interesting if not quite useful
13:50:55  <bnoordhuis>bind(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
13:50:56  <bnoordhuis>connect(3, {sa_family=AF_INET, sin_port=htons(1337), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
13:50:56  <bnoordhuis>write(3, "test", 4) = 4
13:50:56  <bnoordhuis>read(3, "test", 32) = 4
13:51:17  <bnoordhuis>for the strace-challenged, that's a socket that's connected to itself
13:51:26  <bnoordhuis>like a pipe but it uses only a single fd
13:55:19  <indutny>bnoordhuis: meta-socket
13:56:00  * c4milojoined
13:56:16  <bnoordhuis>indutny: or the pinnacle of solipsism, a loopback socket that only talks to itself
13:57:37  <piscisaureus_>bnoordhuis: well you could use that for the self-pipe
13:57:42  <piscisaureus_>saves a file descriptor
13:57:44  <piscisaureus_>woo
13:58:01  <bnoordhuis>the thought crossed my mind, yes :)
14:07:23  * ericktquit (Quit: erickt)
14:09:01  <piscisaureus_>bnoordhuis: does uv-unix also actually start reading when the read_start is called before uv_accept?
14:14:02  <bnoordhuis>piscisaureus_: yes
14:14:17  <piscisaureus_>bnoordhuis: ok, cool
14:20:30  * indutnyquit (Quit: Page closed)
14:20:33  * indutny_joined
14:20:39  <indutny_>heh
14:20:43  <indutny_>finally irccloud is back
14:20:54  <indutny_>least reliable web service ever
14:23:10  <piscisaureus_>bnoordhuis: I think on windows when you do uv_read_start on a listening socket, under some circumstances uv_tcp_read_start cannot return EINVAL synchronously
14:23:28  <piscisaureus_>bnoordhuis: (this happens when a socket is shared via an ipc channel)
14:24:04  * abraxasquit (Remote host closed the connection)
14:24:16  * isaacsjoined
14:26:02  <bnoordhuis>piscisaureus_: you can set/unset a handle flag, can you not?
14:26:41  <piscisaureus_>bnoordhuis: yeah, but the problem is that when a socket arrives over an IPC channel we are unsure whether the sender put it in a listening state or noot
14:26:42  <bnoordhuis>or is it that you don't know if a shared socket is listening?
14:26:47  <bnoordhuis>right
14:26:49  <piscisaureus_>^-- that
14:26:50  <piscisaureus_>yes
14:27:12  <bnoordhuis>you have this homebrew ipc protocol, right? can't you extend that?
14:27:23  <piscisaureus_>yes, in theory
14:27:29  <bnoordhuis>and in practice?
14:27:29  <piscisaureus_>bnoordhuis: so how do you deal with this on unix
14:27:58  <bnoordhuis>piscisaureus_: we don't, currently :)
14:28:46  <piscisaureus_>bnoordhuis: I think there is also a sockopt that you can read
14:28:51  <piscisaureus_>s/you/we/
14:29:22  <bnoordhuis>yes, or call getpeername() to check if it's connected
14:29:37  <bnoordhuis>there are probably more possible approaches
14:30:30  <piscisaureus_>bnoordhuis: yes, SO_ACCEPTCONN does it too
14:31:07  <piscisaureus_>works on BSDs too
14:31:24  <piscisaureus_>but not on that unfortunate piece of crap that shall not be named
14:31:50  <piscisaureus_>which bnoordhuis should do a patch for
14:32:20  <piscisaureus_>I guess I could do that even
14:33:26  * mrb_bkjoined
14:34:04  <isaacs>Anyone object if i remove the openssl tests from the release tarball?
14:34:05  <piscisaureus_>ah wait no it works on linux too
14:34:20  <isaacs>it's annoying on windows
14:34:27  <piscisaureus_>isaacs: why ?
14:34:30  <isaacs>has a bunch of symlinks in it
14:34:33  <piscisaureus_>aah
14:34:37  <isaacs>tar complains
14:34:41  <piscisaureus_>huh
14:34:44  <piscisaureus_>that's unfortunate
14:34:57  <piscisaureus_>I never even noticed :-)
14:35:18  <isaacs>you usually check out from git, though, right?
14:35:23  <piscisaureus_>yes
14:35:40  <piscisaureus_>really, I don't know why anyone would ever want to use a tarball
14:35:41  <isaacs>speaking of which, can you pull and test c48999bef31b36024b83dc7bc6fbc422106fa0b5?
14:35:54  <piscisaureus_>ok
14:36:15  <isaacs>i do when i'm making builds, or for building on unix machines that might not have git
14:36:34  <isaacs>making builds in the src tree directly has a tendency to include the wrong things
14:37:07  <bnoordhuis>isaacs: you can also remove the gyp tests from the tarball
14:37:12  <bnoordhuis>if you don't already do that, that is
14:37:23  <piscisaureus_>isaacs: that's why we have git clean -fdx :-)
14:37:24  <bnoordhuis>they're 3.5M uncompressed
14:37:29  <isaacs>i dunno, i'll check in a second
14:37:38  <isaacs>good call
14:37:48  <piscisaureus_>isaacs: yes, totally broken
14:37:57  <piscisaureus_>isaacs: it seems that all the spawn() tests fail with EINVAL
14:37:59  * theColequit (Quit: theCole)
14:38:06  <isaacs>frag.
14:38:07  <isaacs>ok
14:38:21  <piscisaureus_>isaacs: lemme debug
14:38:29  <isaacs>thanks
14:38:32  * piscisaureus_is reaching a stack of work overflow
14:39:01  * theColejoined
14:39:43  * theColequit (Client Quit)
14:40:12  * mmaleckijoined
14:41:01  * hij1nxquit (Quit: hij1nx)
14:42:42  <piscisaureus_>isaacs: does it work in unix? that would be surprising...
14:43:22  <piscisaureus_>ah, hmm
14:46:24  <isaacs>osx: [02:20|% 100|+ 419|- 3]: Done
14:46:39  <isaacs>simple/test-eio-limit failed, and 2 message test failures (minor)
14:46:45  <isaacs>simple/test-eio-limit is a little concerning
14:46:51  <isaacs>but it's been like that for a while, iirc
14:47:45  * mmalecki_joined
14:48:51  <piscisaureus_>isaacs: ok, I have a fix
14:48:59  <piscisaureus_>isaacs: now running vcbuild.bat debug test-all 2>&1 | tee out.txt
14:49:04  <isaacs>kewl
14:49:18  <isaacs>piscisaureus_: wanna land it on a branch, or gist a patch?
14:50:47  * mmaleckiquit (Ping timeout: 245 seconds)
14:51:07  <piscisaureus_>isaacs: the branch name is v0.7.10-release ?
14:51:14  <isaacs>piscisaureus_: sure
14:51:22  <CIA-108>node: Bert Belder v0.7.10-release * reaadd55 / src/process_wrap.cc : process_wrap: set duplex flags when creating a pipe - http://git.io/PYnwlQ
14:53:04  <piscisaureus_>it would be really nice to have CI
14:53:19  <piscisaureus_>for windows
14:53:44  <isaacs>piscisaureus_: yes.
14:53:47  <isaacs>and for unix, too
14:53:56  <piscisaureus_>isaacs: well, for unix we have travis at least
14:54:02  <isaacs>piscisaureus_: ha.
14:54:04  <isaacs>yeah, right
14:54:16  <isaacs>because there are no diffs between linux and os x and sunos ;P
14:54:31  <piscisaureus_>unexpected error, throwing "ENOENT, open 'D:\\node4\\this file does not exist'"
14:55:08  <saghul>piscisaureus_ quick q: how does one run with elevated privileges on Windows? being admin doesn't seem to be enough
14:55:21  <piscisaureus_>saghul: windows 7 ?
14:55:25  <saghul>yep
14:55:41  <piscisaureus_>saghul: enter cmd in the start menu search box until "cmd.exe" shows up
14:55:55  <piscisaureus_>saghul: then right click on cmd.exe and pick "run as adming"
14:56:02  <piscisaureus_>saghul: or just disable UAC :-)
14:56:29  <saghul>since I run bash.exe... any link to disable UAC?
14:56:49  <tjfontaine>hah I love "disable uac" being a common suggestion
14:56:54  <piscisaureus_>saghul: well, just enter "UAC" in the start menu search box
14:57:03  <saghul>oh, found something in google, I'll check later then :-)
14:57:03  <piscisaureus_>saghul: from there it's easy
14:57:11  <saghul>thanks, piscisaureus_ :-)
14:58:05  <saghul>tjfontaine heh, it feels like "what do you mean I can't do it, I'm Mr. root" :-)
15:00:16  <piscisaureus_>well, it's really unfortunate that windows doesn't ship with a "sudo" command
15:00:24  <piscisaureus_>rather lame, considering that I could write one in like 5 minutes
15:01:23  <tjfontaine>piscisaureus_: I thought you could use runas
15:01:33  <piscisaureus_>no, that doesn't work unfortunately
15:01:45  <piscisaureus_>tjfontaine: that only works to switch users
15:01:52  <piscisaureus_>but not to elevate
15:01:53  <saghul>but that doesn't give you elevated privileges, apparently
15:01:54  <tjfontaine>ah
15:02:03  * hij1nxjoined
15:04:11  <piscisaureus_>isaacs: not too good
15:04:24  <piscisaureus_>isaacs: only 83% through and already 13 failures
15:04:44  <isaacs>ugh
15:05:14  <piscisaureus_>openssl seems to be really broken
15:05:22  <piscisaureus_>well, not really
15:05:57  <isaacs>that's odd... it hasn't been touched since the last few releases.
15:06:20  * mmaleckijoined
15:06:21  <piscisaureus_>yes, it has been broken for a while I think ... but I mean, it's not really really broken
15:06:34  <piscisaureus_>but there's some test failures which are odd, since openssl is a compute-only thing
15:06:40  <piscisaureus_>very little OS involved
15:06:42  <piscisaureus_>so it shouldn't fail
15:09:05  * ericktjoined
15:09:48  * mmalecki_quit (Ping timeout: 245 seconds)
15:10:41  <isaacs>piscisaureus_: i agree.
15:10:47  <isaacs>piscisaureus_: thoughts on the release? hold it back, or push forward?
15:10:53  <isaacs>what's your opinion?
15:11:05  <piscisaureus_>isaacs: well, I think you can release, but I am still only 94% through
15:11:11  <piscisaureus_>isaacs: these failures are not new
15:11:16  <isaacs>sure.
15:11:20  <isaacs>we need to fix them this week.
15:11:22  <piscisaureus_>but they annoy me at every release
15:11:26  <isaacs>yes.
15:14:34  <isaacs>piscisaureus_: force push coming on the release branch
15:14:45  <piscisaureus_>[24:28|% 100|+ 436|- 25]: Done
15:14:49  <CIA-108>node: isaacs v0.7.10-release * r1319835 / (172 files in 18 dirs): Upgrade npm to 1.1.25 - http://git.io/Fi1m8w
15:14:49  <CIA-108>node: isaacs v0.7.10-release * r54a4f99 / (lib/fs.js lib/readline.js): lint - http://git.io/XkzMhQ
15:14:49  <CIA-108>node: Bert Belder v0.7.10-release * r5432a1d / src/process_wrap.cc : process_wrap: set duplex flags when creating a pipe - http://git.io/a1-MHw
15:14:50  <CIA-108>node: isaacs v0.7.10-release * r9b7ff64 / (AUTHORS ChangeLog src/node_version.h): 2012.06.11, Version 0.7.10 (unstable) - http://git.io/_ciPkA
15:16:14  <piscisaureus_>isaacs: https://gist.github.com/2910591
15:16:44  <piscisaureus_>isaacs: a couple of them complain about "weak" not being loaded
15:19:33  <CIA-108>node: isaacs v0.7.10-release * r8bb8750 / Makefile : Remove dep symlinks from tarball - http://git.io/0He2Vw
15:19:33  <CIA-108>node: isaacs v0.7.10-release * rc261c2e / (AUTHORS ChangeLog src/node_version.h): 2012.06.11, Version 0.7.10 (unstable) - http://git.io/VzyK8w
15:19:57  <isaacs>haha, whoops
15:20:03  <isaacs>sorry for the noise everyone
15:20:46  <CIA-108>node: isaacs v0.7.10-release * r76f6a4a / Makefile : Remove dep symlinks from tarball - http://git.io/PB6T7g
15:20:47  <CIA-108>node: isaacs v0.7.10-release * r8d9766a / (AUTHORS ChangeLog src/node_version.h): 2012.06.11, Version 0.7.10 (unstable) - http://git.io/nMfjtA
15:26:20  * iraquit (Quit: Computer has gone to sleep.)
15:41:28  * mmalecki_joined
15:44:42  * mmaleckiquit (Ping timeout: 256 seconds)
15:45:05  * mmaleckijoined
15:48:02  * mmalecki_quit (Ping timeout: 252 seconds)
15:48:31  * pieternjoined
15:53:39  * dapjoined
15:59:26  <CIA-108>node: isaacs master * re9aa57e / src/node_version.h : Now working on 0.7.11 (+6 more commits...) - http://git.io/6cN1kg
15:59:54  <mmalecki>AvianFlu: ^
16:00:42  <AvianFlu>:D
16:03:02  <AvianFlu>isaacs, it looks like when you merged my commit, you missed the force-push that removed the auto-unref'ing
16:03:03  <AvianFlu>?
16:03:53  <AvianFlu>https://github.com/joyent/node/commit/4b021a3541770ae64a415760339bdd3223fdf602#commitcomment-1441609
16:06:40  <isaacs>AvianFlu: hm. seems so, yes.
16:06:57  <isaacs>thanks for catching. i don't think that's relevant enough to ammend the release.
16:07:18  <AvianFlu>AndreasMadsen noticed - and it doesn't seem to break things
16:07:22  <AvianFlu>at least so far
16:07:30  <isaacs>do you?
16:07:32  <isaacs>ok.
16:07:35  <isaacs>i'll land that now
16:08:47  <isaacs>AvianFlu: https://github.com/isaacs/node/commit/1358632e672e2e7097abe12924de5f2b82bde765
16:08:50  <isaacs>that fixes it, yes?
16:09:05  <AvianFlu>yep, that's it
16:10:21  <isaacs>kewl
16:10:33  <CIA-108>node: isaacs master * r1358632 / lib/child_process.js : Remove auto-unref - http://git.io/1as1HQ
16:10:38  <isaacs>sorry i stole the impact points from you ;P
16:10:42  <isaacs>didn't mean to
16:12:21  <AvianFlu>that's all good, I was expecting the 4 or 5 commit comments when I woke up :D
16:17:21  * stephankjoined
16:26:36  * igorzi_quit (Ping timeout: 245 seconds)
16:31:09  * ericktquit (Quit: erickt)
16:37:47  * japjjoined
16:38:11  <piscisaureus_>node.js streams are way too painful
16:38:32  <isaacs>piscisaureus_: yeah, we need to make them less os.
16:38:34  <isaacs>*less so
16:38:52  <isaacs>piscisaureus_: for now, though, we need to make our tests pass first, and get 0.8 out the door.
16:38:53  <piscisaureus_>I was writing a function to download a file and save it to a file
16:38:56  <isaacs>nothing else matters :)
16:39:01  <piscisaureus_>(I know)
16:39:25  <AvianFlu>isaacs, I'm sorry I didn't notice this ten minutes ago - but you also merged the wrong test
16:39:30  <piscisaureus_>If you assume nothing can go wrong, it's a 3-liner
16:39:39  <piscisaureus_>the next 40 lines are all error handling
16:39:43  <AvianFlu>you basically merged the state of things before all the changes we talked about XD
16:39:45  <piscisaureus_>that's just lame
16:41:15  * theColejoined
16:41:42  <isaacs>ugh
16:41:42  <isaacs>ok
16:41:54  <isaacs>AvianFlu: k. can you send a pull req with the fix?
16:42:17  <isaacs>AvianFlu: or even just point me at a patch against current master
16:42:33  * hij1nxquit (Read error: Connection reset by peer)
16:43:08  <AvianFlu>sure, just a sec
16:43:20  <isaacs>thanks.
16:43:25  * mmalecki_joined
16:43:48  <isaacs>piscisaureus_: why would anything go wrong, though?
16:44:08  <isaacs>piscisaureus_: don't coddle the computer. it's not a baby. if it gets it wrong, it deserves the results.
16:46:26  * mmaleckiquit (Ping timeout: 248 seconds)
16:48:18  <piscisaureus_>isaacs: so I have this : https://gist.github.com/2910892
16:48:46  <piscisaureus_>isaacs: even that isn't good - 50% of the cases, `node test.js never exits`
16:49:06  <piscisaureus_>(note that the ETIMEDOUT error takes a while, I am aware of that)
16:49:42  <isaacs>right
16:50:08  * mmaleckijoined
16:50:14  <piscisaureus_>isaacs: if you have any suggestions for a nicer solution, I'd be glad to hear it
16:50:26  <isaacs>busy atm.
16:50:39  <isaacs>piscisaureus_: but using the request module is pretty nice for stuff like this.
16:51:10  <isaacs>piscisaureus_: request(url).on("error", cb).pipe(fs.createWriteStream(filename)).on("close", cb).on("error", cb)
16:51:41  <piscisaureus_>isaacs: yeah but that does not clean up the writestream fd if the request fails
16:52:05  <piscisaureus_>isaacs: also, I am not so sure that cb will be called exactly once, always
16:52:07  <isaacs>we don't clean up the writeStream fd on error? i thought that was fixed.
16:52:18  <isaacs>cb = onlyCallOnce(cb);
16:52:24  <piscisaureus_>ghe
16:52:27  <piscisaureus_>right
16:52:37  <isaacs>function onlyCallOnce (cb) { var called = false; return function (er) { if (called) return; called = true; cb(er) } }
16:52:48  <piscisaureus_>there ya go
16:52:48  * isaacsshrug
16:53:20  <piscisaureus_>isaacs: https://github.com/joyent/node/blob/master/lib/stream.js#L77-83
16:53:32  * mmalecki_quit (Ping timeout: 265 seconds)
16:53:39  <piscisaureus_>isaacs: all we do is remove listeners
16:53:57  <piscisaureus_>isaacs: "hey an error happened. now you sort it out"
16:55:53  <CIA-108>node: isaacs master * r25e8ea1 / (40 files in 13 dirs): Do not gitignore npm's node_modules - http://git.io/EvqumQ
16:56:06  <isaacs>piscisaureus_: nono, i thought we did that in fs.js
16:56:28  * ericktjoined
16:56:42  <piscisaureus_>isaacs: oh, we might
16:56:56  <isaacs>piscisaureus_: might be only in 0.7
16:57:08  <piscisaureus_>isaacs: but if the "in" pipe has an error, then the "out" pipe is leaked
16:57:11  <piscisaureus_>and vice versa
16:57:22  <isaacs>right
16:57:23  <piscisaureus_>and if both have an error then the callback will be made twice
16:57:38  <AvianFlu>isaacs, this should be all it needs https://github.com/AvianFlu/node/compare/detach-test-fix
16:57:38  <piscisaureus_>this is also kind of why we have domains I suppose :-)
16:58:45  <piscisaureus_>but pipe() should really do this magic for you
16:58:53  <piscisaureus_>optionally, I suppose
17:00:24  <isaacs>so, the todo list for v0.9:https://gist.github.com/2911289
17:00:42  <isaacs>piscisaureus_: there's more stuff i forgot, but those are the big rocks that i see.
17:00:50  <isaacs>move those out of hte way, the rest is pretty minor, i think.
17:00:58  <piscisaureus_>isaacs: I have libuv plans
17:01:05  <piscisaureus_>isaacs: but I don't think we should block 0.10 on them
17:01:10  * AndreasMadsenjoined
17:01:16  <isaacs>k
17:01:25  <isaacs>the theme of node v0.9 will be API cleanup.
17:01:30  <piscisaureus_>isaacs: such as allow more queueing in the fs module
17:01:31  <piscisaureus_>hmm
17:01:37  <piscisaureus_>that'd be nice to get in the
17:01:41  <isaacs>i want to try to not add any new features.
17:02:07  <piscisaureus_>isaacs: I want this to be legal
17:02:08  <piscisaureus_>file = fs.open('blah', 'w')
17:02:08  <piscisaureus_>file.write('ha!')
17:02:08  <piscisaureus_>file.write('again')
17:02:12  <piscisaureus_>without race conditions
17:02:30  <isaacs>piscisaureus_: that'd be kind of neat.
17:02:42  <piscisaureus_>isaacs: that requires libuv to not expose file FDs
17:02:42  <isaacs>piscisaureus_: i had looked into doing something like that in v0.8, but it didn't fit.
17:02:47  <isaacs>piscisaureus_: sure.
17:02:49  <piscisaureus_>but proper stream objects
17:02:55  <isaacs>hm.
17:03:25  <piscisaureus_>isaacs: the old API can just keep working
17:03:37  <piscisaureus_>or, old, whatever, the current low-level api
17:04:13  <piscisaureus_>isaacs: so by making libuv smarter about files, we can also try and improve performance in that area
17:04:20  <piscisaureus_>because currently it's slightly lacking
17:04:37  <isaacs>right
17:04:42  <isaacs>yeah, that'd be good
17:04:47  <AndreasMadsen>isaacs: this domain module is very cool, however I'm a bit confused on how to with it in classes. My problem is public methods are not in a domain scope and sync errors in the constructor can not be catched.
17:04:51  <piscisaureus_>but I'd like to try to use kernel aio or mmaped files for read-only streams
17:04:57  <AndreasMadsen>example: https://gist.github.com/2904724
17:05:13  <piscisaureus_>isaacs: so we can properly beat vertx when serving static files
17:05:38  <isaacs>AndreasMadsen: my plan is for you to rewrite domain.js in v0.9, like you did with cluster.js in v0.7 ;)
17:05:55  <AvianFlu>hahahaha
17:06:01  * isaacsonly half-jokign
17:06:09  <AndreasMadsen>isaacs: but I really like domain
17:06:31  <isaacs>AndreasMadsen: in all seriousness, something like this, you have to use to find the rough spots.
17:06:31  <AndreasMadsen>and I still don't like cluster
17:06:40  <isaacs>cluster is pretty nice right now
17:06:45  <isaacs>though i think it's a bit high-level.
17:06:57  <AndreasMadsen>isaacs: that is why I don't like it
17:06:59  <isaacs>it'd be nice to expose more of the API that it uses, so that one *could* conceivably implement it in userland.
17:07:08  <isaacs>right now, that'd be too hard
17:07:23  <AndreasMadsen>isaacs: domain or cluster?
17:07:33  <isaacs>AndreasMadsen: cluster
17:07:53  <isaacs>AndreasMadsen: i think that most of the bits are there now. the only magic that cluster really needs is the net.listen club.
17:08:02  <isaacs>but that's just based on an env anyway
17:08:24  <mmalecki>a net.listen hook would be kinda neat
17:08:34  <mmalecki>so that you could tell when app opens up a port
17:08:44  <mmalecki>isn't it kinda what you want?
17:08:45  <AndreasMadsen>isaacs: yes I try that now and then, that was the main purpose of my massive child.send patch was to remove some of the magic.
17:09:01  <mmalecki>because I can implement that, we'd love to use it in haibu-carapace
17:09:03  <AndreasMadsen>isaacs: however I will look intro it again.
17:09:12  <isaacs>mmalecki: for v0.9 maybe
17:09:31  <AndreasMadsen>isaacs: but I would like to know how to work with sync errors in domain
17:09:33  <mmalecki>I'm down, let's figure out some API
17:09:37  <isaacs>piscisaureus_: where'd we leave listen({fd:3})?
17:11:17  <piscisaureus_>isaacs: I think that's not a good api
17:11:25  <piscisaureus_>it should be in net.CreateServer
17:11:32  <piscisaureus_>er, net.Server
17:11:33  <isaacs>piscisaureus_: oh, ok.
17:11:37  <isaacs>whatevs.
17:11:43  <piscisaureus_>well, hmm
17:11:45  <isaacs>the API can be anything.
17:11:47  <piscisaureus_>complicated
17:11:56  <isaacs>i like putting it in .listen() because that's where you'd put the port or socket.
17:12:01  <isaacs>so putting the FD there makes sense.
17:12:04  * mmalecki_joined
17:12:16  <piscisaureus_>yeah, I sort of understand
17:12:17  <isaacs>but it's not a strong feeling. if you think it makes the implementation harder, then it's not worth it.
17:12:31  <piscisaureus_>I was afraid that net.createServer could already be creating a new FD
17:12:47  <piscisaureus_>but obviously it can't because it doesn't know whether it will be a pipe or a socket yet
17:12:48  * igorzijoined
17:14:39  <piscisaureus_>isaacs: ok, listen({fd: 1})
17:14:50  <AndreasMadsen>isaacs: If I remember correctly the only real cluster magic is in exports._createServerHandle. And that could be solved if userland could do net.Server().listen() in the master but without and ._handle.onconnection. So userland could just send the server instance using child.send to some workers and have them attach and ._handle.onconnection by server.on('connection') got by process.on('message')
17:15:08  * mmaleckiquit (Ping timeout: 246 seconds)
17:15:39  * TheJHjoined
17:15:45  <isaacs>piscisaureus_: do you know what needs to happen in libuv for this? i'm guessing you have like 2 months of work to get done before next week, so is there anyway you could offload this to someone else?
17:15:57  <AndreasMadsen>isaacs: would this domain patch be allowed (https://github.com/AndreasMadsen/node/commit/abb7b404ffc9e089fa96c0af6ca4df958d5d0cd5)
17:15:58  <piscisaureus_>isaacs: well, nothing I think
17:16:15  <piscisaureus_>isaacs: the work is to be done in the binding layer
17:16:32  <isaacs>hm. right.
17:16:35  <piscisaureus_>isaacs: call uv_guess_handle(fd)
17:16:49  <piscisaureus_>isaacs: depending on the result create a PipeWrap or TcpWrap
17:16:54  <isaacs>piscisaureus_: can you comment on the issue?
17:16:58  <piscisaureus_>isaacs: then call uv_listen
17:17:01  * igorziquit (Ping timeout: 245 seconds)
17:17:07  <isaacs>piscisaureus_: i think some people at Joyent need this feature, i'll try to get them to implement it.
17:17:28  <isaacs>some other folks have asked about it, as well, but it'd be good to share the load, that's all.
17:17:39  <isaacs>plus, once someone gets a patch accepted, they're hooked, and keep helping us :)
17:18:09  <isaacs>AndreasMadsen: i prefer to avoid try/catch. it obscures the original source of the error.
17:18:56  <isaacs>AndreasMadsen: but you could do process.nextTick(this.bind(fn))
17:19:04  * igorzijoined
17:19:04  * txdvjoined
17:20:45  <AndreasMadsen>isaacs: Oh, I leaned something new today then :). process.nextTick would require an callback or an query if any initialization happens.
17:22:13  * kohaijoined
17:22:22  <piscisaureus_>isaacs: https://github.com/joyent/node/issues/3388#issuecomment-6250474
17:23:40  <AvianFlu>isaacs, left you https://github.com/joyent/node/pull/3404 when you get the chance
17:23:46  * AvianFlugoes to do real work
17:24:01  <isaacs>piscisaureus_: thanks
17:24:07  <AndreasMadsen>isaacs: how does try/catch fake the stack trace, I can't provoke it to do that.
17:24:07  * felixgequit (Quit: felixge)
17:24:09  <isaacs>AvianFlu: thanks, i'll pull in shortly
17:24:56  <isaacs>AndreasMadsen: the stack is the same, but the TryCatch object in C++ is broken, so we can't show the little line number thingie
17:25:10  <isaacs>AndreasMadsen: that always reports the place where it was thrown from
17:25:51  <AndreasMadsen>isaacs: ahh, yes I see that now
17:26:01  <AndreasMadsen>very sad
17:26:43  <isaacs>AndreasMadsen: yeah, that's why we put in some hacks to do stuff like: threw=true; try {fn(); threw = false } finally { if(threw) cleanup() }
17:26:57  <isaacs>so that we don't catch it, but still do teh cleanup if we need to
17:27:26  * igorziquit (Ping timeout: 245 seconds)
17:29:04  <CIA-108>node: Charlie McConnell master * r2eb181d / (2 files in 2 dirs): child_process: fix test implementation for options.detached - http://git.io/FIJBzg
17:30:41  <AndreasMadsen>isaacs: hard problem to solve, I will have to give it some thought
17:31:00  <isaacs>AndreasMadsen: looking forward to what you come up with :)
17:32:21  <AndreasMadsen>isaacs: well I have some final examination to finish first and those are not in async programming :(
17:33:07  <AndreasMadsen>But how knows the amount of node problems I solve is rather high
17:33:16  <AndreasMadsen>^ when I sleep
17:35:31  <isaacs>ryah: good idea on the crowdsourced perf test :)
17:37:11  <AndreasMadsen>so outsourced people have to get paid for sleeping now, :o
17:45:13  <philips>piscisaureus_: The gyp guys responded with a reasonable response
17:45:21  <piscisaureus_>philips: link?
17:45:21  <philips>piscisaureus_: It turns out libtool warns about this too
17:45:27  <piscisaureus_>oh
17:45:46  <piscisaureus_>I think bnoordhuis should fix it, then :-)
17:45:54  <piscisaureus_>rename linux/core.c
17:45:56  <philips>piscisaureus_: https://groups.google.com/forum/?fromgroups#!topic/gyp-developer/QN-nYWTMUkM
17:46:12  <philips>piscisaureus_: Yea, I can send a patch if bnoordhuis can't do it.
17:46:42  <piscisaureus_>he can :-)
17:46:58  <philips>piscisaureus_: heh, sweet ;)
17:47:23  <philips>http://www.jankratochvil.net/project/libtool/
17:47:26  <piscisaureus_>isaacs: fuck
17:47:40  <isaacs>?
17:47:40  <piscisaureus_>isaacs: when I try to build the x64 of 0.7.10 I get this mksnapshot shit again
17:47:50  <piscisaureus_>run_mksnapshot
17:47:50  <piscisaureus_> .. wordt niet herkend als een interne
17:47:50  <piscisaureus_> of externe opdracht, programma of batchbestand.
17:47:50  <piscisaureus_>:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(151,5): error MSB6006: "cmd.exe" exited w
17:47:50  <piscisaureus_>th code 1. [D:\node4\deps\v8\tools\gyp\v8_snapshot.vcxproj]
17:48:28  <isaacs>the word isn't harkened all in internal of external operations program of batch stand?
17:48:29  * japjquit (Read error: Connection reset by peer)
17:48:50  * isaacs<3 dutch
17:49:00  <piscisaureus_>haha
17:49:16  * mmaleckijoined
17:49:23  <piscisaureus_>I was like, "wtf, isaacs tendency to speak middle english is killing me here"
17:50:14  <piscisaureus_>isaacs: http://translate.google.com/#nl|en|..%20wordt%20niet%20herkend%20als%20een%20interne%20%20of%20externe%20opdracht%2C%20programma%20of%20batchbestand.
17:50:17  <isaacs>for me, reading dutch is like trying to read while drunk
17:50:18  <piscisaureus_>isaacs: flawless
17:50:56  <isaacs>it *feels* like i shoudl be able to read it, but i actually can't.
17:51:12  <piscisaureus_>hehe
17:52:14  * mmalecki_quit (Ping timeout: 244 seconds)
17:56:49  * mmalecki_joined
18:00:09  * mmaleckiquit (Ping timeout: 256 seconds)
18:12:01  * mmalecki_changed nick to mmalecki
18:12:42  <piscisaureus_>https://github.com/joyent/node/issues/3383#issuecomment-6251680
18:12:55  <piscisaureus_>^-- on windows 0.7 is slower than 0.6
18:13:27  <piscisaureus_>weird. I am pretty sure that at some point it was faster
18:14:25  * theColequit (Quit: theCole)
18:23:38  * brsonjoined
18:23:48  * benviequit
18:34:05  * AvianFluquit (Quit: Leaving)
18:34:23  * AvianFlujoined
18:34:36  * mmalecki_joined
18:35:47  * mmaleckiquit (Ping timeout: 245 seconds)
18:48:36  * mmaleckijoined
18:51:57  * mmalecki_quit (Ping timeout: 265 seconds)
19:13:08  * indutny_changed nick to indutny
19:17:27  * AndreasMadsenquit (Remote host closed the connection)
19:23:32  * AndreasMadsenjoined
19:25:27  <CIA-108>node: yangguo@chromium.org master * r33be301 / (3 files): Force inlining CopyChars and String::Get. - http://git.io/r2sKpg
19:25:27  <CIA-108>node: Bert Belder master * r2301eb6 / deps/v8/src/objects.h : v8: force inlining of v8::internal::DescriptorArray methods - http://git.io/2ubpdg
19:25:54  <piscisaureus_>^-- well, that puts master on par with 0.6, on windows
19:26:12  <piscisaureus_>for the bytes/123 benchmark, that is
19:27:03  * mmalecki_joined
19:31:06  * mmaleckiquit (Ping timeout: 265 seconds)
19:34:01  * brsonquit (Ping timeout: 244 seconds)
19:35:10  <isaacs>sweet
19:35:11  <isaacs>thanks, piscisaureus_
19:35:44  <piscisaureus_>isaacs: it was just msvc making the wrong inlining decisions
19:35:57  <isaacs>i see
19:36:07  <piscisaureus_>I have sent a patch (that was accepted) upstream to fix these issues before
19:41:00  * brsonjoined
19:42:54  <piscisaureus_>btw, try ab -k or bytes/1024
19:43:12  <piscisaureus_>bytes/123 seems to be the only one where we didn't get faster ...
19:45:05  <isaacs>piscisaureus_: weird~
19:45:14  <isaacs>i dont' get what the fascination is with bytes/123
19:45:19  <isaacs>why not bytes/12345?
19:45:35  <isaacs>123 bytes is not a very big webpage
19:45:48  <mmalecki_>bytes alignment?
19:45:48  <mmalecki_>or lack of it?
19:46:03  <piscisaureus_>isaacs: well, I sort of get it
19:46:23  <piscisaureus_>isaacs: It measures raw overhead of setting up a connecting and writing http headers
19:46:41  <isaacs>yeah
19:46:45  <isaacs>but not as well as bytes/1
19:46:48  <piscisaureus_>isaacs: but yeah, 123 bytes is very little... even when you're just sending json
19:47:11  <isaacs>but i suppose, since that was the only one that got slower on win32, it's worth having around as a test ;)
19:47:21  <isaacs>clearly it's some sort of local maximum
19:47:24  <isaacs>or minimum
19:47:35  <piscisaureus_>isaacs: well, i didn't really test stuff below bytes/123
19:47:38  <isaacs>i see
19:47:44  <piscisaureus_>isaacs: I tried n > 123 and -k and /unicode
19:47:49  <isaacs>kewl
19:48:21  <piscisaureus_>isaacs: but when ryah opened the original issue, bytes/1024 was also slower than 0.6
19:48:36  <piscisaureus_>however for me, here, it's faster
19:54:24  <piscisaureus_>isaacs: ryah: bytes/12345 is well worth benchmarking btw :-)
19:54:30  <piscisaureus_>node got twice as fast in that area
19:57:07  * mmaleckijoined
19:59:57  * mmalecki_quit (Ping timeout: 245 seconds)
20:00:44  <isaacs>piscisaureus_: i'm gonna write up a blog post with changes and some benchmarks for tomorrow morning
20:00:52  <piscisaureus_>kewl
20:00:56  <isaacs>piscisaureus_: didn't want to compete with today's release and WWDC this morning
20:04:17  * mikealjoined
20:05:10  * irajoined
20:06:22  * brsonquit (Ping timeout: 240 seconds)
20:11:25  * brsonjoined
20:17:52  * mmalecki_joined
20:20:32  <CIA-108>libuv: Bert Belder master * re0c6114 / src/win/timer.c : windows: remove run-time RB_INSERT check from release builds - http://git.io/XJm0Og
20:21:02  * mmaleckiquit (Ping timeout: 244 seconds)
20:25:14  <creationix>piscisaureus_, didn't you guys recently add something that makes it easier to integrate with ui event loops?
20:25:24  <creationix>uv_poll or something
20:25:28  <tjfontaine>the uv_poll api
20:25:28  <piscisaureus_>creationix: well, we added uv_poll indeed
20:25:36  <piscisaureus_>creationix: that's basically ev_io btw
20:25:43  <creationix>I don't know libev
20:26:08  <piscisaureus_>creationix: what event loop do you want to integrate with?
20:26:13  <creationix>iOS
20:26:18  <piscisaureus_>hmm
20:26:26  <piscisaureus_>that's CF right?
20:26:34  <tjfontaine>yes
20:27:39  * xaqjoined
20:28:45  * travis-cijoined
20:28:45  <travis-ci>[travis-ci] joyent/libuv#404 (master - e0c6114 : Bert Belder): The build passed.
20:28:45  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3b417d1...e0c6114
20:28:45  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1595405
20:28:45  * travis-cipart
20:32:03  <piscisaureus_>tjfontaine: do you know if it possible to add a mach port to a kqueue set ?
20:32:31  <tjfontaine>piscisaureus_: I don't know the answer to that without looking
20:32:54  * igorzijoined
20:33:42  * isaacsquit (Remote host closed the connection)
20:35:41  * mmaleckijoined
20:38:49  * mmalecki_quit (Ping timeout: 256 seconds)
20:41:06  <piscisaureus_>creationix: a quick glance over the CF api doesn't really reveal anything that would leak a kqueue / mach port
20:41:27  <piscisaureus_>creationix: I think it's easier to use CF as the mail loop driver
20:41:32  <piscisaureus_>*main
20:41:50  <creationix>hmm, how bad will that hurt network performance?
20:41:53  <piscisaureus_>creationix: the only thing is that you'd need to leech the kqueue fd and the maximum block time out of libuv
20:41:54  <creationix>or battery life
20:42:31  <piscisaureus_>creationix: I think bnoordhuis has plans to expose the kqueue/epoll fd and uv_get_poll_timeout anyway
20:42:37  <piscisaureus_>creationix: well, I don't think it'll matter much
20:42:56  <piscisaureus_>creationix: the plan is not to busyloop - busylooping is easy
20:43:27  <piscisaureus_>creationix: rather, corefoundation makes a callback into one of your functions, in which you call uv_run_once
20:43:42  <piscisaureus_>creationix: so the latency could be slightly higher
20:44:06  <creationix>when I interface node and SDL, I do a setInterval(getSdlEvents, 1000/60)
20:44:17  <creationix>but that's because I want a 60hz animation loop anyway
20:44:21  <piscisaureus_>creationix: the alternative would be to crack open CF (/ read the manual really well), or run CF and libuv on separate threads
20:44:23  * philipsquit (Excess Flood)
20:44:30  <piscisaureus_>creationix: well, that's busylooping :-)
20:44:45  <creationix>busylooping-ish
20:44:47  * philipsjoined
20:44:48  <piscisaureus_>yes
20:44:48  <creationix>but yeah
20:45:01  <creationix>the ipad is dual-core right?
20:45:09  <creationix>I think the two-thread idea is fine
20:45:09  <piscisaureus_>I think so, yeah
20:45:20  <creationix>I want to run libuv and make opengl calls from one thread
20:45:29  <piscisaureus_>I know what this is about :-)
20:46:07  <piscisaureus_>creationix: so would you run opengl from the uv thread?
20:46:17  <creationix>ideally, yes
20:46:27  <creationix>my main app logic will be in that thread
20:46:39  <piscisaureus_>creationix: then what do you need the cf loop for? for dispatching ui events?
20:46:47  <creationix>ui events and getting a window up
20:46:58  <piscisaureus_>creationix: yeah, I suppose that could work
20:47:08  <piscisaureus_>you'd have to send ui events to the uv loop (I suppose)
20:47:13  * mmalecki_joined
20:47:17  <piscisaureus_>but that's possible with uv_async etc
20:47:29  <creationix>uv_async, hmm
20:47:45  <piscisaureus_>or with a pipe, if you want :-)
20:49:12  <creationix>a pipe is probably easiest
20:49:19  <creationix>I can json or msgpack encode the events
20:49:31  <piscisaureus_>maybe, ehm, use a struct :-)
20:49:42  <creationix>nah, that's shared memory thing is overrated ;)
20:49:59  <piscisaureus_>ghe dude
20:50:03  * mmaleckiquit (Ping timeout: 245 seconds)
20:50:07  <creationix>oh, you mean byvalue structs
20:50:12  <piscisaureus_>noo
20:50:26  <piscisaureus_>just make a linked list of malloced structs
20:50:31  <piscisaureus_>and protect it with a mutex
20:50:33  <piscisaureus_>voila
20:50:40  <creationix>so the pipe is just for sync
20:50:42  <creationix>not for data?
20:50:52  <piscisaureus_>well, use uv_async and not a pipe :-)
20:50:58  * japjjoined
20:51:13  <piscisaureus_>I mean, you don't have to process 10K ui events per second
20:51:16  <piscisaureus_>more likely, 5
20:51:22  <piscisaureus_>who cares who you implement it
20:51:27  <piscisaureus_>make it as easy as possible
20:51:30  <creationix>well touch events are fairly fast, but nowhere near 10k/second
20:51:44  <creationix>max a few hundred
20:51:50  <piscisaureus_>*shrug*
20:52:07  <piscisaureus_>even the ipad won't break a sweat
20:52:14  <creationix>ok, I guess I need to learn some objective C and build out a shell
20:52:26  <creationix>libuv builds fine for iOS I'm told
20:52:27  <piscisaureus_>creationix: did someone buy you an ipad already?
20:52:38  <japj>pquerna: do you also validate date(string) fields with node-swiz? (I can't find any example/test using dates)
20:52:39  <creationix>not yet, but I have an old one with a cracked screen
20:52:42  <piscisaureus_>creationix: well, I think you need a mac first
20:52:52  <creationix>I have several macs, I just prefer to use linux
20:54:01  <creationix>so CF doesn't care if I make opengl calls from a non-main thread? I'm so used to systems like web workers where only the main thread can do UI work
20:54:18  <piscisaureus_>creationix: you could also consider skipping libuv entirely... I think CF has socket support
20:54:28  <piscisaureus_>creationix: I don't know what you will miss tho
20:54:59  <creationix>yeah, thought about that, but I kinda want to use libuv
20:55:03  * mmaleckijoined
20:55:15  <creationix>so I can port my app to other platforms easier
20:55:26  <piscisaureus_>creationix: I think opengl is threadsafe as long as you don't access it concurrently from multiple threads
20:55:29  <piscisaureus_>creationix: like v8
20:55:36  <creationix>perfect
20:55:51  <creationix>time to open XCode...
20:56:06  <piscisaureus_>XCode... the pain
20:56:16  <piscisaureus_>I think I prefer notepad over xcode
20:56:30  <piscisaureus_>(keep in mind that i have a profound hate for notepad)
20:58:48  * mmalecki_quit (Ping timeout: 245 seconds)
21:01:57  <creationix>is there another way to make iOS apps? I'm all ears
21:02:34  <tjfontaine>there are some tutorials about doing the compiling from cli
21:03:31  <bnoordhuis>piscisaureus_: what's the issue with core.c again? the new gyp doesn't like that there's two of them?
21:04:11  <piscisaureus_>bnoordhuis: yes, well, there can't be two core.c's in one library
21:04:24  <bnoordhuis>hah, what a silly rule
21:04:51  <bnoordhuis>does it matter if they're in, say, src/unix and src/linux?
21:04:58  <piscisaureus_>bnoordhuis: no
21:05:03  <bnoordhuis>or are duplicates completely verboten now?
21:05:06  * avalanche123quit (Quit: Leaving...)
21:05:09  <piscisaureus_>bnoordhuis: yes
21:05:17  <bnoordhuis>how silly
21:05:18  <piscisaureus_>bnoordhuis: apparently libtool and msvc doesn't like it
21:05:53  <bnoordhuis>msvc maybe but libtool?
21:06:07  <piscisaureus_>that's what the gyp guys say... I don't know what libtool is even
21:06:15  <piscisaureus_>:-p
21:06:34  <bnoordhuis>creationix: i don't think the opengl spec promises anything about thread safety
21:07:02  <bnoordhuis>creationix: and os x's flavor requires a 'context per thread' model iirc
21:07:33  <piscisaureus_>the alternative would be to join CF and libuv
21:07:54  <piscisaureus_>bnoordhuis: since CF is not very flexible in this regard, we'd have to expose the kqueue fd and uv_poll_timeout
21:08:16  <bnoordhuis>oh wait, on os x you _can_ use the context from multiple threads as long as you use proper locking
21:08:51  <bnoordhuis>piscisaureus_: i'll send a patch to apple :)
21:09:24  * paddybyersquit (Quit: paddybyers)
21:09:26  <tjfontaine>good luck getting that in mountain lion
21:09:58  <mmalecki>can you send a patch to apple?
21:10:37  <tjfontaine>jump in #llvm on oftc and you'll even have access to the people who work on that stuff
21:11:08  <mmalecki>interesting!
21:11:35  <mmalecki>"uhm, hey folks, I've got a kernel patch for you"
21:14:36  * indexzerojoined
21:14:54  * mmalecki_joined
21:15:23  * felixgejoined
21:15:23  * felixgequit (Changing host)
21:15:23  * felixgejoined
21:16:47  * isaacsjoined
21:17:18  <isaacs>bnoordhuis: quick question.. so, /proc/stat reports size=0 from lstat, which confuses fs.readFile
21:17:37  <bnoordhuis>isaacs: yes, i've seen the ML thread
21:17:44  <isaacs>bnoordhuis: should we be suspicious of any file that reports a 0 filesize, and just try to read 1024 or something from it?
21:17:46  <bnoordhuis>i can reproduce it, not the timer issue though
21:17:58  <isaacs>yeah, i dont' grok the timer thing
21:17:59  * mmaleckiquit (Ping timeout: 244 seconds)
21:18:08  <bnoordhuis>isaacs: well... yes, if it lives under /dev, /proc or /sys
21:18:40  <bnoordhuis>so i would go with 'assume the kernel lies and try to read some bytes anyway'
21:19:34  <isaacs>heh.
21:19:47  <bnoordhuis>you can check the file type that fstat() reports ('is this is a regular file?') and if not, always read
21:19:54  <isaacs>it grates me a bit to have magic paths in fs.js, but i guess the magic paths are in the OS
21:20:12  <isaacs>> fs.lstatSync('/proc/stat').isFile()
21:20:12  <isaacs>true
21:20:13  <isaacs>bnoordhuis: ^
21:20:30  <tjfontaine>don't forget that magic paths can be anywhere
21:21:13  <isaacs>yeah
21:21:20  <isaacs>i think we need to just say, if size=0, don't trust it
21:22:37  <bnoordhuis>yes, sorry, that's what i meant
21:25:40  * AndreasMadsenquit (Remote host closed the connection)
21:33:36  * mmaleckijoined
21:35:32  * rendarquit
21:36:35  * mmalecki_quit (Ping timeout: 244 seconds)
21:37:06  <bnoordhuis>piscisaureus_: https://groups.google.com/group/nodejs/browse_thread/thread/ceb82ff04b7aae9
21:37:06  <bnoordhuis>piscisaureus_: https://github.com/joyent/node/blob/2301eb6/lib/child_process.js#L333 seems to be the culprit
21:37:51  * igorziquit (Ping timeout: 245 seconds)
21:38:14  <piscisaureus_>bnoordhuis: yes, so ?
21:38:22  <piscisaureus_>bnoordhuis: ok, that code is lame
21:39:08  * mmalecki_joined
21:39:43  <piscisaureus_>bnoordhuis: I have the tendency to fire the guy who wrote that
21:42:34  * mmaleckiquit (Ping timeout: 265 seconds)
21:42:47  <bnoordhuis>piscisaureus_: yeah, he should be let go
21:43:04  <bnoordhuis>piscisaureus_: but can you reproduce the issue?
21:43:16  <bnoordhuis>and if so, what happens if you remove that check?
21:43:27  <piscisaureus_>bnoordhuis: didn't trym but yeah, the bug is very obvious
21:44:01  <bnoordhuis>i wonder if it actually guards against something though
21:44:12  <bnoordhuis>e.g. runaway memory consumption
21:44:33  <CIA-108>node: Bert Belder reviewme * ra96cdb1 / lib/child_process.js : Cluster: don't silently drop messages when the write queue gets big - http://git.io/nF5X8Q
21:44:34  <piscisaureus_>bnoordhuis: yes, it probably does
21:44:40  <piscisaureus_>bnoordhuis: ^ ?
21:45:35  * igorzijoined
21:46:26  <bnoordhuis>piscisaureus_: s/Cluster/cluster/, otherwise lgtm
21:47:18  <CIA-108>node: Bert Belder master * rcfa2869 / lib/child_process.js : cluster: don't silently drop messages when the write queue gets big - http://git.io/XQfrrw
21:50:45  * mmaleckijoined
21:51:34  <isaacs>review? https://github.com/isaacs/node/commit/21163e48033e9fd1b5812dd6f4ca8fce7b9d5797
21:53:05  <piscisaureus_>bnoordhuis: I wonder if _writeQueueSize could not be maintained properly for ipc channels on windows
21:53:10  <piscisaureus_>bnoordhuis: I will check
21:53:15  <piscisaureus_>I mean, 1mb backlog... that's a lot
21:53:38  * mmalecki_quit (Ping timeout: 244 seconds)
21:54:07  * paddybyersjoined
21:55:05  <piscisaureus_>bnoordhuis: isaacs: should we not use seek(fd, 0, SEEK_END) for that?
21:55:10  <piscisaureus_>or would that not work either?
21:55:33  <bnoordhuis>piscisaureus_: you can't lseek() /proc files
21:55:46  <isaacs>yeah, if stat is lying, i'd suspect that seek would be even more cagey
21:56:29  <isaacs>bnoordhuis: fixed your nit: https://github.com/isaacs/node/commit/fs-readfile-zero-length-error
21:57:11  * mmalecki_joined
21:59:59  * mmaleckiquit (Ping timeout: 246 seconds)
22:00:34  <bnoordhuis>isaacs: that's one evil test :)
22:00:43  <isaacs>:D
22:01:34  <isaacs>bnoordhuis: for a long time, i've wanted to write an EvilFS fuse program to run fs tests again
22:01:37  <isaacs>*against
22:01:45  <isaacs>it'd do everything you're supposed to be careful of.
22:02:05  <isaacs>every race fails. read always returns between 0 and 5 bytes. stat() lies about everythign. crazy stuff.
22:02:14  <bnoordhuis>hah, that'd be awesome
22:02:24  <piscisaureus_>bnoordhuis: I think I know what happens
22:02:36  <piscisaureus_>bnoordhuis: the channel is sync on unix, but not on windows
22:02:39  <isaacs>k, i'm gonna land this then. it's a low-hanging win :)
22:02:52  <isaacs>oh, more nits. nvm...
22:02:55  <isaacs>i'll fix that first :)
22:02:58  <tjfontaine>isaacs: there are some similar futzer fuse's out there iirc
22:03:00  <bnoordhuis>piscisaureus_: that could very well explain it
22:03:10  <tjfontaine>*fuzzer
22:03:29  <isaacs>how would you guys feel about a Buffer.flatten(array) method?
22:03:35  <isaacs>I write this loop a lot.
22:04:21  <isaacs>pass in an array of buffers and a length, and it'll return you a flattened one.
22:04:50  <tjfontaine>I'm not sure if flatten is what I would call it, but yes I would appreciate that method as well
22:05:27  <bnoordhuis>isaacs: buffertools calls it .concat
22:05:41  <tjfontaine>yes, that's more along what I say
22:05:48  <isaacs>bnoordhuis: oh, sure.
22:05:51  <piscisaureus_>oh the humanity
22:06:03  <isaacs>bnoordhuis: is that on the global Buffer object, or a buffer.concat(otherBuffer)
22:06:19  <isaacs>bnoordhuis: we have a lot of cases in node-core where we keep a list of buffer objects, then flatten them all at the end
22:06:22  <tjfontaine>global, because of the static sizing iirc
22:06:34  <piscisaureus_>you unix guys have made such a mess of blocking/nonblocking stdio :-(
22:06:39  <bnoordhuis>isaacs: global, i think. maybe both
22:06:42  <piscisaureus_>^-- bnoordhuis ryah
22:06:56  <bnoordhuis>piscisaureus_: it was all done by that guy we had to let go
22:06:58  <isaacs>bnoordhuis: the actual ideal awesome thing would be a zero-copy flatten.
22:07:13  <isaacs>bnoordhuis: like, just shift all the pointers around.
22:07:16  <piscisaureus_>very painful
22:07:21  <bnoordhuis>isaacs: that would require some brutal hacks to v8
22:07:27  <isaacs>yeah, i imagine.
22:07:33  <bnoordhuis>isaacs: that'd probably kill general buffer performance
22:07:35  <isaacs>copying is not so bad.
22:08:06  <piscisaureus_>I definitely can't add blocking pipe support within the 0.8 timeline ;-(
22:08:14  <tjfontaine>I think it's only global https://github.com/coolaj86/node-bufferjs/blob/master/bufferjs/concat.js
22:08:34  <piscisaureus_>also, I don't even know what should be blocking and what not
22:08:44  * mmaleckijoined
22:11:43  <piscisaureus_>isaacs: i am going to send an email to nodejs-dev about this, cause I don't know what to do any more...
22:11:46  * mmalecki_quit (Ping timeout: 248 seconds)
22:14:13  * mmalecki_joined
22:16:26  <isaacs>piscisaureus_: sorry, i've been only sort of half paying attention to this issue.
22:16:32  <piscisaureus_>isaacs: nvm
22:16:42  <isaacs>piscisaureus_: what is the problem for v0.8? is this blocking something else that we'd discussed?
22:16:45  <piscisaureus_>I am just a little bit frustrated by all this mess
22:16:58  <isaacs>yeah, that's probably fair.
22:17:14  <piscisaureus_>isaacs: no, but the lack of agreement is impairing my ability to fix bugs here
22:17:22  * mmaleckiquit (Ping timeout: 265 seconds)
22:17:32  <isaacs>agreement between humans or between platforms?
22:17:48  <piscisaureus_>isaacs: basically, that means that this issue -> https://groups.google.com/group/nodejs/browse_thread/thread/ceb82ff04b7aae9 <- won't be solved for 0.8
22:17:53  <piscisaureus_>not properly, that is
22:18:13  <piscisaureus_>isaacs: agreement on how node should behave, so, that's between humans :-)
22:18:15  <isaacs>i see
22:18:27  <piscisaureus_>I think I am going to forget about it now
22:18:34  <isaacs>yeah, this has 0.9 written all over it.
22:18:58  <isaacs>iiuc, then, the issue is that process.send is sync on unix, but async on win32, so if you send/send/send..., on windows, it'll eventually start dropping messages?
22:19:10  <isaacs>if the child doesn't pick them up soon enough
22:19:12  <piscisaureus_>isaacs: yeah, so I've just dropped the dropping
22:19:14  * mmaleckijoined
22:19:23  <isaacs>hrm... that sounds... not so great.
22:19:41  <isaacs>any way to make it sync on windows as well? or is that the frustration you're talking about?
22:19:43  <piscisaureus_>isaacs: so now your node will eventually blow up
22:19:48  * mmalecki_quit (Ping timeout: 245 seconds)
22:19:55  <piscisaureus_>isaacs: well, the question is if we really want to make it sync
22:20:18  <piscisaureus_>isaacs: I suppose that's not even a very bad idea for cluster channels
22:20:25  <piscisaureus_>but in general I think it's a bad idea
22:20:29  <isaacs>sure
22:20:41  <isaacs>for cluster processes, i think sync message passing is not so bad.
22:21:02  <piscisaureus_>isaacs: well, from the manager's perspective it is
22:21:24  <piscisaureus_>if the master blocks because the worker is busy, then the master also hangs
22:21:35  <piscisaureus_>not great
22:21:48  <piscisaureus_>ideally we'd just have writeSync for nonblocking streams (yuk)
22:21:57  <piscisaureus_>I think that's the most reasonable thing to do here actually
22:22:21  <piscisaureus_>so all the apis that are not good at handling backpressure (e.g. console.log and cluster sends) can use that
22:22:31  <bnoordhuis>i forgot (again, i think) why we made it sync. because pipes fill up quickly?
22:22:31  <piscisaureus_>and when people need that, they can just use the async write
22:22:53  <piscisaureus_>bnoordhuis: I think so no data get lost on a crash
22:23:16  <isaacs>yeah, i really do not know why it's sync eihter.
22:23:29  <isaacs>but it sounds like too much of an architectural change to even consider for v0.8 at this point
22:23:58  <bnoordhuis>piscisaureus_: node could consider it a regular stream and back off when .write() returns false, right?
22:23:58  <isaacs>put it off for a few weeks, or better yet, let more people get bit by it so we can get some data about what the best approach is.
22:24:08  <bnoordhuis>but yes, let it rest for now :)
22:24:26  <piscisaureus_>bnoordhuis: yes, that would be possible
22:24:46  <piscisaureus_>bnoordhuis: although - if cluster sends() should handle backpressure, then we should implement a drain event etc
22:25:22  * pquerna_joined
22:25:40  * pfox___joined
22:26:27  <isaacs>bnoordhuis, tjfontaine: https://github.com/isaacs/node/compare/buffer-flatten
22:26:36  * TheJHquit (Read error: Operation timed out)
22:26:43  <isaacs>tjfontaine: coolaj's isn't suitable for core. it's a bit too fancy and not optimized for speed.
22:27:19  <tjfontaine>isaacs: sure indeed, I was just pointing it out
22:28:34  * txdvquit (Quit: No Ping reply in 180 seconds.)
22:28:44  * txdvjoined
22:29:07  * theColejoined
22:29:31  * igorziquit (Ping timeout: 245 seconds)
22:30:21  * deoxxaquit (Ping timeout: 248 seconds)
22:30:21  * indutnyquit (Ping timeout: 248 seconds)
22:30:22  * pquernaquit (Ping timeout: 248 seconds)
22:30:22  * pfox__quit (Ping timeout: 248 seconds)
22:30:22  * japjquit (Ping timeout: 248 seconds)
22:30:23  <tjfontaine>isaacs: the method seems straight forward enough to me
22:30:25  * paddybyersquit (Quit: paddybyers)
22:30:42  * deoxxajoined
22:30:53  * pfox___quit (Ping timeout: 240 seconds)
22:31:14  * isaacsquit (Ping timeout: 244 seconds)
22:31:52  * indutnyjoined
22:31:53  * einarosquit (Ping timeout: 240 seconds)
22:32:17  * bnoordhuisquit (Ping timeout: 244 seconds)
22:32:53  * demarchiquit (Ping timeout: 269 seconds)
22:34:36  * demarchijoined
22:35:20  * isaacsjoined
22:35:51  * mmalecki_joined
22:38:59  * pfox__joined
22:39:04  * mmaleckiquit (Ping timeout: 252 seconds)
22:39:04  * felixgequit (Quit: felixge)
22:39:29  * einarosjoined
22:41:59  * c4miloquit (Remote host closed the connection)
22:42:05  * igorzijoined
22:43:51  * bnoordhuisjoined
22:45:43  <bnoordhuis>apparently i timed out...
22:46:14  <bnoordhuis>piscisaureus_: i'm undecided if those v8 patches have positive, negative or no impact on unix. the difference is so small it might just be noise. does it help on windows?
22:46:23  <piscisaureus_>bnoordhuis: yes
22:46:37  <piscisaureus_>bnoordhuis: I think on unix these functions were inlined anyway
22:46:37  <bnoordhuis>piscisaureus_: how much? i want numbers!
22:46:56  <bnoordhuis>piscisaureus_: not always, i've seen them in profile logs
22:46:57  <piscisaureus_>bnoordhuis: it gave me ~ +200 r/s
22:47:15  <bnoordhuis>okay, that's an easy win
22:47:19  <piscisaureus_>bnoordhuis: also, when I profile bytes/12345 then the difference is pretty big actually
22:47:27  <piscisaureus_>bnoordhuis: you should try that too
22:48:00  <bnoordhuis>ah, i just recompiled v8 again...
22:48:11  * pquerna_quit (Changing host)
22:48:11  * pquerna_joined
22:48:13  * pquerna_changed nick to pquerna
22:48:17  <piscisaureus_>bnoordhuis: yeah, fuck that, make multiple checkouts :-)
22:50:05  <isaacs>bikeshed opinions? flatten or concat?
22:50:10  <AvianFlu>concat
22:50:21  * isaacsis in the minority.
22:50:23  <isaacs>Concat it is.
22:50:25  <AvianFlu>I wasn't sure what flatten would even mean there
22:50:28  <AvianFlu>at first
22:51:01  <piscisaureus_>isaacs: anything as long as you document that it is basically a memcpy :-)
22:51:31  * mmaleckijoined
22:51:36  <isaacs>piscisaureus_: it's either a memcpy or a reference to list[0] or new Buffer(0)
22:51:41  <isaacs>and yes, it is documneted.
22:51:52  <bnoordhuis>https://lists.debian.org/debian-qa/2011/10/msg00056.html <- "Lucas managed to get Amazon to award Debian $10,000 [3] in order to run about 60 full archive rebuilds on their infrastructure"
22:52:01  <bnoordhuis>heating up the earth by 0.1 degree celsius
22:52:10  <bnoordhuis>but in all seriousness, that's pretty nice of amazon
22:52:33  <CIA-108>node: isaacs master * rd53cdc5 / (3 files in 3 dirs): Add Buffer.concat method - http://git.io/qiyyfw
22:52:53  * xaqquit (Remote host closed the connection)
22:54:18  <isaacs>wait, wat?
22:54:23  * mmalecki_quit (Ping timeout: 245 seconds)
22:54:31  <isaacs>oh, right, concat.
22:57:50  <CIA-108>node: isaacs master * r6ce013d / (lib/fs.js test/simple/test-fs-readfile-zero-byte-liar.js): fix fs.readFile with lying size=0 stat results - http://git.io/Y84g8w
23:08:31  * indexzeroquit (Read error: Connection reset by peer)
23:08:46  * indexzerojoined
23:10:46  <piscisaureus_>anyone here understands the rationale behind test-net-write-slow?
23:10:48  <piscisaureus_>what does it test?
23:12:56  <bnoordhuis>piscisaureus_: that .setTimeout() works, i think
23:13:20  <piscisaureus_>bnoordhuis: well, that'd be surprising
23:13:32  <piscisaureus_>bnoordhuis: if the timeout actually triggers, the process crashes
23:14:11  <bnoordhuis>piscisaureus_: maybe i should've said that writes finish before .setTimeout() triggers :)
23:14:41  <piscisaureus_>in windows the entire test takes 2.5 s
23:14:51  <piscisaureus_>no wonder that the timer (200ms) triggers :-(
23:16:13  <bnoordhuis>maybe you should optimize your network code :)
23:16:28  <bnoordhuis>i agree it's not a great test
23:16:40  <bnoordhuis>but that's true for any test involving timers and i/o
23:17:02  <piscisaureus_>bnoordhuis: the thing is
23:17:12  <piscisaureus_>it does settimeout(x, 20)
23:17:18  * theColequit (Quit: theCole)
23:17:23  <piscisaureus_>if I use process.nextTick it finishes in no time
23:18:41  <piscisaureus_>and the timer doesn't block for (much) more than it should
23:18:42  <bnoordhuis>i don't mind if you scrap it
23:19:24  * mmalecki_joined
23:19:38  <piscisaureus_>no, I am wondering why it passes on unix
23:20:18  <piscisaureus_>on windows, it does about 90 reads with 20ms timeouts between the,
23:20:24  <piscisaureus_>do the math
23:20:34  <piscisaureus_>that can never finish in 200 ms :-(
23:21:38  <piscisaureus_>maybe unix scales the receive window to something like 256k
23:21:40  <piscisaureus_>that'd work
23:21:44  <piscisaureus_>but on windows, it doesn't
23:22:08  <bnoordhuis>have i mentioned lately what a POS waf is?
23:22:14  * mmaleckiquit (Ping timeout: 246 seconds)
23:22:18  * iraquit (Quit: Leaving...)
23:22:37  <bnoordhuis>piscisaureus_: it passes because i/o is really fast :)
23:22:50  <piscisaureus_>bnoordhuis: that cant be true
23:23:12  <piscisaureus_>bnoordhuis: it can only pass because it reads in very big chunks and/or ignore stream.pause() requests
23:23:12  <bnoordhuis>it's all localhost traffic so the data is sent and received in big chunks
23:23:22  <bnoordhuis>exactly :)
23:23:28  <piscisaureus_>but even then
23:23:40  <bnoordhuis>that's all there is to it
23:23:43  <piscisaureus_>how many data can you read at most in one read()
23:23:43  <bnoordhuis>strace it in your vm
23:23:53  <piscisaureus_>65k right?
23:24:05  <bnoordhuis>yes, but uv-unix reads in a loop
23:24:17  <piscisaureus_>yes, but it calls pause() in the read cb
23:24:23  <piscisaureus_>so it should fall off the loop
23:25:36  <bnoordhuis>piscisaureus_:
23:25:36  <bnoordhuis>write(7, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 46336) = 46336
23:25:37  <bnoordhuis>write(7, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 200000) = 150272
23:25:37  <bnoordhuis>read(6, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 65536) = 65536
23:25:37  <bnoordhuis>read(6, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 65536) = 65536
23:25:37  <bnoordhuis>read(6, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 65536) = 65536
23:25:38  <bnoordhuis>write(7, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 49728) = 49728
23:25:40  <bnoordhuis>write(7, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 200000) = 146880
23:25:51  <bnoordhuis>that's just a snippet btw
23:25:52  <piscisaureus_>aaaaaaah
23:25:58  <piscisaureus_>bnoordhuis: now I see
23:26:16  <piscisaureus_>bnoordhuis: probably, a write resets the timer on unix
23:26:26  <piscisaureus_>bnoordhuis: but on windows all the data is queued in a tight loop
23:26:34  <piscisaureus_>I think the timer doesn't get reset
23:26:54  <bnoordhuis>the timer is managed by node, not uv-unix
23:28:19  <piscisaureus_>bnoordhuis: the test transfers 2 * 10^6 bytes
23:28:50  <piscisaureus_>bnoordhuis: max. 65536 bytes can be read in one pass
23:28:58  <piscisaureus_>so that's at least 31 passes
23:29:09  <piscisaureus_>there's a 20ms timeout between passes
23:29:23  * c4milojoined
23:29:24  <piscisaureus_>so that makes 30*20 = 600 ms
23:29:25  <piscisaureus_>at least
23:29:34  <piscisaureus_>so if the timeout is 200ms, the socket should time out
23:31:41  <bnoordhuis>https://github.com/joyent/node/blob/f482236/deps/v8/src/objects.cc#L10190 <- i wonder if this ever made it into a release version of chromium
23:32:27  <bnoordhuis>if yes, there's probably an exploit in there somewhere
23:32:53  <piscisaureus_>bnoordhuis: you mean, the assert?
23:33:09  <bnoordhuis>piscisaureus_: well, the fact that it fails badly with typed arrays
23:33:18  <bnoordhuis>piscisaureus_: https://github.com/joyent/node/issues/3403
23:33:22  <piscisaureus_>ah
23:33:45  <piscisaureus_>yes, wel v8 3.9 is in chromium
23:33:47  <piscisaureus_>but 10/11 are not
23:34:05  <bnoordhuis>this is with 3.6.6.25
23:34:14  <piscisaureus_>ah
23:34:19  <piscisaureus_>yeah that's already quite outdated
23:34:33  <piscisaureus_>although... the ASSERT should not be in a release build I think
23:34:48  <bnoordhuis>no, that's what makes it potentially exploitable
23:35:03  <bnoordhuis>without the assert, it will try to sort the typed array
23:35:15  <piscisaureus_>but I suppose later versions of v8 have it fixed
23:35:15  <bnoordhuis>but that ends up badly
23:35:25  <bnoordhuis>yes, works fine with 3.9 and up
23:38:21  <piscisaureus_>bnoordhuis: hmm, I see what happens
23:38:28  <piscisaureus_>in test-net-write-slow
23:38:39  <piscisaureus_>I will just up the time limit, there is no bug in here
23:38:55  * indexzeroquit (Read error: Connection reset by peer)
23:39:20  * indexzerojoined
23:43:39  * indexzero_joined
23:43:58  * indexzeroquit (Ping timeout: 252 seconds)
23:43:58  * indexzero_changed nick to indexzero
23:44:42  <CIA-108>node: Bert Belder master * r00ba1cb / test/simple/test-net-write-slow.js : test-net-write-slow: increase the socket timeout period - http://git.io/lblAjA
23:45:51  <bnoordhuis>hah, why not just scrap it?
23:46:03  <piscisaureus_>why?
23:46:14  <piscisaureus_>it stresses some parts of node
23:46:17  <piscisaureus_>that's a good thing to do
23:49:59  <CIA-108>libuv: Ben Noordhuis master * r84f0d96 / src/unix/dl.c : unix: reset error status in uv_dlopen() - http://git.io/0RsAaw
23:52:46  * travis-cijoined
23:52:46  <travis-ci>[travis-ci] joyent/libuv#405 (master - 84f0d96 : Ben Noordhuis): The build passed.
23:52:46  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/e0c6114...84f0d96
23:52:46  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1596901
23:52:46  * travis-cipart
23:57:50  <CIA-108>node: Bert Belder master * r094f742 / test/simple/test-http-get-pipeline-problem.js : test-http-get-pipeline-problem: don't fail if there are stray files in the temp dir - http://git.io/zTtf9w