00:00:03  <bnoordhuis>who're the people that you're talking to?
00:00:14  <mikeal>there are several groups
00:00:22  <mikeal>but i'm pretty sure Nuno will be the one who comes through
00:00:37  <isaacs>bnoordhuis, TooTallNate: k, whatevs. i'm ok with it.
00:00:49  <isaacs>(re listeners() returning the same array all the time)
00:01:05  <bnoordhuis>TooTallNate: lgtm if it works as advertised
00:01:06  <TooTallNate>isaacs: plus, isn't deleting a prop slower than not deleting it?
00:01:29  <TooTallNate>so this is actually an optimization :D
00:02:07  <CIA-99>node: Nathan Rajlich master * r928ea56 / (2 files in 2 dirs): events: don't delete the listeners array in removeListener() - http://git.io/e0O4Ig
00:02:22  <bnoordhuis>mikeal: okay, cool. who should we (we as in cloud9) contact if we want to help out?
00:04:30  <mikeal>help out how?
00:05:01  <mikeal>if you want to sponsor we'll send you something as soon as dates are locked down
00:07:57  <CIA-99>node: Charlie McConnell master * rc7b8073 / (4 files in 2 dirs):
00:07:57  <CIA-99>node: child_process: Separate 'close' event from 'exit'
00:07:57  <CIA-99>node: Currently, a child process does not emit the 'exit' event until 'close' events
00:07:57  <CIA-99>node: have been received on all three of the child's stdio streams. This change makes
00:07:57  <CIA-99>node: the child object emit 'exit' when the child exits, and a new 'close' event when
00:07:58  <CIA-99>node: all stdio streams are closed. - http://git.io/cK0OKg
00:10:06  * toothrquit (Ping timeout: 240 seconds)
00:10:35  <mmalecki>mikeal: oh, euro nodeconf, when?
00:10:41  <isaacs>AvianFlu: thanks!
00:10:47  <mmalecki>AvianFlu: ++
00:10:49  <kohai>AvianFlu has 98 internet points
00:10:50  <isaacs>bnoordhuis: https://github.com/isaacs/node/commit/069ed985f5258647ac0c74c6a3dec8e953646f46 review plz?
00:10:52  <isaacs>AvianFlu: ^
00:11:31  <AvianFlu>oh sweet!
00:12:09  <AvianFlu>looks good to me
00:16:08  * toothrjoined
00:16:50  * travis-cijoined
00:16:50  <travis-ci>[travis-ci] joyent/node#598 (master - 928ea56 : Nathan Rajlich): The build is still failing.
00:16:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/761a82b...928ea56
00:16:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/876518
00:16:50  * travis-cipart
00:17:11  <TooTallNate>one last review? https://github.com/TooTallNate/node/compare/process.config2
00:17:17  <TooTallNate>isaacs: got the test case in there ^
00:19:34  <mikeal>mmalecki: nothing solid yet
00:19:50  <isaacs>TooTallNate: lgtm!
00:19:58  <mikeal>although, i think the guys who did NodeCamp.eu last year are doing a camp in the woods
00:20:05  <TooTallNate>isaacs: thanks, landing
00:20:07  <mmalecki>mikeal: great idea anyway :)
00:20:09  <isaacs>TooTallNate: this needs the vcbuild.bat change as well?
00:20:11  <isaacs>or is that already in?
00:20:11  <mikeal>which is awesome and i wish the timing would work out for me to go
00:20:16  <TooTallNate>isaacs: yes, that's already merged
00:20:20  <isaacs>great.
00:20:25  <mikeal>mmalecki: i do a camp in the woods every septermber, NodeConf SummerCamp :)
00:20:39  <mmalecki>mikeal: I know and I'll try to be there!
00:20:44  <TooTallNate>mikeal: i'll actually come this time!
00:20:50  <mikeal>word!
00:20:52  <isaacs>summercamp is fantastic
00:20:52  <AvianFlu>node conf summer camp was the shit.
00:20:55  <TooTallNate>(instead of paying and not showing up) :p
00:21:11  <mikeal>still better than showing up and not paying ;)
00:22:40  * travis-cijoined
00:22:40  <travis-ci>[travis-ci] joyent/node#599 (master - c7b8073 : Charlie McConnell): The build is still failing.
00:22:40  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/928ea56...c7b8073
00:22:40  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/876540
00:22:40  * travis-cipart
00:23:16  <CIA-99>node: Nathan Rajlich master * rbea2e15 / tools/js2c.py :
00:23:16  <CIA-99>node: js2c: fix to support files other than ones ending with 2 char extensions
00:23:16  <CIA-99>node: Previously this was basically hard-coded for *.js files, but now we
00:23:16  <CIA-99>node: need to include the 'config.gypi' file in there as well. - http://git.io/erTIZg
00:23:18  <CIA-99>node: Nathan Rajlich master * r95fd517 / node.gyp : node.gyp: include the config.gypi file in the js2c inputs list - http://git.io/dAGiHg
00:23:19  <CIA-99>node: Nathan Rajlich master * r11d8823 / (3 files in 3 dirs):
00:23:19  <CIA-99>node: process: add `process.config`
00:23:19  <CIA-99>node: This is the JS representation of the `config.gypi` file that was used when
00:23:19  <CIA-99>node: compiling node. With this information, you can tell whether the current node
00:23:19  <CIA-99>node: binary has shared or static dependencies, or any other configuration options
00:23:20  <CIA-99>node: that may have been used. - http://git.io/5IICCg
00:23:20  <CIA-99>node: Nathan Rajlich master * r7cb0f5f / (Makefile tools/installer.js):
00:23:21  <CIA-99>node: install: update install.js to use `process.config`
00:23:21  <CIA-99>node: Now that the node_prefix is available from within node, we can use it :) - http://git.io/yVFMYA
00:24:18  <CIA-99>node: isaacs master * r0fb4fb4 / doc/api/child_process.markdown : Document ChildProcess exit/close event difference - http://git.io/P8MPPw
00:31:05  <bnoordhuis>mikeal: help out monetary probably
00:31:08  <bnoordhuis>and with swag :)
00:31:30  <mikeal>cool
00:31:42  <mikeal>Cloud9 is in my list of sponsors from previous evenets
00:31:54  <mikeal>so once we get something solid an email will go out
00:32:09  <mikeal>i'm already talking to you guys about NodeConf, NodeConf SummerCamp and TacoConf in another thread
00:37:51  * travis-cijoined
00:37:51  <travis-ci>[travis-ci] joyent/node#600 (master - 7cb0f5f : Nathan Rajlich): The build is still failing.
00:37:51  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c7b8073...7cb0f5f
00:37:51  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/876577
00:37:51  * travis-cipart
00:39:25  * orlandovftwquit (Ping timeout: 252 seconds)
00:53:56  * isaacsquit (Remote host closed the connection)
01:01:36  * piscisaureus_joined
01:08:12  <piscisaureus_>hey bnoordhuis
01:08:16  <piscisaureus_>what are you working on
01:08:34  <bnoordhuis>my abs
01:09:14  <bnoordhuis>piscisaureus_: also, can you review this? https://github.com/bnoordhuis/libuv/compare/joyent:master...master
01:09:48  <piscisaureus_>bnoordhuis: right
01:10:03  <piscisaureus_>bnoordhuis: I am going away for a few days but I was just wondering if you were doing anything interesting
01:10:15  <bnoordhuis>oh, i've got enough lined up
01:10:16  <piscisaureus_>bnoordhuis: btw - I wrote down the libuv refcount refactor
01:10:21  <piscisaureus_>spec
01:10:22  <bnoordhuis>yep, i noticed
01:10:50  <piscisaureus_>bnoordhuis: the ares tree thing is nice
01:11:01  <piscisaureus_>bnoordhuis: but were we not going to externalize cares?
01:11:21  <bnoordhuis>piscisaureus_: were we?
01:11:45  <piscisaureus_>bnoordhuis: yeah, it was more of a long term plan though
01:11:50  <piscisaureus_>after uv_external_fd
01:11:53  <bnoordhuis>oh right
01:12:03  <bnoordhuis>well, in the mean time we can have nice rbtrees
01:13:45  <piscisaureus_>bnoordhuis: lgtm by the way
01:13:56  <bnoordhuis>piscisaureus_: thanks, merging
01:14:12  <CIA-99>libuv: Ben Noordhuis master * r6031156 / test/runner.c :
01:14:12  <CIA-99>libuv: test: silence compiler warning
01:14:12  <CIA-99>libuv: main_proc is never read without having been initialized first but gcc 4.4.x
01:14:12  <CIA-99>libuv: fails to infer that. - http://git.io/Waz6XQ
01:14:13  <CIA-99>libuv: Ben Noordhuis master * rc21184c / test/benchmark-ares.c : test: make variables in benchmark-ares static - http://git.io/PlDw7w
01:14:13  <CIA-99>libuv: Ben Noordhuis master * rdfda500 / (7 files in 4 dirs):
01:14:13  <CIA-99>libuv: unix, win: store ares handles in a binary tree
01:14:13  <CIA-99>libuv: Store the uv_ares_task_t handles in a red-black tree, not a linked list.
01:14:14  <CIA-99>libuv: Fixes #72. - http://git.io/Yy0dQw
01:14:48  <bnoordhuis>piscisaureus_: $ git shortlog -ns
01:14:48  <bnoordhuis> 337 Ryan Dahl
01:14:48  <bnoordhuis> 333 Ben Noordhuis
01:14:48  <bnoordhuis> 333 Bert Belder
01:14:49  <bnoordhuis>:)
01:14:52  * travis-cijoined
01:14:52  <travis-ci>[travis-ci] joyent/libuv#136 (master - dfda500 : Ben Noordhuis): The build is still failing.
01:14:52  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7a2bd05...dfda500
01:14:52  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876721
01:14:52  * travis-cipart
01:15:05  <piscisaureus_>lol
01:15:13  <piscisaureus_>let's do 4 commits each
01:15:16  <piscisaureus_>shit I have no time
01:15:21  <piscisaureus_>you are going to pass me this weekend
01:15:22  <TooTallNate>bnoordhuis: haha, nice race going there
01:22:34  <piscisaureus_>bnoordhuis: btw - your rbtree commit does not compile
01:23:17  <bnoordhuis>piscisaureus_: eh?
01:23:29  <piscisaureus_>bnoordhuis: what does RB_GENERATE_INTERNAL do?
01:23:55  <bnoordhuis>it generates create/insert/delete/find functions
01:24:14  <piscisaureus_>bnoordhuis: dude
01:24:27  <piscisaureus_>__atribute(( in uv-common.h ??
01:24:49  * AvianFluquit (Quit: Leaving)
01:25:03  <piscisaureus_>bnoordhuis: RB_GENERATE_INTERNAL is, as the macro name quite clearly suggests...
01:25:07  <piscisaureus_>internal
01:25:52  <bnoordhuis>hah, i use it in inotify.c too
01:26:14  <bnoordhuis>but i expect that you want RB_GENERATE_STATIC?
01:26:42  <piscisaureus_>yeah. I have a commit now
01:26:47  <piscisaureus_>plus another one :-p
01:27:31  <bnoordhuis>well, the thing is
01:27:43  <bnoordhuis>RB_GENERATE_STATIC generates a lot of 'unused function' warnings
01:28:39  <bnoordhuis>piscisaureus_: to wit (and to spam): ../src/uv-common.c:190: warning: ‘uv__ares_tasks_RB_NFIND’ defined but not used
01:28:40  <bnoordhuis>../src/uv-common.c:190: warning: ‘uv__ares_tasks_RB_NEXT’ defined but not used
01:28:40  <bnoordhuis>../src/uv-common.c:190: warning: ‘uv__ares_tasks_RB_PREV’ defined but not used
01:28:40  <bnoordhuis>../src/uv-common.c:190: warning: ‘uv__ares_tasks_RB_MINMAX’ defined but not used
01:28:40  <bnoordhuis>../src/unix/linux/inotify.c:135: warning: ‘uv__inotify_watchers_RB_NFIND’ defined but not used
01:28:41  <bnoordhuis>../src/unix/linux/inotify.c:135: warning: ‘uv__inotify_watchers_RB_NEXT’ defined but not used
01:28:43  <bnoordhuis>../src/unix/linux/inotify.c:135: warning: ‘uv__inotify_watchers_RB_PREV’ defined but not used
01:28:45  <bnoordhuis>../src/unix/linux/inotify.c:135: warning: ‘uv__inotify_watchers_RB_MINMAX’ defined but not used
01:29:09  <CIA-99>libuv: Bert Belder reviewme * rb2f478e / src/uv-common.c :
01:29:09  <CIA-99>libuv: Use UV_GENERATE_STATIC instead of UV_GENERATE_INTERNAL
01:29:09  <CIA-99>libuv: Fixes the Windows build. - http://git.io/RcA4cQ
01:29:09  <CIA-99>libuv: Bert Belder reviewme * r91fa014 / (include/uv.h src/unix/error.c src/win/error.c):
01:29:09  <CIA-99>libuv: Add UV_ENOSPC and mappings to it
01:29:09  <CIA-99>libuv: Closes GH-337 - http://git.io/nFvQBA
01:29:18  <piscisaureus_>bnoordhuis: --^
01:29:20  <kohai>bnoordhuis has 11 beers
01:29:28  <piscisaureus_>bnoordhuis: can you review?
01:29:44  <bnoordhuis>piscisaureus_: lemme guess, same as https://github.com/bnoordhuis/libuv/commit/master ?
01:29:48  <piscisaureus_>bnoordhuis: on windows the macro adds __UNUSED
01:30:28  <piscisaureus_>bnoordhuis: right
01:30:43  <bnoordhuis>let me see if i can fix those warnings in tree.h
01:30:45  <piscisaureus_>bnoordhuis: ok, go ahead and land bnoordhuis/master
01:30:55  <piscisaureus_>or - ywah
01:31:02  <bnoordhuis>and you can land 91fa014 :)
01:31:08  * travis-cijoined
01:31:08  <travis-ci>[travis-ci] joyent/libuv#137 (reviewme - 91fa014 : Bert Belder): The build is still failing.
01:31:08  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b2f478e^...91fa014
01:31:08  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876749
01:31:08  * travis-cipart
01:31:54  <CIA-99>libuv: Bert Belder master * raff94a0 / (include/uv.h src/unix/error.c src/win/error.c):
01:31:54  <CIA-99>libuv: Add UV_ENOSPC and mappings to it
01:31:54  <CIA-99>libuv: Closes GH-337 - http://git.io/nGc-0g
01:32:28  <bnoordhuis>piscisaureus_: so where is __UNUSED added then? i only see __unused and that's defined at the top of tree.h as a blank macro
01:32:32  * travis-cijoined
01:32:32  <travis-ci>[travis-ci] joyent/libuv#138 (master - aff94a0 : Bert Belder): The build is still failing.
01:32:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/dfda500...aff94a0
01:32:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876763
01:32:32  * travis-cipart
01:32:48  <CIA-99>libuv: Bert Belder v0.6 * r163d8de / (include/uv.h src/unix/error.c src/win/error.c):
01:32:48  <CIA-99>libuv: Add UV_ENOSPC and mappings to it
01:32:48  <CIA-99>libuv: Closes GH-337 - http://git.io/Hkxhuw
01:32:54  * mikealquit (Quit: Leaving.)
01:32:58  * isaacsjoined
01:33:00  <piscisaureus_>bnoordhuis: yes that''s what I meant but I accidentally hit capslock
01:33:31  <bnoordhuis>piscisaureus_: but `#define __unused` is all it is
01:33:45  <bnoordhuis>how does that work?
01:34:33  * travis-cijoined
01:34:33  <travis-ci>[travis-ci] joyent/libuv#139 (v0.6 - 163d8de : Bert Belder): The build is still failing.
01:34:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/66a959c...163d8de
01:34:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876771
01:34:33  * travis-cipart
01:34:44  <bnoordhuis>oh, i think i've nailed it
01:36:09  <CIA-99>libuv: Ben Noordhuis master * r87151c8 / (src/unix/linux/inotify.c src/uv-common.c): Use RB_GENERATE_STATIC, not RB_GENERATE_INTERNAL. - http://git.io/frC-jw
01:36:10  <CIA-99>libuv: Ben Noordhuis master * r681aa83 / include/uv-private/tree.h : Mark rbtree functions with __attribute__((unused)). - http://git.io/ZkzXJA
01:38:06  * travis-cijoined
01:38:07  <travis-ci>[travis-ci] joyent/libuv#140 (master - 681aa83 : Ben Noordhuis): The build is still failing.
01:38:07  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/aff94a0...681aa83
01:38:07  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876806
01:38:07  * travis-cipart
01:40:09  <piscisaureus_>^-- cheater
01:40:17  <piscisaureus_>2 commits to fix a fuckup
01:40:19  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
01:40:48  <CIA-99>libuv: Bert Belder v0.6 * r4ae316b / src/win/winapi.h : Windows: fix compiler warnings - http://git.io/jfwKUw
01:41:16  <bnoordhuis>you just had to go and do it, didn't you? :)
01:41:23  <bnoordhuis>two can play that game!
01:42:15  <piscisaureus_>it's nice tho
01:42:22  <piscisaureus_>down to 49 issues
01:42:29  * travis-cijoined
01:42:29  <travis-ci>[travis-ci] joyent/libuv#141 (v0.6 - 4ae316b : Bert Belder): The build is still failing.
01:42:29  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/163d8de...4ae316b
01:42:29  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876839
01:42:29  * travis-cipart
01:45:33  * abraxasjoined
01:48:15  <CIA-99>libuv: Ben Noordhuis master * r379ca42 / (5 files):
01:48:15  <CIA-99>libuv: test: fix compiler warnings
01:48:15  <CIA-99>libuv: * remove unused variables and functions
01:48:15  <CIA-99>libuv: * replace %llu with %zu when printing size_t variables - http://git.io/lmXPJg
01:48:33  <bnoordhuis>+1 commit
01:50:08  * travis-cijoined
01:50:09  <travis-ci>[travis-ci] joyent/libuv#142 (master - 379ca42 : Ben Noordhuis): The build is still failing.
01:50:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/681aa83...379ca42
01:50:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/876855
01:50:09  * travis-cipart
01:50:26  <piscisaureus_>337 Ryan Dahl
01:50:26  <piscisaureus_> 335 Bert Belder
01:50:26  <piscisaureus_> 333 Ben Noordhuis
01:50:30  <piscisaureus_>is what my git says
01:51:59  <bnoordhuis>$ git shortlog -ns | head -n3
01:51:59  <bnoordhuis> 337 Ryan Dahl
01:51:59  <bnoordhuis> 336 Ben Noordhuis
01:51:59  <bnoordhuis> 334 Bert Belder
01:52:41  <piscisaureus_>aah shit
01:52:43  <piscisaureus_>anyway
01:52:50  <piscisaureus_>Imma quit
01:52:58  <piscisaureus_>no low hanging fruit in the issues list no more
01:53:05  <bnoordhuis>have fun in austria, bertje
01:53:13  <piscisaureus_>maybe the EAI patch
01:53:15  <piscisaureus_>yeah
01:53:20  <piscisaureus_>why u not coming man
01:53:32  <bnoordhuis>have to take care of the family
01:53:48  <piscisaureus_>caretaker
01:54:01  <piscisaureus_>goodbye, I'll be back tuesday
01:54:09  <piscisaureus_>so its gonna be a long weekend for you ben
01:54:23  <piscisaureus_>unless fire breaks out
01:54:24  <bnoordhuis>and a good opportunity to score some more commits
01:54:38  <piscisaureus_>you'll be the only one available to fix c9.io
01:54:40  <piscisaureus_>oh with tim
01:54:42  <piscisaureus_>good luck
01:54:49  <bnoordhuis>just press the on/off button, right?
01:55:07  <piscisaureus_>go to c9.io/__/reset.aspx
01:55:18  <bnoordhuis>no doubt :)
01:56:58  <piscisaureus_>later
01:58:27  <bnoordhuis>later, bertje
02:06:02  * piscisaureus_quit (Ping timeout: 260 seconds)
02:09:54  * brsonquit (Ping timeout: 248 seconds)
02:12:43  * orlandovftwjoined
02:38:12  * AvianFlujoined
02:52:01  * orlandovftwquit (Ping timeout: 248 seconds)
03:08:47  * elijah-mbpjoined
03:13:23  * elijah-mbpquit (Ping timeout: 260 seconds)
03:16:07  * TooTallNatejoined
03:17:29  * isaacsquit (Remote host closed the connection)
03:38:39  * philipsquit (Excess Flood)
03:39:25  * philipsjoined
03:42:36  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
04:09:02  * bnoordhuisquit (Ping timeout: 252 seconds)
04:44:31  * orlandovftwjoined
04:45:59  * orlandovftwquit (Client Quit)
04:46:16  * orlandovftwjoined
04:49:00  * orlandovftwquit (Client Quit)
04:49:15  * orlandovftwjoined
05:04:30  * mikealjoined
05:24:37  * mjr_joined
06:35:45  * mmaleckichanged nick to mmalecki[zzz]
06:46:30  * AvianFluchanged nick to AvianusAsleepus
07:06:25  * paddybyersquit (Quit: paddybyers)
07:13:44  * paddybyersjoined
07:56:57  * stephankquit (Quit: *Poof!*)
07:57:08  * paddybyersquit (Quit: paddybyers)
08:07:54  <mjr_>Hey guys, after our recent move to Joyent, we are getting a lot of these:
08:07:55  <mjr_>https://gist.github.com/2049062
08:10:15  * mmalecki[zzz]changed nick to mmalecki
08:25:41  * paddybyersjoined
08:30:43  * paddybyersquit (Quit: paddybyers)
08:50:15  * mmaleckichanged nick to mmalecki[away]
08:58:09  * orlandovftwquit (Ping timeout: 265 seconds)
09:12:51  * travis-cijoined
09:12:51  <travis-ci>[travis-ci] joyent/node#601 (master - 0fb4fb4 : isaacs): The build is still failing.
09:12:51  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/7cb0f5f...0fb4fb4
09:12:51  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/878369
09:12:51  * travis-cipart
09:25:24  * paddybyersjoined
09:42:30  * dshaw_quit (Ping timeout: 244 seconds)
09:42:44  * rendarjoined
09:43:26  * rendarquit (Client Quit)
09:57:17  * rendarjoined
10:14:09  * mmalecki[away]changed nick to mmalecki
10:46:49  * mmaleckichanged nick to mmalecki[away]
11:07:24  * abraxasquit (Remote host closed the connection)
11:07:52  * mikealquit (Ping timeout: 246 seconds)
11:07:58  * abraxasjoined
11:12:31  * abraxasquit (Ping timeout: 252 seconds)
11:26:58  * wankdankerjoined
12:02:28  * piscisaureus_joined
12:22:37  * creationixquit (Ping timeout: 260 seconds)
12:25:36  * creationixjoined
13:49:11  * philipsquit (Excess Flood)
13:51:29  * philipsjoined
13:57:32  * mmalecki[away]changed nick to mmalecki
14:04:48  * bnoordhuisjoined
14:32:19  * isaacsjoined
14:40:54  * pfox___joined
14:52:44  <CIA-99>node: Rod Vagg master * r6628a3b / doc/api/fs.markdown : doc: fix # links from (and within) api/fs - http://git.io/bF-NpA
14:53:13  <CIA-99>node: Rod Vagg v0.6 * r90b785c / doc/api/fs.markdown : doc: fix # links from (and within) api/fs - http://git.io/SWLC2g
14:57:18  * AvianusAsleepuschanged nick to AvianFlu
15:01:39  * travis-cijoined
15:01:39  <travis-ci>[travis-ci] joyent/node#603 (v0.6 - 90b785c : Rod Vagg): The build was fixed.
15:01:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b9bd2d3...90b785c
15:01:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/880462
15:01:39  * travis-cipart
15:02:53  <isaacs>merging v0.6 into master. please don't land anything for a few minutes.
15:02:55  <CIA-99>node: Shigeki Ohtsu master * r534264d / doc/api/net.markdown : doc: Add condition to emit close event of net.Server - http://git.io/0f5Daw
15:03:05  <isaacs>after that :)
15:03:28  <isaacs>bnoordhuis: ^
15:03:42  <bnoordhuis>isaacs: noted
15:04:45  <isaacs>it's a bit late since v0.6 is probably done with, but i really gotta get the version numbers out of being hard-coded in the dos.
15:04:47  <isaacs>*docs
15:04:58  <isaacs>makes merge commits even more tedious
15:07:59  <CIA-99>node: isaacs master * rec735cb / (124 files in 22 dirs): (log message trimmed)
15:07:59  <CIA-99>node: Merge remote-tracking branch 'ry/v0.6' into merge-v0.6
15:07:59  <CIA-99>node: Conflicts:
15:07:59  <CIA-99>node: ChangeLog
15:07:59  <CIA-99>node: deps/npm/AUTHORS
15:07:59  <CIA-99>node: deps/npm/html/api/bin.html
15:07:59  <CIA-99>node: deps/npm/html/api/bugs.html
15:08:09  <isaacs>bnoordhuis: done. thanks :)
15:17:54  * travis-cijoined
15:17:54  <travis-ci>[travis-ci] joyent/node#604 (master - 534264d : Shigeki Ohtsu): The build is still failing.
15:17:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/6628a3b...534264d
15:17:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/880553
15:17:54  * travis-cipart
15:33:38  * piscisaureus_quit (Ping timeout: 276 seconds)
15:45:22  <isaacs>review, please? 46376888cd2afb5d34bfdb08ba7f9d1b4c6b5d4a
15:45:25  <isaacs>er, https://github.com/isaacs/node/commit/46376888cd2afb5d34bfdb08ba7f9d1b4c6b5d4a
15:49:32  <bnoordhuis>isaacs: lgtm
15:49:48  <isaacs>thanks
15:49:53  <CIA-99>node: isaacs master * r4637688 / (6 files in 5 dirs): Remove hard-coded version number from docs - http://git.io/3fLaSg
15:49:53  <CIA-99>node: isaacs master * r76a771b / (5 files in 4 dirs): doc: Remove extraneous index.html's from hyperlinks - http://git.io/yy5jIg
15:51:14  * pieternjoined
16:05:01  * mikealjoined
16:06:44  * mikealquit (Read error: Connection reset by peer)
16:06:48  * mikealjoined
16:13:41  * mikealquit (Quit: Leaving.)
16:15:46  * piscisaureus_joined
16:19:28  <piscisaureus_>mjr_: ECONNABORTED means that the local end dropped the connection. If it isn't your kernel that drops connections (e.g. due to resource constraints) you should probably treat is as ECONNRESET.
16:19:56  <piscisaureus_>mjr_: some unixes tend to report ECONNRESET instead of ECONNABORTED anyway
16:25:29  * igorziquit (Ping timeout: 245 seconds)
16:29:46  * dapquit (Quit: Leaving.)
16:30:40  * orlandovftwjoined
16:32:15  * piscisaureus__joined
16:35:49  * piscisaureus_quit (Ping timeout: 246 seconds)
16:37:11  * piscisaureus__quit (Ping timeout: 264 seconds)
16:51:05  * sh1mmerquit (Quit: sh1mmer)
16:52:49  * elijah-mbpjoined
16:58:51  * hij1nxjoined
17:12:48  * igorzijoined
17:15:17  * k-sjoined
17:15:32  <k-s>hi guys
17:15:59  <k-s>I'm from EFL (Enlightenment, #edevelop) project and would like to have libuv to integrate well with our main loop: Ecore
17:16:22  <k-s>ecore, for what is the scope now, is similar to GMainLoop or any other main loop out there: timers, idlers, fd handler...
17:16:39  <k-s>what do you think is the best way to get it integrated
17:16:58  <k-s>so we don't keep a fork of libuv or node.js (our target is to use node.js)
17:17:18  <coderarity>k-s: does Node.js really fit? I mean, a lot of it is about the asynchronous event loop
17:17:25  <k-s>sure it does!
17:17:30  <k-s>efl is mainly about gui development
17:17:38  <k-s>and async event loop is at its core
17:17:45  <k-s>that's why everything depends on ecore
17:18:19  <k-s>we were building our own stuff called "elev8", a js/v8 binding for efl
17:18:27  <tjfontaine>k-s: you can just do the uv_run_once from your main loop to keep things spinning
17:18:29  <k-s>but really, it makes no sense to duplicate what you have in node.js
17:19:29  <coderarity>k-s: but you don't want to fork node at all?
17:19:35  <k-s>from all point of views it would make sense to integrate. Then you can have GUI from node.js, and we can get the modules you already have in JS (tons at npm) and also build on existing developer base and knowledge
17:19:38  <pfox___>anyone know what the timeline/status is on transitioning away from uv_err_t to just ints?
17:19:42  <k-s>coderarity: no, don't want to fork
17:19:46  <coderarity>k-s: I see
17:20:17  <k-s>tjfontaine: doable... but there isn't a better way?
17:20:40  <k-s>tjfontaine: another option we foresee is to get the epoll fd and monitor it on our main loop
17:20:54  <k-s>also
17:20:56  * TooTallNatejoined
17:21:13  <k-s>efl is the core of "Tizen", the LinuxFoundation + Samsung + Intel mobile operating system
17:21:27  <k-s>currently we're only advocating web apps, as those that run in the browser
17:21:58  <k-s>but we hope that aside from C, people can write it in JS + Node + EFL with this :-)
17:22:16  <coderarity>k-s: so you're trying to use node.js to make non-web browser based GUI's?
17:22:20  <k-s>so it's our chance to get node.js by default on phones :-)
17:22:34  <k-s>coderarity: yes, of course people can mix stuff
17:23:03  <k-s>like have a node.js and create a view on web browser, or webkit/efl
17:24:34  <coderarity>k-s: why would you make a GUI app over a web app?
17:25:09  <k-s>depends
17:25:21  <k-s>maybe you have some part of it written
17:25:28  <k-s>and just want to make it possible to run 'offline'
17:25:42  <k-s>then you can isolate the parts of your node.js server to run on the phone
17:25:49  <k-s>and sync when you're online
17:25:54  <coderarity>k-s: there's offline stuff in HTML5
17:26:01  <k-s>sure
17:26:15  <k-s>but then you need it to be fully written and run in the browser :-)
17:26:24  <k-s>my role is just to make it possible
17:26:30  <k-s>not writting apps myself
17:26:37  <k-s>anyway
17:26:39  <coderarity>what's wrong with making it work in the web browser?
17:26:59  <k-s>the core target is to allow native (non-web) applications in javascript
17:27:06  <coderarity>k-s: and you could always do something like Microsoft is doing in windows 8
17:27:27  <k-s>then there is no html, just js + efl = awesomeness ;-)
17:27:40  <k-s>coderarity: what is ms doing for win8?
17:28:05  <coderarity>k-s: you can make apps in JavaScript/HTML/CSS that can access OS features, and those are available through the windows store
17:28:06  * orlandovftwquit (Quit: leaving)
17:28:17  <coderarity>k-s: or even look at Google Chrome OS, those are all web apps too
17:28:34  <k-s>ah
17:28:41  <k-s>that is currently in tizen
17:28:53  <k-s>that's the first thing they got
17:28:56  <k-s>100% web
17:29:07  <k-s>now they also want native apps using EFL
17:29:10  <k-s>both in C and JS
17:29:31  <k-s>C is good, is fast... but people can't get it right. Unfortunately. (I'm a C dev)
17:29:41  <k-s>then JS provides a good balance
17:29:50  <k-s>function closures is helpful for callbacks and so on
17:30:06  <k-s>so we're building the next-gen app support
17:30:12  <k-s>(current is 100% web)
17:30:50  <coderarity>k-s: what do you need to have a native app? I mean, if you want to add native OS functions, you can do that by adding some extensions available to privileged web apps. Microsoft is doing that in Windows 8
17:31:15  <k-s>there are multiple reasons, one being performance
17:31:32  <k-s>although webkit is fast
17:31:45  <k-s>efl is orders of times faster for some things
17:31:49  <coderarity>k-s: well v8 is what node runs on, that's the same thing behind google chrome
17:32:01  <k-s>coderarity: in that case I mean native C apps
17:32:33  <k-s>also, EFL is powerful in some ways, and you can't access it from the browser
17:32:36  <coderarity>k-s: well, you could also write a C module for node
17:32:52  <coderarity>k-s: that C module could have your C stuff from EFL
17:32:52  <k-s>to create the view, it wouldn't make sense to create EFL widgets inside a browser
17:33:35  <coderarity>k-s: yeah, well if you're really set on using EFL in that way, then you should make a native module, those are written in C++, and you could use that to interface with EFL
17:34:00  <coderarity>k-s: http://nodejs.org/docs/v0.4.6/api/addons.html
17:34:04  <k-s>yes
17:34:07  <k-s>we'll migrate to it
17:34:28  <k-s>right now we have 'elev8', that should be converted into a series of node.js modules
17:34:36  <k-s>BUT we need a way to get the main loop integrated
17:34:49  <k-s>likely a way to build node.js with ecore main loop
17:35:12  <coderarity>k-s: you would probably have to fork node
17:35:18  <k-s>really? :-(
17:35:40  <coderarity>k-s: I mean, replacing the loop behind node.js is a big thing, that's not the type of thing that could just be integrated into the source code
17:35:43  <k-s>given that libuv have support for linux, windows... I expected to be able to have an 'ecore' version
17:36:47  <coderarity>k-s: that's something that's determined at compile time, you could always fork libuv, and if you kept the API compatible I suppose you could do that
17:36:59  <coderarity>getting it merged in is a different story, I can't help with that
17:37:31  <k-s>who could help with that?
17:37:55  <coderarity>k-s: isaacs could probably help, I'm not sure who to send you to though
17:38:14  <k-s>ok, will be around
17:38:14  <isaacs>coderarity: whoa! ancient doc!
17:38:29  <coderarity>isaacs: good point
17:38:30  <isaacs>coderarity: http://nodejs.org/api/addons.html
17:38:33  <isaacs>k-s: ^
17:38:49  <coderarity>googling API docs ends up badly
17:39:13  <TooTallNate>i'm guessing jquery was close to the top?
17:39:23  <isaacs>hm. maybe we should just exclude v0.4 docs in the robots.txt.
17:39:33  <k-s>isaacs: but how to get a new backend for libuv accepted?
17:39:35  <isaacs>coderarity: what did you google for?
17:39:53  <isaacs>k-s: you need to talk to piscisaureus (bert belder)
17:40:01  <isaacs>k-s: he's not here at the moment.
17:40:03  <k-s>ok
17:40:06  <isaacs>k-s: but he's the king of libuv
17:40:38  <k-s>ok
17:40:49  <isaacs>bnoordhuis and igorzi are also quite involved with libuv.
17:41:01  <TooTallNate>isaacs: i've been wanting to look into a Cocoa backed for a while now
17:41:15  <isaacs>i try to stay more on the js side of things, but i do get pulled into c++ more often than i'd like.
17:41:17  <coderarity>isaacs: I have no idea
17:41:39  <TooTallNate>isaacs: this stdio stuff looks pretty nice
17:42:05  <AvianFlu>I concur :D
17:42:20  <coderarity>I think I googled something, and someone linked to docs from a long time ago, and that was the tab that was open so I used it to go to a different part
17:42:25  <coderarity>it gets so confusing sometimes
17:42:49  <coderarity>TooTallNate: yeah all of that awesome stdio redirection to files on windows
17:43:09  * dshaw_joined
18:00:47  * hij1nxquit (Quit: hij1nx)
18:01:57  * dapjoined
18:09:22  <indutny_sleeping>isaacs: hey
18:09:28  <isaacs>hi :)_
18:09:30  <indutny_sleeping>isaacs: sorry, I was almost away
18:09:34  <isaacs>indutny_sleeping: irc'ing in your sleep?
18:09:36  <indutny_sleeping>seen your email about debugger
18:09:37  <isaacs>;P
18:09:43  <indutny_sleeping>sleepwalking
18:09:44  <indutny_sleeping>err
18:09:46  <indutny_sleeping>sleeptalking
18:09:49  <isaacs>kewl
18:09:49  <indutny_sleeping>:)
18:09:55  <isaacs>yeah, there's some kind of weird race going on.
18:10:04  <indutny_sleeping>yes, that's a well known
18:10:05  * stephankjoined
18:10:13  <indutny_sleeping>I'll try fixing it this weekend
18:10:17  <isaacs>awesome.
18:10:38  <isaacs>don't feel too obligated. if you decide to keep cranking on candor instead, just lmk, and either i or ben or someone else can dig into it.
18:10:52  <isaacs>but some pointer or comment at the very least woudl be really nice.
18:10:54  <indutny_sleeping>ok
18:11:10  <indutny_sleeping>I'll let you know in that case
18:11:16  <isaacs>thanks :)
18:11:20  <indutny_sleeping>:)
18:11:37  <isaacs>it actually isn't just a race condition in teh test, as i'd originally thought.
18:12:01  <isaacs>the debugger itself seems to miss debugger; statements encountered on the first-tick.
18:12:09  <isaacs>but not all the time
18:12:13  <isaacs>just most of the time :)
18:12:34  <isaacs>i suspect a v8 change made it from a rare occurrence that it breaks, to a rare occurrence that it works
18:13:52  <indutny_sleeping>:)
18:13:58  <indutny_sleeping>I'll fix v8 then
18:14:10  <indutny_sleeping>hehe
18:16:35  <TooTallNate>indutny_sleeping: also if you get a sec, could you try my tty->readline branch to make sure i didn't mess up the debugger?
18:16:35  <TooTallNate>https://github.com/TooTallNate/node/compare/tty-readline-migration
18:17:10  * brsonjoined
18:17:26  <indutny_sleeping>TooTallNate: ok
18:17:30  <indutny_sleeping>tomorrow
18:17:34  <TooTallNate>np
18:17:36  <TooTallNate>thanks
18:22:46  <coderarity>isaacs: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740522(v=vs.85).aspx
18:23:02  <coderarity>you think that might work with windows for that spawn stuff you had?
18:23:41  <isaacs>coderarity: thanks! i think bert and/or igorzi had mentioned something a bit like this, but the issue was that just the FD number isn't enough info.
18:23:45  * JoshWilsdonjoined
18:25:34  <coderarity>isaacs: you mean in example 5?
18:25:49  <isaacs>coderarity: well, in pretty much all the examples
18:26:07  <isaacs>coderarity: that's why it's passing the fin or ferr stream rather than fin.fd or ferr.fd
18:26:20  * CoverSli1ejoined
18:27:04  <coderarity>isaacs: oh yeah
18:27:32  <isaacs>coderarity: the assumption is that we'll bundle the required info in that somewhat-opaque object
18:28:32  <coderarity>isaacs: yeah, but why would you want to use the fd number, and not the stream itself?
18:28:52  * ircretaryquit (Ping timeout: 252 seconds)
18:29:01  <coderarity>I mean, typing fin.fd seems a little excessive, you just want the fin connected to it, right?
18:29:14  * CoverSlidequit (Ping timeout: 252 seconds)
18:30:00  <isaacs>coderarity: well, sure. what you want, though, is that the underlying socket gets directly used, without passing all the bytes through the userland JS layer.
18:30:38  * ircretaryjoined
18:31:28  <coderarity>hmm, ok
18:35:32  * mikealjoined
18:35:53  * piscisaureus__joined
18:35:57  * piscisaureus__changed nick to piscisaureus_
18:36:42  * skomskijoined
18:38:50  <isaacs>JoshWilsdon: yo
18:38:57  <isaacs>JoshWilsdon: http://piscisaureus.no.de/
18:39:09  <isaacs>http://piscisaureus.no.de/libuv/latest
18:39:21  <JoshWilsdon>isaacs: yep I saw that.
18:39:28  <JoshWilsdon>Thanks!
18:39:31  <isaacs>kewl
18:39:56  <isaacs>so, yeah, i'm reworking this stdio.js proposal based on some of your feedback.
18:40:01  <isaacs>non-array option-5 is out.
18:40:12  <JoshWilsdon>yeah, I think that's for the best.
18:40:59  <isaacs>also, that allows spacing it out. like, if you ONLY need to set fd=5, you coudl do streams:[null, null, whatever]
18:41:52  <JoshWilsdon>yep
18:42:24  <JoshWilsdon>I think everything else makes sense.
18:42:27  <isaacs>i think this api is definitely capable, and only has a few edges to sand down from a usability pov.
18:42:36  <isaacs>the big question is whether or how it'll work for windows.
18:43:19  <isaacs>at the very least, we can do the same pipe_wrap trick we use for child_process.fork, and just stream.pipe() it together in javascript land.
18:43:41  <isaacs>which will be a little bit slow and terrible, but i really think most windows programs are not doing this anyway.
18:44:42  <AvianFlu>isaacs, ++
18:44:44  <kohai>isaacs has 13 beers
18:47:09  * orlandovftwjoined
18:47:09  * orlandovftwquit (Client Quit)
18:47:19  * piscisaureus_quit (Read error: Operation timed out)
18:47:24  * orlandovftwjoined
18:47:37  <isaacs>the other advantage of this will be that we can implement child_process.fork all in JS, by using this API.
18:47:49  * piscisaureus_joined
18:47:59  * skomskiquit (Quit: skomski)
18:48:05  <isaacs>and that perennial nodejitsu complaint can finally be put to rest :)
18:48:34  <AvianFlu>"We Try Things in JS so You Don't Have To." (tm)
18:52:01  * skomskijoined
19:03:12  <piscisaureus_>isaacs: I kind of like your proposal
19:03:45  <piscisaureus_>isaacs: I am missing the part where you have to open fd 4 as a listening server
19:03:55  <piscisaureus_>or something
19:04:58  <isaacs>piscisaureus_: spawn(c,a,{streams:[{name: 'customthingie', value: server}]})
19:05:14  <isaacs>piscisaureus_: or, unnamed: spawn(c,a,{streams:[server]})
19:05:29  <isaacs>oh, that'd be fd=3
19:05:38  <isaacs>spawn(c,a,{streams:[null, server]})
19:05:38  <piscisaureus_>isaacs: no, I mean, the listenFD replacement
19:05:59  <isaacs>oh, right
19:06:03  <isaacs>yeah, working on that :)
19:06:11  * skomskiquit (Quit: skomski)
19:06:19  <piscisaureus_>isaacs: btw, I am not sure about the naming of different fds
19:06:57  <isaacs>var child=spawn(c,a,{streams:[null, 'stream']}); http.createServer(..).listenHandle(child.streams.anonymous_4)
19:06:59  <isaacs>or something
19:07:29  * paddybyersquit (Ping timeout: 252 seconds)
19:07:56  <piscisaureus_>could we just have `cp = spawn(c, a, { streams: { 3: server, 5: mysocket })`
19:07:56  <piscisaureus_>assert(cp.streams[0] === cp.stdin);
19:07:56  <piscisaureus_>assert(cp.streams[5] === mysocket);
19:09:20  <JoshWilsdon>I for one like that better. (using numbers)
19:09:28  <isaacs>piscisaureus_: objects with numeric members are weird
19:09:38  <piscisaureus_>isaacs: also, we need a proposal for opening a pipe and turning one end into a proper net.Socket instance and dropping the other one off at a child process
19:10:03  <piscisaureus_>isaacs: we should probably just take an array-ish there
19:10:11  <piscisaureus_>and ignore undefined values
19:10:19  <isaacs>piscisaureus_: would we then map that same number to the fd in the child_proc?
19:10:28  <piscisaureus_>isaacs: yes
19:10:30  <piscisaureus_>that's the idea
19:10:37  <isaacs>piscisaureus_: what happens when you do {streams:[foo, bar, baz]}
19:10:43  <isaacs>piscisaureus_: is that like customFds all over again?
19:10:51  <piscisaureus_>isaacs: yup
19:11:15  <piscisaureus_>isaacs: but you do need to control *which* fd gets assigned in the child
19:11:32  <isaacs>yeah, so, that's what the array was, but i'm bumping them up by 3
19:11:43  <isaacs>and then a stdio member for the others.
19:11:44  * sh1mmerjoined
19:11:50  <isaacs>but i guess it is a bit of a clumsier api that way
19:11:53  <piscisaureus_>isaacs: yeah, to me that is way too magic
19:12:13  <isaacs>if we were *only* doing stdio 0,1,2, then the stdio:{in,out,err} would be nice
19:12:23  <piscisaureus_>yeah, that would have been much nicer
19:12:30  <isaacs>but i was mostly keeping this separate and name-oriented for your benefit :)
19:12:34  <isaacs>your = windows
19:12:35  <piscisaureus_>but unfortunately the unix people beat us to it
19:12:41  <piscisaureus_>oh, I don't mind
19:13:06  <piscisaureus_>isaacs: FDs are not numbers, except for those that you pass to child processes :-)
19:13:12  <piscisaureus_>isaacs: don't ask
19:13:15  <isaacs>ok, so, i'm going to udpate it then to just be an array called "streams"
19:13:16  <isaacs>hahaha
19:13:27  <piscisaureus_>yeah
19:13:28  <isaacs>and you don't pass numbers in it, though still?
19:13:34  <piscisaureus_>no, no numbers
19:13:36  <piscisaureus_>that can't work
19:13:39  <isaacs>like, pass in a fileReadStream or a socket or whatever.
19:13:45  <piscisaureus_>yeah
19:13:48  <isaacs>or the stream from another child proc
19:14:02  <isaacs>and we'll just map child.stdin === child.streams[0] for compatibility
19:14:10  <piscisaureus_>or <<whatever is returned by fs.open>> would probably also work
19:14:12  <isaacs>but if you want to look at some other stream, look in teh child.streams array at the fd
19:14:21  <piscisaureus_>although I am not guaranteeing that it will always keep working on windows
19:14:46  <piscisaureus_>yeah
19:14:49  <piscisaureus_>or the handle or whatever
19:14:56  <piscisaureus_>we have to specify a libuv api for this
19:15:07  <isaacs>yeah, if we really want to make this robust, we need to get rid of fs.open returning an integer.
19:15:16  <isaacs>it should be a Handle object.
19:16:02  <piscisaureus_>isaacs: yeah, that would be nice from one, but also rather odd from another perspective.
19:16:32  <isaacs>true.
19:16:36  <piscisaureus_>but - yeah, I'd be down with that
19:16:36  <isaacs>since it does actually return an int
19:16:42  <tjfontaine>the net stuff is going to be Handle based as well? so we can Handle.unref?
19:16:53  <piscisaureus_>tjfontaine: the net stuff is already handle based
19:17:09  <piscisaureus_>tjfontaine: and - yes, you will have unref()
19:17:12  <tjfontaine>k, the refing just isn't there yet
19:17:13  <tjfontaine>nod
19:17:24  <piscisaureus_>tjfontaine: although those are not really related to one another :-)
19:17:32  <piscisaureus_>tjfontaine: we have to do the refcount refactor in libuv
19:17:36  * tjfontainenods
19:18:06  <piscisaureus_>tjfontaine: https://github.com/joyent/libuv/issues/347 if you want to start coding :-p
19:18:29  <tjfontaine>piscisaureus_: I'll let you take the lead :)
19:20:04  <isaacs>piscisaureus_: so, just to be clear, then: the only thing currently missing from this stdio proposal is a way to do server.listenHandle(child.streams[4]), right?
19:20:32  <isaacs>piscisaureus_: and to note that we're going to want to pipe the child process stream to something soon, but not pass everything through JS layer
19:20:44  <isaacs>set up a pipe_wrap pair or something
19:21:05  <piscisaureus_>isaacs: no, that's what I mean
19:21:13  <piscisaureus_>isaacs: I mean, what people used to do with listenFD(4)
19:21:31  <isaacs>piscisaureus_: oh, ok, so server.listen(process.streams[4])
19:21:32  <piscisaureus_>isaacs: someone spawned *us* with FD 4 being something typical
19:21:45  <isaacs>in the child proc
19:21:50  <piscisaureus_>isaacs: yes
19:22:15  <piscisaureus_>isaacs: although you should note that there is no way for a child to detect which streams were passed
19:22:21  <isaacs>spawn(c,a,[null,something]); // in the child... http.createServer(..).listen(process.streams[4])
19:22:43  <isaacs>piscisaureus_: we should just pass an env or something.
19:23:04  <piscisaureus_>isaacs: yeah, but what if systemd spawns us with fd4 set. It's not going to set an env var...
19:23:15  <isaacs>right
19:23:15  <piscisaureus_>isaacs: I don't care about node spawning node. That's not the problem we are solving.
19:23:23  <isaacs>fair enough
19:23:42  <isaacs>how would a program normally detect this? like, not in node?
19:23:48  <isaacs>JoshWilsdon: ^?
19:23:55  <piscisaureus_>isaacs: it doesn't
19:24:02  <piscisaureus_>isaacs: that's why programs *specify*
19:24:06  <isaacs>k
19:24:19  <isaacs>so you just say "I know that FD #4 will be a thing. Use that one."
19:24:24  <piscisaureus_>isaacs: yes
19:25:00  <isaacs>piscisaureus_: is there *anything* like this at all in windows land?
19:25:00  <piscisaureus_>isaacs: so what we used to have is `new net.Socket({fd: 4})` for this
19:25:06  <isaacs>rigth
19:25:14  <piscisaureus_>isaacs: yes and no.
19:25:29  <piscisaureus_>isaacs: yes, there is anything like it, but it is rarely used.
19:25:35  <isaacs>k
19:25:47  <isaacs>so, we could have something like: server.listenHandle(createHandle(4))?
19:26:01  <piscisaureus_>yeah, that'd work
19:26:28  <isaacs>what would that do on windows?
19:26:31  <isaacs>createHandle(4) i mean
19:26:47  <JoshWilsdon>sorry yeah, as piscisaureus_ said, you don't detect. You specify.
19:27:04  <piscisaureus_>isaacs: most likely, HANDLE h = (HANDLE) _get_osfhandle(4);
19:27:24  <piscisaureus_>isaacs: ... and hope for the best
19:27:27  <isaacs>ok
19:27:30  <isaacs>sure.
19:27:44  <isaacs>so if that fails, we throw or emit('error') or whatever, and it's up to you to deal with that.
19:27:50  <piscisaureus_>isaacs: so we can go for the smart and the dumb option
19:28:37  <piscisaureus_>isaacs: so we could do process.openFD(4) which would ask libuv to figure out what type of fd it is and wrap it as a reasonable javascript stream object
19:29:01  <piscisaureus_>isaacs: the only thing is, it is not always possible to tell whether the user needs a net.Server or a net.Socket
19:29:24  <isaacs>piscisaureus_: yeah, that's what i'm thinking. it's up to you to know what fd4 should be
19:29:51  <piscisaureus_>isaacs: so actuall, I'd be down with fs.createReadStream({fd: 4}). net.createSocket({fd: 4}), net.createServer({fd: 4}).
19:30:03  <piscisaureus_>isaacs: where we specify this api is only there for inheriting handles
19:30:05  <isaacs>so you do net.Socket(fd...) or net.Server().listen(fd...)
19:30:42  <piscisaureus_>isaacs: I would to specify in in the constructor, and not as an argument to the listen call
19:30:51  <isaacs>piscisaureus_: ok.
19:30:58  <piscisaureus_>I think this would suffice
19:30:59  <isaacs>that's a departure from listenFD()
19:31:08  <piscisaureus_>yeah, but I never really got that
19:31:12  <isaacs>but i guess it's more consistent
19:31:23  <isaacs>or we could do net.connect({fd:4})
19:31:36  <piscisaureus_>you mean net.createConnection?
19:31:46  <isaacs>oh, right
19:31:47  <piscisaureus_>yeah, that would also work for me
19:31:56  <isaacs>but like, either in the .connect() and .listen(), or in the ctor
19:32:01  * mikeal1joined
19:32:06  <isaacs>is it possible for a server to listen on a fd, and also on a port?
19:32:26  * piscisaureus_quit (Read error: Connection reset by peer)
19:32:44  <isaacs>damn. yeti probably got 'im.
19:33:03  * piscisaureus_joined
19:33:06  * mikealquit (Ping timeout: 240 seconds)
19:33:39  <piscisaureus_>isaacs: unlikely, but possible in theory
19:33:52  <piscisaureus_>isaacs: sorry, my connection dropped. I am in a bus, going on a company trip
19:34:07  <isaacs>aha
19:34:35  <isaacs>piscisaureus_: i think it's better to not be in the ctor, in that case.
19:34:46  <isaacs>piscisaureus_: unless we want to say that servers can only listen to one thing.
19:35:25  <isaacs>piscisaureus_: net.createServer(listenCb).listen({fd:4}).listen("some-sock").listen(1337)
19:36:14  <piscisaureus_>huh, why?
19:36:35  * brsonquit (Ping timeout: 246 seconds)
19:36:37  <piscisaureus_>isaacs: it's not like servers can actually listen at more than 1 thing right?
19:36:43  <piscisaureus_>isaacs: or -
19:36:58  <piscisaureus_>net.createServer(function() {..}).listen(80).listen(81) <-- that works???
19:37:10  <isaacs>well, listen() doesn't return the server, i don't think
19:38:10  <isaacs>hm, no, they can't
19:38:15  <piscisaureus_>isaacs: afaik net.Server instances wrap exactly one socket.
19:38:16  <isaacs>the API doesn't really make you aware of that.
19:38:20  <isaacs>it just silently doesn't work
19:38:25  <isaacs>well that's shitty :)
19:38:27  <piscisaureus_>yeah, that's probably wrong
19:38:40  * isaacsresisting the urge to try to solve every problem ever
19:39:05  <piscisaureus_>that's weird
19:39:15  <piscisaureus_>I am leaving the country now, so no internet for a while
19:39:17  <piscisaureus_>isaacs: ttyl.
19:39:25  <piscisaureus_>sorry about that btw
19:39:36  <isaacs>ok, have fun!
19:39:37  <piscisaureus_>yeti really got me now
19:39:41  <isaacs>stay away from yeti
19:39:45  <piscisaureus_>:-)
19:39:46  <isaacs>they're roudy drunks
19:39:46  <piscisaureus_>later
19:39:52  <isaacs>lates
19:41:16  <coderarity>isaacs: how are you supposed to pass around those handles without them going through JS?
19:41:37  * AndreasMadsenjoined
19:41:51  <isaacs>coderarity: well, the handle object will be exposed to JS. but it won't emit 'data' events with buffers
19:42:03  <isaacs>coderarity: we'll just tell the OS to hook up the tubes appropriately
19:42:15  <coderarity>isaacs: oh I see
19:42:16  * paddybyersjoined
19:42:57  <coderarity>isaacs: I'm not sure how it works on Unix, but on Windows you just give the child access to the file handles. so you would still have access to that file handle in JS, even though you also gave it to the child process?
19:44:03  * mikeal1quit (Quit: Leaving.)
19:44:04  * AndreasMadsencan't recognize my self today
19:44:16  <coderarity>isaacs: for example, if you're giving the child file handles, like for stdin, after you gave them to the child, you would still have the file handles yourself
19:44:22  * piscisaureus_quit (Ping timeout: 265 seconds)
19:44:54  <coderarity>isaacs: i mean, there's nothing stopping you from writing to that same file handle that the child got in theory, right? or reading from it?
19:45:06  <isaacs>coderarity: sure.
19:45:27  <isaacs>coderarity: but what i'm saying is, the child won't then duplicate all those bytes on a child.streams[n] interface
19:45:54  <coderarity>isaacs: so it wouldn't send all the data to those streams unless you opened another one?
19:46:45  <coderarity>isaacs: you're saying that child.streams[n] won't emit 'data' events? you would have to copy them to get that data?
19:51:51  <isaacs>coderarity: the goal here is to get back the functionality that was exposed in a very unix-centric way in 0.4
19:52:14  <isaacs>but in a way that plays nice with windows and isn't quite as ugly
19:52:37  * AndreasMadsenquit (Read error: Connection reset by peer)
19:52:52  * AndreasMadsenjoined
19:53:58  <isaacs>if you do: spawn(c,a,{streams:[,,,null,'stream']}) then you'd set fd=3 to /dev/null, and have a stream object in teh parent that corresponds to fd=4 in the child
19:55:18  <coderarity>isaacs: oh, so streams correspond to customFds, and since Windows uses handles you need to change it from fds to handles?
19:55:37  <coderarity>I wasn't here for 0.4.x
19:56:19  <coderarity>it says 'hook new process to existing stream', that makes sense
19:57:58  * sh1mmerquit (Ping timeout: 250 seconds)
19:58:06  <coderarity>isaacs: I don't see what you mean the problem is though, I mean, if you hand in a stream to that, then on Windows it's a HANDLE and on Unix it's a file descriptor, right? and the child process can take a handle on window, and by the looks of it a file descriptor on Windows
19:58:32  <coderarity>a handle on windows and a file descriptor on Unix*
20:02:06  * paddybyersquit (Quit: paddybyers)
20:09:00  <isaacs>coderarity: yes, you are beginning to see the tricky part of the riddle :)
20:12:27  <coderarity>hmm, I need to learn more about all of that Unix stuff
20:12:37  <coderarity>it's weird knowing Windows but not Unix
20:13:59  <coderarity>it'd be easier to understand this if I knew the differences in more detail
20:15:34  * sh1mmerjoined
20:16:40  <isaacs>it's really very simple on Unix.
20:17:01  <isaacs>fd's are numbers. sockets and pipes and files: all the same kind of thing, for the most part.
20:17:06  <isaacs>at least, they pretend to be.
20:17:33  <tjfontaine>net.isIP('');
20:17:34  <tjfontaine>4
20:17:39  <tjfontaine>that seems very wrong
20:18:06  <isaacs>tjfontaine: yeah, it does..
20:18:36  <coderarity>yeah, I kinda got that vibe
20:18:38  <tjfontaine>hmm that's an explicitly handled case
20:18:42  <coderarity>"everything is better on Unix"
20:18:50  <isaacs>coderarity: well, not *everything*
20:18:56  <isaacs>windows wins in some areas.
20:18:59  <coderarity>isaacs: well, yeah
20:19:02  <coderarity>isaacs: like DirectX
20:19:08  <coderarity>isaacs: which is the main reason I am acquainted with it
20:19:18  <isaacs>coderarity: or the fact that node.exe works on every windows ever, and always will, most likely
20:19:30  <isaacs>coderarity: binary deploys for other operating systems is so painful
20:19:37  <coderarity>isaacs: you mean with all of the COM stuff?
20:19:59  <tjfontaine>isaacs: I'm going to move on since that's how net seems to want to handle that case
20:20:28  * dshaw_quit (Quit: Leaving.)
20:21:50  * coderaritygoes away for real
20:29:12  * paddybyersjoined
20:46:14  <tjfontaine>[03:31|% 100|+ 371|- 3] for my dns stuff, two are debugger-repl, and the other is http-full-response, which I'm not sure is normal
20:49:51  * paddybyersquit (Quit: paddybyers)
20:52:18  * brsonjoined
20:56:51  * skomskijoined
21:06:50  * skomskiquit (Quit: skomski)
21:15:07  * pieternquit (Quit: pietern)
21:19:04  <bnoordhuis>k-s: how does ecore's event loop work internally?
21:19:26  <bnoordhuis>if it's just a couple of file descriptors, that should be relatively straightforward to integrate into libuv
21:22:00  <k-s>bnoordhuis: it's in a way similar to glib
21:22:12  <k-s>bnoordhuis: actually we integrate with glib
21:22:29  <k-s>bnoordhuis: i'm reading libev's code, and while it does handle some nice things
21:22:44  <k-s>it will be a pain to have both to play together nicely
21:22:59  <k-s>I'm fearing to have that upstreamable will be no-go
21:23:18  <bnoordhuis>k-s: okay, so what do you have in mind?
21:23:19  <k-s>and we'll have to go with a fork node/libuv using a patch
21:23:33  <bnoordhuis>tjfontaine: http-full-response sometimes fails
21:23:53  <k-s>bnoordhuis: the easiest way would be to use libev's epoll implementation, register epoll's fd with ECORE. Then call ev_run_once()
21:25:22  <k-s>we can replace ecore's select() function, as libev also mention. But currently we already do that if glib is integrated with ecore :-/
21:27:28  * AndreasMadsenquit (Remote host closed the connection)
21:30:03  <bnoordhuis>k-s: that should work. so all you need is the epoll fd and ev_run_once?
21:30:10  <k-s>yes
21:30:26  <k-s>but then... it would be a hack and likely not accepted by libuv/node.js
21:30:40  <bnoordhuis>no, you're right about that :)
21:30:55  <k-s>another option that requires way more work
21:31:04  <k-s>is to create a new implementation/platform for libuv
21:31:17  <k-s>so there is win, unix (ev) and a new 'ecore'
21:31:27  <k-s>but it would be lots of work
21:31:34  <bnoordhuis>yes
21:31:44  <bnoordhuis>not something anyone of us has time for, i think
21:33:07  <bnoordhuis>let me think it over for a bit
21:33:43  <k-s>me too, no immediate action as I have to travel in few minutes
21:34:19  <k-s>http://docs.enlightenment.org/auto/ecore/group__Ecore__Main__Loop__Group.html if you need some reference on ecore's side
21:34:54  <k-s>ideally I want things upstream and no forks
21:34:59  <k-s>of libuv or node.js
21:38:22  <k-s>some functions from libuv are also provided by our 'eina' lib, like locks and basic fs access
21:39:24  <bnoordhuis>we can probably work something it
21:39:39  <bnoordhuis>*out
21:39:54  <bnoordhuis>integrating with other event loops is a recurring theme so i guess we should handle it somehow :)
21:40:09  <k-s>yeah, it would be awesome to make that easier
21:40:25  <k-s>i googled and found glib and qt guys had that too
21:48:36  <k-s>gotta go
21:48:37  <k-s>bbl
21:48:43  * k-schanged nick to k-s[AWAY]
22:08:23  * rendarquit
22:19:40  * paddybyersjoined
22:25:47  * dshaw_joined
22:38:29  * sh1mmerquit (Quit: sh1mmer)
22:45:52  <igorzi>bnoordhuis: hey.. yt?
22:46:14  <TooTallNate>isaacs: can i merge? https://github.com/joyent/node/pull/2949
22:46:29  <TooTallNate>specifically, i should confirm he's signed the cla (which he says he has)
22:47:16  <isaacs>TooTallNate: oh, right, i need to share that to you.
22:47:18  <isaacs>one sec
22:49:43  <isaacs>TooTallNate: yes, he's signed the CLA.
22:49:56  <TooTallNate>cool thanks
22:49:58  <isaacs>TooTallNate: have to really dig to figure out who that guy is, though. he should put a name or something in his github profile.
22:50:13  <isaacs>TooTallNate: ryah is the only one with admin access to the doc, but i requested that he add you to it.
22:50:29  <isaacs>TooTallNate: "the doc" = the google doc of CLA signers
22:50:47  <TooTallNate>isaacs: i figured, ok sounds good thanks
22:50:50  <TooTallNate>i'll squash this then
22:50:53  <isaacs>kewl
22:50:59  <isaacs>yes, should be one commit, ofcourse.
22:52:37  <TooTallNate>crazy repl's over curl!!! https://gist.github.com/2053342
22:53:06  <TooTallNate>isaacs: ^ that's what's possible with the repl overhaul :D
22:53:17  <isaacs>baller!!
22:54:31  <isaacs>TooTallNate: that landed yesterday, right?
22:54:48  <isaacs>er, no, i'm thinking of process.config
22:54:50  <TooTallNate>isaacs: no, still working on tests/docs
22:54:56  <TooTallNate>yes, process.config landed
22:54:59  <isaacs>ah, ok, kewl.
22:56:08  * sh1mmerjoined
22:59:00  <bnoordhuis>igorzi: yes
23:02:59  <CIA-99>node: Alex Xu master * r5abcdc9 / configure : build: fix configure with spaces in CC - http://git.io/ui3pvA
23:05:17  <igorzi>bnoordhuis: once in a while i see this:
23:05:19  <igorzi>net.js:622
23:05:23  <igorzi> for (var i = 0; i < self._connectQueue.length; i++) {
23:05:28  <igorzi> ^
23:05:32  <igorzi>TypeError: Cannot read property 'length' of null
23:05:36  <igorzi> at Object.afterConnect [as oncomplete] (net.js:622:45)
23:05:57  <igorzi>bnoordhuis: how can it be?
23:07:06  <igorzi>v8 bug?
23:07:16  <bnoordhuis>igorzi: no, i think we have a race in lib/net.js
23:07:35  <bnoordhuis>if one of the queued callbacks destroys the socket, _connectQueue will be null on the next iteration of that for loop
23:08:04  <bnoordhuis>i suppose the easy solution is to assign self._connectQueue to a local variable before entering the loop
23:08:30  <bnoordhuis>'race' is not really the proper word for it but you know what i mean
23:09:18  <igorzi>bnoordhuis: ahh ok, makes sense
23:12:15  <igorzi>bnoordhuis: we probably want to get out of that loop as soon as the socket is destroyed?
23:14:51  <bnoordhuis>igorzi: shouldn't all callbacks have the opportunity to run?
23:16:37  <bnoordhuis>yes, i think they have to, otherwise there's a huge potential for resource leaks
23:18:01  * travis-cijoined
23:18:01  <travis-ci>[travis-ci] joyent/node#606 (master - 5abcdc9 : Alex Xu): The build is still failing.
23:18:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/76a771b...5abcdc9
23:18:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/884393
23:18:01  * travis-cipart
23:18:01  <igorzi>bnoordhuis: aren't these pending writes that get queued (before the socket is connected)? if the socket is destroyed - these writes won't happen anyway
23:19:53  <bnoordhuis>igorzi: i'm thinking of write callbacks that need to release some resource after the write is done (file descriptor, database connection, whatever)
23:23:56  <igorzi>bnoordhuis: yeah, i see your point.. right now if we just continue through the loop Socket._write would throw.. so we should probably make it smarter and dispatch the callback?
23:24:45  <bnoordhuis>igorzi: yes
23:43:05  * paddybyersquit (Quit: paddybyers)