00:07:31  * ericktquit (Read error: Operation timed out)
00:34:34  * mikealquit (Quit: Leaving.)
00:48:36  * EhevuTov_quit (Quit: This computer has gone to sleep)
00:54:19  * avalanche123quit (Quit: Computer has gone to sleep.)
00:58:59  * arlolraquit (Quit: Linkinus - http://linkinus.com)
01:01:28  * hij1nxjoined
01:11:44  * dapquit (Quit: Leaving.)
01:16:29  <joeandaverde>creationix: around?
01:45:16  * lohkeypart
01:53:36  <benvie>wow
01:53:42  <benvie>this libuv book is awesome
01:55:02  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:19:35  * chobi_e_changed nick to chobi_e
02:23:28  * beachdogquit (Remote host closed the connection)
02:26:13  * charliesomejoined
02:30:24  * joeandaverdequit (Quit: Leaving)
02:33:47  * chobi_echanged nick to chobi_e_
02:37:58  * joeandaverdejoined
02:38:05  * blackorzarquit (Remote host closed the connection)
03:25:46  * brsonquit (Quit: leaving)
03:40:34  * TheJHquit (Ping timeout: 264 seconds)
04:18:09  * brsonjoined
04:30:38  * mikealjoined
04:31:53  * mikealquit (Client Quit)
05:14:56  * AlbireoXchanged nick to AlbireoX`Away
05:45:09  * dshaw_joined
05:51:02  * blackorzarjoined
05:51:02  * AvianFluchanged nick to AvianusAsleepus
05:58:42  * ericktjoined
06:12:09  <joeandaverde>wtkf
06:12:14  <joeandaverde>chunked encoding...
06:12:23  <joeandaverde>headers after the data?
06:12:31  <joeandaverde>something seems so odd about that
06:42:40  * paddybyersjoined
06:46:13  * ericktquit (Quit: erickt)
06:57:49  * paddybyersquit (Quit: paddybyers)
07:03:19  * dlkfjjoined
07:16:45  * dshaw_quit (Quit: Leaving.)
07:30:52  * dominictarrquit (Quit: Leaving)
07:32:56  * dlkfjquit
07:34:33  * rendarjoined
08:02:08  * dshaw_joined
08:11:03  * stagasjoined
08:16:31  * brsonquit (Read error: Connection reset by peer)
08:16:48  * brsonjoined
08:27:13  * charliesomequit (Remote host closed the connection)
08:27:36  * charliesomejoined
08:48:24  * brsonquit (Quit: leaving)
08:54:36  <deoxxa>joeandaverde: technically they're "trailers"
08:55:03  <deoxxa>joeandaverde: they make sense for some stuff like message digests
09:21:36  * blackorzarquit (Ping timeout: 240 seconds)
10:09:22  * bnoordhuisjoined
10:42:21  * TheJHjoined
11:10:14  * mmaleckijoined
11:43:07  * txdvquit (Read error: Operation timed out)
11:45:16  * txdvjoined
12:03:15  * mikealjoined
12:12:16  * beachdogjoined
12:15:29  <CIA-108>node: Ben Noordhuis v0.8 * rd559bed / src/ev-emul.h : node: use variadic functions in ev-emul.h - http://git.io/_ODXZg
12:18:43  <mmalecki>hm, why isn't util.pump deprecated?
12:39:21  * Leomjoined
12:42:32  * stagasquit (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner 1.9.0.17/2009122204])
12:51:26  * beachdogquit (Remote host closed the connection)
13:05:08  * mmaleckichanged nick to mmalecki[food]
13:05:14  * Leomquit (Ping timeout: 250 seconds)
13:09:24  * dshaw_quit (Quit: Leaving.)
13:36:36  * Leomjoined
14:00:06  * hij1nxquit (Quit: hij1nx)
14:12:07  * blackorzarjoined
14:15:54  <bnoordhuis>/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so when searching for -lstdc++
14:15:54  <bnoordhuis>/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a when searching for -lstdc++
14:15:54  <bnoordhuis>/usr/bin/ld: cannot find -lstdc++
14:16:09  <bnoordhuis>why the hell is gyp trying to link to libstdc++ in a c only project?
14:29:30  <indutny>bnoordhuis: haha
14:29:37  <indutny>because it's a true way to write C
14:30:16  <indutny>I suppose you do not have .cpp, nor .cc files in the project?
14:30:47  <bnoordhuis>none, it's libuv
14:31:05  <bnoordhuis>it's because gyp runs g++ to link instead of ld
14:33:03  <indutny>oh
14:33:04  <indutny>nice
14:34:45  * hij1nxjoined
14:53:31  * AvianusAsleepuschanged nick to AvianFlu
14:57:11  <CIA-108>libuv: Ben Noordhuis v0.8 * r4fe369b / test/benchmark-sizes.c : test: add uv_fs_event_t to benchmark-sizes.c - http://git.io/St_ndg
14:57:12  <CIA-108>libuv: Ben Noordhuis v0.8 * rb5b8ead / (test/test-fs-event.c test/test-list.h): test: add failing fs_event test - http://git.io/D_AKYA
14:57:14  <CIA-108>libuv: Ben Noordhuis v0.8 * rec76a42 / test/benchmark-sizes.c : test: add uv_loop_t to benchmark-sizes.c - http://git.io/3Dtq2w
14:57:15  <CIA-108>libuv: Ben Noordhuis v0.8 * r4fe1916 / (3 files in 3 dirs): linux: fix 'two watchers, one path' segfault - http://git.io/o1scSQ
14:57:23  <CIA-108>node: Ben Noordhuis v0.8 * r879d329 / (7 files in 4 dirs): deps: upgrade libuv to 4fe1916 - http://git.io/Sjj9vg
14:57:58  * Leomquit (Ping timeout: 264 seconds)
14:59:01  * travis-cijoined
14:59:01  <travis-ci>[travis-ci] joyent/libuv#502 (v0.8 - 4fe1916 : Ben Noordhuis): The build is still failing.
14:59:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/22f004db61c1...4fe1916926f9
14:59:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1976820
14:59:01  * travis-cipart
15:13:11  * piscisaureus_joined
15:13:30  <joeandaverde>ping?
15:43:31  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:47:00  * hij1nxquit (Quit: hij1nx)
16:00:11  * joeandaverdequit (Quit: Leaving)
16:00:42  * joeandaverdejoined
16:02:11  <bnoordhuis>joeandaverde: pong?
16:02:19  <joeandaverde>hmm, i did reconnect
16:02:26  <joeandaverde>i hadn't seen anything since 1 am last night
16:03:24  <bnoordhuis>oh, that's too bad - you missed the grand party
16:03:30  <joeandaverde>damn
16:03:45  <bnoordhuis>hookers, blackjack, it had everything
16:52:19  * charliesomequit (Quit: Textual IRC Client: www.textualapp.com)
16:57:05  * dominictarrjoined
17:03:40  * AlbireoX`Awaychanged nick to AlbireoX
17:23:48  * chobi_e_changed nick to chobi_e
17:42:40  * mikealquit (Quit: Leaving.)
17:54:58  <tjfontaine>there was a bouncy house and a clown making balloon animals
18:03:55  * joeandaverdequit (Ping timeout: 240 seconds)
18:06:29  <isaacs>why do we do 'eval(process._eval)' as the script instead of just process._eval?
18:06:33  <isaacs>seems kind of weird
18:06:45  <isaacs>and makes the ^^^ output wrong and weird and useless
18:07:08  * mikealjoined
18:07:51  * mikealquit (Client Quit)
18:15:08  * c4milojoined
18:20:42  <isaacs>oic, it's the completion value, since we wrap in a function.
18:20:44  <isaacs>hgm.
18:21:50  * mikealjoined
18:29:00  * paddybyersjoined
18:34:06  * joeandaverdejoined
18:34:44  * paddybyersquit (Quit: paddybyers)
18:41:27  <ryah>\o/
18:41:33  <ryah>computers!
18:44:03  <AvianFlu>ryah, ++
18:44:03  <kohai>ryah has 3 beers
18:44:43  <isaacs>ryah: is the pattern of lights looking correct today?
18:45:23  <isaacs>the lights are all wrong over here. i keep pushing buttons, and it doesnt seem to be helping.
18:47:29  <ryah>yes, they are blinking in a pleasent rhythm
18:48:30  <joeandaverde>arduino fun?
18:48:33  * c4miloquit (Read error: Connection reset by peer)
18:48:50  <indutny>heh
18:48:57  <indutny>I'm fighting with AEC
18:49:02  <indutny>lights are pretty dummy there
18:49:30  * ryahbites his lip. man. not saying anything is difficult.
18:50:25  <indutny>that thing with echoes is really tough
18:50:40  <indutny>since playback/recording runs in different threads
18:50:48  <indutny>and handling runs in another event loop :D
18:51:10  <indutny>I need to figure out what buffer from playback to use when canceling echo from just recorded data
18:53:00  <isaacs>man, i think sometimes that programming is like some kind of personality defect.
18:53:16  <isaacs>it's really bugging me that our syntax error reporting is wrong with node -pe
18:54:30  <ryah>isaacs: how so?
18:54:41  <isaacs>ryah: node --use_strict -pe 'with(this){}'
18:54:49  * piscisaureus_joined
18:54:57  <isaacs>you get a ^^^^ pointing at nothing
18:54:59  <ryah>isaacs: i see
18:55:03  <isaacs>it'd be nice if it actually showed the code
18:55:04  <piscisaureus_>hello
18:55:07  <ryah>yes, that's crappy
18:55:07  <isaacs>but it can't because we wrap in eval()
18:55:13  <isaacs>which we do because we need to get the completion value
18:55:19  <isaacs>and we *also* wrap in a function
18:55:25  * c4milojoined
18:55:28  <isaacs>and js doesn't have auto-returns
18:55:31  <isaacs>except from eval.
18:55:34  <ryah>hm
18:55:36  * isaacsrageface
18:55:46  <ryah>can you put a "return" in the wrap function?
18:56:02  <isaacs>ryah: node --use_strict -pe 'foo=bar; with(this){}'
18:56:15  <isaacs>ryah: if you add a return, it's not good.
18:56:23  <isaacs>that's why we do return eval(process._eval)
18:56:30  <isaacs>so that the eval grabs the completion value, then we return it
18:56:42  <ryah>oh, you knw what i think from the c++ interface v8::Script - it auto returns the last value
18:56:46  <ryah>if you execute it
18:56:54  <isaacs>yeah
18:57:03  <isaacs>but that also obscures the ^^^^
18:57:10  <isaacs>points at the place where you did vm.runInThisContext
18:57:21  * isaacsis like 50 lines of patch into this now
18:58:09  <isaacs>now, i *could* do it by using with(){} instead of a wrapper function, ironically, but !!! use_strict removes that and that's the whole point!
18:58:54  <ryah>heh
18:59:00  <isaacs>ie, instead of function(require,exports,module,__dirname,__filename){codez}, it could be with({require:require,module:module,...}){codez}
18:59:04  <isaacs>then we'd get the completion value
18:59:33  <piscisaureus_>isaacs: wait, does with return a value?
18:59:39  <isaacs>or we could just run it in the global
19:00:05  <isaacs>piscisaureus_: vm.runInThisContext('with({foo:100}) { foo }') === 100
19:00:24  <piscisaureus_>ah, right
19:01:10  <piscisaureus_>isaacs: what about
19:01:10  <piscisaureus_>`var require = __require; delete __require; 100` :-)
19:05:04  <piscisaureus_>ryah: did you op everybody again in node.js ?
19:10:46  <isaacs>ok, i'm gonna back away from this syntax error reporting on node-pe
19:10:54  <isaacs>it's not fixable. fuck it.
19:10:57  <ryah>piscisaureus_: there's a bot now so people can op themselves
19:11:11  <piscisaureus_>ryah: why?
19:11:15  <ryah>fun
19:11:18  <piscisaureus_>ryah: ok
19:11:27  <piscisaureus_>ryah: well, anyway, I am killing the log bot
19:11:35  <ryah>why?
19:11:42  <ryah>i use it all the time
19:11:56  <piscisaureus_>ryah: because people ban it when you do this op stuff
19:12:03  <piscisaureus_>ryah: and I am sick of fixing it all the time
19:12:08  <ryah>:/
19:12:12  <piscisaureus_>ryah: so either you knock it off or it is dead
19:12:21  <piscisaureus_>ryah: I have more fun things to waste my time on
19:12:23  <ryah>let's just tell them to not ban it
19:12:32  <ryah>what's the bot's name?
19:12:36  <piscisaureus_>slurp
19:12:45  * brsonjoined
19:13:00  <piscisaureus_>yeah, like that's gonna work
19:13:18  <joeandaverde>lol
19:14:31  <isaacs>piscisaureus_: if you can figure out how to make slurp registered, i'll give it all kinds of op super rights
19:14:54  * dominictarrquit (Ping timeout: 246 seconds)
19:14:57  <piscisaureus_>I will try
19:15:06  <piscisaureus_>disabling node.js for the time being
19:15:23  <isaacs>there's also http://static.izs.me/irclogs/node.js/
19:15:33  <piscisaureus_>that's probably fine too
19:15:39  <ryah>piscisaureus_: they will take care of it
19:18:22  * Leomjoined
19:18:23  <piscisaureus_>isaacs: the problem is not so much that it gets banned. But there is a ban of all no.de IPs that gets reinstated all the time, and there is an exception for slurp, which gets dropped every now and then.
19:18:32  <piscisaureus_>so
19:23:53  * dominictarrjoined
19:24:41  <isaacs>ok, so this: https://gist.github.com/3194476
19:25:02  <isaacs>got this actually sort of working
19:25:32  <isaacs>but using vm.runInThisContext instead of eval(), and setting the closure vars as globals, and adding 62 spaces to the front of the script.
19:25:35  <isaacs>too gross?
19:27:15  * avalanche123joined
19:31:20  <creationix>isaacs, what's it trying to do?
19:31:24  <creationix>(the gist)
19:31:41  <isaacs>creationix: put the ^^^^ under the with instead of just under nothing
19:31:52  <isaacs>creationix: observe: node --use_strict -pe 'with(this){}'
19:32:26  <isaacs>undefined:1
19:32:27  <isaacs>^^^^
19:32:30  <isaacs>instead of:
19:32:39  <isaacs>eval:1
19:32:40  <isaacs>with(this){}
19:32:40  <isaacs>^^^^
19:33:02  <creationix>nasty, I see
19:33:03  <joeandaverde>is that caused by eval?
19:33:12  <joeandaverde>the fact that you don't see "with..."
19:34:38  <creationix>lol, I see the 62 spaces
19:34:46  <creationix>what a mess
19:36:14  <creationix>isaacs, so where is the current code for pe?
19:36:21  <creationix>the one that doesn't work
19:36:26  <isaacs>creationix: it's in src/node.js
19:36:37  <isaacs>creationix: search for process._eval
19:38:52  <isaacs>hm... this fix makes it break in a different way for ReferenceErrors or thrown errors though
19:39:23  * mmalecki[food]changed nick to mmalecki[vodka]
19:40:05  <creationix>ahh, found it "return eval(process._eval)"
19:40:49  <isaacs>righg
19:41:28  <isaacs>so for other kinds of errors, it's back to that old issue about how TryCatch objects lose their getSourceLine() values when they're rethrown.
19:41:34  <creationix>what does "(new Function(process._eval))()" do?
19:42:45  * Leomquit (Quit: Leaving)
19:43:52  <isaacs>creationix: doesn't return the completion value, that's what
19:43:54  <isaacs>just calls it
19:45:55  * avalanche123quit (Quit: Computer has gone to sleep.)
19:46:09  <isaacs>ok, i think i may have figured it out...
19:46:27  <isaacs>we weren't displaying the error all the time when calling vm.runIn*Context(script, name, true)
19:46:35  <isaacs>so it was relying on the rethrown
19:47:18  <isaacs>i'm considering removing the 62 character thing, and instead just putting a \n in the module wrapper, and subtracting one from the reported line number
19:47:55  <isaacs>oh, wait, no, that won't work, because people call vm.runInNewContext() themselves
19:47:59  <isaacs>and they don't know to add a \n
19:48:13  <isaacs>they *also* don't know to add 62 spaces, though...
19:52:20  <isaacs>no, that won't work. hrm.
19:53:22  <creationix>couldn't we just insert a \n before what they give us
19:58:08  <isaacs>creationix: yeah...
19:58:18  <isaacs>creationix: so, i'm debating between a few things
19:58:32  <isaacs>1. errors that report "at eval:1:68"
19:58:35  <isaacs>when it happened on char 6
19:58:52  <isaacs>2. errors that report "at eval:2:6", when it happened on line 1
19:59:07  <isaacs>3. adding yet another flag to say "I didn't wrap this thing"
19:59:20  <isaacs>4. just removing that stupid offset thing altogether, and letting the first line leak for modules.
19:59:27  <isaacs>since they almost never throw on the first line anyway
19:59:31  <isaacs>and when they do, it's already a lie.
20:00:05  <isaacs>or 5) change the stack output so that the offset is reflected there as well, and there are no lies told to the user, and no non-user-code leaked.
20:00:18  <creationix>4 or 5 sound good
20:00:50  <isaacs>i think 4 is the best. it's the least magical, and the most simple.
20:02:26  * `3rdEdenjoined
20:09:36  * AvianFluquit (Ping timeout: 244 seconds)
20:13:34  * piscisaureus_quit (Ping timeout: 264 seconds)
20:16:04  * AvianFlujoined
20:19:05  <isaacs>alright.. seems to be working
20:19:14  <isaacs>make jslintfix <-- very handy
20:19:24  <joeandaverde>woot!
20:20:06  <joeandaverde>isaacs: do you have any significant evidence that a JS http parser can be faster than the c implementation?
20:20:18  <isaacs>joeandaverde: no.
20:20:28  <isaacs>i don't have any evidence of this. but i would like some :0
20:20:29  <isaacs>:)
20:20:36  <joeandaverde>isaacs: My initial naive implementation is getting about 6k/sec vs 20k/sec
20:20:56  <joeandaverde>lots of room to make up!
20:21:43  <joeandaverde>i'm trying a completely different route now.
20:23:51  <joeandaverde>here's the repo: I'm completely rewriting it because of chunked encoding? I'm figuring all this out as i go. https://github.com/joeandaverde/node-http-parser-js/blob/master/HttpParser.js
20:26:32  <creationix>joeandaverde, how does my tiny one perform on your box
20:26:39  <creationix>(not that it implements chunked encoding yet)
20:26:51  <joeandaverde>i think we're at the same spot
20:26:53  <joeandaverde>i'll run it.
20:28:24  * stagasjoined
20:28:44  <creationix>isaacs, yes, options 4 was better I think
20:30:47  * chobi_echanged nick to chobi_e_
20:31:20  <isaacs>https://gist.github.com/3194476
20:31:49  <isaacs>joeandaverde: the best approach is to write the most minimal http parser you can get away with, and benchmark every chagne
20:32:28  <isaacs>joeandaverde: don't proceed to add *any* features that are not strictly necessary until you're out-performing http_parser.c on node's benchmark/http.sh benchmark
20:32:32  <joeandaverde>isaacs: agreed
20:32:59  <joeandaverde>creationix: about 8k/sec
20:33:00  <isaacs>joeandaverde: then back-pedal any time something causes you to lose performance, and keep updating the benchmark to test each new feature you add.
20:33:33  <creationix>isaacs, does it have to be faster for all cases or just some common ones?
20:33:48  <isaacs>creationix: it has to be on par.
20:33:51  <creationix>large chunked requests with trailing headers, for example are hard
20:33:58  <isaacs>creationix: faster is always better, of cours.e
20:34:04  <isaacs>but it cannot be more than 2% slower for any use case.
20:34:07  <creationix>but simple GET / HTTP1.1 I'm about 10% faster
20:34:26  <creationix>ok, so can't be significantly slower for any use case
20:34:29  <creationix>that's going to be hard
20:34:32  <isaacs>yeah
20:34:37  <isaacs>how much slower is it for trailing headers?
20:34:47  <isaacs>and does it do chunked encoding?
20:34:47  <creationix>don't know yet, haven't implemented it
20:34:55  <isaacs>oh, ok, so a lot slower then ;P
20:35:00  <isaacs>0 vs >0
20:35:10  <creationix>NaN vs >0
20:35:22  <joeandaverde>lol
20:35:53  <joeandaverde>that's what's concerning me? i just implemented as basic as possible header parsing and streaming of the body
20:35:56  <creationix>no, I think 0 is more correct. There is a concrete number of runs it finished in a second
20:35:56  <isaacs>creationix: there IS an important set of cheating you can do, though: it doesn't need to support every interface of http_parser.c, just all the interfaces we use.
20:36:12  <creationix>right, and I may change the API if it makes it signiicantly faster
20:36:16  <isaacs>yes
20:36:19  <creationix>like in node we don't listen for every http header and value
20:36:24  <isaacs>right
20:36:25  <creationix>but http_parser.c does
20:36:26  <isaacs>we don't care about that
20:36:41  <isaacs>basically, it just has to support the use cases we actually have.
20:36:44  <isaacs>so yuo can skip a lot of work
20:36:57  <creationix>requests, responses, bodies, chunked bodies, headers, trailers
20:36:58  <joeandaverde>chunked encoding, upgrade, and keep alive?
20:37:10  <creationix>keepalive is just a header value right?
20:37:14  <creationix>nothing in the wire protocol is there/
20:37:17  <isaacs>creationix: yeah, i think that's about it
20:37:24  <creationix>so the parser doesn't need to care
20:37:26  <joeandaverde>i'm ah
20:37:27  <isaacs>right
20:37:34  <joeandaverde>except to know that it's a keep alive request?
20:37:34  <creationix>same for upgrade I think
20:37:42  <isaacs>the parser should just assume that yoer' going to pipe in some bytes, and it'll do some stuff.
20:38:05  <isaacs>node's responsible for detaching the parser from the socket if we're going to reuse the socket
20:38:10  <creationix>When I get back to it, my next step was to make benchmarked unit tests using the test suite
20:38:22  <creationix>and test all the bodies with chunk sizes from 1 to all bytes
20:38:38  <isaacs>yeah, it'd be really nice if node's `make bench` was a) useful, and b) parseable
20:38:55  <isaacs>and if all the benchmarks were actually consistent in their output
20:39:19  <isaacs>it's a mess right now. there's a lot of useful stuff there, but it's not easy to use if you don't know what it's supposed to look like
20:41:22  * Leomjoined
20:43:05  <creationix>joeandaverde, right, but the code using httpParser can just read the emitted headers and know if it's keepalive right?
20:43:14  <creationix>I'm not sure that responsibility belongs in the parser
20:43:26  <joeandaverde>i agree, i just noticed it was present in http_parser.c
20:43:34  <creationix>the parser just needs to convert the byte stream to usable js events as quickly and effeciently as possible
20:44:01  <joeandaverde>sounds simpler :)
20:46:03  <creationix>I noticed that I'm emitting headers as an object (like what you get in req.headers), but the unit tests deal in terms of raw arrays
20:46:17  <creationix>the arrays are more correct, but I wonder what the overhead of converting the arrays to an object is
20:46:26  <creationix>since node usually just does that anyway
20:47:41  <joeandaverde>i did too until i started running the tests from test-http-parser.js
20:50:26  * TheJHquit (Ping timeout: 246 seconds)
20:59:55  <isaacs>creationix: if you create the objects in the same order each time, i believe it's faster to create the object instead of the array.
21:00:01  <isaacs>creationix: but i'm not sure you can guarantee that
21:00:26  <isaacs>creationix: i'd even be ok with the parser just providing the header block as a string
21:00:28  * stagasquit (Read error: Connection reset by peer)
21:00:49  <isaacs>(it should do that anyway, i guess, but probably also parse it)(
21:03:16  <joeandaverde>really you're not creating the array each time. You're pushing the key and value onto an existing array of headers.
21:03:44  <joeandaverde>i can't imagine creating an object each time even with the same "hidden class" is any faster than that
21:04:19  <creationix>so the format at the C level is [["Key", "value"],["Key", "value"]]
21:04:33  <creationix>which supports multiple headers with the same key!
21:04:56  <joeandaverde>hmm, from what i saw in JS it looks like [key, value, key, value]
21:05:06  <joeandaverde>i could be wrong, however
21:05:27  <creationix>that would be faster
21:05:29  <creationix>and about as useful
21:05:36  <creationix>either way, it's not the node public JS api
21:05:44  <creationix>which is {"key":"value}
21:05:49  <creationix>notice the lower-case
21:06:28  <creationix>ok, I'll try ["Key","value","Key","value"] in the parser
21:06:35  <creationix>it's easy enough to convert that to the proper js object
21:07:00  <joeandaverde>i saw that in test-http-parser.js
21:07:53  <creationix>yeah, I know the C api because I use it in luvit and I know the node api because I use node
21:07:58  <creationix>but I don't know node's internal api
21:08:00  <isaacs>creationix: [[key,val],[key,val]] would be nice.
21:08:13  <isaacs>creationix: [key,val,key,val] might be faster, but it's clumsy to work with
21:08:14  <joeandaverde>what's the advantage to that, isaacs ?
21:08:27  <creationix>isaacs, I don't think it's more clumsy
21:08:33  <isaacs>joeandaverde: more correct, preserves ordering, multiple values with the same key
21:08:34  <creationix>unless you're a foreach and destructuring addict
21:08:50  * isaacsgoes to forEach anonymous meetings
21:09:02  <creationix>I'm talking about [k,v,k,v] vs [[k,v],[k,v]]
21:09:04  <isaacs>and I would be hooked on destructuring, if it was availabie in V8
21:09:06  <isaacs>yeah
21:09:35  <creationix>but again, the latter is easy to derive from the former
21:09:36  <isaacs>[k,v,k,v] means that you have to do stuff like obj[kv[i]] = kv[i + 1]
21:09:42  <creationix>and most node clients will only use {k:v}
21:09:48  <joeandaverde>in the case that you're creating a new array as in [[k,v], [k,v]] why not use [{key:, value:}, {key:, value:}]
21:10:13  <isaacs>joeandaverde: because if you have {key:val} and you don't know what the 'key" is, you have to get it in a really awkward way
21:10:25  <isaacs>joeandaverde: if an object only has one key ever, it should be [key,val]
21:10:37  <isaacs>if the key is not deterministic
21:10:44  <creationix>joeandaverde, because most people still "feel" that arrays are more effecient
21:10:49  <creationix>and it is if you JSON.serialize it
21:10:54  <isaacs>or {key: 'set-cookie', value:'a=b;expires=tomorrow'}
21:11:08  <joeandaverde>^^ that's what i'm proposing
21:11:19  <isaacs>given how hidden classes work, that's quite possibly the fastest.
21:11:33  <isaacs>but if the array is always an array of strings, i'm guessing that V8 could chomp on that crazy good, also
21:11:53  <isaacs>joeandaverde: oh, i see, i thought you were proposing {key:value} not {key,value}
21:11:57  <isaacs>joeandaverde: my mistake :)
21:12:09  <joeandaverde>all good, we're on the same page now :)
21:12:10  <creationix>I kkew what he meant ;)
21:12:39  <creationix>so, for the parser, the only correct way is to have an array of some sort since keys can repeat
21:12:46  <creationix>and the most effecient is [k,v,k,v\
21:12:59  <isaacs>creationix: not clear that the most efficient is [k,v,k,v]
21:13:04  <isaacs>s/efficient/fast/
21:13:06  <creationix>unless the end user actually wants [[k,v],[k,v]]
21:13:19  <isaacs>the *simplest* is [k,v,k,v]
21:13:30  <creationix>well, an array is an object
21:13:39  <creationix>even simple arrays only holding two strings
21:13:46  <creationix>I guess we'd have to bench to make sure
21:13:50  <creationix>v8 is one complicated beast
21:13:53  <isaacs>but the fastest mayu well be [new Header(k, v), new Header(k, v)] where function Header(k, v) { this.key = k; this.value = v }
21:14:08  <creationix>isaacs, heh, probably
21:14:12  <creationix>new is freaky fast in v8
21:14:20  <isaacs>if you have a ctor, and objects alwyas are created in the same deterministic order in the ctor, V8 can optimize its brains out
21:14:24  * saghul_joined
21:14:40  <isaacs>that's how you get C-ish speed out of V8
21:14:51  <joeandaverde>that wouldn't need to really be morphed again, would it?
21:15:05  <joeandaverde>vs [k,v,k,v] which would definitely need to be converted to another structure
21:15:11  <isaacs>well, then you could have HeaderSet.add(Header)
21:15:18  <isaacs>like, make it look like full-on Java
21:15:25  <joeandaverde>that being [new Header(k,v)...
21:15:45  <isaacs>arrays are super fast, too, if they have no holes, and always contain the same sort of thing
21:15:49  * Leomquit (Ping timeout: 255 seconds)
21:15:56  <isaacs>and you can get more speed if you use new Array(n) when n is known
21:16:10  <joeandaverde>yeah, i wonder what default n is
21:16:55  <joeandaverde>in c# for example, lists start with 4, then grow to 8, and 16 and so on
21:17:00  <joeandaverde>i wonder if that's similar to how v8 works
21:17:04  <isaacs>creationix, ryah: got it working https://github.com/joyent/node/pull/3791
21:17:12  <isaacs>tne node -pe thing
21:17:44  <creationix>isaacs, nice, complete with unit tests
21:17:49  <creationix>removing hacks is always good
21:20:09  * saghul_quit (Quit: ["Textual IRC Client: www.textualapp.com"])
21:22:22  * piscisaureus_joined
21:24:38  <joeandaverde>creationix: when using does it ever send this
21:24:40  <joeandaverde>Send request failed!
21:24:40  <joeandaverde>Send request failed!
21:24:40  <joeandaverde>apr_socket_recv: Connection reset by peer (54)
21:24:50  <joeandaverde>oops, when using ab
21:24:55  <creationix>not sure
21:25:06  <piscisaureus_>joeandaverde: faulty ab on mac. Compile it yourself
21:25:09  <joeandaverde>i re-run it and it finally processes my requests
21:25:18  <joeandaverde>piscisaureus_: i did that D:
21:25:55  <joeandaverde>piscisaureus_: i'm running This is ApacheBench, Version 2.3 <$Revision: 655654 $>
21:26:24  <piscisaureus_>joeandaverde: I don't know... maybe compile another version. I was just relaying some basic knowledge. Otherwise I know nothing.
21:26:39  <joeandaverde>piscisaureus_: thank you
21:27:35  * c4miloquit (Remote host closed the connection)
21:30:32  <joeandaverde>creationix: if you're messing with the http parser stuff now do you mind running ab against my "rewrite" branch? I'm not fully trusting ab on my machine.
21:30:36  <joeandaverde>https://github.com/joeandaverde/node-http-parser-js/tree/rewrite
21:31:01  <joeandaverde>the coffeeshop i'm at is closing. I'll be back in a little bit.
21:31:15  <isaacs>joeandaverde: also, ab against 127.0.0.1, not localhost
21:31:20  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:31:28  * dshaw_joined
21:32:01  <joeandaverde>isaacs: thanks, i did have that issue to start with :)
21:32:21  <joeandaverde>ab -n 10000 -k http://127.0.0.1:8080/
21:32:26  * beachdogjoined
21:37:32  <ryah>creationix: dont worry about trailing headers - but chunked encoding is important
21:38:21  <creationix>yes, chunked is very common and node apps don't want to deal with that
21:38:39  <creationix>joeandaverde, sorry, reviving my living room raspberry pi
21:38:45  <creationix>the last update killed my ethernet driver
21:39:06  <creationix>I'm writing a node server to control the video playback over the web
21:39:58  <creationix>when I get my luvit-gl stuff done, I'll write some gui apps
21:40:15  <creationix>only gl and mp4 is fast on the raspberry pi
21:40:40  * `3rdEdenquit (Quit: Zzzz)
21:40:55  * joeandaverdequit (Ping timeout: 240 seconds)
21:43:54  * mordy___part
21:52:46  * joeandaverdejoined
22:07:29  * hzjoined
22:09:51  <joeandaverde>i think upgrading to mountain lion jacked up my PATH
22:18:11  * rendarquit
22:18:40  * avalanche123joined
22:22:01  * hzquit (Ping timeout: 272 seconds)
22:39:46  <joeandaverde>at first try this seems much more reliable for OSX users than ab: https://github.com/lighttpd/weighttp
22:39:51  <joeandaverde>for http benchmarking
22:41:27  <bnoordhuis>joeandaverde: there's also siege
22:54:25  * blackorzarquit (Ping timeout: 244 seconds)
22:56:10  * mikealquit (Quit: Leaving.)
22:58:36  * dshaw_quit (Quit: Leaving.)
23:02:17  * mikealjoined
23:03:20  * dshaw_joined
23:08:57  * Leomjoined
23:28:43  * mikealquit (Quit: Leaving.)
23:31:46  * Leomquit (Ping timeout: 246 seconds)
23:31:55  <CIA-108>node: Tom Hughes-Croucher master * rc05f52c / lib/child_process.js : child_process: improve maxBuffer error message - http://git.io/-CXhKw
23:31:59  * dshaw_quit (Quit: Leaving.)
23:44:04  * btraskjoined