00:00:06  * travis-cijoined
00:00:06  <travis-ci>[travis-ci] joyent/node#15 (master - e53e9c7 : Ryan Dahl): The build was fixed.
00:00:06  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/06d86eb...e53e9c7
00:00:06  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/384189
00:00:06  * travis-cipart
00:14:35  * luxigoquit (Remote host closed the connection)
00:16:09  <bnoordhuis>lessons learned, don't util.format("%j") a fastbuffer - it tries to json-ify the whole slab
00:20:01  * dapquit (Quit: Leaving.)
00:20:11  * piscisaureus__quit (Read error: Connection reset by peer)
00:20:35  * piscisaureus_joined
00:21:50  <mjr_>Yeah, that'll wedge you up for quite a while, depending on the size.
00:22:30  <piscisaureus_>bnoordhuis: I think this write issue could also cause memory leaks with http
00:22:54  <piscisaureus_>bnoordhuis: http sockets are open with allowHalfOpen
00:23:12  <bnoordhuis>piscisaureus_: that sounds plausible
00:23:15  <piscisaureus_>so if the client sends FIN we just stop the read watcher
00:24:10  <piscisaureus_>so we don't attempt any reads so we don't see the error
00:24:13  <piscisaureus_>and since write errors are never reported the socket just remains in limbo forever
00:24:34  <bnoordhuis>why do we set halfOpen:true anyway?
00:24:45  <piscisaureus_>bnoordhuis: also, the write callback does return so the timeout timer gets reset every time
00:25:14  <piscisaureus_>bnoordhuis: because if a client doesn't set content-length the end of the request body is marked by FIN
00:25:24  <piscisaureus_>bnoordhuis: but the server may still want to send a response after that
00:25:58  <bnoordhuis>ah right - http...
00:32:31  <mjr_>If you guys are in SF next week, Voxer is having a holiday party on Wednesday to which you are invited.
00:33:42  <bnoordhuis>mjr_: would love to but i'm halfway across the world
00:33:57  <mjr_>heh, of course. I just thought I'd throw that out there.
00:34:18  <piscisaureus_>I'm actually in mexico next week but it's still way too far :-)
00:34:38  <mjr_>We sure do appreciate all the work you guys put into node.
00:46:15  <mjr_>OK, got another stuck one
00:47:01  <benvie>soo about the rapping
00:47:05  <benvie>good stuff
00:47:32  <mjr_>bnoordhuis: got a stuck one, but that strace didn't work
00:47:37  <mjr_>write(2084, "\25\3\0\0 .\327\377\252\310\3120!z$CWoJ\262\4\316\200D\262\375+\32\221\212f\333"..., 37) = -1 EPIPE (Broken pipe)
00:47:47  <mjr_>sudo strace -p 12211 -e write=2084
00:47:47  <mjr_>strace: invalid descriptor `2084'
00:49:13  <mjr_>ryah: ^^
00:49:16  <mjr_>Can do gdb stuff if you want
00:50:36  <mjr_>https://gist.github.com/81525f200cdc78e11a6f
00:52:31  <mjr_>I guess I'll apply that patch and see if it happens again.
00:52:43  <bnoordhuis>mjr_: can we continue tomorrow? it's 2 am here, gotta get some sleep
00:52:49  <mjr_>sure, np.
00:53:22  * bnoordhuissigns off for the night
00:54:12  * bnoordhuisquit (Quit: Leaving)
00:56:33  * dapjoined
00:59:51  * mralephquit (Quit: Leaving.)
01:27:39  <piscisaureus_>hmm this so so weird
01:28:07  <piscisaureus_>some kind of funghus has eaten my node.js shirt :-(
01:28:28  <piscisaureus_>not it's full of big holes
01:28:47  <piscisaureus_>the weird thing is, it ate *only* that particular shirt
01:29:07  <piscisaureus_>everything else in my closes is completely unaffected
01:29:12  <piscisaureus_>*closet
01:37:36  <ryah>mjr_: still there?
01:37:54  <mjr_>Hey
01:38:06  <mjr_>Had to restart that process, sorry
01:38:27  <ryah>mjr_: did you try that patch from ben?
01:38:34  <mjr_>I did not, but I will
01:38:44  <mjr_>Seems like a win
01:38:57  <ryah>yes
01:40:18  <mjr_>We just got up to 400,000 HTTPS at once.
01:43:07  <mjr_>Did you see that stack from gdb?
01:43:18  <mjr_>Runtime_Math_pow()
01:43:19  <mjr_>?
01:48:21  <ryah>uh no - let me look
01:48:38  <ryah>oh i wouldn't trust those frames
01:53:08  <piscisaureus_>especially not when a pow() call is in the middle
01:56:30  * ericktquit (Quit: erickt)
01:59:49  * piscisaureus_quit (Ping timeout: 240 seconds)
02:04:02  <CIA-111>node: Ryan Dahl master * r59055b2 / (src/node_buffer.cc src/node_buffer.h src/node_vars.h): Move node_buffer.cc globals to struct - http://git.io/MP7KSQ
02:04:02  * sh1mmerquit (Quit: sh1mmer)
02:04:03  <CIA-111>node: Ryan Dahl master * re10fd32 / (7 files): move global vars from platfrom, node_signal_watcher to struct - http://git.io/6lO19A
02:17:11  * travis-cijoined
02:17:11  <travis-ci>[travis-ci] joyent/node#16 (master - e10fd32 : Ryan Dahl): The build passed.
02:17:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e53e9c7...e10fd32
02:17:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/384498
02:17:11  * travis-cipart
02:25:37  <igorzi>ryah piscisaureus_: finally found why i was not seeing any improvements with non-0 reads
02:26:17  <igorzi>basically, the uv server that i am using for testing writes the http response, and closes the connection in the write callback
02:27:29  <igorzi>with non-0 reads, we are doing an extra malloc, because we queue another read after reading the request (which requires 64K buffer)
02:29:02  <igorzi>if i uv_close() the connection inside the read callback (right after uv_write) that eliminates the extra malloc/free
02:29:29  <igorzi>and with that i am seeing the ~3% improvement
03:00:55  * brsonquit (Quit: leaving)
03:16:08  * mikealquit (Quit: Leaving.)
03:20:02  * ericktjoined
03:26:36  * isaacsquit (Quit: isaacs)
03:26:39  * ericktquit (Read error: Connection reset by peer)
03:30:59  * ericktjoined
04:10:13  * mikealjoined
04:15:17  * isaacsjoined
04:25:03  * ericktquit (Quit: erickt)
04:30:00  * ericktjoined
05:34:18  * mmaleckiquit (Ping timeout: 244 seconds)
05:40:19  * felixgejoined
05:40:19  * felixgequit (Changing host)
05:40:19  * felixgejoined
05:40:32  * mmaleckijoined
06:09:54  * ericktquit (Ping timeout: 240 seconds)
06:25:41  * dapquit (Quit: Leaving.)
06:36:16  * ericktjoined
06:39:08  * mikealquit (Quit: Leaving.)
06:45:50  * sh1mmerjoined
06:50:02  * sh1mmerquit (Client Quit)
07:09:00  * ericktquit (Quit: erickt)
07:10:46  * mikealjoined
07:12:09  * isaacsquit (Quit: isaacs)
07:56:53  * mikealquit (Quit: Leaving.)
08:07:34  * mralephjoined
08:08:42  * indexzerojoined
08:17:45  * mikealjoined
08:21:45  * mikealquit (Client Quit)
08:25:23  * kuebkjoined
08:30:27  * kuebk1joined
08:33:27  * kuebkquit (Ping timeout: 252 seconds)
08:37:06  * kuebk1quit (Ping timeout: 240 seconds)
08:38:31  * kuebkjoined
09:11:25  * indexzeroquit (Read error: Connection reset by peer)
09:11:43  * indexzerojoined
09:19:59  * indexzeroquit (Ping timeout: 252 seconds)
09:20:55  * indexzerojoined
09:30:59  * indexzeroquit (Ping timeout: 252 seconds)
09:34:25  * mralephquit (Quit: Leaving.)
10:54:40  * piscisaureus_joined
13:25:00  * luxigojoined
13:40:07  * creationixquit (Quit: ZNC - http://znc.sourceforge.net)
13:42:07  * creationixjoined
14:00:17  * bnoordhuisjoined
14:01:06  <bnoordhuis>piscisaureus_: what's the greatest, most expensive windows 7? enterprise, professional or ultimate?
14:01:12  <bnoordhuis>ultimate has a nice ring to it
14:14:11  * bnoordhuisis downloading windows 7 ultimate sp1 x64
14:14:41  <mmalecki>bnoordhuis: difference is minor
14:15:02  <mmalecki>(yeah, I actually have a win7, crysis won't run under linux)
14:48:09  <CIA-111>node: Tim Oxley v0.6 * r871194d / doc/api/util.markdown : docs: document util.inspect's colors param - http://git.io/P-KDQQ
14:56:55  * AndreasMadsenjoined
14:58:31  * travis-cijoined
14:58:31  <travis-ci>[travis-ci] joyent/node#17 (v0.6 - 871194d : Tim Oxley): The build was broken.
14:58:31  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/22c2c34...871194d
14:58:31  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/386086
14:58:31  * travis-cipart
14:58:51  * AndreasMadsen_joined
15:02:10  <AndreasMadsen_>I'm online for about an hour to discuss cluster 2.0
15:02:25  <AndreasMadsen_>piscisaureus: I'm online for about an hour to discuss cluster 2.0
15:12:20  * AndreasMadsenquit (Quit: Leaving)
15:12:55  * AndreasMadsenjoined
15:19:47  * AndreasMadsen_quit (Quit: Page closed)
15:32:28  * kuebkpart
15:33:30  <CIA-111>libuv: Ben Noordhuis master * r248ca5d / src/unix/error.c : unix: translate ETIMEDOUT to UV_ETIMEDOUT - http://git.io/V0P7Zw
15:33:30  <CIA-111>libuv: Ben Noordhuis master * r34e95d1 / src/unix/core.c :
15:33:30  <CIA-111>libuv: unix: make it safe to delete the default loop
15:33:30  <CIA-111>libuv: Fixes a potential free() of non-malloc'ed memory. - http://git.io/a9ZZwA
15:33:30  <CIA-111>libuv: Ben Noordhuis master * r0db3274 / src/unix/stream.c :
15:33:31  <CIA-111>libuv: unix: check UV_CLOSING flag in uv__write()
15:33:31  <CIA-111>libuv: uv__write() runs after the read callbacks have fired. Said callbacks may have
15:33:32  <CIA-111>libuv: closed the handle, handle that graciously. - http://git.io/xIYovQ
15:33:32  <CIA-111>libuv: Ben Noordhuis master * rb89c31b / src/unix/pipe.c : unix: fix warning: return 0 in function returning void - http://git.io/BqSpnQ
15:33:33  <CIA-111>libuv: Ben Noordhuis master * r0d8cb08 / (4 files): Merge branch 'v0.6' - http://git.io/0zHnzg
15:40:36  <piscisaureus_>AndreasMadsen: that's cool but hmm... can you be here tonight?
15:40:51  <piscisaureus_>AndreasMadsen: it works better is SF has woken up as well
15:41:04  <piscisaureus_>*is -> when
15:42:10  <piscisaureus_>bnoordhuis: Enterprise. For non-enterprises Ultimate is the most expensive one
15:42:28  <bnoordhuis>piscisaureus_: i already started downloading ultimate
15:42:35  <AndreasMadsen>piscisaureus_: we are in same timezone right?
15:42:47  <piscisaureus_>bnoordhuis: Enterprise is basically the same as ultimate except that enterprise allows switching languages
15:43:07  <piscisaureus_>AndreasMadsen: we are, but ryah is also somewhat important in this project :-)
15:43:15  <AndreasMadsen>Yes
15:44:12  <AndreasMadsen>One moment
15:44:29  * AndreasMadsen_joined
15:44:31  <piscisaureus_>bnoordhuis: I am doing nothing again today. I still hope I can get the wrap list out before my holiday
15:44:45  <piscisaureus_>bnoordhuis: I think it's gonna be night shift work saturday or tomorrow
15:44:53  <bnoordhuis>piscisaureus_: wrap list == handle walker in node?
15:45:03  <piscisaureus_>bnoordhuis: the list stuff you need for isolates
15:45:08  <piscisaureus_>and domains
15:45:24  <bnoordhuis>tell me why i need it?
15:45:36  <piscisaureus_>bnoordhuis: because you need to tear down an isolate when it crashes
15:45:43  <piscisaureus_>so you have to kill all handles
15:46:10  <bnoordhuis>right
15:46:38  <bnoordhuis>doesn't that handle walker thing i wrote do most of that?
15:46:57  <piscisaureus_>bnoordhuis: it'll probably help
15:46:58  <bnoordhuis>i mean, it allows you to walk the handles - adding a handle killer is the work of 5 minutes and three lines of code
15:46:59  <piscisaureus_>bnoordhuis: for now
15:47:02  <AndreasMadsen_>piscisaureus: I have to go to bed about 22:00 UTC+1 but until when im fine. There is also a birthday in the weekend so it will have to be friday, but my brain dosn't work that well after after 22:00.
15:47:05  * ericktjoined
15:47:29  <bnoordhuis>AndreasMadsen: that's why the lord our saviour gave us amphetamines
15:47:33  <piscisaureus_>bnoordhuis: I assume you didn't implement the handle walker for windows :-)
15:47:41  <piscisaureus_>AndreasMadsen_: drop by around 8
15:47:44  <bnoordhuis>piscisaureus_: no, but it's easy to add - four lines of code
15:48:07  <piscisaureus_>AndreasMadsen: that's when we have the daily call too
15:48:18  <piscisaureus_>bnoordhuis: it's not, because on windows we don't keep a list of watchers
15:48:28  <piscisaureus_>so you'd have to add that as well
15:48:32  <piscisaureus_>which obviously we could
15:48:44  <piscisaureus_>but imho it's better to do this stuff in the binding layer
15:48:47  <piscisaureus_>which I am doing now
15:48:58  <bnoordhuis>it's trivial, just embed an ngx_queue_t in the handle
15:49:13  <AndreasMadsen_>piscisaureus_: In the morning I assume. But there I'm in school at that time.
15:49:15  <bnoordhuis>actually, i like that it's in libuv - i want to use it outside of node
15:49:23  <bnoordhuis>how old are you, AndreasMadsen_?
15:49:26  <piscisaureus_>AndreasMadsen_: no tonight at 20.00 pm
15:49:45  <AndreasMadsen_>bnoordhuis: I'm 18
15:50:05  <AndreasMadsen_>Well tonight is fine
15:50:06  <bnoordhuis>working in open source always makes me feel so old... (i'm 29)
15:50:27  <piscisaureus_>you are :-)
15:50:35  <AndreasMadsen_>bnoordhuis: but I started typing <html> for about 6 years ago.
15:50:41  <bnoordhuis>my next job is going to be as a cobol programmer, i'll be the junior by at least 15 years
15:51:11  <mmalecki>AndreasMadsen_: haha, sounds like what I did (I'm 17). high five!
15:51:20  <bnoordhuis>AndreasMadsen_: kids these days... when i was that old, i was writing 8086 assembly
15:51:32  <piscisaureus_>these kids :-/
15:51:33  <mmalecki>bnoordhuis: please don't mention cobol.
15:51:35  <AndreasMadsen_>:)
15:52:14  <piscisaureus_>next up we'll run in trouble with amnesty for relying on child labor
15:54:19  <AndreasMadsen_>The funny thing about this is that I can't get a student job because I don't have any job experience, but I guess that the employes loss.
15:55:10  <mmalecki>AndreasMadsen_: keep on hacking open source. I got a job 2 months after I started with node. people will notice you.
15:55:48  <AndreasMadsen_>mmalecki: That's cool
15:56:05  <piscisaureus_>AndreasMadsen_: it's true. If you get some good stuff in you'll be hired in no time
15:57:55  * AndreasMadsen_quit (Quit: Page closed)
16:05:06  * AndreasMadsenquit (Ping timeout: 240 seconds)
16:05:16  * isaacsjoined
16:09:38  * ericktquit (Quit: erickt)
17:04:12  <bnoordhuis>ref/unref bugs are annoyingly hard to debug right now
17:04:16  <bnoordhuis>how can we do better?
17:15:45  * mikealjoined
17:15:47  * AndreasMadsenjoined
17:16:54  * AndreasMadsenquit (Client Quit)
17:17:47  * mikealquit (Client Quit)
17:26:24  * dapjoined
17:28:56  * ericktjoined
17:32:13  <piscisaureus_>bnoordhuis: uv_ref and unref should take a handle as parameter
17:32:50  <piscisaureus_>bnoordhuis: and it should assert if a handle is (un)refed more than once
17:32:59  <piscisaureus_>bnoordhuis: so we keep the ref state in a flags field
17:33:13  <bnoordhuis>piscisaureus_: agreed
17:34:03  * mikealjoined
17:35:59  * ericktquit (Remote host closed the connection)
17:36:15  * ericktjoined
17:46:51  * ryahquit (Ping timeout: 255 seconds)
17:47:33  * ryahjoined
18:04:26  * mikealquit (Quit: Leaving.)
18:07:03  * mikealjoined
18:09:16  <indutny>isaacs: https://github.com/isaacs/npm/issues/1855
18:09:25  <indutny>hi
18:09:36  <isaacs>indutny: hello
18:09:38  <isaacs>let's figure this out
18:09:56  <indutny>isaacs: looks like wierd update/validation problem
18:21:17  * mikealquit (Quit: Leaving.)
18:54:17  * AndreasMadsenjoined
18:54:24  * AndreasMadsen_joined
18:55:37  * brsonjoined
18:58:00  <piscisaureus_>call in 5?
18:58:16  <igorzi>yep
18:58:36  <ryah>yep
18:58:44  <AndreasMadsen>yep
18:59:13  <piscisaureus_>is AndreasMadsen also joining?
18:59:18  <AndreasMadsen>Yes
18:59:34  * bnoordhuistoo
19:07:08  <AndreasMadsen>Is there always a void in the beginning?
19:09:19  <piscisaureus_>AndreasMadsen: we're actually having a call
19:09:27  <piscisaureus_>we'll talk to you later
19:09:33  <piscisaureus_>in a few minutes
19:10:07  * brsonquit (Ping timeout: 244 seconds)
19:13:23  * felixgequit (Quit: felixge)
19:37:33  <ryah>https://github.com/joyent/node/issues/2288
19:39:00  <ryah>AndreasMadsen: hi
19:39:15  <AndreasMadsen>Hi
19:40:19  <ryah>AndreasMadsen: so we're really happy about your cluster patch
19:40:30  <AndreasMadsen>Thats great
19:40:31  <ryah>AndreasMadsen: my only problem is that it's a bit big
19:40:41  <AndreasMadsen>Yes i know
19:40:45  <ryah>AndreasMadsen: im also worried about adding a lot of API all at once
19:41:11  <ryah>AndreasMadsen: is there like a way this can be broken into a few peices?
19:41:13  <AndreasMadsen>We are talking about 0.7.x right?
19:41:20  <ryah>with the most minimal improtant changes first
19:41:21  <ryah>yes
19:41:55  <ryah>but even though we can change API in v0.7 we don't want to be extremely radical
19:42:17  <ryah>i'd rather minimize API changes - or at least land them in parts
19:43:15  <AndreasMadsen>Well its pretty integrated so it is hard, but i'm thinking 1: message system 2: autoFork and events, 3: signal handling, 4: zero-downtime restart
19:43:34  <ryah>where does fork(env) land in there?
19:43:37  <bnoordhuis>fun fact, libev doesn't epoll_ctl(EPOLL_CTL_DEL) when you stop the watcher, it sets a flag and handles removal right after epoll_wait()
19:43:47  <bnoordhuis>the assumption being that the watched fd has been closed anyway
19:44:23  <AndreasMadsen>ryah: it was in https://github.com/joyent/node/pull/2042
19:44:41  <AndreasMadsen>ryah: I agree it should be removed
19:44:52  <ryah>oh i see
19:45:00  <piscisaureus_>bnoordhuis: what does that mean?
19:45:08  <piscisaureus_>that it's not going to be slow?
19:45:17  <ryah>AndreasMadsen: so are your patches supposed to be ontop of #2042?
19:45:22  <bnoordhuis>piscisaureus_: less slow anyway, it's pretty clever
19:45:29  <AndreasMadsen>ryah: No
19:46:19  <ryah>AndreasMadsen: you also have a lot of lint fixing in there
19:46:28  <ryah>which i would want to break into separate commits
19:46:52  <AndreasMadsen>ryah: about that API, you should remember that the most important API change (not addition) is that cluster.fork is not a child_process.fork, you will have to do cluster.fork().process.
19:47:19  <AndreasMadsen>ryah: didn't I do that?
19:47:21  <ryah>1. lint 2. child_process silent option 3. add fork(env) 4. message system 5. autoFork and events 6. signal handling
19:48:19  <ryah>AndreasMadsen: https://github.com/joyent/node/pull/2038/files#r280922
19:48:21  <AndreasMadsen>Oh i forgot the child_process changes, this sounds fine.
19:48:47  <ryah>let's first do the 1,2,3
19:48:54  <ryah>then talk more about futher changes
19:49:18  <ryah>sorry to slow you down like this - i really want to encourage you to work on this more - but i want to land this in peices and understand the implications
19:49:36  <ryah>also - do we have a signed CLA from you?
19:49:50  <AndreasMadsen>ryah: CLA yes
19:50:25  <ryah>great
19:50:28  <AndreasMadsen>ryah: should I make another pull request with 1, then another with 2 ...
19:55:48  <AndreasMadsen>ryah: about that fork(env) should that be removed - i do think is a bit strage. If fork(env) should exist what about individual process arguments?
20:00:16  <piscisaureus_>bnoordhuis: https://github.com/joyent/libuv/blob/master/src/unix/stream.c#L407 <-- also optimization territory. You should not attemt when a previous write returned EAGAIN.
20:00:16  <AndreasMadsen>ryah: I would also like a comment about the event names and method names, should there be a 100% consistency between the worker object and the cluster object?
20:00:59  * AndreasMadsen__joined
20:01:46  <piscisaureus_>ryah: igorzi: <-- this also needs fixing. I would do it but ben and I couldn't agree on what the solution should be.
20:01:49  <piscisaureus_>https://github.com/joyent/node/issues/2229
20:02:06  <bnoordhuis>piscisaureus_: it used to...
20:02:38  <piscisaureus_>bnoordhuis: I don't think so.
20:03:44  <bnoordhuis>piscisaureus_: it still does - if < len bytes is written, the next call will result in EAGAIN so we bail out
20:03:49  <ryah>mjr_: do you have a report about the patch handling afterWrite status codes?
20:03:59  <ryah>AndreasMadsen: yes separate pull requests
20:04:52  * AndreasMadsenquit (Ping timeout: 265 seconds)
20:05:08  * sh1mmer_joined
20:06:49  <ryah>AndreasMadsen__: maybe fork() should be like child_process.fork() with args first?
20:06:52  <AndreasMadsen__>ryah: My IRC connect when down, did you get that about fork(env), and API consistency
20:06:52  <piscisaureus_>bnoordhuis: sorry, I misunderstood how libuv-unix works
20:07:01  <ryah>AndreasMadsen__: yes
20:07:11  <ryah>AndreasMadsen__: http://piscisaureus.no.de/log/latest
20:09:10  * sh1mmer_quit (Client Quit)
20:10:38  <ryah>AndreasMadsen__: do we really care about program args to workers?
20:10:40  <ryah>*shrug*
20:10:47  <ryah>i like the simplicity of fork(env)
20:12:14  <AndreasMadsen__>ryah: I don't do in .fork, but I think the .setupMaster({args: []}) should exist.
20:12:39  <ryah>AndreasMadsen__: hm
20:14:38  <AndreasMadsen__>So sometimes I wan't a http and https cluster, but really don't want to create 2 files just to change require('http') to require('https'), this is where i think that args can be used.
20:14:59  <AndreasMadsen__>I'm talking about 2 different clusters
20:15:40  * mralephjoined
20:16:48  <AndreasMadsen__>^^ wan't = want
20:19:37  * ryahtopic: http://drewww.github.com/socket.io-benchmarking/
20:47:45  <piscisaureus_>mjr_: yt?
20:47:51  <mjr_>hi
20:48:04  <piscisaureus_>mjr_: did ben's patch work for you?
20:48:14  <mjr_>We are rolling out that status checking patch right now.
20:48:27  <mjr_>Literally syncing the new version of node as we speak
20:48:52  <mjr_>Then we'll do a rolling restart across the cluster. It'll take about 30 mins to complete.
20:49:59  <piscisaureus_>mjr_: so what is the time frame until you "know"? How long does it ususally take before leaks become noticeable?
20:50:33  <mjr_>The leaks are not my primary concern. The main problem is that sometimes a process will get stuck in a tight loop and never return.
20:51:49  <mjr_>Also, it seemed to happen mostly only under peak load, which is about 5PM Pacific.
20:54:15  <piscisaureus_>for the statisticians here: Given that a bug occurs on average 3 times an hour, how much time needs to pass before you can be 95% certain that the bug has been fixed?
20:56:41  <mjr_>BTW, we have dshaw on the team now, and on his first day he's rolling out this patch to our cluster. :)
20:58:44  <piscisaureus_>cool
21:01:30  * AndreasMadsen__quit (Quit: Page closed)
21:04:37  * dshaw_joined
21:18:16  <piscisaureus_>the answer to my statistical question was 8 hrs and 59 minutes btw
21:18:50  <piscisaureus_>so if mjr_'s bugs really happened only 3 times an hour on average we have to wait 9 hours before we are 95% sure if the bug works
21:19:06  <piscisaureus_>er, if the fix works
21:19:14  <mjr_>right, OK
21:19:29  <mjr_>I think our traffic will actually be higher today, if we can get things situated first
21:20:01  <mjr_>It's really an unbelievable amount of traffic that we are getting.
21:25:40  <creationix>does uv_readlink printf stuff when you call it
21:26:00  <creationix>I'm getting "OK, success" printed to my stdout when I call it
21:26:09  <creationix>I can't find anywhere in my code that could be doing that
21:28:14  <ryah>ryan@mac1234:~/projects/libuv% grep -R "OK, success" src
21:28:14  <ryah>-1- ryan@mac1234:~/projects/libuv%
21:29:12  <piscisaureus_>ryah: it's probably fprintf(stderr, "%s: %s" :-)
21:29:32  <creationix>yeah, can't find it in libuv src either
21:29:55  <creationix>I would think it's my code or node would see the same thing too when built with latest libuv
21:29:57  <piscisaureus_>creationix: what happens if you readlink a nonexisting path :-)
21:30:08  * felixgejoined
21:30:08  * felixgequit (Changing host)
21:30:08  * felixgejoined
21:31:19  <creationix>piscisaureus_: same thing
21:31:26  <piscisaureus_>also, OK, success?
21:31:28  <creationix>strange
21:31:49  <creationix>I'll bet it's throwing an exception and my repl is just showing the error message
21:31:58  <creationix>not sure why it's OK, success for a not found path though
21:32:53  <piscisaureus_>creationix: it's a libuv bug
21:32:59  <piscisaureus_>creationix: happens for me in node too
21:33:08  <creationix>the success part?
21:33:14  <creationix>the printing part is my bug though?
21:33:17  <bnoordhuis>ryah: https://github.com/joyent/libuv/blob/b89c31b/src/unix/core.c#L456 and https://github.com/joyent/libuv/blob/b89c31b/src/unix/core.c#L469 <- why the unref and particulary the ref?
21:33:27  <piscisaureus_>> require('fs').readlinkSync('foo');
21:33:27  <piscisaureus_>Error: OK, success 'D:\nodejs\node3\deps\uv\foo
21:33:27  <piscisaureus_> at Object.readlinkSync (fs.js:422:18)
21:33:27  <piscisaureus_> at repl:1:15
21:33:27  <piscisaureus_><<cut>>
21:33:32  <bnoordhuis>ryah: https://github.com/joyent/node/blob/871194d/src/node.cc#L227 <- node unrefs it too
21:34:07  <piscisaureus_>creationix: are you on windows or unix?
21:34:08  <bnoordhuis>piscisaureus_: i'm 95% sure there's a bug report about that
21:34:16  <creationix>piscisaureus_: linux
21:34:21  <ryah>bnoordhuis: this is to match libev behavior
21:34:34  <bnoordhuis>it looks circumspect and confusing
21:34:48  <bnoordhuis>(to me at least)
21:34:56  <ryah>bnoordhuis: it's to keep the ref count of uv_idle_t at 1 instead of 2
21:35:01  <ryah>yes it's very confusing
21:35:06  <ryah>that's why we want to remove all that shit :)
21:35:11  <bnoordhuis>heh, good :)
21:35:19  <creationix>yeah ev ref counts are weird
21:35:20  <ryah>by the way
21:35:36  <ryah>can we talk about strategy for doing this ref simplification?
21:35:42  <bnoordhuis>sure, fire away
21:36:04  <ryah>so i want all of the public inteface to be in uv-common.c
21:36:14  <ryah>e.g. uv_read_start()
21:36:46  <ryah>and that thse are just very thing wrappers around calls into platform specific functions
21:37:47  <ryah>the platform specific uv_read_start() would be - say - uv__read_start()
21:38:02  <bnoordhuis>sounds good so far
21:38:21  <ryah>then these common wrapper functions would be good places for handling ref counting
21:38:26  <piscisaureus_>creationix: https://github.com/joyent/libuv/blob/master/src/unix/fs.c#L151-153
21:38:31  <piscisaureus_>creationix: we take patches :-)
21:38:36  <ryah>so i would split the ref count patches into two parts
21:38:50  <ryah>1) make public interface functions shared with wrappers
21:39:08  <ryah>2) move ref counting to shared interface functions
21:39:38  <ryah>but we should come up with a better way for naming the platform specific functions
21:39:56  <ryah>because we're already using double underscore in several places to just mean "private"
21:40:18  <bnoordhuis>uv__read_start() would be private right?
21:40:28  <ryah>yes
21:40:36  <ryah>im worried about uv_write() and uv__write()
21:40:42  <ryah>we already have both
21:40:55  <bnoordhuis>oh, like that - we should rename the unix uv__write()
21:41:21  <ryah>well or we could just come up with a better naming scheme for the platform specific interface functions
21:41:38  <ryah>uv_plat_write()
21:41:43  <bnoordhuis>yuck
21:41:45  <ryah>:)
21:41:50  <bnoordhuis>uv__internal_write()
21:41:50  <ryah>uv_p_write()
21:41:53  <piscisaureus_>creationix: hmm, it's more complicated than that.
21:42:01  <ryah>meh
21:42:01  <bnoordhuis>uv_p_write i can live with
21:42:08  <ryah>what if we use a struct
21:42:19  <ryah>each platform make a struct with a bunch of function pointers
21:42:29  <ryah>oh yeah
21:42:32  <ryah>that's what i want to do
21:42:33  <bnoordhuis>and do a pointer lookup each time? nooo
21:42:44  <ryah>i knew you would say that
21:42:48  <bnoordhuis>and you can forget about inlining that way
21:42:53  <bnoordhuis>hah, so why bring it up? :)
21:42:59  <ryah>look - for many of these functions we switch on handle->type already
21:43:19  <ryah>so what we can do is have each platform define various function for each handle->type
21:43:27  <ryah>a struct for each handle basically
21:43:45  <bnoordhuis>you're a closet c++ programmer, ryan dahl
21:43:52  <ryah>that way we could move the switch (handle->type) {} that's in uv_close into the uv-common.c
21:44:03  <ryah>im out of the closet baby
21:45:09  <ryah>i was thinking something similiar to linux's struct file_operations
21:45:56  <bnoordhuis>hrm, let me get used to the idea
21:46:02  <ryah>here's what the code in uv-common would look like:
21:46:07  <bnoordhuis>i suppose it makes sense since we have a lot of handle types now
21:47:00  * ericktquit (Quit: erickt)
21:47:19  <ryah>void uv_close(uv_handle_t* handle) { switch (handle->type) { case UV_TCP: tcp_handle_ops.close(handle); break; ... })
21:47:34  <ryah>(modulo syntax errors)
21:48:21  <ryah>case UV_TCP: tcp_handle_ops.close(handle); break; case UV_NAMED_PIPE: pipe_handle_ops.close(handle); break; ....
21:49:11  <piscisaureus_>ryah: then why don't you just make it a proper vtable
21:49:17  <piscisaureus_>ryah: instead of switch, just do
21:49:22  <bnoordhuis>still... how is that better than -> switch (handle->type) { case UV_TCP: return uv__p_tcp_close(handle); }
21:49:26  <ryah>compare these two:
21:49:30  <ryah>https://github.com/joyent/libuv/blob/f5c2a4a1ae28ab9136520a1f8f307653ca891dd9/src/win/handle.c#L83
21:49:30  <piscisaureus_>handle->ops.close(handle);
21:49:48  <ryah>https://github.com/joyent/libuv/blob/f5c2a4a1ae28ab9136520a1f8f307653ca891dd9/src/unix/core.c#L81
21:50:01  <ryah>^-- obviously we need to share this between platforms
21:50:16  <ryah>piscisaureus_: sure
21:50:30  <ryah>it's another pointer deref though
21:50:42  <ryah>but whatever
21:50:52  <bnoordhuis>double indirection makes optimizing baby jesus cry
21:51:04  <piscisaureus_>ryah: hmm, yeah a deref for a load and switch
21:51:11  <piscisaureus_>i wonder what's worse
21:52:04  <bnoordhuis>ryah: why is an ops struct better than a direct function call?
21:52:15  <bnoordhuis>i mean this -> switch (handle->type) { case UV_TCP: return uv__p_tcp_close(handle); }
21:52:18  <ryah>bnoordhuis: i feel like it organizes the handles better
21:52:24  <ryah>but yeah it doesn't matter
21:52:30  <ryah>it's something we can decide to do later
21:52:35  <piscisaureus_>I agree that thw switch solution is better btw
21:52:57  <piscisaureus_>I just had to run a compiler in my head
21:53:50  <piscisaureus_>the nice thing about the double indirection is that people can define their own handle types
21:53:52  <piscisaureus_>and plug them in
21:54:19  <bnoordhuis>who is going to do that and why?
21:55:18  <piscisaureus_>good question my dear
21:56:18  <bnoordhuis>another question, how are we going to deal with libev reffing? just deref every handle and handle it in libuv?
21:56:36  <piscisaureus_>bnoordhuis: it's not that simple
21:56:51  <piscisaureus_>bnoordhuis: i guess you would call uv_sweep or something
21:57:05  <bnoordhuis>uv_sweep?
21:57:13  <piscisaureus_>er, ev_sweep
21:57:22  <piscisaureus_>but that's probably not the correct name
21:57:43  <bnoordhuis>what does it do?
21:57:59  <piscisaureus_>sorry I was wrong
21:58:50  <piscisaureus_>bnoordhuis: you would do:
21:58:50  <piscisaureus_>do {
21:58:50  <piscisaureus_> ev_run(EVRUN_ONCE)
21:58:50  <piscisaureus_>} while (loop->refs > 0);
21:59:00  <ryah>^-- yes
22:02:02  * benviequit
22:03:32  <bnoordhuis>piscisaureus_: i think that's what i mean with 'handle it in libuv'
22:03:43  * ericktjoined
22:05:04  <piscisaureus_>bnoordhuis: I was confused by the "deref every handle" statement
22:05:26  <piscisaureus_>bnoordhuis: if you do this the libev reference count will be completely ignored
22:06:08  <ryah>bnoordhuis: so what do you think about putting all the public interface functions into src/public.c ?
22:06:22  <ryah>bnoordhuis: src/api.c ?
22:06:23  * benviejoined
22:06:42  <ryah>like V8
22:06:47  <bnoordhuis>ryah: that second one then, or src/uv.c - one less character to type
22:07:04  <ryah>src/api.c then - i don't like src/uv.c
22:07:19  <ryah>okay - and how are we going to name the second layer functions
22:07:21  <ryah>platform speicfic
22:07:36  <ryah>i think the easiest thing to do first is to just make wrappers for everything
22:08:05  <bnoordhuis>well.. uv__write() for uv_write() seems most straight-forward, just have to deal with the name clashes
22:08:25  <ryah>no that's going to be too confusing
22:09:15  <ryah>uv_write (src/api.c) calls uv_p_write() (src/unix/stream.c) which calls uv__write() (src/unix/stream.c)
22:09:24  <ryah>or
22:09:38  <ryah>uv_write (src/api.c) calls uv_p_write() (src/win/stream.c)
22:10:49  <bnoordhuis>the second one
22:10:59  <bnoordhuis>if it means one less function call
22:11:21  <ryah>that wasn't a choice - just the situation on both platforms
22:11:59  <bnoordhuis>oh, right
22:12:08  <bnoordhuis>what's confusing about uv_write vs uv__write btw?
22:12:33  <bnoordhuis>piscisaureus_: what version of msvs 2010 should i download? lots of options...
22:14:31  <bnoordhuis>premium or professional?
22:14:37  * bnoordhuisflips a coin
22:14:47  <piscisaureus_>bnoordhuis: ultimate
22:15:01  <piscisaureus_>if you think having the most expensive version will make you happy
22:15:16  <bnoordhuis>always
22:15:19  <piscisaureus_>bnoordhuis: you got your msdn already?
22:15:22  * ericktquit (Quit: erickt)
22:15:29  * piscisaureus_remembers waiting for 2 monts
22:16:21  <piscisaureus_>bnoordhuis: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/product-comparison
22:17:24  <bnoordhuis>piscisaureus_: yeah, got it today
22:17:35  <piscisaureus_>bnoordhuis: not that it matters for you. The only really nice feature that comes with ultimate is intellitrace, but it works only for managed code.
22:20:28  * sh1mmer_joined
22:21:40  * sh1mmer_quit (Client Quit)
22:33:36  * sh1mmerjoined
22:41:55  * felixgequit (Quit: felixge)
22:42:09  <piscisaureus_>are these designs secret?
22:42:11  * sh1mmerquit (Read error: No route to host)
22:48:14  <DrPizza>ultimate also has some nice piece of intrastructure that plugins can depend on
22:48:18  <DrPizza>which is actually very annoying
22:49:28  <DrPizza>Things like debugger canvas (http://msdn.microsoft.com/en-us/devlabs/hh227299) require ultimate not because they do anything super-advanced or high-end, but because they depend on graphing and similar features that are only found in Ultimate
23:01:39  <ryah>piscisaureus_: the new node website? yes
23:10:36  <CIA-111>node: Ryan Dahl master * rcced79d / (4 files): Move a few more global vars into struct - http://git.io/q7xuhw
23:10:59  <CIA-111>node: Ryan Dahl master * r3d3f29c / wscript : Remove wscript - http://git.io/AkUeEg
23:11:03  <ryah>i feel like the makefiles that GYP generates are much better than running waf build
23:20:25  <igorzi>ryah piscisaureus_: https://gist.github.com/1449202
23:20:36  <igorzi>msi upgrade --^
23:20:55  * ericktjoined
23:21:44  <ryah>igorzi: great
23:21:53  <igorzi>ryah: ok, i'll land
23:22:00  <ryah>igorzi: k
23:22:32  <CIA-111>node: Igor Zinkovsky v0.6 * rb24cdb3 / (3 files in 2 dirs):
23:22:32  <CIA-111>node: Enable upgrades in MSI.
23:22:32  <CIA-111>node: Fixes #2228. - http://git.io/SX9PwA
23:22:59  <piscisaureus_>igorzi: why do you regenerate the product id on every build?
23:23:15  <piscisaureus_>(just curious)
23:23:28  <igorzi>piscisaureus_: it's required for major upgrades
23:23:45  <igorzi>piscisaureus_: major upgrade -> new product id
23:24:01  <piscisaureus_>igorzi: but now it gets regenerated every time...
23:24:19  <igorzi>piscisaureus_: yeah, that's fine.. why is that an issue?
23:24:39  <piscisaureus_>igorzi: because now all upgrades are major upgrades
23:24:44  <piscisaureus_>oh wait
23:24:47  <igorzi>piscisaureus_: yes, that's the point
23:24:47  <piscisaureus_>we want that :-)
23:24:52  <igorzi>:)
23:25:00  <ryah>rebasing isolates branch is painful
23:25:32  <piscisaureus_>igorzi: but will windows installer still understand that it needs to remove the old version?
23:25:41  * ryahboots windows to try the new msi hotness
23:26:16  <igorzi>piscisaureus_: yes, that's what upgradecode is for (which stays the same between installs)
23:27:42  <igorzi>piscisaureus_: we could include the product id into the tree, but then we'd have to remember to manually change it for every release, and that would be bad
23:28:00  * travis-cijoined
23:28:00  <travis-ci>[travis-ci] joyent/node#18 (master - cced79d : Ryan Dahl): The build passed.
23:28:00  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/e10fd32...cced79d
23:28:00  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/387877
23:28:00  * travis-cipart
23:28:38  * mmaleckisuggests putting libuv on travis as well
23:29:10  * travis-cijoined
23:29:11  <travis-ci>[travis-ci] joyent/node#19 (master - 3d3f29c : Ryan Dahl): The build passed.
23:29:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/cced79d...3d3f29c
23:29:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/387884
23:29:11  * travis-cipart
23:31:57  <ryah>mmalecki: yes please
23:32:26  <piscisaureus_>igorzi: no this is fine
23:32:43  <mmalecki>ryah: ok! :) will pull request today.
23:35:09  * travis-cijoined
23:35:09  <travis-ci>[travis-ci] joyent/node#20 (v0.6 - b24cdb3 : Igor Zinkovsky): The build was fixed.
23:35:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/871194d...b24cdb3
23:35:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/387972
23:35:09  * travis-cipart
23:37:47  <ryah>bnoordhuis: im going to land the isolates rebase
23:37:50  <ryah>bnoordhuis: that okay?
23:38:11  <bnoordhuis>ryah: sure
23:38:41  <CIA-111>node: Ben Noordhuis isolates * r76adeab / (src/node.cc src/node_isolate.cc): isolates: add _newIsolate() and _joinIsolate() to process object (+5 more commits...) - http://git.io/I-qjew
23:39:19  <ryah>now to integrate the struct globals into the isolate
23:40:49  * piscisaureus_quit (Ping timeout: 240 seconds)
23:40:53  * dshaw_quit (Quit: Leaving.)
23:45:26  * dshaw_joined
23:45:50  <ryah>https://github.com/joyent/node/blob/3d3f29cf0626bcb1688da4fc0621b659a66fe4d9/src/node_vars.h#L21-193
23:45:55  <ryah>^-- lots of globals
23:46:37  <ryah>we should probably just initialize all these symbols at the beginning of the program
23:46:44  <ryah>simpler to maintain and probably faster
23:46:53  <ryah>or slower
23:47:08  <bnoordhuis>at least simpler
23:47:35  <bnoordhuis>ryah: // node_crypto.cc
23:47:35  <bnoordhuis> uv_rwlock_t* locks;
23:47:43  <bnoordhuis>^ you can't move those
23:47:49  <ryah>oh sorry
23:48:40  * dshaw_quit (Client Quit)
23:49:10  * dshaw_joined
23:51:51  * travis-cijoined
23:51:52  <travis-ci>[travis-ci] joyent/node#21 (isolates - 76adeab : Ben Noordhuis): The build failed.
23:51:52  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/6c41c5d...76adeab
23:51:52  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/387995
23:51:52  * travis-cipart
23:58:53  <CIA-111>node: Ryan Dahl master * rc5e51ce / (src/node_crypto.cc src/node_vars.h): Move lock back to node_crypto.cc - http://git.io/V1oFcA