00:01:30  * mmaleckijoined
00:04:42  * c4miloquit (Remote host closed the connection)
00:04:50  * mmalecki_quit (Ping timeout: 248 seconds)
00:05:53  <CIA-108>node: Bert Belder master * rb27a4cb / test/simple/test-module-loading.js : test-module-loading: convert backslashes to forward slashes - http://git.io/8oLX0A
00:10:17  <piscisaureus_>bnoordhuis: a unix question - how long does it take before
00:10:17  <piscisaureus_>net.createConnection(9932, 'www.c9.io') returns ECONNREFUSED ?
00:10:31  <piscisaureus_>is it super small
00:10:37  <ryah>can we get an os.tempDir() which returns "/tmp" ?
00:10:53  <piscisaureus_>uv_get_temp_dir?
00:10:54  <ryah>and something else on windows?
00:11:29  <piscisaureus_>ryah: yeah
00:11:41  <piscisaureus_>ryah you can also just use process.env.TEMP
00:11:43  <ryah>It's kind of annoying that temp files during tests are put in node/test/tmp
00:11:43  <bnoordhuis>piscisaureus_: in general or on my laptop?
00:11:49  <piscisaureus_>bnoordhuis: for you
00:12:20  <bnoordhuis>piscisaureus_: 0.3s
00:12:20  * mikealquit (Quit: Leaving.)
00:12:23  <ryah>piscisaureus_: i dont have that env on unix
00:12:41  <piscisaureus_>bnoordhuis: aha
00:13:04  <bnoordhuis>ryah: process.env.TEMP || '/tmp'. TEMP is a windows thing afaik
00:13:11  <piscisaureus_>yeah
00:13:13  * mikealjoined
00:13:21  <piscisaureus_>so I agree that it is not a bad idea
00:13:41  <bnoordhuis>getting temp files right (securely) is surprisingly tricky though
00:13:57  <piscisaureus_>bnoordhuis, well, now that we have "x" mode it should be doable
00:14:05  <ryah>https://github.com/joyent/node/issues/3407
00:14:15  <ryah>go has this method - it's super useful
00:14:20  <piscisaureus_>http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992%28v=vs.85%29.aspx
00:14:24  <piscisaureus_>e.g.
00:14:24  <bnoordhuis>mode x? i thought that died when vga went out of vogue
00:15:01  <bnoordhuis>oh, exclusive mode
00:23:24  <CIA-108>node: Bert Belder master * r517cea3 / test/pummel/test-net-connect-econnrefused.js : test-net-connect-econnrefused: don't take forever to complete - http://git.io/SS56vw
00:24:23  * mmalecki_joined
00:27:18  * c4milojoined
00:27:29  * mmaleckiquit (Ping timeout: 244 seconds)
00:29:48  * mmalecki_quit (Ping timeout: 252 seconds)
00:31:17  <igorzi>piscisaureus_: hey
00:31:28  <igorzi>piscisaureus_: does "vcbuild msi" work for you?
00:31:31  <piscisaureus_>igorzi
00:31:37  <piscisaureus_>: hey
00:31:38  <piscisaureus_>:-)
00:31:41  <piscisaureus_>igorzi: no
00:31:48  <piscisaureus_>igorzi: there's something broken in the v8 gyp files
00:31:57  <piscisaureus_>igorzi: vcbuild nosnapshot msi works for me
00:32:40  <igorzi>piscisaureus_: hmm.. how's wix connected to gyp?
00:32:51  <piscisaureus_>igorzi: oh, is wix broken ?
00:33:03  <igorzi>piscisaureus_:; yep, i'm getting:
00:33:04  <igorzi>Unresolved reference to symbol 'WixComponentGroup:Product.Generated' in section 'Product:*'
00:33:22  <igorzi>piscisaureus_: it goes away if i remove this: https://github.com/joyent/node/blob/master/tools/msvs/msi/product.wxs#L129
00:34:07  <piscisaureus_>igorzi: a sec, I am retrying
00:34:23  <piscisaureus_>igorzi: it would surprise me tho - isaac managed to build 0.7.10 today
00:35:04  <piscisaureus_>igorzi: yes, works for me
00:35:09  <igorzi>piscisaureus_: maybe a difference in wix tools.. do you know which version of wix you got?
00:35:28  <piscisaureus_>D:\node4>candle
00:35:29  <piscisaureus_>Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0
00:35:42  <igorzi>piscisaureus_: hmm, i got 3.6
00:35:59  <piscisaureus_>igorzi: if you say that this line is bogus, be my guest and drop it :-)
00:36:25  <igorzi>piscisaureus_: let me verify first :)
00:41:21  * dapquit (Quit: Leaving.)
00:53:14  <piscisaureus_>bnoordhuis: on unix, is it legal to kill a process twice ?
00:55:19  * indexzeroquit (Read error: Connection reset by peer)
00:57:01  <bnoordhuis>piscisaureus_: yes and no
00:57:25  <bnoordhuis>piscisaureus_: you can send a signal twice, no problem, but if the process is already dead you'll get ESRCH
00:57:33  <piscisaureus_>right, ok
00:57:34  <piscisaureus_>thanks
00:57:35  <bnoordhuis>already dead means zombie mode
01:01:03  <piscisaureus_>somehow I get EPERM when I try to kill python
01:09:27  <bnoordhuis>piscisaureus_: you're trying to kill a process that you don't own (and you're not root)
01:10:10  <piscisaureus_>bnoordhuis: well, I am admin and UAC is off. Also, I jus spawned python myself
01:10:23  <bnoordhuis>oh, windows
01:14:05  <isaacs>igorzi, piscisaureus_: I build it with `vcbuild msi release nosnapshot`
01:14:14  <piscisaureus_>yeah
01:14:18  <piscisaureus_>mksnapshot is broken
01:15:28  * pieternquit (Quit: pietern)
01:16:38  <isaacs>that's a sham
01:16:39  <isaacs>e
01:20:51  <piscisaureus_>bnoordhuis: I think there is a race in the child_process.exec timeout/overflow handling
01:21:25  <piscisaureus_>bnoordhuis: if the child exits normally just before it times out, or the buffer overflows
01:21:41  <piscisaureus_>bnoordhuis: then child_process.js tries to kill it
01:21:49  <piscisaureus_>but this means it might get ESRC
01:22:02  <piscisaureus_>and then throw from child_process.js, which is not catchable
01:26:01  <piscisaureus_>it's also rather lame that an exec-ed process can emit error
01:27:49  <bnoordhuis>piscisaureus_: noted
01:28:03  <bnoordhuis>but i'm off to bed :)
01:28:07  <piscisaureus_>alright
01:28:16  <piscisaureus_>I as going to say let's fire the guy
01:34:34  * bnoordhuisquit (Ping timeout: 265 seconds)
01:55:20  * abraxasjoined
02:04:37  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:24:34  * ericktquit (Ping timeout: 248 seconds)
02:25:00  * abraxasquit (Remote host closed the connection)
02:25:15  * abraxasjoined
02:30:43  * AvianFluquit (Quit: Leaving)
02:38:57  * c4miloquit (Remote host closed the connection)
02:44:00  * Ariajoined
02:45:57  * mikealquit (Quit: Leaving.)
03:07:33  * brsonquit (Quit: leaving)
03:09:07  * AvianFlujoined
03:13:10  * ericktjoined
03:24:16  * ericktquit (Quit: erickt)
03:30:41  * ericktjoined
03:33:52  * erickt_joined
03:33:52  * ericktquit (Read error: Connection reset by peer)
03:33:52  * erickt_changed nick to erickt
03:36:03  * ericktquit (Read error: Connection reset by peer)
03:36:11  * ericktjoined
03:38:29  * brsonjoined
04:23:08  * Ariaquit (Remote host closed the connection)
04:53:21  * benviejoined
05:06:47  * isaacsquit (Remote host closed the connection)
05:16:00  * isaacsjoined
05:17:26  * ericktquit (Quit: erickt)
05:20:00  * paddybyersjoined
05:21:14  * TheJHjoined
05:26:52  * TheJHquit (Ping timeout: 240 seconds)
05:49:36  * brsonquit (Quit: leaving)
05:58:49  * AvianFluquit (Quit: This computer has gone to sleep)
06:02:51  * felixgejoined
06:02:51  * felixgequit (Changing host)
06:02:51  * felixgejoined
06:11:10  * isaacsquit (Remote host closed the connection)
06:19:34  * japjjoined
06:21:07  <japj>ircretary: ask piscisaureus_ if he recently did a clean build of nodejs master on windows?
06:21:07  <ircretary>japj: I'm not sure what to do with that command. Ask for help in PM.
06:21:29  <japj>ircretary: tell piscisaureus_ did you recently do a clean build of nodejs master on windows?
06:21:29  <ircretary>japj: I'll be sure to tell piscisaureus_
06:22:10  <japj>ircretary: tell isaacs a windows build slave for travis might be usefull for node ;)
06:22:10  <ircretary>japj: I'll be sure to tell isaacs
06:22:26  * japjquit (Remote host closed the connection)
06:45:26  * brsonjoined
06:50:55  * stephankquit (Quit: *Poof!*)
07:31:20  * rendarjoined
07:32:34  * brsonquit (Quit: leaving)
08:19:06  * igorziquit (Ping timeout: 245 seconds)
08:23:07  * saghulquit (Read error: Operation timed out)
08:24:46  * saghuljoined
09:05:29  * paddybyersquit (Quit: paddybyers)
10:54:57  * hij1nxjoined
10:55:34  * hij1nxquit (Excess Flood)
10:55:55  * hij1nxjoined
11:04:51  * hij1nxquit (Quit: hij1nx)
11:19:48  * felixgequit (Quit: felixge)
11:37:01  * abraxasquit (Remote host closed the connection)
11:38:38  * hij1nxjoined
11:42:42  * irajoined
11:43:11  * bnoordhuisjoined
12:41:34  * hij1nxquit (Quit: hij1nx)
12:53:36  * felixgejoined
12:53:36  * felixgequit (Changing host)
12:53:36  * felixgejoined
13:05:24  <indutny>bnoordhuis: heya
13:05:40  <indutny>bnoordhuis: don't you think that .readFile(Sync) logic is kindof borked
13:06:03  <indutny>I just read the code and it's really vulnerable to race conditions
13:06:16  * \toothrotjoined
13:06:17  <indutny>like file may be changed between fs.stat call and reading it
13:06:37  <bnoordhuis>indutny: that's not the only thing wrong with it...
13:06:44  <bnoordhuis>https://github.com/joyent/node/pull/3414
13:07:01  <indutny>bnoordhuis: indeed, but it's really related to this "optimization"
13:07:25  <bnoordhuis>indutny: the use of fs.stat is indeed subject to races with concurrent writers
13:07:53  * toothrquit (Ping timeout: 240 seconds)
13:08:05  <bnoordhuis>but it's not really an issue if the writer enlarges the file
13:08:08  <indutny>bnoordhuis: indeed, however there'll be always some race conditions, if we won't lock file (which is possible only on BSD)
13:08:23  <bnoordhuis>oh, file locking...
13:08:32  <bnoordhuis>you know file locks are opt-in, right?
13:08:49  <indutny>what do you mean by opt-in?
13:09:09  <bnoordhuis>it only works if all readers and writers apply locks
13:09:17  <indutny>bnoordhuis: ah, right
13:09:25  <indutny>I forgot this
13:09:58  <bnoordhuis>re fs.stat, if the writer grows the file, we'll just do a partial read, no biggie
13:10:13  <bnoordhuis>i'll have to check what happens if the file gets truncated
13:10:27  <bnoordhuis>if the buffer gets shrunk correspondingly
13:11:03  <indutny>bnoordhuis: I think it'll hang
13:11:17  <CIA-108>node: Shigeki Ohtsu master * re3a2dd1 / lib/fs.js : fs: fix fs.readFileSync to work on real empty file - http://git.io/WkmDmg
13:11:19  <CIA-108>node: Shigeki Ohtsu master * r4eb2804 / lib/fs.js : fs: fix typo in fs.readFile of lying size=0 stat - http://git.io/Rs2daA
13:11:19  <indutny>bnoordhuis: https://github.com/shigeki/node/blob/191c913d833251d956e6ce09eda7ca8dd896713a/lib/fs.js#L224
13:12:50  <indutny>bnoordhuis: while .readFile() will just return error
13:13:09  <indutny>well, this is an **edge case**
13:13:15  <indutny>but it's still possible
13:13:18  <bnoordhuis>yes
13:16:29  <bnoordhuis>hrm yes, looks like it'll go in an infinite loop
13:24:55  <indutny>indeed
13:29:00  <indutny>is it supposed to give us some sort of dominance in vert.x competition
13:29:09  <indutny>which I decline to exist :)
13:32:31  <bnoordhuis>it seemed like low-hanging fruit at the time
13:37:47  * piscisaureus_joined
13:38:26  * piscisaureus_quit (Client Quit)
13:39:04  * piscisaureus_joined
13:41:04  <bnoordhuis>indutny: https://github.com/bnoordhuis/node/commit/8f1aaee
13:41:34  <indutny>bnoordhuis: yeah, but what about .readFileSync?
13:41:38  <indutny>bnoordhuis: .readFile fix lgtm
13:42:38  * c4milojoined
13:44:34  <bnoordhuis>indutny: patience, young grashopper. everything in small steps :)
13:44:41  <indutny>hahaha, right
13:44:46  <indutny>actually .readFile won't loop
13:45:02  <indutny>ah, no, it'll
13:46:53  <bnoordhuis>indutny: it uses pread() and that returns 0 if you try to read past end of file, it won't error
13:47:02  <indutny>yeah, I got it now
13:58:30  <CIA-108>node: Bert Belder v0.6 * rbb2ce1a / lib/child_process.js : cluster: don't silently drop messages when the write queue gets big - http://git.io/Jci6fg
14:04:10  * isaacsjoined
14:06:36  <bnoordhuis>indutny: https://github.com/bnoordhuis/node/commit/e6c4619
14:12:18  * xaqjoined
14:12:55  * rendarquit (Ping timeout: 265 seconds)
14:16:39  <bnoordhuis>isaacs: https://github.com/bnoordhuis/node/compare/master%5E%5E...master
14:17:42  <indutny>bnoordhuis: lgtm
14:17:49  <bnoordhuis>cool, i'll land it
14:18:02  <CIA-108>node: Ben Noordhuis master * r8f1aaee / lib/fs.js : fs: fix infinite loop in fs.readFile() - http://git.io/MGTdbA
14:18:02  <CIA-108>node: Ben Noordhuis master * re6c4619 / lib/fs.js : fs: fix infinite loop in fs.readFileSync() - http://git.io/YMZlKQ
14:18:35  <isaacs>bnoordhuis: test would be nice
14:18:43  <isaacs>bnoordhuis: how does the loop happen?
14:18:53  <indutny>isaacs: I'm afraid that it's not really reproducible
14:19:12  <bnoordhuis>yeah, i'd be hard-pressed to write a reliable test for that :)
14:19:29  <isaacs>oic
14:19:37  <isaacs>so the bytesRead returns 0 even though we knew the size
14:19:45  <bnoordhuis>yes
14:20:28  <bnoordhuis>stat'ing the file size is a nice optimization but you shouldn't trust it blindly
14:20:33  <isaacs>bnoordhuis: in that case, if size !== 0, you should also truncate buffer to pos
14:21:04  * rendarjoined
14:21:23  <isaacs>bnoordhuis: otherwise we're returning garbage in that case.
14:21:32  <bnoordhuis>isaacs: yes, i was getting to that :)
14:22:20  <indutny>is this week a release week?
14:22:43  <indutny>isaacs: ^
14:23:19  <isaacs>indutny: yes, i'd like to get 0.7.11 out asap. we're waiting on ev_* shims in libuv, and landing listen({fd:#})
14:23:53  <isaacs>indutny: since 0.7.10 went out yesterday, this is a double-release week :)
14:24:36  <indutny>ook
14:26:51  <bnoordhuis>is setting `buf.length = n` considered bad style?
14:27:24  * TheJHjoined
14:27:39  <isaacs>bnoordhuis: can't you just return a slice?
14:27:49  <isaacs>bnoordhuis: i mean, i do that all the time with arrays, i guess.
14:27:59  <isaacs>but usually only to set it to 0
14:28:30  <isaacs>oh! also, yes, we can test this, probably, by shimming fs.read so that it takes 100ms longer
14:28:35  <bnoordhuis>yeah, i guess that's better
14:28:53  <bnoordhuis>also... out/Release/node -e 'Buffer(Buffer(2), 0, 2)' -> node: ../src/node_object_wrap.h:52: static T* node::ObjectWrap::Unwrap(v8::Handle<v8::Object>) [with T = node::Buffer]: Assertion `handle->InternalFieldCount() > 0' failed.
14:29:20  <isaacs>weird
14:29:27  <isaacs>that looks like a bug
14:34:56  <bnoordhuis>i'm going to force-push the buffer slice thing, don't want to clutter up the history too much
14:35:16  <CIA-108>node: Ben Noordhuis master * r408bfec / lib/fs.js : fs: fix infinite loop in fs.readFile() - http://git.io/ZDSIjA
14:35:16  <CIA-108>node: Ben Noordhuis master * r0385b17 / lib/fs.js : fs: fix infinite loop in fs.readFileSync() - http://git.io/xJtH1A
14:36:55  <indutny>oh noe
14:37:00  <indutny>s/noe/noes
14:38:37  <indutny>bnoordhuis: can you please assist me, what is max_int in C/C++? Is there any constant
14:39:01  <bnoordhuis>indutny: INT_MAX from limits.h
14:39:07  <bnoordhuis>what do you need it for?
14:39:12  <indutny>yeah
14:39:19  <indutny>for sort
14:40:07  <indutny>int i = INT_MAX
14:40:13  <bnoordhuis>indutny: there's also std::numeric_limits<int>::max() if you want go all c++-y
14:40:43  <bnoordhuis>but INT_MAX is shorter
14:40:52  * TheJHquit (Ping timeout: 246 seconds)
14:41:27  <bnoordhuis>indutny: out of curiosity, how does INT_MAX come into play when sorting?
14:41:54  <indutny>bnoordhuis: well, I'm allocating registers and need some sort of maximum range value
14:42:14  <indutny>bnoordhuis: Later I'll choose a register with a minimal value
14:42:31  * AvianFlujoined
14:42:47  <bnoordhuis>the llvm blog had an interesting blog post about register allocation sometime ago
14:43:08  <indutny>bnoordhuis: well, mraleph recommended a good article
14:43:26  <indutny>bnoordhuis: http://www.christianwimmer.at/Publications/Wimmer04a/
14:43:29  <bnoordhuis>http://blog.llvm.org/2011/09/greedy-register-allocation-in-llvm-30.html <- that one
14:43:53  <bnoordhuis>ah right, i think i've read that paper
14:44:29  <indutny>bnoordhuis: nice!
14:44:51  <indutny>I'm really blocked by this stuff atm, actually
14:44:57  <tjfontaine>llvm++
14:44:57  <kohai>llvm has 1 beer
14:45:01  <indutny>had already tried two different implementations
14:49:59  * hij1nxjoined
15:01:21  <CIA-108>libuv: Bert Belder master * r048422d / (src/win/winapi.c src/win/winapi.h): windows: fix some comments - http://git.io/i_ugig
15:01:21  <CIA-108>libuv: Bert Belder master * rb7e150e / src/win/process.c : windows: uv_kill() should report UV_ESRC when the victim is already dead - http://git.io/oPCIFQ
15:01:41  * hij1nx_joined
15:03:40  * hij1nxquit (Ping timeout: 265 seconds)
15:03:41  * hij1nx_changed nick to hij1nx
15:06:50  <piscisaureus_>any objections to upgrading libuv in node
15:06:51  <piscisaureus_>?
15:06:55  <piscisaureus_>bnoordhuis, indutny ?
15:07:58  <indutny>+1
15:08:07  <indutny>what about that uv_read_start issue?
15:08:09  * travis-cijoined
15:08:09  <travis-ci>[travis-ci] joyent/libuv#406 (master - b7e150e : Bert Belder): The build passed.
15:08:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/84f0d96ae04b...b7e150ee917c
15:08:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1602138
15:08:09  * travis-cipart
15:08:13  <piscisaureus_>I will treat bnoordhuis' silence as a yes
15:08:22  <indutny>piscisaureus_: we need some fixes for it
15:08:22  * loladirojoined
15:08:29  <CIA-108>node: Bert Belder master * rb615077 / (33 files in 7 dirs): uv: upgrade to b7e150ee - http://git.io/Imn3OQ
15:08:31  <indutny>piscisaureus_: even if they'll be trivial and incomplete
15:08:45  <piscisaureus_>indutny: yes. I need 23 other fixes as well
15:08:46  <piscisaureus_>this helps
15:10:26  <indutny>:)
15:10:30  <indutny>exactly 23?
15:10:32  <indutny>piscisaureus_: ^
15:10:44  <piscisaureus_>indutny: yes, actually :-)
15:11:01  <piscisaureus_>indutny: well, I have 23 tests to fix, that is :-0
15:11:15  <indutny>hahahaha
15:11:55  * loladiroquit (Read error: Connection reset by peer)
15:12:00  * loladiro_joined
15:12:45  * toothrjoined
15:14:53  * \toothrotquit (Ping timeout: 240 seconds)
15:15:31  * pieternjoined
15:17:29  * hij1nxquit (Quit: hij1nx)
15:22:45  * \toothrotjoined
15:23:53  * toothrquit (Ping timeout: 240 seconds)
15:39:55  * benviequit
15:48:02  * ericktjoined
15:55:19  * brsonjoined
15:55:42  * ericktquit (Remote host closed the connection)
15:56:02  * ericktjoined
16:04:49  <piscisaureus_>isaacs: yt?
16:05:09  <isaacs>yo
16:05:36  <piscisaureus_>isaacs: nvm, I am going to comment on the issue anyway
16:05:46  <isaacs>heh :)
16:11:18  * creationixpart
16:14:26  <piscisaureus_>isaacs: https://github.com/joyent/node/issues/3409#issuecomment-6274853
16:19:46  <isaacs>piscisaureus_: so, i'm taking a look at listenfd
16:19:55  <piscisaureus_>isaacs: cool
16:19:56  <isaacs>if I create a new TTYWrap, it seems to want to be either readable or not.
16:20:10  <isaacs>how strict is that is_readable flag?
16:20:25  * mralephjoined
16:20:26  <piscisaureus_>isaacs: very :-)
16:20:28  <piscisaureus_>isaacs: why ?
16:20:41  <piscisaureus_>isaacs: it is either readable or writable
16:20:44  <isaacs>well... should the server's fd be readable...?
16:20:45  <isaacs>or not?
16:20:52  <isaacs>isn't it duplex always?
16:21:01  <piscisaureus_>isaacs: huh, you should never create a new TTYWrap
16:21:22  <piscisaureus_>isaacs: oh - right
16:21:24  <isaacs>oh, i completely misread your comment
16:21:25  <piscisaureus_>ghe
16:21:27  <piscisaureus_>good question
16:21:33  <isaacs>TcpWrap, not TtyWrap
16:21:43  <isaacs>but yes, if guessHandleType returns 'TTY', then what?
16:21:47  <isaacs>i guess we can just throw.
16:22:10  <piscisaureus_>isaacs: well, TTY handles are not usable, so yeah you could just throw
16:22:22  <isaacs>k
16:22:23  * \toothrotchanged nick to toothr
16:22:49  <piscisaureus_>isaacs: I suppose the readability of writability of a tty wrap could be detectable tho... maybe we should add that
16:22:58  <piscisaureus_>no hurry tho :-)
16:42:36  <isaacs>piscisaureus_: the pipe_wrap listen({fd}) is pretty straightforward. i don't actually see any way to bind a TcpWrap to a fd, though...
16:43:02  <piscisaureus_>heh
16:43:05  <piscisaureus_>there may not be one
16:43:41  <piscisaureus_>isaacs: add an issue to expose uv_tcp_open to libuv
16:43:53  <isaacs>is that already in libuv? or no?
16:44:05  <piscisaureus_>isaacs: I am sure there are internal methods for it - but it's probably not part of the public api
16:44:12  <piscisaureus_>so we just need to expose uv_tcp_open
16:44:16  <isaacs>k
16:45:14  * stephankjoined
16:46:51  <isaacs>yeah, no uv_tcp_open in libuv atm
16:48:49  * benviejoined
17:00:07  * loladirojoined
17:02:04  * loladiro_quit (Ping timeout: 244 seconds)
17:08:53  * TooTallNatejoined
17:10:03  <piscisaureus_>hmm
17:10:08  <piscisaureus_>I fucked something up guys
17:10:19  <piscisaureus_>I'm going to have to force push node
17:10:31  <isaacs>uh oh
17:10:34  <isaacs>what happened?
17:10:48  <piscisaureus_>isaacs: I accidentally committed a wrong file together with an uv upgrade
17:11:02  * japjjoined
17:11:08  <isaacs>can you revert the whole commit and then do it as two commits?
17:11:18  <isaacs>ie, how "wrong" is the file?
17:11:28  <piscisaureus_>well, it's just a test
17:11:57  <isaacs>that doesn't sound so bad. just git rm it and push a fix.
17:12:07  <isaacs>force pushes are kind of unpleasant in a shared repo
17:12:21  <isaacs>on master anyway
17:13:35  <indutny>force pushes make kittens cry
17:13:39  <indutny>in my house
17:13:44  <indutny>especially when I do rebases
17:13:45  <japj>isaacs: hi, I am unable to build node 0.7.10 on windows (from the tar.gz released, aswell as the master git tree)
17:13:57  <japj>indutny: oh, how many kittens do you have?
17:14:02  <indutny>japj: two
17:14:08  <japj>indutny: I have only one cat, and he is from 1993
17:14:09  <indutny>one big kitten and one small
17:14:20  <indutny>well, my first cat is from 2010
17:14:21  <isaacs>japj: add "nosnapshot" to the build comand
17:14:29  <CIA-108>node: isaacs v0.7.10-fix * r427662c / (40 files in 13 dirs): Do not gitignore npm's node_modules - http://git.io/GYXauQ
17:14:29  <isaacs>japj: mksnapshot is busted atm
17:14:35  <japj>isaacs: is that new?
17:14:36  <japj>ah
17:14:40  <isaacs>japj: it's new-ish
17:15:00  <japj>I was wondering, since It used to work without any issues
17:15:13  <japj>and I got slightly worried ;)
17:17:17  * isaacsquit (Remote host closed the connection)
17:24:40  * hij1nxjoined
17:30:02  * igorzijoined
17:32:43  * paddybyersjoined
17:37:08  * isaacsjoined
17:39:13  * hij1nxquit (Read error: Connection reset by peer)
17:40:55  <piscisaureus_>as erik corry just said
17:40:56  <piscisaureus_>Erik Corry: My God, it's full of slowness!
17:40:56  <piscisaureus_>Erik Corry: 3.9 gives me 6420/s
17:40:56  <piscisaureus_>Erik Corry: Bleeding edge gives me 5548/s
17:40:56  <piscisaureus_>Erik Corry: SOMEONE SHOULD FIX THIS
17:41:00  <piscisaureus_>:-)
17:41:04  <piscisaureus_>^-- awareness
17:41:16  <japj>hehe ;)
17:41:37  <japj>is node the new v8 benchmark now?
17:41:47  <piscisaureus_>I don't think so
17:42:48  <japj>anyway, before I head off to big band rehearsal for the evening.. is the v0.8 milestone list still up to date? https://github.com/joyent/node/issues?milestone=10&page=1&state=open I can have a look at 3099 if it is still relevant for 0.8
17:43:02  * hij1nxjoined
17:43:43  <isaacs>hahah
17:43:45  <isaacs>piscisaureus_: that's awesome
17:44:07  <isaacs>we should make it easier to swap out the v8 that node uses, just so that the v8 team can make sure that all their releases are awesome for us
17:44:09  <AvianFlu>yeah, srsly, lol
17:46:20  * loladiroquit (Read error: Operation timed out)
17:46:47  * loladirojoined
17:48:19  <piscisaureus_>it's not hard
17:48:23  <piscisaureus_>rm -rf deps/v8
17:48:39  <piscisaureus_>ls -s deps/v8 ~/v8-latest
17:48:50  <tjfontaine>*ln
17:48:55  <piscisaureus_>yeah
17:49:01  <piscisaureus_>and reverse the argumetns :-)
17:49:06  <tjfontaine>heh that too
17:51:30  * brsonquit (Ping timeout: 248 seconds)
17:52:15  * paddybyersquit (Quit: paddybyers)
17:52:36  <TooTallNate>japj: re #3099… i've been holding off since nobody has been asking for it specifically
17:52:43  <TooTallNate>we may push it back to v0.9
17:56:49  * dapjoined
17:57:11  <CIA-108>node: Bert Belder master * rcbeeea6 / (33 files in 7 dirs): Revert "uv: upgrade to b7e150ee" - http://git.io/pizZcQ
17:57:11  <CIA-108>node: Bert Belder master * ra55faea / (32 files in 6 dirs): uv: upgrade to b7e150ee - http://git.io/ygvCqQ
17:58:30  * brsonjoined
17:59:11  <CIA-108>node: Bert Belder reviewme * r486a5b3 / (doc/api/child_process.markdown lib/child_process.js): Fix child_process.kill oddities - http://git.io/5mprZQ
17:59:11  <CIA-108>node: Bert Belder reviewme * r3c283f9 / test/pummel/test-exec.js : test-exec: make it work on Windows - http://git.io/JIayeA
17:59:33  <piscisaureus_>isaacs: ^ can you review the two `reviewme` commits ?
17:59:42  * hithere2joined
18:00:39  * TheJHjoined
18:00:42  <isaacs>piscisaureus_: i'm still not convinced that throwing is better than emitting here.
18:01:08  * hij1nxquit (Read error: Connection reset by peer)
18:01:23  <isaacs>it's an error connected to a specific node object. if there are no listeners, it throws just the same.
18:01:37  * hij1nxjoined
18:01:43  <isaacs>it seems like it'd be good to at least have the *option* to handle that in the idiomatic node way
18:03:27  * loladiro_joined
18:05:00  * dapquit (Quit: Leaving.)
18:05:29  <piscisaureus_>isaacs: if that's true, then I think spawn() should also emit
18:05:50  * hij1nxquit (Read error: Connection reset by peer)
18:05:52  <piscisaureus_>isaacs: and `kill` should emit error asynchronously
18:06:04  <piscisaureus_>isaacs: which will make it uncatchable again
18:06:42  <isaacs>well, i mean, just change the throw with .emit("error")
18:06:51  <isaacs>the try/catch is still valid
18:06:54  * loladiroquit (Ping timeout: 252 seconds)
18:06:54  * loladiro_changed nick to loladiro
18:07:38  <isaacs>we throw in ctors, emit in methods
18:08:02  <isaacs>but i can see it's an edge case
18:08:06  <isaacs>how did v0.6 do it?
18:08:21  <isaacs>v0.6 threwq.
18:08:29  <isaacs>k. whatever. throw is fine, i guess. lgtm :)
18:08:47  <piscisaureus_>isaacs: if that changed, lemme look up the commit
18:09:06  <isaacs>i think it might've been changed because of some cluster thing that's no longer relevant here, iirc.
18:09:54  <piscisaureus_>https://github.com/joyent/node/commit/5b43c63c88ae191ca3a4b1b3d1a57222593c7f9c
18:10:19  <isaacs>5b43c63c yeah
18:10:38  <isaacs>sometimes commits are a bit TOO atomic ;)
18:11:07  <piscisaureus_>It lacks reasoning
18:11:54  <isaacs>i think it was AndreasMadsen's response to my suggestion that some other throws ought to have been error emits
18:12:31  <isaacs>and he said, "What about this one!?" and i said, "sure, lgtm" because in this case the reasoning for throw or emit isn't so clear.
18:12:38  <piscisaureus_>It seems I will ahve to fix the test
18:12:49  <piscisaureus_>isaacs: I do not agree in this case, as you already noticed
18:12:53  <isaacs>hahah
18:13:07  <isaacs>and i'm capable of convincing myself in either direction, as you have no doubt noticed ;)
18:13:27  * dapjoined
18:13:55  <isaacs>in general, emit('error') is better for things that are: 1. tied to a specific object, 2. asynchronously triggered, and 3. outside the control of the programmer.
18:14:07  <isaacs>if you call something with the wrong data types, throw immediately.
18:14:21  <isaacs>but if something that works most of the time suddenly fails once in a blue moon, that's an event
18:14:29  <piscisaureus_>yes
18:14:38  <isaacs>child.kill('SIGKILL') *usually* works.
18:14:46  <isaacs>and it's not really up to you to make it work if it doesn't
18:14:56  * isaacsworking on convincing myself the other direction, watch out...
18:14:57  <piscisaureus_>well, the question is usually what you would do next
18:15:17  <isaacs>in this case, i may want to know that the child didn't get my message.
18:15:22  <piscisaureus_>normally in an error situation you would say, "okay, it's broken, let's clean it up"
18:15:29  <isaacs>ie, sometimes you kill('SIGUSR2') to get it to do something
18:15:34  <piscisaureus_>yes
18:15:44  <piscisaureus_>otherwise I would have made kill ignore it altogether :-)
18:15:45  <isaacs>if i get a ESRC there, i want to know about it, and it's tied to an object, somewhat outside of my control, etc.
18:15:48  <isaacs>that's a message.
18:15:52  <isaacs>try/catch feels wrong here.
18:16:13  <isaacs>and for exec()'s use-case, emit('error') is just as good, since nothing will be listening, and it'll throw
18:16:19  <piscisaureus_>isaacs: so the problem is, how would you clean up your child process when error happens
18:16:31  <isaacs>maybe i'd have to know to spawn a new one, or delete some files, or whatever.
18:16:33  <isaacs>that's app-specific
18:16:41  <isaacs>but *that* child is no longer doing his job as i expect.
18:16:48  <isaacs>"doing his job" might be shutting down
18:16:48  <piscisaureus_>isaacs: well, yeah, maybe you;d want to kill the process :-)
18:16:51  <isaacs>but it might also be something else.
18:17:06  <piscisaureus_>isaacs: so you cannot kill it because when you do, you will just trigger another error event
18:17:15  <isaacs>unix signals are the worst design api in unix.
18:17:21  <isaacs>they try to do way too much
18:17:41  <tjfontaine>and it doesn't matter if they're in uninterruptible sleep anyway
18:17:42  <isaacs>it would've been good to have signals be one thing, and "shut down this process" be a completely different thing.
18:18:02  <isaacs>but anyway...
18:18:22  <piscisaureus_>isaacs: okay
18:18:28  <isaacs>maybe we mark that the ChildProcess had a kill error, and if you try to kill it and it fails, and it already has a kill error, we just return
18:18:31  <piscisaureus_>error event it wil be
18:18:44  <isaacs>piscisaureus_: how do you feel about a "i had an error with kill" flag?
18:18:56  <isaacs>just to prevent the child.on('error', function (er) { log(er); child.kill() })
18:20:08  <isaacs>none of the errors that kill raises can be fixed by killing again, anyway.
18:20:18  <isaacs>so if you've gotten an error from kill(), then kill() should now be a noop
18:20:53  * japjquit (Ping timeout: 240 seconds)
18:20:56  <piscisaureus_>well :-)
18:21:18  <piscisaureus_>isaacs: one failed kill doesn't mean the next will fail
18:21:22  <bnoordhuis>back
18:22:07  <piscisaureus_>isaacs: some signals will trigger ENOSYS on windows ;_0
18:22:14  <isaacs>piscisaureus_: according to man 2 kill on osx, ubuntu, centos, and smartos, it can only raise ESRCH, EINVAL, or EPERM.
18:22:22  <isaacs>oh, right, I forgot about The Moon.
18:22:47  <isaacs>ok, so, if we get an ESRCH or EPERM or EINVAL, then this.kill = function () {}?
18:23:45  <piscisaureus_>isaacs: ok. so here are the meanings:
18:23:45  <piscisaureus_>ESRC -> the child process is dead.
18:23:45  <piscisaureus_>EPERM -> no access. should never happen with child processes that we spawned ourselves.
18:23:45  <piscisaureus_>ENOSYS/EINVAL -> the signal is not supported on this platform. Should throw synchronously
18:24:07  <isaacs>piscisaureus_: sure.
18:24:16  <isaacs>piscisaureus_: eperm CAN happen, but omg desert island rare bs condition.
18:24:29  <isaacs>piscisaureus_: if the child dies, and the machine is spawning a lot of processes, eventually the pid will be reused.
18:24:49  <isaacs>so the pid could come to refer to some process not owned by uid
18:24:58  <isaacs>should be treated like esrch
18:25:05  <piscisaureus_>isaacs: if the child dies, then node will emit an `exit` event and kill() will turn into a no-op
18:25:20  <isaacs>piscisaureus_: right. i'm assuming that somehow that didn't work.
18:25:28  <piscisaureus_>isaacs: no
18:25:32  <isaacs>it's safe to ignore.
18:25:40  <piscisaureus_>isaacs: and the pid can't be reused until we reaped the child
18:25:50  <piscisaureus_>isaacs: so EPERM kan never happen
18:25:56  <piscisaureus_>isaacs: so actually, I'm thinking
18:26:02  <piscisaureus_>kill() should just return bool
18:26:06  <isaacs>what about if the process does setuid() to some other uid?
18:26:15  <piscisaureus_>oh, that I do not know
18:26:17  <piscisaureus_>bnoordhuis: ?
18:26:20  <bnoordhuis>you'll get EPERM
18:26:34  <isaacs>right, unless you'er uid=0, which on most systems you have to be to do setuid, but not all.
18:26:42  <bnoordhuis>though you (almost) always have to be root in order for setuid to work
18:26:44  <isaacs>on sunos you could enable that specific permission
18:27:19  <bnoordhuis>yes, linux has a capability for that
18:27:36  <isaacs>so, imo, we should probably not assume that eperm can't happen
18:27:41  <isaacs>even though it's crazy rare
18:27:49  <isaacs>the reaping case, yes, that is rare enough to ignore.
18:27:58  <isaacs>and maybe impossible, or an OS bug if it does happen :)
18:28:21  * brsonquit (Quit: leaving)
18:28:29  <piscisaureus_>isaacs: ok.
18:28:35  <isaacs>piscisaureus_: should ENOSYS be treated like EINVAL?
18:28:38  <isaacs>when does that happen?
18:28:43  <piscisaureus_>isaacs: on windows
18:28:52  <piscisaureus_>isaacs: process.kill(process.pid, 'SIGABRT')
18:28:58  <isaacs>ok
18:29:02  * brsonjoined
18:29:15  <isaacs>maybe we shouldn't try to pre-filter the signals, and just let the OS tell us what it can and can't handle.
18:29:16  <piscisaureus_>isaacs: SIGABRT is defined but we have no way to inject that into a process
18:29:24  <isaacs>if we get an EINVAL or ENOSYS then we throw it
18:29:29  <isaacs>because your program is doing a wrong thing
18:29:37  <piscisaureus_>ignore ESRC
18:29:45  <piscisaureus_>in the case of child process
18:29:54  <piscisaureus_>and emit EPERM
18:30:27  <piscisaureus_>that makes sense
18:30:32  <isaacs>so, kill() raising ESRCH can only happen via race condition, correct? the child has died, but the 'exit' event hasn't happened yet?
18:30:37  <piscisaureus_>yes
18:30:48  <piscisaureus_>isaacs: not true for process.kill(pid) of course
18:30:49  <isaacs>oh, wait:
18:30:50  <isaacs> [ESRCH] The process id was given as 0, but the sending process does not have a process group.
18:31:14  <piscisaureus_>isaacs: for child_process.kill you don't specify a pid
18:31:19  <isaacs>so, yeah, child_process.kill() should ignore ESRCH
18:31:20  <isaacs>youer' right
18:31:44  <isaacs>process.kill should probably just, i dunno... throw everythign?
18:31:53  <piscisaureus_>yes, it already does
18:31:55  <isaacs>kewl.
18:32:12  <isaacs>child.kill() ==> ESRCH, ignore; EPERM: emit; EINVAL,ENOSYS: throw
18:33:42  <isaacs>commute time. bbiab
18:34:04  * isaacsquit (Remote host closed the connection)
18:39:12  <piscisaureus_>https://chromiumcodereview.appspot.com/9844025 <-- the culprit
18:45:32  * paddybyersjoined
18:53:38  * hij1nxjoined
18:53:47  * loladiroquit (Ping timeout: 244 seconds)
18:55:49  * iraquit (Quit: Textual IRC Client: http://www.textualapp.com/)
18:56:39  * loladirojoined
19:00:52  * avalanche123joined
19:03:49  * isaacsjoined
19:08:46  * loladiroquit (Quit: loladiro)
19:11:55  * loladirojoined
19:12:02  * mikealjoined
19:12:25  <piscisaureus_>bnoordhuis: is it possible to kill process 0 on unix (when you're root)
19:12:35  <piscisaureus_>bnoordhuis: e.g. can I write a test that does kill(0) ?
19:13:06  <tjfontaine>pid 1 is usually init, I have no idea what 0 would be
19:13:09  <bnoordhuis>piscisaureus_: it's process 1 but no, you can't
19:13:48  <bnoordhuis>you can however send a SIGSTOP to init
19:14:01  <bnoordhuis>which is awesome because it will no longer reap zombie processes
19:14:05  <piscisaureus_>bnoordhuis: will I get EPERM when I try ?
19:14:30  <piscisaureus_>Yeah I never got why it rapes zombies anyway
19:14:35  <bnoordhuis>haha
19:14:41  <bnoordhuis>typo?
19:14:45  <tjfontaine>heh
19:14:54  <tjfontaine>necrophiliac that damn init
19:15:07  <tjfontaine>is there a term for having sex with the undead?
19:15:17  <CIA-108>node: Bert Belder reviewme * r4df98b9 / test/pummel/test-exec.js : test-exec: make it work on Windows - http://git.io/blZuPQ
19:15:17  <CIA-108>node: Bert Belder reviewme * r8fe8cd5 / (lib/child_process.js src/node.js): Fix child_process.kill oddities - http://git.io/scwFEg
19:16:21  <bnoordhuis>i wonder if rule 34 applies here
19:16:28  <tjfontaine>almost certainly
19:16:35  <bnoordhuis>piscisaureus_: to answer your question, you should get an EPERM
19:17:53  <piscisaureus_>bnoordhuis: good
19:17:56  <CIA-108>node: Bert Belder reviewme * r76e20fd / (lib/child_process.js src/node.js): Fix child_process.kill oddities - http://git.io/Rh21Ew
19:18:04  <piscisaureus_>bnoordhuis: and on broken platforms, you will get a kernel panic
19:18:06  <piscisaureus_>awesome
19:18:30  <tjfontaine>did you just panic your system then?
19:20:18  <piscisaureus_>tjfontaine: well, on windows the system process has pid 4
19:20:20  <piscisaureus_>:-p
19:20:23  <tjfontaine>heh
19:20:24  <piscisaureus_>and I get EPERM as well
19:20:34  <piscisaureus_>pid 0 == inactive system processes
19:20:39  <piscisaureus_>but I get ESRC
19:22:10  <bnoordhuis>piscisaureus_: kill(0, sig) sends a signal to all the processes in the process group
19:22:17  <isaacs>kill(0) kills hte process group
19:22:21  <isaacs>process leader
19:22:23  <bnoordhuis>hah, beat you!
19:22:25  <isaacs>you did :)
19:22:38  <isaacs>if you're not in a process group, then it's ESRCH
19:23:18  <piscisaureus_>ah, still here isaacs :-)
19:23:26  <piscisaureus_>isaacs: ^-- second try
19:23:26  <isaacs>back, actually
19:23:36  <isaacs>about to go get lunch, though
19:25:32  <isaacs>brb
19:25:43  <isaacs>isn't child.stdout/err sometimes null, if it's set to 'ignore'?
19:26:09  <CIA-108>node: Bert Belder reviewme * r4fc42c4 / (lib/child_process.js src/node.js): Fix child_process.kill oddities - http://git.io/BccCNg
19:26:18  <piscisaureus_>isaacs: not when you use `exec`
19:30:59  * hij1nxquit (Ping timeout: 246 seconds)
19:36:14  * hij1nxjoined
19:36:48  <piscisaureus_>ok, I am going to take a break
19:37:07  <piscisaureus_>bnoordhuis: will you @ keizersgracht this week?
19:41:46  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:42:22  * felixgequit (Quit: http://www.debuggable.com/)
19:44:53  * hithere2changed nick to hithere
19:45:38  * indutnytopic: Release early, rape zombies
19:49:25  <bnoordhuis>indutny: haha :)
19:53:28  <CIA-108>node: Ben Noordhuis v0.6 * re6339cc / (src/node_crypto.cc test/simple/test-crypto.js): crypto: make cipher/decipher accept buffer args - http://git.io/VZhjbA
19:53:38  <CIA-108>node: Ben Noordhuis master * r900196e / (src/node_crypto.cc test/simple/test-crypto.js): crypto: make cipher/decipher accept buffer args - http://git.io/fLuq1w
19:54:39  <bnoordhuis>hrm, maybe that shouldn't have landed in v0.6...
19:55:27  <bnoordhuis>and gone it is
19:59:33  * igorzi_joined
20:00:21  * igorziquit (Ping timeout: 245 seconds)
20:02:06  * piscisaureus_joined
20:03:00  * mikealquit (Quit: Leaving.)
20:03:32  * mikealjoined
20:06:53  <CIA-108>node: Ben Noordhuis master * r8963a52 / doc/api/crypto.markdown : doc: update crypto cipher/decipher docs - http://git.io/436x_w
20:14:15  <pquerna>philips: https://github.com/joyent/libuv/pull/466
20:17:21  <piscisaureus_>would also need uv_get_poll_timeout to be exposed (and possibly renamed)
20:21:56  <philips>bnoordhuis: piscisaureus_ : I would love to review the API you plan to build
20:22:30  <bnoordhuis>oh, i just closed that PR
20:23:01  <bnoordhuis>philips: i'm undecided on the actual names but let's go with uv_poll_fd(loop) and uv_poll_timeout(loop) for now
20:23:12  <AvianFlu>piscisaureus_, btw, isn't it ESRCH and not ESRC?
20:23:20  <bnoordhuis>philips: it's TBD what unit of time the timeout should be
20:23:20  <piscisaureus_>AvianFlu: you are probably riht
20:23:25  <piscisaureus_>*right
20:23:32  <bnoordhuis>it is
20:23:33  <philips>I really want to integrate libuv in an Core Foundation event loop so I can build OSX apps in luvit
20:23:44  <piscisaureus_>hey, I've heard that before
20:24:01  <piscisaureus_>philips: yes, you'd need the timeout
20:24:13  <bnoordhuis>philips: also... what does core foundation use to poll?
20:24:15  <philips>piscisaureus_: Yea, for sure
20:24:25  <philips>bnoordhuis: you can use a kqueue to wake the loop up
20:24:26  <bnoordhuis>kqueue is kind of notorious for not being very embeddable
20:24:29  <philips>bnoordhuis: and a timer of course
20:24:53  <philips>bnoordhuis: dirty hack I did to test it out: https://github.com/philips/eventloops/blob/master/osx.c#L50
20:25:36  <bnoordhuis>philips: right. it works?
20:25:43  <piscisaureus_>philips: if you do it like that uv_timer and uv_idle won't work
20:25:58  <philips>bnoordhuis: seems to but I need timers too
20:26:04  <philips>bnoordhuis: well, the next timeout needed
20:26:25  <philips>piscisaureus_: yea, I need the next timeout time, right?
20:26:35  <piscisaureus_>philips: yep
20:27:12  <piscisaureus_>philips: and you probably need to set the "process only one event" flag when you call CFRunLoopRunInMode
20:27:39  <piscisaureus_>philips: or, you have to be sure that you never start/change an uv_timer from a callback made by CF
20:29:04  <philips>piscisaureus_: oh, right. Would have to mutex timer manipulation and run_once
20:29:35  <piscisaureus_>philips: well, that's one way
20:29:40  <piscisaureus_>philips: what you could also do
20:30:10  <piscisaureus_>* create an CFSocket or whatever, the CF equivalent of uv_poll with the kqueue fd in it, and a dummy callback
20:30:28  <piscisaureus_>* call CFRunLoopRunInMode from an uv_prepare callback
20:30:29  <isaacs>bnoordhuis: buffers in crypto!!! \o/
20:30:32  <isaacs>w00t
20:31:10  <bnoordhuis>isaacs: that's only a partial fix though :) there are probably other places where buffers should work but don't
20:31:23  <piscisaureus_>philips: then just use uv_run to drive the loop :-)
20:31:57  <isaacs>bnoordhuis: sure.
20:32:09  <isaacs>bnoordhuis: btw, any chance of getting ev_* shimmed by thursday?
20:32:21  <isaacs>bnoordhuis: i wanna get 0.7.11 out asap
20:33:06  <bnoordhuis>isaacs: er, maybe. i'm almost done with getting rid of libev, which would make shimming ev_io and friends a lot easier
20:33:37  <bnoordhuis>biab
20:33:44  <isaacs>bnoordhuis: k. please keep me posted. people are awaiting it eagerly.
20:34:46  * creationixjoined
20:41:47  <CIA-108>node: Bert Belder reviewme * r7392362 / (lib/child_process.js src/node.js): Fix child_process.kill oddities - http://git.io/HH3_tw
20:41:48  <CIA-108>node: Bert Belder reviewme * reeffde7 / test/simple/test-child-process-kill.js : test-child-process-kill: make it pass on windows - http://git.io/a6X4Ew
20:42:08  <piscisaureus_>^-- AvianFlu: fixed the ESRC(H)
20:42:43  * loladiroquit (Read error: Connection reset by peer)
20:42:49  * loladiro_joined
20:43:07  * loladiro_changed nick to loladiro
20:44:31  <piscisaureus_>How do I build node-weak for the gc tests?
20:44:50  <isaacs>piscisaureus_: make node_modules/weak
20:44:56  <isaacs>piscisaureus_: oh, on windows?
20:45:00  <piscisaureus_>yes
20:45:07  <piscisaureus_>all those tests are failing right now
20:45:19  <isaacs> @if [ ! -f node ]; then make all; fi
20:45:19  <isaacs> @if [ ! -d node_modules ]; then mkdir -p node_modules; fi
20:45:19  <isaacs> ./node deps/npm/bin/npm-cli.js install weak \
20:45:21  <isaacs> --nodedir="$(shell pwd)" \
20:45:23  <isaacs> --prefix="$(shell pwd)" --unsafe-perm # go ahead and run as root.
20:45:48  <piscisaureus_>aha
20:45:56  <piscisaureus_>that's not working on windows eh
20:46:18  <isaacs>mkdir /p node_modules ; Release\node.exe deps\npm\bin\npm-cli.js install weak --nodedir="..cwd.." --prefix="..cwd.."
20:46:28  <isaacs>i don't recall how to get the cwd in a cmd script
20:46:37  <piscisaureus_>echo %~dp0
20:46:39  <isaacs>~0db%
20:46:42  <isaacs>oh, ah, right
20:46:53  <isaacs>what does that mean, btw?
20:46:54  <piscisaureus_>alright
20:47:04  <isaacs>did someone's cat step on the keyboard, and they decided that would be the token?
20:47:07  <isaacs>does dp stand for something?
20:47:16  <piscisaureus_>isaacs: %0 == argv[0]
20:47:27  * brsonquit (Ping timeout: 244 seconds)
20:47:31  <isaacs>directory prefix?
20:47:36  <piscisaureus_>isaacs % (~options) 0
20:47:45  <piscisaureus_>dp means directory path or something
20:47:49  <isaacs>oh, right, dir path
20:47:51  <isaacs>neat.
20:47:56  <isaacs>are these options written down somewhere?
20:48:07  * mraleph1joined
20:48:22  <piscisaureus_>isaacs: no, drive path actually
20:48:43  <piscisaureus_>isaacs: so d expands to c:\ and p expands to Users\blabla\node
20:48:57  <piscisaureus_>isaacs: try `for /?`
20:49:13  <piscisaureus_>(and skip to page 4 or so)
20:49:44  <piscisaureus_>isaacs: or here: http://technet.microsoft.com/en-us/library/bb490909
20:50:11  <isaacs>neat
20:51:37  * loladiroquit (Read error: Connection reset by peer)
20:51:43  * loladiro_joined
20:52:45  <TooTallNate>why wouldn't the `npm install weak` work on windows?
20:52:57  <TooTallNate>piscisaureus_: what happens?
20:53:30  <piscisaureus_>TooTallNate: well, I don't know
20:53:38  <isaacs>TooTallNate: probably because node and npm aren't installed, or there's no node_modules folder already
20:53:55  <piscisaureus_>TooTallNate: but I don't like that I have to do that to make `vcbuild test` work
20:54:05  <piscisaureus_>isaacs: do I have to create node_modules upfront
20:54:07  <piscisaureus_>?
20:54:07  <TooTallNate>piscisaureus_: oh, maybe because there's no `./node`, but theres `Release/node`
20:54:21  <isaacs>TooTallNate: oh, another thing: can you send me a pull req that documents the nodedir config?
20:54:22  <piscisaureus_>isaacs: I never do, and it usually works :-)
20:54:37  <isaacs>piscisaureus_: if there's a node_modules folder in ../ then it'll install it there instead.
20:54:44  <piscisaureus_>ah
20:54:51  <TooTallNate>isaacs: sure, though technically *any* node-gyp variable can be specified through npm like that
20:55:04  <isaacs>piscisaureus_: best practice is to create the dir first in this case, since we don't have a package.json, and npm doesn't have any other way to know where your project root is
20:55:05  <piscisaureus_>zet iz not wat whe whant eh
20:55:20  <isaacs>TooTallNate: wanna document all the node-gyp variables in npm's docs, then?
20:55:47  <TooTallNate>isaacs: where should that go exactly (theres lots of .md files :D )
20:56:08  <isaacs>TooTallNate: doc/cli/config.md. the list of options is in alphabetical order.
20:56:17  <TooTallNate>ahh cool. ya i can do that
20:59:03  * japjjoined
20:59:52  * ericktquit (Ping timeout: 240 seconds)
21:01:18  * ericktjoined
21:17:16  * brsonjoined
21:20:05  * loladiro_quit (Read error: Connection reset by peer)
21:20:24  * loladirojoined
21:22:49  * avalanche123quit (Quit: Computer has gone to sleep.)
21:23:43  * \toothrotjoined
21:25:20  <piscisaureus_>isaacs: whenever you have time, review the reviewme branch :-)
21:25:27  <piscisaureus_>isaacs: then I can carry on fixing tests
21:25:58  <isaacs>ok, back to it
21:26:00  <isaacs>call just ended
21:26:06  <piscisaureus_>kewl
21:26:28  * toothrquit (Ping timeout: 245 seconds)
21:29:27  <isaacs>piscisaureus_: + this.killed = true;
21:29:30  * \toothrotchanged nick to toothr
21:29:39  <isaacs>piscisaureus_: so, it's probably outside of the scope here, but why do we set that, exactly?
21:29:55  <piscisaureus_>isaacs: I don't know, but it always was there
21:29:59  <isaacs>piscisaureus_: child.kill('SIGUSR2') would set child.killed = true
21:30:00  <isaacs>yeah
21:30:10  <isaacs>i guess, whatevs, let's leave it
21:30:39  <piscisaureus_>isaacs: that is 0.9 work I suppose
21:30:47  <isaacs>ok, i like it
21:30:48  <isaacs>lgtm
21:30:51  <piscisaureus_>good
21:30:53  <piscisaureus_>phew
21:31:17  <isaacs>land it, then make tests pass, or if you find some moments, lmk where to go to add tcp_open
21:31:21  <isaacs>uv_tcp_open
21:31:50  <piscisaureus_>isaacs: yes
21:31:55  <CIA-108>node: Bert Belder master * rb53b8b8 / test/pummel/test-exec.js : test-exec: make it work on Windows - http://git.io/jngf4A
21:31:55  <CIA-108>node: Bert Belder master * r10f85fa / (lib/child_process.js src/node.js): Fix child_process.kill oddities - http://git.io/53UJWQ
21:31:55  <CIA-108>node: Bert Belder master * rb866a96 / test/simple/test-child-process-kill.js : test-child-process-kill: make it pass on windows - http://git.io/d4EGew
21:32:07  <piscisaureus_>isaacs: actually, uv_guess_handle doesn't even detect tcp handles atm
21:32:09  <isaacs>w00t
21:32:16  <piscisaureus_>isaacs: it says they're pipes
21:32:21  <isaacs>piscisaureus_: oh, really?
21:32:29  <piscisaureus_>which probably works 95% btw
21:32:30  <isaacs>i thought they'd get UV_UNKNOWN
21:32:36  <piscisaureus_>no
21:32:38  <isaacs>maybe we can just make listenFD be a pipe thing?
21:32:45  <isaacs>isn't that what it used to be?
21:32:53  <isaacs>(in which case, i'm basically done)
21:33:04  <piscisaureus_>isaacs: umm, well, I think it works 95% now
21:33:13  <piscisaureus_>read/write etc should all work (on unix)
21:33:18  <piscisaureus_>windows doesn't matter
21:33:25  <isaacs>right
21:33:33  <piscisaureus_>isaacs: just the stuff like remoteAddress will probably do something weird
21:33:45  <piscisaureus_>or, that won't work at all
21:33:52  <isaacs>so, i'm tempted to just raise ENOTSUP or something on windows, to be sure.
21:33:53  <piscisaureus_>address() will do something weird
21:33:59  <isaacs>i'd rather that it crash fast than behave oddly
21:34:09  <piscisaureus_>isaacs: when, exactly ?
21:34:20  <piscisaureus_>isaacs: if windows says it's a pipe, it is really a pipe
21:34:21  <isaacs>Server.listen({fd:3}) <-- throws on windows
21:34:31  <piscisaureus_>windows will tell you fd 3 is unknown otherwise
21:34:34  <isaacs>right
21:34:38  <piscisaureus_>so you should probably throw when that happens
21:34:45  <isaacs>but listening on a pipe, is that going to be weird on windoes?
21:34:51  <piscisaureus_>umm
21:34:52  <isaacs>let's assume for the moment it's only pipes that we care about
21:34:55  <piscisaureus_>yeah
21:35:03  <piscisaureus_>you'll probably get EISCONN :-)
21:35:11  <isaacs>hm.
21:35:14  <piscisaureus_>so, whatever you think is right
21:35:21  <isaacs>for now, let's unix philosophy this shit.
21:35:34  <isaacs>just try and do what we need to do, and see what yells at us.
21:35:43  <piscisaureus_>yeah
21:35:47  <isaacs>node is not your mommy.
21:35:48  <piscisaureus_>I will try it once you land it
21:35:54  <isaacs>k
21:36:02  <piscisaureus_>and fix libuv if it should do something it doesn't atm
21:36:27  * piscisaureus_continues cooking
21:36:36  * irajoined
21:39:17  <igorzi_>piscisaureus_: hey
21:39:20  <igorzi_>piscisaureus_: pls review the ETW patch: https://github.com/igorzi/node/commit/ae3737a0f1bd8ba16917f8750bf808eedb0e100f
21:43:44  * paddybyersquit (Quit: paddybyers)
21:44:19  * ericktquit (Quit: erickt)
21:47:09  * paddybyersjoined
21:50:44  <isaacs>hmmm...
21:50:54  <isaacs>i'm having a bit of trouble coming up with a portable use case here.
21:51:16  <isaacs>all the uses for listenfd that i can find are either handled better with cluster, or are very illumos-specific
21:53:36  * japjquit (Read error: Connection reset by peer)
21:54:40  * avalanche123joined
21:55:21  * AvianFlupart ("Leaving")
21:55:55  * paddybyersquit (Quit: paddybyers)
21:59:16  <piscisaureus_>yes
21:59:19  <piscisaureus_>illumon--
21:59:19  <kohai>illumon has -1 beer
21:59:26  <piscisaureus_>illumos--
21:59:27  <kohai>illumos has -1 beer
21:59:30  * stephankquit (Quit: *Poof!*)
21:59:38  <piscisaureus_>isaacs: although systemd does something similar I think
21:59:43  <isaacs>yeah
21:59:46  <isaacs>i'm trying out some thigns
21:59:50  <isaacs>i think i'll be able to do it
22:00:03  <isaacs>just would prefer that it be closer to an actual use case so that i know we're getting it right, that's all.
22:00:10  <piscisaureus_>haha
22:00:34  <piscisaureus_>maybe illumos should not do this crazy stuff
22:00:38  <isaacs>ahah
22:00:53  <isaacs>well, they'd just use fork or cluster, except that the fd is being passed between zones
22:01:03  <isaacs>so the processes can only do ipc, they can't actually spawn one anotehr
22:01:11  <isaacs>and that ipc can only be over a socket
22:01:21  <isaacs>making an OS is hard :)
22:01:37  <piscisaureus_>isaacs: well I know a very nice way to do this stuff
22:02:06  <piscisaureus_>net.createConnection(1234, 'the-other-zones-ip'')
22:02:11  <piscisaureus_>^-- isaacs: what about that?
22:02:13  <piscisaureus_>fully portable
22:02:16  * mrb_bkpart
22:02:35  * AvianFlujoined
22:03:00  <dap>piscisaureus_: For a test case, or for our use case? Doesn't work for our use case because you can't auth the other side the way you can with a UDS.
22:04:09  <piscisaureus_>dap: just curious, what if I send a dirfd to over the UDS ?
22:04:29  <piscisaureus_>can I then open files in the other zone's fs (with openat etc?)
22:04:31  <dap>piscisaureus_: Remember that in Unix, you *always* listen on an FD. The only reason illumos is special for this use case is because Node has taken two of the most common cases of that (listening on UDS and TCP sockets) and made them first-class (or special cases, depending on your point of view :), and we've already been using another one.
22:04:51  <dap>piscisaureus_: not sure.
22:06:27  <piscisaureus_>dap: I know you always listen on an fd... but it's rather to listen on an fd that you didn't create yourself
22:06:31  <piscisaureus_>*rather odd
22:06:37  <piscisaureus_>or let's say, uncommon
22:08:16  <piscisaureus_>dap: also, I think read() and write() are the kind of operations that you would do on every fd. listen() is just an oddball thing for sockets.
22:08:39  <dap>What I meant was that Unix made an explicit decision to decouple the source of the fd from uses like bind and listen, precisely so that you could compose them in ways the creators didn't initially consider without having to change the API. I don't think it was an accident that there's no "create tcp socket and listen" function.
22:08:57  <dap>I understand Node's reasons for first-classing those things, of course.
22:09:50  <dap>But if the more primitive model isn't exposed, you can expect to hear from people with use cases you hadn't expected :)
22:10:50  <dap>My point was really just that in the Unix context, it's totally reasonable to listen on an fd you got from some other place — that's how the API is designed.
22:11:01  <dap>In defense of our doing so :)
22:12:52  * demarchipart
22:12:52  <piscisaureus_>dap, ok :-)
22:13:26  <piscisaureus_>dap: what I find very weird about unix is that you have to guess which fds you may have inherited
22:14:09  <piscisaureus_>dap: it would be much nicer to just have
22:14:09  <piscisaureus_>int main(int argc, char* arv[], int fdc, int fdv[]) {
22:16:48  * stephankjoined
22:17:27  <TooTallNate>isaacs: what's up with this missing "npmlog" in v0.7.10?
22:18:50  <piscisaureus_>igorzi_: what's the conceptual difference between etw_provider and win32_etw_provider ?
22:20:22  <AvianFlu>TooTallNate, it was left out of the git tag but not the tarball, there's a second 0.7.10-fix tag or something
22:20:32  <isaacs>TooTallNate: 'node_modules' was added to .gitignore for `make test-gc` to not pollute the repo
22:20:38  <isaacs>TooTallNate: should've been ./node_modules
22:20:47  <isaacs>TooTallNate: fixed on the 0.7.10-fix tag, and the tarball and binaries
22:20:54  <TooTallNate>ahh right
22:21:04  <TooTallNate>isaacs: the tarballs too? how long ago?
22:21:23  <isaacs>TooTallNate: less than an hour after release.
22:21:27  <isaacs>iirc
22:23:13  <TooTallNate>what does that mean?
22:23:13  <TooTallNate>Assertion failed: (!!(events & UV__IO_READ) ^ !!(events & UV__IO_WRITE)), function uv__stream_io, file ../deps/uv/src/unix/stream.c, line 730.
22:23:57  <TooTallNate>^ happens with this script: https://gist.github.com/2920470
22:27:31  <TooTallNate>bnoordhuis: i bet you'll have an idea :D ^
22:27:53  * TheJHquit (Ping timeout: 240 seconds)
22:28:14  <bnoordhuis>TooTallNate: yes. i can probably even fix it
22:28:37  <TooTallNate>bnoordhuis: does that mean libuv bug?
22:29:10  <bnoordhuis>TooTallNate: yes
22:29:23  <TooTallNate>damn :D
22:29:24  <piscisaureus_>it means you're doing something unsupported :-p
22:29:27  <TooTallNate>want me to open an issue?
22:30:27  <piscisaureus_>imo if we would want to support that, the syntax should be
22:30:34  <piscisaureus_>tty.createReadStream() :-)
22:31:07  <TooTallNate>piscisaureus_: agreed :)
22:31:24  <TooTallNate> /dev/tty is literally the only valid thing I can think of that your would pass in though :D
22:31:29  <piscisaureus_>yes
22:31:56  <piscisaureus_>and on w1nd0w5 you would pass in "conin$" or "conout$"
22:32:29  <TooTallNate>well, cool, at least there's an equivalent :D
22:32:38  <piscisaureus_>let's see if that works
22:33:42  * ericktjoined
22:35:14  <TooTallNate>a little background: i'm trying to make `echo "{ foo: 'bar' }" | cdir` work on hij1nx's cdir :D
22:35:24  <bnoordhuis>piscisaureus_: what did we decide about https://github.com/joyent/node/issues/3402 ? set UV_HANDLE_READING flag and start read watcher after connect or listen?
22:35:49  <bnoordhuis>TooTallNate: i kind of consider it a bug. you shouldn't be able to hit that assert
22:36:13  <piscisaureus_>bnoordhuis: fix windows and make uv_read_start possible before connecting
22:36:33  <TooTallNate>bnoordhuis: is there a simple fix?
22:36:52  <bnoordhuis>piscisaureus_: 'fix windows' seems a challenging task...
22:36:58  <bnoordhuis>TooTallNate: yes. don't do that :)
22:37:12  <piscisaureus_>bnoordhuis: yeah, also, it's kinda irrelevant here
22:37:24  <TooTallNate>ya ya :p i think my use-case is fair though
22:37:24  <piscisaureus_>bnoordhuis: however, I am going to fix windows before looking at that bug
22:37:28  <piscisaureus_>see you in two weeks
22:37:43  <bnoordhuis>and that was the last we ever heard of him
22:38:39  <piscisaureus_>damn
22:38:51  <piscisaureus_>suddenly I found myself in the rape zombies channel
22:39:33  <bnoordhuis>TooTallNate: you know, that snippet actually works for me, once i add a require('assert')
22:39:55  <TooTallNate>bnoordhuis: ohh, right...
22:40:01  <TooTallNate>so it's the same issue as before
22:40:46  <TooTallNate>bnoordhuis: https://github.com/joyent/node/issues/3072
22:41:19  <bnoordhuis>TooTallNate: yes
22:41:41  <bnoordhuis>though i don't quite understand what os x does different
22:42:31  <TooTallNate>hmmm, damn
22:43:40  <TooTallNate>bnoordhuis: anything i can do to help debug?
22:45:08  <bnoordhuis>TooTallNate: inspect it in gdb?
22:45:22  <bnoordhuis>the two things to look for are how the fd is added to the pollset
22:45:41  <bnoordhuis>i.e. is it being watched for reading, writing or both
22:46:13  <TooTallNate>does that take more that `bt full`? :p
22:46:21  <bnoordhuis>yes :)
22:47:20  * xaqquit (Read error: Connection reset by peer)
22:47:50  * xaqjoined
22:51:18  * c4miloquit (Remote host closed the connection)
22:56:38  * rendarquit
23:00:24  * loladiroquit (Read error: Connection reset by peer)
23:01:17  * loladirojoined
23:03:14  * loladiroquit (Read error: Connection reset by peer)
23:03:20  * loladiro_joined
23:10:32  <bnoordhuis>piscisaureus_: ping
23:10:49  <piscisaureus_>bnoordhuis: ewa?
23:11:28  * mraleph1quit (Quit: Leaving.)
23:12:11  <bnoordhuis>piscisaureus_: i want to share uv_handle_init() between unix and win
23:12:21  <bnoordhuis>or at least make it accessible
23:12:28  <bnoordhuis>do you want to keep it inlined?
23:13:28  <piscisaureus_>bnoordhuis: it would be nice to keep it inlined, yes
23:13:36  <piscisaureus_>bnoordhuis: also, go ahead
23:13:49  <bnoordhuis>cool
23:14:09  <piscisaureus_>igorzi_: hey, yt?
23:19:47  * loladiro_quit (Quit: loladiro_)
23:19:55  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/c5d62b7
23:22:08  * loladirojoined
23:22:24  * loladiroquit (Client Quit)
23:22:42  <piscisaureus_>bnoordhuis:
23:22:42  <piscisaureus_>#ifdef WIN32
23:22:43  <piscisaureus_>handle->next_closing = NULL;
23:22:45  <piscisaureus_>why ?
23:23:58  <piscisaureus_>bnoordhuis: where does unix keep the endgame queue?
23:24:07  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/blob/84f0d96/src/win/process.c#L1095 <- that looks like a bug
23:24:28  <bnoordhuis>piscisaureus_: why not?
23:24:34  <piscisaureus_>bnoordhuis: how so?
23:24:40  <piscisaureus_>(re the process bug)
23:24:40  <bnoordhuis>what is this endgame queue you speak of?
23:24:53  <piscisaureus_>bnoordhuis: ah, you removed the endgame queue from unix ?
23:24:56  <bnoordhuis>if (stream->type = UV_TTY) { <- assignment, not comparison
23:25:19  <piscisaureus_>h, YES
23:25:37  <bnoordhuis>YES <- that's what she said
23:26:24  <bnoordhuis>piscisaureus_: re that commit, lgty or not?
23:26:57  <piscisaureus_>bnoordhuis: I don't mind you initializing handle->endgame_next
23:27:00  <piscisaureus_>or whatever
23:27:20  <bnoordhuis>is that a lgtm?
23:27:25  <piscisaureus_>bnoordhuis: but I wonder why you don't init the similar-in-purpose list that unix uses
23:27:48  <bnoordhuis>what list?
23:28:08  <bnoordhuis>oh, i understand the confusion :)
23:28:17  <bnoordhuis>read carefully, young grashopper: #ifndef _WIN32
23:28:35  <piscisaureus_>ha!
23:28:39  <piscisaureus_>yes
23:28:42  <piscisaureus_>ok
23:28:43  <piscisaureus_>lgtm
23:28:46  <bnoordhuis>cool :)
23:29:56  <CIA-108>libuv: Ben Noordhuis master * r95e89c6 / (14 files in 3 dirs): unix, windows: share uv__handle_init() - http://git.io/nFEVDg
23:31:39  <CIA-108>libuv: Bert Belder master * r9f44b0e / src/win/process.c : windows: fix serious typo in init_child_stdio - http://git.io/MS0tIw
23:31:53  <piscisaureus_>bnoordhuis: mind if I upgrade libuv in node again?
23:32:04  <bnoordhuis>piscisaureus_: not at all
23:32:30  <piscisaureus_>lemme run the uv tests once more before doing that
23:32:45  <bnoordhuis>that's always a good idea :)
23:33:33  <piscisaureus_>+156 -0
23:33:44  <piscisaureus_>\o
23:37:25  <CIA-108>node: Bert Belder master * re4f4c63 / (14 files in 3 dirs): uv: upgrade to 9f44b0e3 - http://git.io/sOX9rg
23:37:28  <piscisaureus_>Node on windows: 20 failures left
23:39:31  <piscisaureus_>bnoordhuis: do you know what test-eio-limit is supposed to test?
23:39:46  * travis-cijoined
23:39:46  <travis-ci>[travis-ci] joyent/libuv#407 (master - 95e89c6 : Ben Noordhuis): The build passed.
23:39:46  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b7e150ee917c...95e89c6a0efe
23:39:46  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1606032
23:39:46  * travis-cipart
23:40:39  * c4milojoined
23:41:34  * travis-cijoined
23:41:35  <travis-ci>[travis-ci] joyent/libuv#408 (master - 9f44b0e : Bert Belder): The build passed.
23:41:35  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/95e89c6a0efe...9f44b0e393f6
23:41:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1606034
23:41:35  * travis-cipart
23:48:33  <piscisaureus_>aah hmm
23:48:50  <piscisaureus_>node should make inherited stdios non-inheritable
23:51:44  <piscisaureus_>bnoordhuis: hey, what would you prefer:
23:51:44  <piscisaureus_>make all inherited fds noninheritable -
23:51:44  <piscisaureus_>* uv_init() does that automatically, or...
23:51:44  <piscisaureus_>* have some explicit function for that, or...
23:51:44  <piscisaureus_>* have it done by uv_pipe_open / uv_tty_open ?
23:51:44  <piscisaureus_>bnoordhuis: I understand that on unix the problem is kinda different. The likelihood of "accidentally" inheriting a stdio fd is small because generally you would dup2 something else over it. Also, on unix there is no way to tell which fds are inherited.
23:53:34  <bnoordhuis>piscisaureus_: yes. so i don't quite understand the problem :)
23:53:41  <piscisaureus_>bnoordhuis: ok, here's the problem
23:53:48  <piscisaureus_>test-child-process-detached
23:54:04  <piscisaureus_>it spawns a process, which spawns another, which spawns another
23:54:20  <piscisaureus_>bnoordhuis: but the first process never exits
23:54:32  <piscisaureus_>because the child_process.stdout/err streams keep the loop alive
23:54:45  <AvianFlu>piscisaureus_, I noticed that late last night. for some reason if you change process.on('exit') to child.on('exit') it'll work
23:54:49  <piscisaureus_>because they are accidentally inherited by the 3rd process
23:55:04  <AvianFlu>well� it won't hang
23:55:22  <piscisaureus_>AvianFlu: well, I know what the problem is :-)
23:55:38  <piscisaureus_>It has been reported by some microsoft israel guys a couple of months ago actually
23:55:45  <AvianFlu>oh yeah, I remember that issue
23:56:49  <piscisaureus_>I can make the same happen on unix, actually
23:56:56  <piscisaureus_>bnoordhuis: if that helps you understand the problem
23:58:29  <bnoordhuis>piscisaureus_: i'm listening
23:58:38  <bnoordhuis>but i think i got the gist of it
23:59:28  <bnoordhuis>so why does that child process inherit stdio fds in the first place?