00:04:03  * pfox___joined
00:10:02  <piscisaureus_>ok, windows is *really* retarded :-( :-(
00:10:32  * elijah-mbpjoined
00:11:04  <tjfontaine>you're just now coming to this conclusion? :)
00:17:49  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
00:18:47  <piscisaureus_>igorzi_, isaacs: yt?
00:26:22  * mmaleckichanged nick to mmalecki[zzz]
00:28:17  <piscisaureus_>igorzi_: isaacs: https://gist.github.com/1997507
00:28:21  <igorzi_>piscisaureus_: reviewing
00:28:43  <piscisaureus_>igorzi_: yeah, review the patch first, then look at the other gist
00:33:14  * pfox___quit (Ping timeout: 272 seconds)
00:33:35  <igorzi_>piscisaureus_: lgtm
00:33:40  <piscisaureus_>kewl
00:36:17  <igorzi_>piscisaureus_: so should it be statting test/file9 or test2/file9 ?
00:36:28  * paddybyersquit (Quit: paddybyers)
00:36:34  <piscisaureus_>hmm
00:36:38  <piscisaureus_>test2/file9 I think
00:36:40  <isaacs> // Stat test2/file9. This often fails, even if readdirSync reports the file
00:36:40  <isaacs> // is there!
00:36:40  <isaacs> console.log(fs.statSync("test/file9"));
00:36:49  <isaacs>piscisaureus_: should that be stat'ing test2/file9?
00:36:53  <isaacs>or test/file9?
00:37:27  <piscisaureus_>meh
00:37:30  <piscisaureus_>I made a typo
00:37:31  <piscisaureus_>ghe
00:39:14  <piscisaureus_>isaacs: still, that is exactly what is happening for me
00:39:21  <piscisaureus_>isaacs: although that test does not reproduce it
00:45:03  <igorzi_>piscisaureus_: so rename + stat, and stat is failing?
00:45:44  <piscisaureus_>igorzi_: so what I am seeing in npm is that a folder is renamed, but after that stat or open that should be in the new folder fails
00:45:57  <piscisaureus_>igorzi_: readdirSync reports the file is there though
00:46:14  <piscisaureus_>igorzi_: and if I wait for a couple of ms before trying to stat it works fine.
00:46:35  <igorzi_>piscisaureus_: and that only happens with the network share?
00:47:14  <igorzi_>piscisaureus_: that sounds a lot like what we were seeing earlier with antivirus or indexing service locking the file
00:47:14  <piscisaureus_>igorzi_: *shrug* looks like it
00:47:36  <piscisaureus_>igorzi_: yeah but that would not generate ENOENT, plus I have no antivirus on my system
00:48:02  <igorzi_>piscisaureus_: right, that shouldn't be ENOENT.. do you have indexing service running?
00:48:19  <piscisaureus_>igorzi_: yes, but that, too, should not be indexing network shares
00:48:53  <igorzi_>piscisaureus_: maybe something on the remote machine (where the share is located) is locking the file for a few ms
00:49:19  <igorzi_>piscisaureus_: i'll try to run procmon on the remote machine
00:53:37  <igorzi_>4:50:33.4558731 PM MsMpEng.exe 6436 CreateFileMapping C:\public\node_modules\___mkdirp.npm\package\.npmignore FILE LOCKED WITH WRITERS SyncType: SyncTypeCreateSection, PageProtection:
00:53:50  <igorzi_>piscisaureus_: MsMpEng.exe --^
01:00:57  <piscisaureus_>igorzi_: right. But why does it fail for package.json then?
01:01:04  <piscisaureus_>igorzi_: cuz that is what it does for me
01:02:18  <igorzi_>piscisaureus_: can you try to run procmon on the machine where you have the share>?
01:02:55  <piscisaureus_>sure
01:20:47  * mjr_quit (Quit: mjr_)
01:24:37  <piscisaureus_>igorzi_: I think I got it now :-)
01:24:40  <piscisaureus_>igorzi_: no shit.
01:24:55  <igorzi_>piscisaureus_: ok.. what is it?
01:25:05  <piscisaureus_>igorzi_: I'll post a gist shortly
01:25:18  <piscisaureus_>igorzi_: doing a final review before i make a fool of myself again
01:26:09  <igorzi_>piscisaureus_: are you not seeing something locking down the file on the remote machine?
01:26:24  <piscisaureus_>igorzi_: no I think it is a caching problem
01:26:43  <piscisaureus_>igorzi_: npm stats node_modules/express/package.json first and then it is not there
01:27:01  <piscisaureus_>then it unpacks it to another folder and renames that folder to node_modules/express
01:27:06  <piscisaureus_>so package.json now exists
01:27:09  <piscisaureus_>but windows says not
01:27:40  <igorzi_>piscisaureus_: you have a gist that reproduces it?
01:28:15  <piscisaureus_>igorzi_: https://gist.github.com/1997507
01:29:37  * AvianFlujoined
01:29:40  * abraxasjoined
01:31:23  <igorzi_>piscisaureus_: repros for me if i run with the network share
01:32:07  <piscisaureus_>igorzi_: exactly
01:34:42  <piscisaureus_>igorzi_: so what do you think we should do about it?
01:35:22  <igorzi_>piscisaureus_: i'm still of the opinion that something is locking down the file on the machine where the share is located
01:35:46  <piscisaureus_>igorzi_: alright.
01:36:04  <igorzi_>piscisaureus_: btw, i can't reproduce if the share is on the same machine
01:36:15  <piscisaureus_>igorzi_: but don't you think it is funny that removing the first statSync in the test changes that?
01:38:40  <igorzi_>piscisaureus_: ohh i missed that.. yeah it is strange
01:40:48  * pieternquit (Quit: pietern)
01:48:07  <igorzi_>piscisaureus_: i just confirmed that it's not MsMpEng.exe
01:48:21  <piscisaureus_>cool
01:48:43  * dapquit (Quit: Leaving.)
01:51:52  <igorzi_>piscisaureus_: btw, it repros even if i do a wait before stat
01:53:16  <piscisaureus_>igorzi_: for me, it doesn't reproduce if I run with procmon
01:53:28  <igorzi_>piscisaureus_: nm.. if i increase the wait to 5 sec - it goes away
01:53:31  * perezdquit (Quit: perezd)
01:53:47  <piscisaureus_>5 seconds is a long time :-)
01:55:03  <igorzi_>piscisaureus_: yeah.. it if i take it down to 3 seconds it still fails
01:57:35  <igorzi_>piscisaureus_: i think we should try to create a repro in c against win32 api
01:57:45  <igorzi_>piscisaureus_: gtg.. i'll be online later
01:58:49  <piscisaureus_>igorzi_: david ebbo was going to do it in c#
02:02:23  <CIA-99>node: Bert Belder v0.6 * rdaaccc7 / (3 files in 3 dirs): uv: upgrade to 1ac71a31 - http://git.io/LLIbhA
02:02:23  <CIA-99>node: Bert Belder v0.6 * r3733a85 / src/node_file.cc : Windows: include syscall in fs errors - http://git.io/rGvY6A
02:09:11  * mikealjoined
02:10:45  * travis-cijoined
02:10:45  <travis-ci>[travis-ci] joyent/node#568 (v0.6 - 3733a85 : Bert Belder): The build was fixed.
02:10:45  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/33f9074...3733a85
02:10:45  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/818525
02:10:45  * travis-cipart
02:14:02  <isaacs>piscisaureus_: we're gonna have to have a 0.6.13, aren't we?
02:14:06  * isaacso\
02:14:09  * isaacso\
02:14:15  * isaacsToT
02:16:07  <piscisaureus_>isaacs: yup, at some point. let's fix the unc bug.
02:19:09  <CIA-99>node: Bert Belder master * rdaaccc7 / (3 files in 3 dirs): uv: upgrade to 1ac71a31 - http://git.io/LLIbhA
02:19:10  <CIA-99>node: Bert Belder master * r3733a85 / src/node_file.cc : Windows: include syscall in fs errors - http://git.io/rGvY6A
02:19:12  <CIA-99>node: Bert Belder master * r31ad1d2 / (10 files in 7 dirs): Merge branch 'v0.6' - http://git.io/b9gG8A
02:23:07  * benviequit
02:23:40  <CIA-99>libuv: Bert Belder master * r2ef5798 / (include/uv.h src/unix/error.c src/win/error.c src/win/util.c):
02:23:41  <CIA-99>libuv: Merge remote-tracking branch 'origin/v0.6'
02:23:41  <CIA-99>libuv: Conflicts:
02:23:41  <CIA-99>libuv: src/unix/core.c - http://git.io/-_PJ9A
02:23:42  <CIA-99>libuv: Bert Belder master * r1ac71a3 / (include/uv.h src/unix/error.c src/win/error.c): Map EBUSY and ENOTEMPTY errors - http://git.io/IZKzCQ
02:25:32  * travis-cijoined
02:25:33  <travis-ci>[travis-ci] joyent/libuv#121 (master - 2ef5798 : Bert Belder): The build is still failing.
02:25:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/d07f246...2ef5798
02:25:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/818585
02:25:33  * travis-cipart
02:27:32  * pieternjoined
02:30:36  * brsonquit (Quit: leaving)
02:34:05  * travis-cijoined
02:34:05  <travis-ci>[travis-ci] joyent/node#569 (master - 31ad1d2 : Bert Belder): The build is still failing.
02:34:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/5ad0140...31ad1d2
02:34:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/818563
02:34:05  * travis-cipart
02:46:35  * igorzijoined
02:47:18  <igorzi>isaacs: i think at some point you mentioned that you want to get rid of this dir renaming in npm, and just untar everything into the final destination
02:47:32  <igorzi>isaacs: are you still planning to do that?
02:47:36  <isaacs>igorzi: sure.
02:47:40  <isaacs>but bigger fish to fry
02:47:46  <isaacs>unless this is breaking something badly
02:47:57  <igorzi>isaacs: cause that would probably also resolve this issue
02:48:01  <isaacs>i mean, node should be able to rename directories, though
02:48:05  <isaacs>and that should actually work
02:48:28  <piscisaureus_>igorzi: I don't know if you saw the npm issue, but David was able to reproduce in c#
02:48:39  <piscisaureus_>igorzi: so he is going to talk to the OS guys now
02:49:37  <igorzi>piscisaureus_: yeah, i know
02:50:14  <piscisaureus_>igorzi: I don't mean to be rude, but microsoft is doing this super edgy stuff and it fails due to (apparently) a windows bug. Is it unreasonable to expect that msft fixes it?
02:51:00  <igorzi>piscisaureus_: it's not unreasonable to expect it to be fixed if it is a bug.. i'm not saying that npm should work around windows bugs
02:51:01  <tjfontaine>how far back do you expect them to fix it? and how likely do you think lusers are to apply the fix?
02:51:29  <piscisaureus_>well, it is not something that many people will run into
02:51:54  <piscisaureus_>If there is a reasonable workaround we will apply it probably.
02:52:19  <igorzi>piscisaureus_: i'm saying that we had another issue with a/v locking down the file, for which we had to add retry logic.. that wouldn't be needed if the files were downloaded directly into their final location
02:53:00  <piscisaureus_>yeah - that one is annoying
02:53:30  <piscisaureus_>This rename stuff is probably unnecessary and it should be removed.
02:55:59  <piscisaureus_>igorzi: I think MoveFileEx has some flag that makes sure it blocks until the change is committed to disk
02:56:13  <piscisaureus_>igorzi: *_WRITE_THROUGH iirc
02:56:18  <piscisaureus_>igorzi: maybe that'll fix it
03:02:36  <igorzi>piscisaureus_: hmm, i wonder if that's honored for network writes
03:03:47  <igorzi>piscisaureus_: if this is the case.. it's also possible that we could run into the same issue with CreateFile+WriteFile (not just MoveFileEx)?
03:04:38  * igorzi_quit (Ping timeout: 245 seconds)
03:06:17  <piscisaureus_>igorzi: well I think that the result of the first (failing) NtCreateFile call is cached somehow, and the cache is not properly flushed when a directory is renamed so the file begins to exist.
03:07:03  <piscisaureus_>igorzi: a WriteFile call would imply we open/create the file first, and I assume that would properly flush the cache
03:07:33  <piscisaureus_>igorzi: we should first try this
03:07:33  <piscisaureus_>stat('a')
03:07:33  <piscisaureus_>rename('b', 'a')
03:07:33  <piscisaureus_>stat('a')
03:07:45  <igorzi>piscisaureus_: CreateFile also has FILE_FLAG_WRITE_THROUGH
03:08:17  <piscisaureus_>true
03:39:43  * txdvjoined
03:42:17  <isaacs>igorzi piscisaureus_: oh, so apparently that's broken in .NET/C# as well?
03:42:22  <isaacs>i guess i better just work around it in npm, then
03:43:49  * mikealquit (Quit: Leaving.)
03:44:05  <isaacs>either add some flexible timeout buffering, or just do like I ought to do, and unpack right into place.
03:56:35  * isaacsquit (Remote host closed the connection)
04:03:05  * mikealjoined
04:12:07  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
04:19:36  * benviejoined
04:24:05  * mikealquit (Quit: Leaving.)
04:35:48  <igorzi>piscisaureus_: MOVEFILE_WRITE_THROUGH doesn't fix it
05:51:24  * avsejquit (Ping timeout: 244 seconds)
05:52:32  * avsejjoined
05:57:45  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
05:58:51  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
06:05:26  * indutny_sleepingchanged nick to indutny
06:10:56  * dshaw_quit (Quit: Leaving.)
06:11:11  * dshaw_joined
06:28:30  * toothrquit (Read error: Connection reset by peer)
06:29:15  * toothrjoined
06:36:31  * dshaw_quit (Quit: Leaving.)
06:44:17  * hij1nxjoined
07:48:59  * kuebkjoined
07:54:18  * stephankquit (Quit: *Poof!*)
08:00:15  * paddybyersjoined
08:04:55  * rendarjoined
08:37:12  * txdv_joined
08:41:15  * txdvquit (Ping timeout: 252 seconds)
08:57:07  * hij1nxquit (Quit: hij1nx)
08:58:36  * paddybyersquit (Quit: paddybyers)
09:00:16  * mikealjoined
09:09:44  * indutnychanged nick to indutny_away
09:31:33  * paddybyersjoined
09:31:43  * benviequit
09:34:28  * benviejoined
09:37:54  * benviequit (Client Quit)
09:46:17  * benviejoined
09:58:42  <igorzi>piscisaureus_: hey, i tried using the old stat implementation (the one that uses FindFirstFileExW), and the problem doesn't happen
10:03:17  <igorzi>piscisaureus_: it only happens with CreateFile when it's called twice with OPEN_EXISTING (1st when the file doesn't exist and 2nd when it exists)
10:03:51  <rendar>igorzi: why FindFirstFileExW and not FindFirstFileExA ?
10:04:13  <igorzi>piscisaureus_: if the 2nd CreateFile is called with OPEN_ALWAYS then the problem doesn't happen
10:04:28  <igorzi>rendar: cause we're dealing with utf16 strings
10:04:44  <rendar>igorzi: oh, i tought all libuv worked with utf8
10:05:28  <igorzi>rendar: the uv api takes utf8, but win32 either takes ascii or utf16, so we convert to utf16
10:06:16  <rendar>got it
10:07:53  <rendar>igorzi: speaking about win32 stuff, the other day i've noticed a possible bug, but i don't know if it is, in libuv/src/win/fs.c there is fs__read (and fs__write as well) which allocate an OVERLAPPED structure in the stack, according to msdn it is wrong
10:11:08  <igorzi>rednar: that's fine because the file is not opened with FILE_FLAG_OVERLAPPED
10:11:19  <rendar>oh i see
10:11:24  <rendar>its always synchronous?
10:11:36  <igorzi>rendar: yeah
10:12:11  <igorzi>piscisaureus_: damn.. it looks like this caching behavior is a feature http://technet.microsoft.com/en-us/library/ff686200(v=WS.10).aspx
10:29:46  * kuebkpart
10:48:18  * mikealquit (Ping timeout: 276 seconds)
11:25:18  * indutny_awaychanged nick to indutny
11:30:07  * abraxasquit (Remote host closed the connection)
11:31:14  * abraxasjoined
11:35:30  * abraxasquit (Ping timeout: 244 seconds)
12:00:53  * mikealjoined
12:57:02  * mmalecki[zzz]changed nick to mmalecki
13:16:40  * piscisaureus_joined
14:07:49  * bnoordhuisjoined
14:14:12  <CIA-99>libuv: Frank Denis master * r1c8cf61 / src/win/core.c :
14:14:13  <CIA-99>libuv: windows: initialize ares handles list
14:14:13  <CIA-99>libuv: We need to initialize the ares handles linked list or else bad things can happen
14:14:13  <CIA-99>libuv: when we try to perform async lookups. - http://git.io/LjbcxA
14:15:04  <piscisaureus_>bnoordhuis: ^-- that guy
14:15:09  <piscisaureus_>bnoordhuis: look here: https://github.com/joyent/libuv/blob/1c8cf617f9911148499f1a46ad91969d8a58a26e/src/win/core.c#L61-94
14:15:24  <piscisaureus_>bnoordhuis: he does a one-line patch and he doesn't even bother to find a nice place for the line.
14:16:49  <bnoordhuis>yes...
14:29:18  <bnoordhuis>piscisaureus_: btw, have you checked `git shortlog -ns` with libuv recently?
14:30:51  <piscisaureus_>I don't even know what that does
14:31:00  <mmalecki>bnoordhuis: ++
14:31:01  <kohai>bnoordhuis has 12 beers
14:31:10  <bnoordhuis>piscisaureus_: try it :)
14:31:14  <piscisaureus_>I bet it redirects to http://www.youtube.com/watch?v=dQw4w9WgXcQ
14:31:19  <bnoordhuis>haha
14:32:12  <mmalecki>bnoordhuis: btw, what's up with detached spawn?
14:32:21  <mmalecki>you guys ever figured out why'd setsid fail?
14:32:59  <bnoordhuis>mmalecki: detached spawn got reverted
14:33:05  <bnoordhuis>haven't had time to look into why
14:33:22  <mmalecki>bnoordhuis: that's why I'm asking
14:35:07  <mmalecki>piscisaureus_: it does that: http://github-high-scores.heroku.com/joyent/libuv/high_scores/
14:35:52  <mmalecki>also, I'm 95 commits behind indutny
14:36:31  <indutny>hahaha
14:36:40  <indutny>are you still watching that?
14:36:48  <mmalecki>indutny: YES.
14:37:15  <indutny>lul I made 134 commits
14:50:02  * hij1nxjoined
14:51:17  * hij1nxquit (Client Quit)
14:51:40  * hij1nxjoined
14:59:40  <bnoordhuis>why o why does a cluster worker emit 'death' instead of 'exit'?
15:00:23  <mmalecki>bnoordhuis: to make it more dramatic
15:00:33  <mmalecki>bnoordhuis: also, change it?
15:01:02  <bnoordhuis>i feel like it
15:01:15  <mmalecki>so do it.
15:01:40  <bnoordhuis>yeah... first i have this bug to fix
15:02:26  <mmalecki>we all do!
15:03:15  <bnoordhuis>annoying, this 'death' event also doesn't give you the status code
15:03:44  <mmalecki>fail? also, I thought .fork() would just return a child process
15:03:54  <bnoordhuis>exitCode == null -- nuh-uh, it crashed
15:06:36  <mmalecki>bnoordhuis: for API consistency, we should make it return child_process.fork, imo
15:06:55  <mmalecki>or export ChildProcess and inherit
15:07:08  <bnoordhuis>at least something that quacks like it
15:07:17  <mmalecki>yeah
15:08:24  <mmalecki>"quacks like a fork" would be a good name for a band
15:08:44  <mmalecki>or quackslikeafork.tumblr.com
15:10:18  <piscisaureus_>bnoordhuis: on unix, can you open an tty with open("/dev/tty0") ?
15:10:51  <piscisaureus_>bnoordhuis: (if stdio is redirected)
15:12:42  <bnoordhuis>piscisaureus_: yes
15:12:48  <bnoordhuis>/dev/tty is the current terminal
15:41:24  * isaacsjoined
15:46:41  <CIA-99>libuv: Bert Belder v0.6 * r743cab9 / test/runner.c : Test runner: avoid process_wait failure when the test process didn't start - http://git.io/COAMoA
15:46:42  <CIA-99>libuv: Bert Belder v0.6 * rab18b7d / test/test-tty.c : Make test-tty pass with redirected stdio - http://git.io/X-QiWQ
15:46:44  <CIA-99>libuv: Bert Belder v0.6 * rf43f1a7 / src/win/handle.c :
15:46:44  <CIA-99>libuv: Windows: avoid uv_guess_handle crash in when fd < 0
15:46:44  <CIA-99>libuv: Happens only when using a debug version of the crt. - http://git.io/wnz1lg
15:47:16  <piscisaureus_>bnoordhuis: can you review http://git.io/X-QiWQ?
15:47:26  * travis-cijoined
15:47:26  <travis-ci>[travis-ci] joyent/libuv#123 (v0.6 - ab18b7d : Bert Belder): The build is still failing.
15:47:26  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/1ac71a3...ab18b7d
15:47:26  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/821998
15:47:26  * travis-cipart
15:47:41  <piscisaureus_>bnoordhuis: I tentatively landed it, but the unix part needs an eye from an unix expert
15:48:20  <piscisaureus_>bnoordhuis: a beer if you catch the error!
15:48:27  <piscisaureus_>(there is one!)
15:53:16  <CIA-99>libuv: Bert Belder v0.6 * reb0ef4c / test/test-tty.c : Fix javascript-ism - http://git.io/CKB5Gg
15:53:20  <piscisaureus_>too late
15:53:32  <bnoordhuis>piscisaureus_: open('/dev/tty'
15:53:34  <bnoordhuis>wut?
15:53:41  <bnoordhuis>oh, you fixed it
15:54:09  * travis-cijoined
15:54:09  <travis-ci>[travis-ci] joyent/libuv#124 (v0.6 - eb0ef4c : Bert Belder): The build is still failing.
15:54:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ab18b7d...eb0ef4c
15:54:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/822040
15:54:09  * travis-cipart
15:55:25  <piscisaureus_>bnoordhuis: meh.
15:55:37  <bnoordhuis>piscisaureus_:
15:55:38  <bnoordhuis>../test/test-tty.c:25:16: warning: io.h: No such file or directory
15:55:39  <bnoordhuis>../test/test-tty.c: In function ‘run_test_tty’:
15:55:39  <bnoordhuis>../test/test-tty.c:37: error: expected expression before ‘/’ token
15:55:39  <bnoordhuis>../test/test-tty.c:62: warning: implicit declaration of function ‘open’
15:55:39  <bnoordhuis>../test/test-tty.c:62: error: ‘O_WRONLY’ undeclared (first use in this function)
15:55:40  <bnoordhuis>../test/test-tty.c:62: error: (Each undeclared identifier is reported only once
15:55:42  <bnoordhuis>../test/test-tty.c:62: error: for each function it appears in.)
15:56:20  <piscisaureus_>bnoordhuis: what do I need to include to have open() ?
15:56:36  <piscisaureus_>On windows that would be unistd.h but I bet that's not the case on uniux
15:56:48  <bnoordhuis>piscisaureus_: unistd.h and fcntl.h
15:56:54  <bnoordhuis>i'll fix it up
15:57:16  <piscisaureus_>bnoordhuis: thnx.
15:57:18  <bnoordhuis>because hey, if you want the work done right, you need to do it yourself, right?
15:57:48  <piscisaureus_>bnoordhuis: that is often true. I bet I could fix it with a couple of commits using travis :-)
15:58:38  <CIA-99>libuv: Bert Belder test * r03d505b / test/test-tty.c : Fix unix build - http://git.io/57PNpw
15:58:43  <piscisaureus_>let's see what travis says ^-- :-)
15:58:58  <bnoordhuis>piscisaureus_: 5a4a45e in my repo
15:59:10  <bnoordhuis>that's a neat commit hash btw
15:59:46  <bnoordhuis>piscisaureus_: you should have tested it / let me test it before you pushed it
16:00:05  <piscisaureus_>bnoordhuis: probably
16:00:17  <bnoordhuis>not probably, certainly. broken builds suck if you're bisecting
16:00:24  * travis-cijoined
16:00:24  <travis-ci>[travis-ci] joyent/libuv#125 (test - 03d505b : Bert Belder): The build failed.
16:00:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/03d505b
16:00:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/822067
16:00:24  * travis-cipart
16:00:36  <bnoordhuis>when you're done, squash it and force-push
16:00:47  <piscisaureus_>bnoordhuis: I will rebase
16:01:01  <piscisaureus_>this commit seems to have fixed it
16:03:12  <piscisaureus_>bnoordhuis: I was just trying to gather some shortlog karma L-\\:-)
16:03:44  <CIA-99>libuv: Bert Belder v0.6 * re53d7e3 / test/test-tty.c : Make test-tty pass with redirected stdio - http://git.io/L8R4ig
16:05:25  * travis-cijoined
16:05:25  <travis-ci>[travis-ci] joyent/libuv#126 (v0.6 - e53d7e3 : Bert Belder): The build is still failing.
16:05:25  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/eb0ef4c...e53d7e3
16:05:25  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/822105
16:05:25  * travis-cipart
16:36:46  * sh1mmerquit (Quit: sh1mmer)
17:06:09  <bnoordhuis>https://github.com/bnoordhuis/libuv/commit/6e17317 <- review anyone?
17:06:33  <bnoordhuis>there's a 30 minute review window, after that i'm merging it >:-)
17:07:07  <bnoordhuis>hmm, maybe a test would be nice
17:08:35  <tjfontaine>I like the premise :)
17:11:26  * igorziquit (Quit: Page closed)
17:13:01  <mmalecki>that's when bnoordhuis started asking for review in the middle of a night
17:18:05  * igorzijoined
17:18:10  * dapjoined
17:18:15  <igorzi>piscisaureus_: yt?
17:25:10  <piscisaureus_>igorzi: yes
17:25:47  <igorzi>piscisaureus_: i don't get your comment about that timeout thing being a bug.. how's it a bug? it's a pretty clearly documented feature
17:33:57  <piscisaureus_>igorzi: "This cache is likely to affect distributed applications running on multiple computers accessing a set of files on a serve – where the applications use an out of band mechanism to signal each other about addition/deletion of files on the server."
17:34:38  <piscisaureus_>igorzi: There are no "distributed applications on multiple computers", let alone an "out of band mechanism to signal each other"
17:35:56  <piscisaureus_>igorzi: there is just one application on one computer accessing a mapped folder. It is not unreasonable to expect that the view on directory contents is consistent.
17:37:14  <igorzi>piscisaureus_: right, it's reasonable. but how is it inconsistent?
17:37:26  <piscisaureus_>igorzi: well:
17:37:48  <piscisaureus_>readdir('dir') -> dir/file appears to be there
17:37:50  <igorzi>piscisaureus_: it's consistent for the duration of FileNotFoundCacheLifetime, which is configurable
17:37:59  <piscisaureus_>stat('dir/file') -> dir/file is not there
17:38:23  <piscisaureus_>quite inconsistent, no?
17:38:52  <igorzi>piscisaureus_: ok, i see what you're talking about now
17:40:14  <piscisaureus_>igorzi: also:
17:40:15  <piscisaureus_>create('dir1/file');
17:40:15  <piscisaureus_>rename('dir1', 'dir2')
17:40:15  <piscisaureus_>stat('dir2/file') // dir2/file should be there, but isn't
17:41:16  <igorzi>piscisaureus_: i thought this only happened when you do stat('dir2/file') before rename
17:41:26  <piscisaureus_>igorzi - that's true
17:41:33  <igorzi>piscisaureus_: which caches filenotfound
17:41:59  <igorzi>piscisaureus_: FindFirstFileExW doesn't go through the cache, which is why readdir works
17:42:34  <piscisaureus_>igorzi: why can't the UNC redirector just purge dir2/* from the stat cache on rename('x', 'dir2') ?
17:43:37  <piscisaureus_>igorzi: it could also purge files it detects to be there FindFirstFileExW from the doesn't-exist cache
17:43:57  <igorzi>piscisaureus_: that would mean hitting the server sooner than FileNotfoundCacheLifetime
17:44:36  <igorzi>piscisaureus_: maybe this is why crt uses FindFirstFileExW for their stat implementation :)
17:44:45  <piscisaureus_>haha
17:44:46  <piscisaureus_>yeah
17:44:57  <piscisaureus_>igorzi: is it unreasonable to purge caches that are known to be outdated?
17:46:31  <igorzi>piscisaureus_: i think it's reasonable, but it depends on the scenario i guess.. maybe they decided that it was acceptable to not purge it even if they know about the rename (i'm just speculating)
17:47:06  <piscisaureus_>igorzi: btw I was thinking, it could be detected with CreateFile(name, CREATE_NEW, FILE_FLAG_DELETE_ON_CLOSE). But I don't like to put that in node.
17:47:06  <igorzi>piscisaureus_: for the benefit of not hitting the server..
17:47:13  <piscisaureus_>igorzi: yeah, maybe.
17:47:28  <piscisaureus_>igorzi: or "they" just didn't think about it
17:47:37  <piscisaureus_>igorzi: just speculating :-)
17:47:42  <igorzi>piscisaureus_: yes, that's also a possibility :)
17:50:49  <piscisaureus_>igorzi: The more I think about it, the dumber it seems. Agreed - not purging the cache avoids hitting the server. But hey, I know a way to hit the server even less: just pretend there are no files at all.
17:50:49  <piscisaureus_>Does http://github.com/microsoft/windows take pull requests?
17:51:12  <tjfontaine>ha.
17:54:11  * perezdjoined
17:56:12  <piscisaureus_>we should have an O_EXCL binding btw
17:56:16  <piscisaureus_>bnoordhuis: agreed?
17:59:33  * sh1mmerjoined
18:04:23  * stephankjoined
18:05:11  * `3rdEdenjoined
18:10:18  * paddybyersquit (Quit: paddybyers)
18:13:53  * pfox___joined
18:18:31  * TooTallNatejoined
18:19:46  * `3rdEdenquit (Quit: Leaving...)
18:23:58  <piscisaureus_>bnoordhuis: hey
18:30:44  * indutnychanged nick to indutny_away
18:31:18  * igorzi_joined
18:51:41  <TooTallNate>hey guys
18:51:50  <TooTallNate>any reason the ZLIB_VERSION isn't exposed in process.versions?
18:52:02  <TooTallNate>want a patch?
18:55:10  * dshaw_joined
18:55:10  <piscisaureus_>TooTallNate: sure
18:59:50  <piscisaureus_>igorzi_: bnoordhuis: isaacs: do you guys agree that connect(6), write(2), shutdown, send(6) should reference the event loop currently?
18:59:50  <piscisaureus_>After the refcount refactor `close` should also ref.
19:00:43  <isaacs>TooTallNate: yeah, sure
19:03:46  <piscisaureus_>(igorzi)
19:05:04  <igorzi_>piscisaureus_: sorry, what do numbers in parenthesis mean? (number of times?)
19:05:32  * brsonjoined
19:06:11  * paddybyersjoined
19:33:13  <piscisaureus_>igorzi_: igorzi: connect, connect6, write, write2, send, send6, shutdown
19:36:43  <igorzi_>piscisaureus_: ohh.. yeah i agree that those should ref the event loop
19:39:44  * pfox___quit (Ping timeout: 265 seconds)
19:40:26  <CIA-99>node: Igor Zinkovsky master * r0c68604 / vcbuild.bat : add jslint to vcbuild.bat - http://git.io/wnodIQ
19:40:57  <piscisaureus_>spawn: 89 spawns/s
19:41:02  <piscisaureus_>so slow :-(
19:53:35  * mjr_joined
19:56:01  * travis-cijoined
19:56:01  <travis-ci>[travis-ci] joyent/node#570 (master - 0c68604 : Igor Zinkovsky): The build is still failing.
19:56:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/31ad1d2...0c68604
19:56:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/823077
19:56:01  * travis-cipart
20:14:35  <TooTallNate>guys i'm running into an interesting dillema from a module-build point-of-view
20:14:44  <TooTallNate>take this for example: https://github.com/ncb000gt/node.bcrypt.js
20:14:49  <TooTallNate>it depends on OpenSSL
20:15:05  <TooTallNate>node statically links openssl (usually), though it is configurable
20:15:25  <TooTallNate>from within node, there's no way to tell if youre using a static or dynamic version
20:15:42  <TooTallNate>but ideally, the bcrypt module would do the same thing node is doing
20:15:52  <TooTallNate>and use the static openssl when it's available
20:16:34  <TooTallNate>so basically i'm thinking we need to expose the shared/static state of deps that node uses somehow
20:17:12  <igorzi_>piscisaureus_: what do you think about https://github.com/joyent/libuv/pull/338 ?
20:20:03  <isaacs>TooTallNate: if it only depends on openssl and node, what does it need that node isn't exposing?
20:20:33  <piscisaureus_>igorzi_: generally ok
20:21:17  <piscisaureus_>igorzi_: I have to do a complete review still.
20:21:30  <TooTallNate>isaacs: well from a gyp standpoint, i dont know whether to -Ideps/openssl/include (for static) or -Lssl (for shared)
20:22:25  <piscisaureus_>igorzi_: also, AvianFlu has submitted a pull request to support detached processes that *do* stay alive. We should make sure those patches work together. https://github.com/joyent/libuv/pull/329
20:25:40  <igorzi_>piscisaureus_: i wonder if CREATE_SUSPENDED + ResumeThread will slow the spawn benchmark even more
20:27:20  <piscisaureus_>igorzi: yeah. It would als be good if we could move most of the work associated with job creation to uv_init
20:28:24  * dshaw_1joined
20:28:47  <isaacs>TooTallNate: well, but if you've installed node from the bin, you don't have deps/openssl/include
20:29:06  <isaacs>TooTallNate: so -Lssl is the only option, unless bcrypt bundles openssl
20:29:10  <igorzi_>piscisaureus_: uv_process_job_init is called from uv_init
20:29:36  * dshaw_quit (Ping timeout: 248 seconds)
20:29:39  <TooTallNate>isaacs: ya but node-gyp downloads that stuff
20:30:42  <isaacs>i see
20:31:10  <TooTallNate>brb lunch
20:31:53  <tjfontaine>I only expect support nightmares if node-gyp is downloading development headers
20:33:23  * mikealquit (Quit: Leaving.)
20:51:32  * `3rdEdenjoined
21:02:12  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
21:06:40  * pfox___joined
21:16:09  * indutny_awaychanged nick to indutny_sleeping
21:21:56  * isaacsquit (Remote host closed the connection)
21:25:52  <TooTallNate>tjfontaine: and why is that?
21:32:05  * paddybyers_joined
21:35:03  * paddybyersquit (Ping timeout: 276 seconds)
21:35:03  <benvie>up until recently the opposite was moreso true
21:35:03  * paddybyers_changed nick to paddybyers
21:35:49  <benvie>I guess maybe because it lowers barrier to entry so you may end up with people less reliably experienced doing this stuff?
21:36:34  <benvie>I wouldn't disagree with that but I think it's it a net positive
21:37:29  <TooTallNate>he's just trolling
21:38:53  <tjfontaine>no not really, I think it's perfectly acceptable to have people independently having installed node headers
21:39:24  <tjfontaine>if I install node via my distro who may have subtly changed configuration, and then use node-gyp which makes different assumptions
21:42:41  <piscisaureus_>igorzi: igorzi_: does the libuv pipe_pound_100 benchmark time out for you too? I'm using the 0.6 branch of libuv
21:46:00  * isaacsjoined
21:53:14  <igorzi_>piscisaureus_: yep pipe_pound_100 is timing out for me too
21:56:32  <piscisaureus_>igorzi: I have ot fcking clue why
21:56:38  <piscisaureus_>s/ot/no
22:29:39  * hij1nxquit (Quit: hij1nx)
22:34:19  * perezd_joined
22:35:40  * perezdquit (Ping timeout: 265 seconds)
22:35:40  * perezd_changed nick to perezd
22:40:03  <bnoordhuis>piscisaureus_: ho. you rang?
22:41:05  * isaacsquit (Remote host closed the connection)
22:58:56  * rendarquit
23:10:30  * perezd_joined
23:12:30  * mikealjoined
23:12:36  * perezdquit (Ping timeout: 246 seconds)
23:14:28  * perezdjoined
23:15:43  * perezd_quit (Ping timeout: 252 seconds)
23:18:39  * perezd_joined
23:20:39  * perezdquit (Ping timeout: 246 seconds)
23:22:21  * paddybyersquit (Quit: paddybyers)
23:24:06  * perezdjoined
23:24:09  * perezd_quit (Ping timeout: 252 seconds)
23:28:47  * perezd_joined
23:29:59  * bnoordhuistopic: #libuv, or how I learned to stop worrying and love async I/O
23:30:18  * perezdquit (Ping timeout: 252 seconds)
23:30:18  * perezd_changed nick to perezd
23:32:18  * isaacs_mobilejoined
23:33:36  * perezd_joined
23:35:11  * perezdquit (Ping timeout: 260 seconds)
23:35:12  * perezd_changed nick to perezd
23:36:06  * hij1nxjoined
23:47:54  * txdv_quit (Ping timeout: 252 seconds)
23:51:01  * isaacs_mobilequit (Remote host closed the connection)