00:00:51  * hij1nxquit (Quit: hij1nx)
00:06:44  <mmalecki>curl'able irssi would be neat.
00:07:16  <piscisaureus>mmalecki: curl-able?
00:07:25  <piscisaureus>mmalecki: probably you want netcat-able?
00:07:50  <mmalecki>piscisaureus: nah, curl-able! curl surrender-cube.jit.su
00:08:04  <mmalecki>but yeah, netcat-able would do it ;)
00:08:48  <piscisaureus>mmalecki: you want to know how that looks on windows? :-)
00:09:30  <mmalecki>piscisaureus: actually, I don't :)
00:10:07  <mmalecki>it's substack's project, so harass him ;)
00:14:43  <piscisaureus>node -e "require('http').get({host:'surrender-cube.jit.su'}, function(res) { res.pipe(process.stdout) })"
00:14:47  <piscisaureus>does the trick
00:14:58  <piscisaureus>but I don't know if this is what I am supposed to see
00:16:49  <mmalecki>piscisaureus: you're supposed to see a rotating cube
00:17:31  <piscisaureus>mmalecki: It looks somewhat like that yeah
00:17:33  * isaacsuses limechat
00:18:26  <tjfontaine>hmm the node one liner is prettier than the curl version
00:19:18  <tjfontaine>wget -q -O- is slightly better
00:21:00  <mmalecki>actually, it's somehow related to output buffering curl does
00:21:15  <mmalecki>s/output//
00:21:54  <mmalecki>there have to be some switches, but node is close enough :)
00:22:10  <tjfontaine>indeed
00:23:24  <TooTallNate>-N / --no-buffer for curl
00:24:32  <piscisaureus>To be honest node I am always amazed how much you can do with node one liners
00:25:08  <piscisaureus>now I am used to the windows shell which lacks many tools so maybe I am too easily satistfied
00:25:40  <tjfontaine>in nix world such things are common, people love their bash and perl one lienrs
00:25:43  <tjfontaine>*liners
00:31:15  <benvie>this is why I have my favorite shell menu addition for .js files: "make runnable"
00:32:05  <benvie>which creates a .cmd file in node's directory (in the path) that invokes the js file passing along everything else
00:32:44  <benvie>using node to shim the nicities of unix into windows
00:32:51  <benvie>for fun and profit
00:33:04  <mmalecki>I mean, use Unix?
00:33:25  <mmalecki>porting unix to windows seems pretty pointless to me ;)
00:33:26  <benvie>but the reverse, shimming the nicities of windows in unix, is a more complicated process =D
00:34:06  <benvie>for that I have my kubuntu vm
00:34:16  <benvie>which kind of does it
00:34:52  <mmalecki>I wish writing OSes was easier :)
00:36:53  <benvie>it would be if there was a node module for writing OSes
00:37:27  <benvie>the gauntlet has been laid
00:37:33  <tjfontaine>then we'd just have more arguments about require('posix');
00:38:22  <benvie>it an x86 architecture can be emulated in js and linux run on it
00:38:27  <benvie>then node can have an os building module
00:38:56  <benvie>nay, must
01:22:08  * mikeal1joined
01:22:11  * mikealquit (Read error: Connection reset by peer)
01:25:32  * isaacsquit (Remote host closed the connection)
01:29:26  * mikeal1quit (Quit: Leaving.)
01:35:55  * mjr_joined
01:40:28  <piscisaureus>wtf
01:41:07  * mmaleckichanged nick to mmalecki[zzz]
01:41:12  * isaacsjoined
01:42:37  * philipsquit (Excess Flood)
01:43:36  * philipsjoined
01:44:35  * mikealjoined
01:49:49  * brsonquit (Quit: leaving)
01:53:56  * abraxasjoined
02:00:38  * perezdjoined
02:05:39  * pieternquit (Quit: pietern)
02:06:20  * mikealquit (Quit: Leaving.)
02:14:53  * mikealjoined
02:20:01  <CIA-99>node: isaacs master * rd5fca08 / benchmark/client_latency.js : A benchmark script for measuring client latency - http://git.io/qREqXg
02:20:02  <CIA-99>node: isaacs master * r17da424 / benchmark/http_server_lag.js : A server with configurable lag for testing - http://git.io/oETuJA
02:20:02  <CIA-99>node: isaacs master * rfb53986 / benchmark/http.sh : Bash script for running http-simple benchmarks - http://git.io/Dt-APA
02:23:32  * perezdquit (Quit: perezd)
02:23:50  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:28:47  <piscisaureus>So
02:28:58  <piscisaureus>I know how to make bytes/1024 faster :-)
02:34:41  <creationix>bytes/1024?
02:39:20  <piscisaureus>http simple
02:39:38  <piscisaureus>ab -t 1000 -c 100 http://localhost:8000/buffer/10240
02:47:38  <piscisaureus>isaacs: what should we do if the user writes a string that ends with a lead surrogate, and then calls write() another time with a string that starts with a trail surrogate?
02:48:27  <piscisaureus>isaacs: would we do something opposite to string_decoder, or is it just the user's responsibility to not split strings in the middle of a surrogate pair?
02:48:36  <piscisaureus>pquerna mjr_ igorzi: ^ ?
02:49:03  <piscisaureus>creationix: ^
02:49:22  <mjr_>When writing buffers, this has to be OK.
02:49:35  <isaacs>piscisaureus: we have to do something the opposite of a string_decoder
02:49:55  <isaacs>singleByteService.pipe(httpResponse)
02:49:58  <isaacs>that has to work ^
02:50:09  <isaacs>even in the presence of U+10FFFF chars
02:50:16  <isaacs>er, U+01FFFF
02:50:20  <piscisaureus>mjr_ isaacs: this does not affect writing buffers
02:50:24  <piscisaureus>only writing strings
02:50:24  * mikealquit (Quit: Leaving.)
02:50:39  <isaacs>piscisaureus: oh, i see
02:50:56  <isaacs>so write("foo\ud800") then write("\uffed")
02:51:01  <piscisaureus>isaacs: yes
02:51:22  <isaacs>yeah, let's punt on that
02:51:52  <piscisaureus>mjr_: isaacs: the problem is that our api has no room for it, there is no set encoding for writes
02:51:55  <piscisaureus>people could do
02:52:09  <piscisaureus>write("foo\ud800", "utf8")
02:52:21  <piscisaureus>write("bla", "base64")
02:52:29  <piscisaureus>write("\uffed", "utf8")
02:54:11  * sh1mmerjoined
02:56:22  * mikealjoined
03:04:30  * mikealquit (Quit: Leaving.)
03:06:37  <piscisaureus>ok. time to go again.
03:06:48  <piscisaureus>The c++ placement new syntax just made me cry
03:10:54  * mikealjoined
03:11:55  <isaacs>piscisaureus: i think if you're writing strings, and they have multibytes (er, multi-words, rather) then it's up to you to not write them brokenly
03:12:19  <piscisaureus>isaacs: right, ok. That makes things easy
03:12:26  <isaacs>piscisaureus: wherever you're getting that string from should be through a string_decoder or something
03:13:21  <piscisaureus>isaacs: yeah, we should not break up strings ourselves. And string decoder should correctly continue decoding after a buffer break, like it already does.
03:13:39  <isaacs>kewl
03:13:52  <piscisaureus>isaacs: something else - why was the SlowBuffer / Buffer distinction invented?
03:14:04  <isaacs>piscisaureus: i'd assume that the majority use case is: turn a buffer into a string, turn the string back into a buffer, write the buffer to a socket/file
03:14:25  <isaacs>piscisaureus: because allocating lots of little buffers and crossing the C++ boundary a lot was found to be slow
03:14:43  <isaacs>piscisaureus: some day, it'd be nice to use TypedArrays or whatever the ES thing is
03:15:15  <piscisaureus>isaacs: hmm. I find just figured out that it is much faster to do the string -> buffer conversion in the binding layer.
03:15:29  <isaacs>piscisaureus: interesting
03:15:33  <piscisaureus>that is, don't really create a buffer - just malloc memory
03:15:41  <piscisaureus>and write that
03:15:57  <piscisaureus>it seems to me that this would make the SlowBuffer kind of unnecessary
03:16:36  <piscisaureus>I don't think many people really do `new Buffer(10)` just for fun. Or do you, mjr_?
03:17:30  <piscisaureus>Buffers are only made when people want to write stuff to a socket or file - or node itself creates it when reading/receiving.
03:17:56  <mjr_>My metrics processing system does new Buffer(some_size)
03:18:05  * mikealquit (Quit: Leaving.)
03:18:13  <piscisaureus>mjr_: what would be a typical size?
03:18:15  <mjr_>It works with UDP packets though.
03:18:21  <mjr_>40 - 100 bytes.
03:18:47  <mjr_>For most stuff though, I never explicitly allocate buffers, they are passed in from "data" callbacks.
03:19:02  <piscisaureus>yeah, exactly
03:19:27  <piscisaureus>but they are created from another slab
03:19:41  <piscisaureus>but yes they still require SlowBuffer
03:31:54  <CIA-99>node: isaacs master * r150053b / benchmark/http_server_lag.js :
03:31:54  <CIA-99>node: Typo in http_server_lag.js script
03:31:54  <CIA-99>node: Thanks, @mscdex - http://git.io/gHq2Ug
03:38:33  * AvianFlujoined
03:41:35  <CIA-99>node: Shea Levy master * r4ff6138 / lib/child_process.js :
03:41:35  <CIA-99>node: fork: don't clear environment by default
03:41:35  <CIA-99>node: - Set options.env to process.env instead of {} by default.
03:41:35  <CIA-99>node: - Shallow clone the passed options.env in case the user passed process.env directly. - http://git.io/43fQww
03:42:20  <piscisaureus>shit, backing out
03:42:51  <isaacs>piscisaureus: backing out?
03:42:56  <piscisaureus>yeah. no cla
03:43:13  <isaacs>ah, yikes.
03:43:16  <isaacs>thanks for catching it
03:44:35  <piscisaureus>I wish we could have a big banner that says "sign the CLA!!!!1"
03:45:30  <piscisaureus>Admittedly, the CLA is not even mentioned in the readme
03:46:22  <isaacs>piscisaureus: we could set up a pull req hook on github that checks this, i think
03:46:25  <isaacs>yui had something like that
03:46:35  <piscisaureus>oh, yeah
03:46:37  <isaacs>really, ti'd be best if github just did this for us.
03:46:48  * travis-cijoined
03:46:48  <travis-ci>[travis-ci] joyent/node#562 (master - 150053b : isaacs): The build is still failing.
03:46:48  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/fb53986...150053b
03:46:48  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/811116
03:46:48  * travis-cipart
03:49:19  <piscisaureus>isaacs: meh, client_latency depends on request
03:49:41  <piscisaureus>isaacs: you didn't get a review did you? >:-)
03:53:32  <CIA-99>node: Bert Belder master * r408f450 / benchmark/client_latency.js : client latency benchmark: don't require('request') - http://git.io/MyU4VA
03:55:52  * mjr_quit (Quit: mjr_)
03:56:20  * travis-cijoined
03:56:20  <travis-ci>[travis-ci] joyent/node#563 (master - 4ff6138 : Shea Levy): The build is still failing.
03:56:20  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/150053b...4ff6138
03:56:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/811158
03:56:20  * travis-cipart
03:59:49  <isaacs>piscisaureus: oh, no, i didn't.
04:00:01  <isaacs>i was playing around with a bunch of stuff in that thing, trying to find the soure
04:00:04  <isaacs>*source
04:00:10  <piscisaureus>isaacs: so what is the issue you are seeing
04:00:32  <isaacs>piscisaureus: so, if you bump up the total number of requests, the latency increases much more in 0.6/master than it did in 0.4
04:00:34  <piscisaureus>isaacs: if I run server_lag and client_latency without any options it creates a file with numbers
04:00:45  <isaacs>piscisaureus: each column is a "run"
04:00:47  <piscisaureus>isaacs: all the numbers are in the range 30-40
04:00:52  <isaacs>piscisaureus: right.
04:01:16  <piscisaureus>well, almost :-)
04:01:23  <piscisaureus>isaacs: so what happens for you?
04:01:24  <isaacs>piscisaureus: https://gist.github.com/1951446
04:02:30  <isaacs>if you do a run with a smaller number of requests (regardless of how many you tell it to run at once) you get dramatically higher latency
04:02:46  <piscisaureus>ach so
04:03:00  <isaacs>er, with a larger number of requests
04:03:04  <piscisaureus>ah, yeah
04:03:18  <piscisaureus>1000 100 10 goes up to ~250 for me
04:03:23  <isaacs>yikes
04:03:41  <isaacs>so, you'd expect that that would throw out 100 requests at a time, since that's the number of sockets it's going to open at once
04:03:55  <isaacs>so 1000 100 10 should have roughly the same values for the first 100 as 100 100 10
04:04:02  <isaacs>then the second batch of 100 should be longer, etc.
04:04:07  <isaacs>more-or-less stacking
04:04:19  <isaacs>but what you instead see is this huge jump.
04:04:35  <isaacs>this is totally killing the joyent portal right now. basically, they're stuck on 0.4 because of this.
04:05:11  <piscisaureus>so it is expected to go up?
04:05:25  <isaacs>you mean, expected to go up as you go down the list?
04:05:31  <piscisaureus>yeah
04:05:35  <isaacs>the values are: numRequests numSockets numRuns
04:05:40  * perezdjoined
04:05:41  <piscisaureus>I mean, what is the pattern that is desirable?
04:05:56  <isaacs>teh pattern is for numRequests to not affect latency overmuch.
04:06:13  <isaacs>but each batch of <numRequests> will stack upon one naother
04:06:40  <isaacs>so you should see something like [1,2,1,1,2,1,0,1, ...] for the first batch, then something like [2,1,2,2,4,2,2] for the second, etc.
04:06:41  <piscisaureus>isaacs: so why do you set maxSockets to 100 when you make 1000 requests?
04:07:04  <isaacs>piscisaureus: because i was trying to figure out if it was a result of requests queuing up in line for an available socket or not
04:07:09  <isaacs>but you can also run it with 1000 1000 10
04:07:14  <isaacs>results are still roughly the same
04:07:50  <isaacs>regardless, the first "batch" (ie, the first <numSockets> lines in each column) should be roughly the same, no matter what the <numRequests> is set to
04:08:05  * travis-cijoined
04:08:05  <travis-ci>[travis-ci] joyent/node#564 (master - 408f450 : Bert Belder): The build is still failing.
04:08:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/150053b...408f450
04:08:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/811219
04:08:05  * travis-cipart
04:08:18  <isaacs>so, 1000 10 10 should look the same (in the first 10 lines) as 100 10 10 or 10 10 10
04:08:46  <piscisaureus>ah
04:08:54  <piscisaureus>well that is the case
04:09:07  <piscisaureus>but if I boost the number of requests it all gets much slower
04:09:41  * mikealjoined
04:09:45  <isaacs>yes
04:10:05  <isaacs>it might get *a bit* slower, with more js objects etc being thrown around, but this is way more than expected.
04:10:08  <isaacs>so something is going on
04:14:07  * mikealquit (Client Quit)
04:15:08  <piscisaureus>1000 1000 1000 makes my kernel run out of memory
04:15:13  <isaacs>piscisaureus: in other news, just `npm install`ed jsdom on windows and it Just Works.
04:15:21  <piscisaureus>really
04:15:21  <isaacs>(provided you have node-gyp installed, of course)
04:15:22  <piscisaureus>cool
04:15:23  <isaacs>yes
04:15:42  <isaacs>now i just need to make it fail gracefully when you don't :)
04:15:43  * mikealjoined
04:15:55  <piscisaureus>hah, that's really cool
04:17:37  <piscisaureus>isaacs: btw, what server are you running? http_simple or http_server_lag?
04:17:41  <isaacs>of course, there's still a million other issues to deal with.
04:17:48  <isaacs>piscisaureus: i'm running http_simple with the client benchmark
04:18:02  <piscisaureus>aha
04:18:04  <piscisaureus>I was running lag
04:18:05  <isaacs>http_server_lag.js is useful to suss out socket-waiting queue behavior
04:18:24  <isaacs>because then each batch will be more distinct
04:18:35  <isaacs>it'll be like 10,10,10,20,20,21,...
04:18:40  <piscisaureus>yeah but
04:18:47  <piscisaureus>somehow the sockets are not properly disconnected
04:18:56  <isaacs>interesting
04:19:13  <piscisaureus>so windows runs out of kernel buffers after opening 60000 sockets or so
04:19:23  <isaacs>ooh... that's not so good
04:29:23  <isaacs>piscisaureus: what's windows cmd-ese for "blah || true; bloo"
04:29:35  <isaacs>piscisaureus: like, do "blah", don't fail if it fails, then do "bloo"
04:29:40  <piscisaureus>alright. This is too complicated for me. I am leavingk.
04:29:43  <piscisaureus>isaacs: oh
04:29:57  <isaacs>piscisaureus: if i do ||(exit 0) it doesn't get to bloo
04:30:00  <isaacs>it just exits completely
04:30:28  <piscisaureus>isaacs: I don't really understand
04:30:40  <piscisaureus>isaacs: can you use a c-family syntax to describe what you want?
04:31:00  <isaacs>piscisaureus: (node-gyp clean || true) && node-gyp configure
04:31:53  <piscisaureus>isaacs: you mean: do A and then do B even if A fails?
04:32:07  <isaacs>piscisaureus: yes, and report the eventual success or failure as the result of B
04:32:18  <isaacs>ie, if B fails, then it failed.
04:32:23  <isaacs>that's the return value i care about
04:32:52  <isaacs>in bash-land, i could just do `node-gyp clean; node-gyp configure`
04:33:02  <isaacs>without any fancy || && magic
04:33:03  <piscisaureus>aah
04:33:11  <piscisaureus>isaacs: a & b
04:33:20  <isaacs>piscisaureus: wait, srsly?
04:33:42  <piscisaureus>isaacs: try it
04:33:51  <isaacs>piscisaureus: ugh. that has a *wildly* different meaning in unix.
04:34:01  <isaacs>piscisaureus: that's "run a in teh background, then run b"
04:34:49  <piscisaureus>isaacs: there is no unix-like background in windows. If anything you would use `start a`
04:35:00  <isaacs>ugh
04:35:14  <isaacs>seriously, windows does not make it easy
04:35:34  <piscisaureus>isaacs: I am really checking out now. bye
04:35:55  <isaacs>piscisaureus: ok, good night
04:35:57  <isaacs>:)
04:36:21  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
04:39:55  * isaacsquit (Remote host closed the connection)
04:50:33  * perezdquit (Quit: perezd)
04:50:47  * mikealquit (Quit: Leaving.)
04:51:22  * dshaw_quit (Quit: Leaving.)
05:22:22  * mikealjoined
06:13:38  * mikealquit (Quit: Leaving.)
06:19:38  * hij1nxjoined
06:32:37  * paddybyersjoined
06:35:34  * AvianFluquit (Ping timeout: 240 seconds)
06:47:02  * mikealjoined
06:48:39  * mikealquit (Client Quit)
06:49:26  * AvianFlujoined
07:03:31  * dapquit (Quit: Leaving.)
07:10:42  * mikealjoined
07:18:32  * paddybyersquit (Quit: paddybyers)
07:24:25  * mjr_joined
07:32:38  * dshaw_joined
07:46:16  * paddybyersjoined
07:48:33  * rendarjoined
07:57:16  * stephankquit (Quit: *Poof!*)
09:04:33  * mikealquit (Quit: Leaving.)
09:06:17  * mikealjoined
09:08:21  * paddybyers_joined
09:11:03  * paddybyersquit (Ping timeout: 276 seconds)
09:11:03  * paddybyers_changed nick to paddybyers
09:17:46  * indutny_sleepingchanged nick to indutny
10:54:15  * dshaw_quit (Quit: Leaving.)
11:09:58  * mjr_quit (Quit: mjr_)
11:14:57  * AndreasMadsenjoined
11:40:50  * abraxasquit
12:09:26  * mjr_joined
12:37:14  * mjr_quit (Quit: mjr_)
12:37:23  * hij1nxquit (Quit: hij1nx)
13:00:21  * bnoordhuisjoined
13:35:15  <CIA-99>libuv: Frank Denis master * r4f1782a / src/unix/cygwin.c : cygwin: we need to include uv-common.h for uv__set_sys_error() - http://git.io/gexCtg
13:35:16  <CIA-99>libuv: Brandon Philips master * rd07f246 / (test/test-fs.c test/test-list.h):
13:35:17  <CIA-99>libuv: test: fs: add tests for read EOF
13:35:17  <CIA-99>libuv: This fix was merged without tests:
13:35:17  <CIA-99>libuv: https://github.com/philips/libuv/tree/fix-read-on-windows-to-handle-eof
13:35:17  <CIA-99>libuv: So take tests from igorzi:
13:35:17  <CIA-99>libuv: https://github.com/igorzi/libuv/commit/46024bf33dcc7fc922378fe0d8b4f59f4c2cd605 - http://git.io/36SIqA
13:37:08  * travis-cijoined
13:37:09  <travis-ci>[travis-ci] joyent/libuv#118 (master - d07f246 : Brandon Philips): The build is still failing.
13:37:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/5505f2e...d07f246
13:37:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/813796
13:37:09  * travis-cipart
13:41:30  <bnoordhuis>ircretary: tell piscisaureus_ review https://github.com/joyent/libuv/pull/326 and https://github.com/joyent/libuv/pull/327
13:41:30  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus_
14:15:09  <CIA-99>node: Colton Baker master * rc84b3c4 / lib/readline.js :
14:15:09  <CIA-99>node: readline: ignore stray escape sequence
14:15:09  <CIA-99>node: Fixes #2876. - http://git.io/D3MPLg
14:30:21  * travis-cijoined
14:30:21  <travis-ci>[travis-ci] joyent/node#565 (master - c84b3c4 : Colton Baker): The build is still failing.
14:30:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/408f450...c84b3c4
14:30:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/814158
14:30:21  * travis-cipart
14:58:47  * mmalecki[zzz]changed nick to mmalecki
15:28:12  * piscisaureus_joined
15:36:56  * felixgejoined
15:45:08  <piscisaureus_>indutny: I saw that you once sent a pull request for uv_uptime on windows. Why did that never get landed?
15:45:17  <piscisaureus_>The other implementations did, right?
16:03:18  <indutny>piscisaureus_: dunno
16:03:21  <indutny>can't remember
16:03:53  <piscisaureus_>indutny: https://github.com/joyent/libuv/issues/203
16:04:09  <piscisaureus_>indutny: it looks like we blatantly ignored your PR and igorzi implemented all of it :-)
16:04:20  <piscisaureus_>indutny: that's bad style, sorry
16:04:21  <indutny>piscisaureus_: hahahaha
16:04:23  <indutny>np
16:04:26  <indutny>I forgot about it
16:04:37  <indutny>:D
16:04:43  <indutny>brb
16:16:38  <bnoordhuis>piscisaureus_: did you review those PRs?
16:18:55  <piscisaureus_>bnoordhuis: yes.
16:20:19  <bnoordhuis>and?
16:20:38  <bnoordhuis>ah, just got the github notification email
16:22:06  <piscisaureus_>bnoordhuis: you should benchmark my v8string branch again with bytes/xxx
16:23:24  * isaacsjoined
16:26:42  <CIA-99>node: Shea Levy master * r024451c / lib/child_process.js :
16:26:42  <CIA-99>node: fork: don't clear environment by default
16:26:42  <CIA-99>node: - Set options.env to process.env instead of {} by default.
16:26:42  <CIA-99>node: - Shallow clone the passed options.env in case the user passed process.env directly. - http://git.io/gaeQIQ
16:28:57  <AndreasMadsen>Could someone take a look at this PR https://github.com/joyent/node/pull/706 , I just faced that issue.
16:30:31  <bnoordhuis>https://github.com/bnoordhuis/node/compare/v8tls <- quick win!
16:30:38  <piscisaureus_>bnoordhuis: can you review https://github.com/igorzi/node/commit/cfd18dbcc6060d97d30a1f2088fa605041443fdd? I think you are more familiar with that code.
16:30:51  <bnoordhuis>shaves off a couple of percentage points on http_simple
16:31:03  <piscisaureus_>nice
16:31:55  <bnoordhuis>piscisaureus_: i've seen that patch. didn't test it but generally lgtm
16:32:03  <piscisaureus_>bnoordhuis: I have a new approach for writing strings to sockets in my v8string branch, which makes a nice win.
16:32:12  <bnoordhuis>okay, i'll test that in a bit
16:32:41  <piscisaureus_>bnoordhuis: The idea is to not create a Buffer object in js land, but just export the string to a malloced region.
16:33:08  <piscisaureus_>bnoordhuis: this way we don't have all that overhead, plus we don't stress the (new Buffer) slab
16:33:26  <bnoordhuis>okay, let me pull from your repo
16:33:54  <bnoordhuis>you still haven't fixed the merge conflicts :)
16:34:16  <piscisaureus_>bnoordhuis: I also did another trick. I overallocate the memory so we don't need to compute the utf8 length, and we can do an unchecked write.
16:34:32  <bnoordhuis>unchecked meaning?
16:34:32  <piscisaureus_>bnoordhuis: eventually I want to disable that for very long strings but for small ones it should be fine
16:34:57  <piscisaureus_>bnoordhuis: not checking for target buffer overflow in the copy-convert code
16:35:43  <bnoordhuis>oh okay. what could possibly go wrong, right?
16:35:53  <piscisaureus_>https://github.com/piscisaureus/node/commit/cc65a2b4a164cb2d4e62fc763ebe2fe6263b2d1f
16:41:42  * travis-cijoined
16:41:42  <travis-ci>[travis-ci] joyent/node#566 (master - 024451c : Shea Levy): The build is still failing.
16:41:42  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c84b3c4...024451c
16:41:42  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/815170
16:41:42  * travis-cipart
16:53:00  * dapjoined
16:53:29  * stephankjoined
17:04:16  * perezdjoined
17:06:12  <bnoordhuis>piscisaureus_: that's what it looks like: https://gist.github.com/b4f7ef6e85420e06894a
17:08:30  <piscisaureus_>bnoordhuis: so what's the numbers
17:09:09  <piscisaureus_>bnoordhuis: callgrind is nice but it is not very meaningful to me
17:09:37  * isaacschanged nick to rms
17:09:37  <bnoordhuis>it's still quite a bit slower
17:09:49  <piscisaureus_>huh
17:09:49  * rmschanged nick to isaacs
17:09:52  <piscisaureus_>no fucking way
17:09:56  <bnoordhuis>you'll have to wait a bit because i'm recompiling everything again...
17:10:00  * isaacschanged nick to rms
17:10:06  * rmschanged nick to Guest43961
17:10:27  * Guest43961changed nick to isaacs
17:11:36  <isaacs>piscisaureus_: got a sec for my windows noobishness?
17:11:36  <isaacs>http://pastie.org/pastes/3535889/text
17:11:47  <isaacs>piscisaureus_: how do i reproduce this? i can't cd into a UNC path, it looks like
17:12:09  <isaacs>ERR! cwd \\davidebb-main\d$\test\NpmTest
17:12:27  <isaacs>C:\Users\Isaac Schlueter\project>cd \\WIN-7KF3EPK4B6V\$C\Users
17:12:27  <isaacs>'\\WIN-7KF3EPK4B6V\$C\Users'
17:12:27  <isaacs>CMD does not support UNC paths as current directories.
17:12:50  <isaacs>er, should be C$ not $C, but still, same error
17:12:53  <piscisaureus_>isaacs: that's true
17:13:04  <isaacs>so... how do you run npm in a UNC path cwd, if you can't cd into it?
17:13:14  <piscisaureus_>isaacs: from powershell
17:13:18  <isaacs>oohhh.... ok
17:13:36  <piscisaureus_>enter "powershell"
17:14:25  <isaacs>'\\WIN-7KF3EPK4B6V\C$\Users\Isaac Schlueter\project'
17:14:25  <isaacs>CMD.EXE was started with the above path as the current directory.
17:14:25  <isaacs>UNC paths are not supported. Defaulting to Windows directory.
17:14:26  <isaacs>C:\Windows
17:14:28  <isaacs>(empty)
17:14:33  <isaacs>that's hilarious
17:15:33  <piscisaureus_>isaacs: that happens if you invoke cmd.exe from powershell
17:15:37  <bnoordhuis>piscisaureus_: can you rebase your v8string branch against master?
17:15:45  * bnoordhuisis off to dinner
17:16:34  <isaacs>piscisaureus_: right, but since we don't have #! support in windows, that's how npm works
17:22:26  <piscisaureus_>isaacs: yeah. so thell the people complaining about that they have to invoke npm manually or map the share to a local drive
17:23:25  <isaacs>piscisaureus_: well, but that's just it. they're managing to invoke npm, but i'm not sure how.
17:23:44  <isaacs>and when i invoke it manually (c:\....\node c:\...\npm\cli.js install) it works fine
17:25:16  <piscisaureus_>isaacs: where's the bug?
17:25:38  <piscisaureus_>bnoordhuis: I rebased the v8string branch
17:25:59  <piscisaureus_>bnoordhuis: also for me bytes/1024 is quite a bit faster
17:26:00  <isaacs>piscisaureus_: https://github.com/isaacs/npm/issues/2230
17:27:13  <mmalecki>isaacs: minor thing, but tools/installer.js isn't being linted
17:29:51  <piscisaureus_>isaacs: can you derive from that log which command is failing?
17:30:02  <piscisaureus_>isaacs: that log <- http://pastie.org/pastes/3535889/text
17:31:27  <isaacs>mmalecki: hm. yeah, js files in tools probably should be linted as well.
17:31:32  <isaacs>if we own them, anyway
17:31:40  * TooTallNatejoined
17:31:46  <isaacs>piscisaureus_: i just commented on the bug
17:31:50  <mmalecki>isaacs: want a pull request or something?
17:32:01  <isaacs>piscisaureus_: i think the previous install failed, and npm isnt' as aggressive about cleaning up the cache as it should be on failure.
17:32:03  <isaacs>mmalecki: sure :)
17:33:05  <piscisaureus_>isaacs: well, the guy told you in the bug report that he was invoking it from powershell :-)
17:33:11  <piscisaureus_>isaacs: you didn't read it well
17:33:28  <piscisaureus_>isaacs: but anyway, this UNKNOWN error has to be fixed
17:33:46  <piscisaureus_>isaacs: but I can't tell from the log where it originates
17:34:11  <piscisaureus_>isaacs: it says
17:34:12  <piscisaureus_>ERR! error installing mkdirp@0.0.7
17:34:12  <piscisaureus_>info unbuild \\davidebb-main\d$\test\NpmTest\node_modules\mkdirp
17:34:12  <piscisaureus_>ERR! error rolling back mkdirp@0.0.7 Error: UNKNOWN, unknown error '\\davidebb-main\d$\test\NpmTest\node_modules\mkdirp'
17:34:44  <isaacs>piscisaureus_: that would be where it's trying to remove a directory
17:34:56  <piscisaureus_>aha
17:35:10  <isaacs>he said he's invoking it from powershell, but he's gotta be invoking it with the full path to the npm js file, which must be super painful
17:35:23  <isaacs>is there some kind of like npm.psh that we should be providing along with the cmd, maybe?
17:35:43  <piscisaureus_>isaacs: well, you could do that.
17:36:02  <piscisaureus_>isaacs: but as he explains he is not normally doing that. I think they are building an automated NPM install tool for azure.
17:36:18  <piscisaureus_>isaacs: so npm would be invoked programmatically
17:36:24  * AndreasMadsenquit (Remote host closed the connection)
17:36:47  <isaacs>right
17:37:15  <mmalecki>piscisaureus_: point them at haibu (we do it right (tm))
17:37:33  <piscisaureus_>mmalecki: steveb@microsoft.com
17:38:09  <mmalecki>piscisaureus_: Steve Ballmer?
17:40:00  <piscisaureus_>isaacs: there is some rmdir retry code in NPM to work around locked directories right?
17:41:29  <isaacs>piscisaureus_: i don't think so
17:41:33  <isaacs>piscisaureus_: oh, wait, maybe
17:42:00  <isaacs>piscisaureus_: yeah, if it gets an EBUSY, then it retries up to 3 times
17:42:09  <isaacs> if (er.code === "EBUSY" && busyTries < exports.BUSYTRIES_MAX) {
17:42:09  <isaacs> var time = (exports.BUSYTRIES_MAX - busyTries) * 100
17:42:09  <isaacs> busyTries ++
17:42:11  <isaacs> // try again, with the same exact callback as this one.
17:42:12  <isaacs> return setTimeout(function () {
17:42:14  <isaacs> rimraf_(p, CB)
17:42:16  <isaacs> })
17:42:17  * igorzi_joined
17:42:18  <isaacs> }
17:42:50  <piscisaureus_>isaacs: yeah. It seems that windows reports a different error when a remote directory is locked, so we report UNKNOWN
17:43:10  <piscisaureus_>oh wait - heh
17:43:17  <piscisaureus_>we always report UNNOWN
17:43:18  <isaacs>wait, that code is not doing what it ought to do...
17:43:38  <isaacs>oh, also, this dates back to the cygwin days
17:45:28  * igorziquit (Ping timeout: 245 seconds)
17:46:27  <isaacs>piscisaureus_: that sounds like a bug :)
17:47:07  * piscisaureus__joined
17:52:58  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:56:46  * piscisaureus__joined
18:01:18  * igorzi_quit (Ping timeout: 245 seconds)
18:01:22  * mikealquit (Quit: Leaving.)
18:01:33  * mikealjoined
18:02:10  * mikealquit (Remote host closed the connection)
18:02:19  * `3rdEdenjoined
18:02:22  * mikealjoined
18:02:33  * mikealquit (Remote host closed the connection)
18:02:50  * mikealjoined
18:03:39  * mikealquit (Client Quit)
18:05:32  * mikealjoined
18:20:30  * AvianFluquit (Quit: Leaving)
18:21:46  * pieternjoined
18:24:44  * dshaw_joined
18:25:02  * mikealquit (Quit: Leaving.)
18:27:16  * mikealjoined
18:28:42  * paddybyersquit (Read error: Connection reset by peer)
18:28:49  * paddybyersjoined
18:32:23  * mjr_joined
18:35:16  * paddybyers_joined
18:35:16  * paddybyersquit (Read error: Connection reset by peer)
18:35:17  * paddybyers_changed nick to paddybyers
18:38:42  * paddybyers_joined
18:38:42  * paddybyersquit (Read error: Connection reset by peer)
18:38:43  * paddybyers_changed nick to paddybyers
18:48:05  * mjr_quit (Quit: mjr_)
18:49:16  * paddybyers_joined
18:50:22  * paddybyers__joined
18:50:22  * paddybyers_quit (Read error: Connection reset by peer)
18:51:06  * paddybyersquit (Read error: Connection reset by peer)
18:51:06  * paddybyers__changed nick to paddybyers
18:54:48  * paddybyersquit (Read error: Connection reset by peer)
18:55:38  * paddybyersjoined
18:57:24  * indutnychanged nick to indutny_sleeping
19:03:59  * mjr_joined
19:09:04  * brsonjoined
19:18:46  <CIA-99>node: Yoshihiro Kikuchi master * rf82ef0f / lib/http.js :
19:18:47  <CIA-99>node: http: remove ClientRequest.prototype.pause()
19:18:47  <CIA-99>node: ClientRequest.prototype.pause() is not needed. ClientRequest is a writable
19:18:47  <CIA-99>node: stream and deferring to OutgoingMessage.prototype.pause() is broken, the method
19:18:47  <CIA-99>node: does not exist. - http://git.io/irKC7w
19:25:42  * dshaw_quit (Quit: Leaving.)
19:33:10  * AndreasMadsenjoined
19:34:01  * travis-cijoined
19:34:01  <travis-ci>[travis-ci] joyent/node#567 (master - f82ef0f : Yoshihiro Kikuchi): The build is still failing.
19:34:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/024451c...f82ef0f
19:34:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/816342
19:34:01  * travis-cipart
19:36:27  * AvianFlujoined
19:44:55  <bnoordhuis>okay, maybe thread-local storage doesn't make that much of a difference after all :(
19:48:08  <piscisaureus_>isaacs: it seems that when rolling back NPM is trying to rmdir a directory that is not empty. Does that work on unices?
19:48:23  <isaacs>kewl/
19:48:29  <isaacs>why is it not empty?
19:48:42  <piscisaureus_>isaacs: cuz windows says so :-)
19:48:42  <isaacs>(no, that doesn't work on unix)
19:49:03  <isaacs>piscisaureus_: rimraf only rmdir's once it's successfully (according to node) unlinked all the files in that dir.
19:49:17  <isaacs>piscisaureus_: is node calling the cb before the files are done unlinking?
19:50:21  <piscisaureus_>isaacs: hmm, let me figure that out
19:52:53  * felixgequit (Quit: felixge)
19:54:21  * dshaw_joined
19:55:41  * mikealquit (Quit: Leaving.)
19:56:11  * paddybyersquit (Ping timeout: 260 seconds)
19:58:10  * felixgejoined
19:58:10  * felixgequit (Changing host)
19:58:10  * felixgejoined
20:01:33  <piscisaureus_>isaacs: is all file writing done via WriteStream in npm?
20:01:37  <piscisaureus_>(it's so big)
20:03:54  <isaacs>piscisaureus_: hm... i am not sure of that.
20:04:03  <isaacs>piscisaureus_: i'm pretty sure i call fs.writeFile here and there
20:04:26  <piscisaureus_>isaacs: writeFile is fine. fs.write is not
20:05:04  <isaacs>piscisaureus_: no, it's always either writeFile or a WriteStream
20:10:15  <piscisaureus_>isaacs: what do you get if you try to remove an non-empty directory on unix?
20:10:18  <piscisaureus_>(with node)
20:11:10  <bnoordhuis>piscisaureus_: exec("rm -rf " + dir)
20:11:26  <bnoordhuis>there's so much wrong with that example...
20:11:42  <piscisaureus_>bnoordhuis: I want to know what error code you get in node
20:12:09  <piscisaureus_>bnoordhuis: `mkdir foo && echo bar > foo/bar`
20:12:23  <piscisaureus_>bnoordhuis: node -e "require('fs').rmdirSync('foo')"
20:13:09  <bnoordhuis>at a guess, EEXIST
20:13:12  <bnoordhuis>but i'll try it
20:13:52  <bnoordhuis>piscisaureus_: Error: UNKNOWN, unknown error 'tmp/'
20:13:58  <piscisaureus_>right
20:14:03  <piscisaureus_>writing a patch
20:14:06  <bnoordhuis>which probably means we haven't mapped ENOTEMPTY
20:14:14  <piscisaureus_>yup
20:14:25  <bnoordhuis>rmdir("tmp/") = -1 ENOTEMPTY (Directory not empty) <- yup indeed
20:19:09  * perezd_joined
20:21:12  * perezdquit (Ping timeout: 276 seconds)
20:21:13  * perezd_changed nick to perezd
20:28:38  <CIA-99>libuv: Bert Belder maperr * r1ac71a3 / (include/uv.h src/unix/error.c src/win/error.c): Map EBUSY and ENOTEMPTY errors - http://git.io/IZKzCQ
20:28:58  <piscisaureus_>^^ bnoordhuis / igorzi - review?
20:30:16  * travis-cijoined
20:30:16  <travis-ci>[travis-ci] joyent/libuv#119 (maperr - 1ac71a3 : Bert Belder): The build failed.
20:30:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/1ac71a3
20:30:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/816667
20:30:16  * travis-cipart
20:31:30  <bnoordhuis>piscisaureus_: lgtm
20:32:22  <CIA-99>libuv: Bert Belder v0.6 * r1ac71a3 / (include/uv.h src/unix/error.c src/win/error.c): Map EBUSY and ENOTEMPTY errors - http://git.io/IZKzCQ
20:34:03  * travis-cijoined
20:34:03  <travis-ci>[travis-ci] joyent/libuv#120 (v0.6 - 1ac71a3 : Bert Belder): The build is still failing.
20:34:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b3fe183...1ac71a3
20:34:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/816697
20:34:03  * travis-cipart
20:34:45  * mikealjoined
20:54:02  <bnoordhuis>slow recompile is slow...
20:54:45  * igorzijoined
20:58:32  * saghulquit (Ping timeout: 272 seconds)
21:03:24  * brsonquit (Ping timeout: 252 seconds)
21:03:39  <bnoordhuis>isaacs, piscisaureus_: https://github.com/bnoordhuis/node/compare/benchmark <- 4.5% increase in http_simple buffer/32 performance
21:03:50  <isaacs>bnoordhuis++
21:03:51  <kohai>bnoordhuis has 11 beers
21:04:02  <bnoordhuis>yeah, wait until you see it - it's not pretty :)
21:04:23  <isaacs>bnoordhuis: deps/v8/src/platform-linux.cc??
21:04:25  <isaacs>srsly?
21:04:39  <isaacs>;P
21:04:40  <bnoordhuis>but it turns out that v8's tls and MakeCallback() are the most expensive functions
21:04:47  * brsonjoined
21:05:11  <bnoordhuis>now http_parser_execute() is at the top of profiler graph, as it should be
21:06:09  <isaacs>interesting
21:06:43  <bnoordhuis>so it looks like we need to rethink MakeCallback()
21:06:57  <bnoordhuis>and send a patch to v8 that makes tls optional
21:12:08  <piscisaureus_>bnoordhuis: yes, MakeCallback shows up on high on windows too
21:12:18  <piscisaureus_>bnoordhuis: (tls does not btw)
21:12:39  <piscisaureus_>except on windows-x64, tls seems to be slow there
21:13:00  <bnoordhuis>i wonder why that is
21:13:08  <bnoordhuis>pthread_getspecific() is pretty optimized
21:13:37  <piscisaureus_>bnoordhuis: I would still like to see the ab output for bytes/1024
21:13:40  <bnoordhuis>i wasn't able to beat it with hand-coded tls
21:13:54  <bnoordhuis>piscisaureus_: with or without your patch?
21:13:57  <piscisaureus_>bnoordhuis: for me it bumps from 5900 to 6400 so that's significant
21:14:03  <piscisaureus_>bnoordhuis: both :-)
21:14:12  <bnoordhuis>aww, so much recompiling
21:14:17  <piscisaureus_>bnoordhuis: aah - I am interested in my patch
21:14:23  <bnoordhuis>i need to get a laptop with more cores...
21:14:27  <piscisaureus_>bnoordhuis: you should keep 2 working copies
21:14:39  <bnoordhuis>yeah
21:14:42  <piscisaureus_>bnoordhuis: or use your mac
21:14:56  <bnoordhuis>no reliable valgrind on the mac
21:15:04  <bnoordhuis>did you rebase your patch?
21:15:11  <piscisaureus_>bnoordhuis: yes
21:15:19  <bnoordhuis>okay, /me compiles
21:15:58  <piscisaureus_>bnoordhuis: it has to compile with NDEBUG btw, there is a really slow assert in there otherwise (that verifies the assumptions I make when I decide to do an unchecked write)
21:17:09  * igorzi_joined
21:17:22  <bnoordhuis>piscisaureus_: okay... do i need to modify common.gypi or ?
21:18:02  * isaacsis working on setting up a few build slaves on JPC
21:18:25  <TooTallNate>isaacs++
21:18:26  <kohai>isaacs has 9 beers
21:18:36  <isaacs>i'd like to have a service where we can push a branch, and then compare benchmarks between then
21:18:46  <bnoordhuis>that would be sweet
21:19:09  <isaacs>the first step is to automate a lot of the manual steps that go into making a build.
21:19:13  <isaacs>becasue that shit is making me crazy.
21:19:37  * igorziquit (Ping timeout: 245 seconds)
21:19:46  <piscisaureus_>bnoordhuis: no
21:20:02  <piscisaureus_>bnoordhuis: there's a commit in the tree that does it
21:20:08  <TooTallNate>bnoordhuis: just compile in Release mode
21:20:26  <piscisaureus_>TooTallNate: well, NDEBUG is currently off even in release mode
21:20:27  <bnoordhuis>TooTallNate: that still doesn't help if you have to recompile all of v8
21:20:34  <bnoordhuis>or was that about NDEBUG?
21:20:46  <TooTallNate>i thought Release mode added NDEBUG
21:21:06  * TooTallNatedon't mind me, don't really know what you're talking about :p
21:21:41  <piscisaureus_>TooTallNate: NDEBUG got disabled at some point. imho it has to be enabled again before 0.8.0 drops
21:22:45  <TooTallNate>piscisaureus_: ahh you're right, however Debug mode still adds DEBUG flag
21:22:53  <TooTallNate>and _DEBUG
21:22:54  <bnoordhuis>*sigh* forgot to `cp -a`, now it's rebuilding everything again...
21:22:57  <piscisaureus_>TooTallNate: that's righj
21:23:10  * AndreasMadsenquit (Remote host closed the connection)
21:23:24  <TooTallNate>why was NDEBUG removed? and what projects use it?
21:23:41  <piscisaureus_>TooTallNate: NDEBUG disables asserts
21:24:18  <TooTallNate>piscisaureus_: ahhh, sweet. learned something new about c today :)
21:24:18  <TooTallNate>thanks
21:28:06  <TooTallNate>bnoordhuis: got another c question: why the do {} while (0) thing in the macro?
21:28:53  <bnoordhuis>TooTallNate: to make statements like `if (cond) foo(); else bar();` work (where foo and bar are macros)
21:29:26  <TooTallNate>bnoordhuis: clever
21:29:35  * felixgequit (Quit: felixge)
21:32:11  <bnoordhuis>piscisaureus_: out/Release/node benchmark/http_simple_auto.js -c 100 -n 100000 bytes/1024
21:32:22  <bnoordhuis>with your patch: 4891.52 req/s
21:32:32  <bnoordhuis>without: 5031.41 req/s
21:33:02  <bnoordhuis>want me to profile it with callgrind?
21:34:04  <piscisaureus_>bnoordhuis: that is very weird and quite unexpected.
21:34:11  <piscisaureus_>bnoordhuis: since here it is the other way round
21:34:21  <piscisaureus_>bnoordhuis: can you try with a different number of bytes btw?
21:34:25  <piscisaureus_>just for my info?
21:34:29  <bnoordhuis>like?
21:34:36  <piscisaureus_>dunno, 10kb?
21:35:05  <bnoordhuis>okay
21:35:14  <piscisaureus_>bnoordhuis: to be honest, I quite heavily optimized with/for msvc
21:35:16  * mikealquit (Quit: Leaving.)
21:36:33  <bnoordhuis>piscisaureus_: seems a little faster now
21:36:51  <bnoordhuis>with your patch: 4354.42
21:37:00  <bnoordhuis>without: 4149.98
21:37:27  <bnoordhuis>so that's almost 5% faster
21:37:31  <bnoordhuis>let me try bytes/1024 again
21:38:58  <bnoordhuis>4419.65 vs 4316.87 now, good
21:39:03  <CIA-99>node: Igor Zinkovsky master * r5ad0140 / (lib/http.js test/simple/test-http-pause-resume-one-end.js):
21:39:03  <CIA-99>node: Emit end event only once
21:39:03  <CIA-99>node: fixes #2888
21:39:03  <CIA-99>node: Previously a pair of end events would be emitted if a response was
21:39:03  <CIA-99>node: paused/resumed, and the underlying socket was closed while the
21:39:03  <CIA-99>node: response was paused - http://git.io/BIITRw
21:39:29  <bnoordhuis>odd that it was slower the last two times...
21:39:30  <piscisaureus_>bnoordhuis: (only if you're interested)
21:40:53  <piscisaureus_>bnoordhuis: if you chop up http_simple.js a little bit so the string gets constructed differently (like `a = 'C' + a`, or `a += a` instead of `a += c`), or including some unicode characters in there, the difference will be way bigger
21:41:17  <piscisaureus_>bnoordhuis: what http_simple tests is the case where the "new" method performs worst
21:42:16  <piscisaureus_>bnoordhuis: and funny enough, it happens to be the case where the v8 method performs best
21:42:27  <bnoordhuis>i'll give it a spin
21:46:35  <bnoordhuis>hah, almost 9.5% speedup
21:46:43  <igorzi_>isaacs piscisaureus_: https://gist.github.com/1996441
21:46:51  <igorzi_>(with additional error mapping)
21:47:17  <piscisaureus_>igorzi_: yeah, I am looking at that too. Something really funny is going on.
21:47:44  <piscisaureus_>igorzi_: I can reproduce in about 25% of the cases or so
21:48:59  <bnoordhuis>piscisaureus_: https://gist.github.com/2c62b4e8d151a64a918b <- it's with that patch that i'm seeing the 9.5% speedup
21:49:01  <bnoordhuis>pretty impressive
21:49:15  <igorzi_>piscisaureus_: verbose mkdir (expected) error ENOENT, no such file or directory '\\igorzi-dev8\public\igorzi-dev8'
21:50:00  <igorzi_>piscisaureus_: nm, i guess this is expected
21:51:05  <piscisaureus_>bnoordhuis: the magic is not really in the new string writer btw (it is in some cases - like when there is unicode in there)
21:51:10  <piscisaureus_>bnoordhuis: it is mostly this - https://github.com/piscisaureus/node/commit/816ef22fbf2158d8ab4063fcab109a702d02ee19
21:51:27  <piscisaureus_>bnoordhuis: convert string to buffer in the binding layer
21:52:12  <bnoordhuis>piscisaureus_: i actually tried something like that a couple of days ago but i didn't see much of a speedup
21:52:46  <piscisaureus_>bnoordhuis: part of it is also in skipping utf8length(), and just allocate three times the string length instead
21:53:13  <bnoordhuis>is that what String::Utf8Value() does?
21:53:37  <bnoordhuis>calculating the byte length, i mean?
21:53:54  <piscisaureus_>bnoordhuis: no, String->Utf8Length() does that
21:54:12  <piscisaureus_>bnoordhuis: we're not using string::Utf8Value for creating buffers, that would be even more retarded
21:58:44  <igorzi_>piscisaureus_: i'm actually able to reproduce pretty much every time
21:58:57  <igorzi_>piscisaureus_: and every time i get: npm ERR! Error: ENOENT, no such file or directory 'Z:\node_modules\mkdirp\package.json'
22:00:13  <piscisaureus_>igorzi_: yeah, funny innit :-)
22:01:19  <isaacs>piscisaureus_: https://github.com/isaacs/npm/blob/af7a466e53c096e54534009e89304e16a7ef1828/lib/utils/tar.js#L192
22:01:27  <isaacs>piscisaureus_: should i just test for EBUSY and UNKNOWN there?
22:01:42  <isaacs>piscisaureus_: it's pretty safe to get a false positive.
22:01:43  <piscisaureus_>isaacs: just test for EBUSY and EACCESS
22:01:58  <isaacs>the only hazard of testing for UNKNOWN is that it might take a second longer to fail
22:01:58  <piscisaureus_>isaacs: testing for UNKOWN seems rather odd :_)
22:02:03  <isaacs>and spin the disk a bit.
22:02:19  <piscisaureus_>emit some CO2
22:02:22  <isaacs>yeah
22:02:23  <isaacs>meh
22:02:33  <isaacs>people drive cars. whatever.
22:02:38  <piscisaureus_>Oh, right, you're american :-)
22:02:42  <isaacs>mother nature's too high and mighty.
22:02:47  <isaacs>needs to be put in her place sometimes.
22:03:45  <piscisaureus_>isaacs: that slide/chain thing is virtually impossible to debug :-/
22:06:33  <isaacs>piscisaureus_: what do you mean, man?
22:06:39  <isaacs>piscisaureus_: it's just "do this function, then do the next one"
22:07:11  <igorzi_>isaacs: here's what i get every time: https://gist.github.com/1996552
22:07:19  <isaacs>it's like a 20 like module, man.
22:08:02  <igorzi_>isaacs: i'm not sure how exactly to read the log, but isn't it failing because of "Error: ENOENT, no such file or directory 'Z:\node_modules\mkdirp\package.json'" ?
22:09:08  <isaacs>igorzi_: yeah, but then fails to rollback
22:09:12  <isaacs>it's weird
22:09:36  <piscisaureus_>apparently it's writeFile that is failing
22:12:34  * rendarquit
22:14:49  <isaacs>piscisaureus_: weird.
22:19:31  <igorzi_>is there a way to tell from the log what operation causes the error?
22:19:45  <igorzi_>isaacs piscisaureus_: --^
22:20:59  <piscisaureus_>isaacs: oh wait, it's just unpack() that errs
22:21:15  <piscisaureus_>igorzi_: no there isn't. I am chopping up chain.js to console.log what it does
22:26:16  <isaacs>piscisaureus_: when i want logging that insane, i usually just run it through dtruss, but i guess there is no such thing in windows?
22:29:01  * bnoordhuisquit (Ping timeout: 260 seconds)
22:29:19  <piscisaureus_>isaacs: yes I am trying with process monitor
22:29:30  <isaacs>kewl
22:29:35  <piscisaureus_>isaacs: the problem is, the slowdown caused by that makes the error go away
22:29:40  <isaacs>ew
22:29:44  <isaacs>that sucks
22:30:00  <isaacs>how do you reproduce the problem?
22:30:14  * `3rdEdenquit (Quit: Leaving...)
22:30:23  <piscisaureus_>isaacs: `npm install express` on a remote share
22:30:36  <piscisaureus_>isaacs: errs in about 1 in 3 cases for me
22:31:14  * mikealjoined
22:31:44  <isaacs>hmm..
22:32:52  <piscisaureus_>igorzi_: this is funny, it shows up in process explorer
22:32:54  <piscisaureus_>11:29:41.1717471 PM node.exe 5956 IRP_MJ_QUERY_INFORMATION \\PISCISAUREUS\Users\Public\node_modules\express\node_modules\___connect.npm\package\lib\middleware BUFFER OVERFLOW Type: QueryAllInformationFile, CreationTime: 3/7/2012 11:30:00 PM, LastAccessTime: 3/7/2012 11:30:16 PM, LastWriteTime: 3/7/2012 11:30:16 PM, ChangeTime: 3/7/2012 11:30:16 PM, FileAttributes: D, AllocationSize: 4,096, EndOfFile: 4,096, NumberOfLi
22:33:10  <piscisaureus_>igorzi_: buffer overflow on stat() ?
22:33:30  <isaacs>hm. maybe it's just that my windows is in a VM, but it works 100% of the time.
22:43:37  * paddybyersjoined
22:43:50  <igorzi_>piscisaureus_: i see a bunch of "CreateFile \\igorzi-devsun\public\node_modules\mkdirp\package.json NAME NOT FOUND Desired Access: Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a"
22:51:17  * `3rdEdenjoined
23:04:00  <piscisaureus_>igorzi_: we should change node_file.cc to include the syscall name when an error happens for an asynchronous operation
23:04:28  <piscisaureus_>igorzi_: also, it would be nice if the callback would be deferred to the next tick on immediate failure (although I think that should never happen)
23:14:41  <piscisaureus_>igorzi_: https://gist.github.com/1997086 <-- review?
23:23:03  * `3rdEdenquit (Quit: Leaving...)
23:26:15  * mikealquit (Quit: Leaving.)
23:40:30  * `3rdEdenjoined
23:43:08  * mikealjoined
23:47:24  * AvianFluquit (Quit: Leaving)
23:56:34  * mikealquit (Quit: Leaving.)