00:02:29  <ryah>attempts to upgrade to lion = fail
00:03:07  <piscisaureus>weird. for me it was painless
00:03:22  * mralephquit (Quit: Leaving.)
00:06:37  <ryah>it's likely due to my linux dual-boot
00:07:08  <piscisaureus>weird. for me it was painless. with windows dualboot
00:07:14  <DrPizza>lion is buggy
01:06:36  * ericktquit (Quit: erickt)
02:09:45  * brsonquit (Ping timeout: 258 seconds)
02:26:07  * isaacsquit (Quit: isaacs)
03:55:44  * mikealjoined
03:55:53  * mikealquit (Read error: Connection reset by peer)
03:56:16  * mikealjoined
03:56:53  * bnoordhuisjoined
04:16:13  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
04:30:32  <CIA-53>libuv: Ben Noordhuis master * r6beeb5f / (.mailmap AUTHORS): Update AUTHORS and .mailmap - http://git.io/FK_ktA
04:36:00  * mikealquit (Quit: Leaving.)
06:01:02  <bnoordhuis>https://github.com/bnoordhuis/libuv/compare/inotify <- review?
06:13:19  <CIA-53>node: Ben Noordhuis master * r44bebc0 / src/node_crypto.cc : crypto: look up SSL errors with ERR_print_errors() - http://git.io/8pzq_g
06:42:21  <igorzi>bnoordhuis: hey, you there?
06:42:33  <bnoordhuis>igorzi: i am
06:42:47  <igorzi>bnoordhuis: are you using the test cluster?
06:42:55  <bnoordhuis>igorzi: no
06:43:28  <igorzi>bnoordhuis: i'll boot it into windows, so that piscisaureus can redo his benchmark
06:43:37  <bnoordhuis>sure
06:43:44  <igorzi>ok
07:01:10  <CIA-53>node: koichik v0.4 * rb93a7cc / doc/api/fs.markdown : docs: add links - http://git.io/UC31WQ
07:13:58  * isaacsjoined
07:23:31  * mralephjoined
07:56:29  * pieternjoined
07:59:05  * mralephquit (Quit: Leaving.)
08:07:46  <indutny>heya!
08:07:52  <indutny>nice to see you again! :)
08:50:06  * isaacsquit (Quit: isaacs)
10:41:47  * pieternquit (Quit: pietern)
12:05:52  * pieternjoined
13:19:53  * piscisaureusjoined
14:12:37  * dmkbotquit (Remote host closed the connection)
14:12:42  * dmkbotjoined
14:13:15  * dmkbotquit (Remote host closed the connection)
14:13:18  * dmkbotjoined
14:13:51  * dmkbotquit (Remote host closed the connection)
14:13:55  * dmkbotjoined
14:14:27  * dmkbotquit (Remote host closed the connection)
14:14:31  * dmkbotjoined
14:15:03  * dmkbotquit (Remote host closed the connection)
14:15:08  * dmkbotjoined
14:15:40  * dmkbotquit (Remote host closed the connection)
14:15:57  * dmkbotjoined
14:16:29  * dmkbotquit (Remote host closed the connection)
14:16:47  * dmkbotjoined
14:17:19  * dmkbotquit (Remote host closed the connection)
14:17:23  * dmkbot1joined
14:17:55  * dmkbot1quit (Remote host closed the connection)
14:18:00  * dmkbotjoined
14:18:31  * dmkbotquit (Remote host closed the connection)
14:18:36  * dmkbotjoined
14:19:07  * dmkbotquit (Remote host closed the connection)
14:19:13  * dmkbotjoined
14:19:59  * dmkbotquit (Remote host closed the connection)
14:20:03  * dmkbotjoined
14:20:35  * dmkbotquit (Remote host closed the connection)
14:20:39  * dmkbotjoined
14:21:11  * dmkbotquit (Remote host closed the connection)
14:21:16  * dmkbotjoined
14:21:48  * dmkbotquit (Remote host closed the connection)
14:21:52  * dmkbotjoined
14:22:24  * dmkbotquit (Remote host closed the connection)
14:22:28  * dmkbotjoined
14:23:01  * dmkbotquit (Remote host closed the connection)
14:23:04  * dmkbotjoined
14:23:37  * dmkbotquit (Remote host closed the connection)
14:23:40  * dmkbotjoined
14:24:13  * dmkbotquit (Remote host closed the connection)
14:24:19  * dmkbotjoined
14:24:51  * dmkbotquit (Remote host closed the connection)
14:24:55  * dmkbotjoined
14:25:28  * dmkbotquit (Remote host closed the connection)
14:25:32  * dmkbotjoined
14:26:03  <piscisaureus>That's it. I am going to leave this country.
14:26:04  * dmkbotquit (Remote host closed the connection)
14:26:08  * dmkbotjoined
14:26:40  * dmkbotquit (Remote host closed the connection)
14:26:44  * dmkbotjoined
14:27:16  * dmkbotquit (Remote host closed the connection)
14:27:20  * dmkbotjoined
14:27:52  * dmkbotquit (Remote host closed the connection)
14:27:56  * dmkbotjoined
14:28:28  * dmkbotquit (Remote host closed the connection)
14:28:32  * dmkbotjoined
14:29:05  * dmkbotquit (Remote host closed the connection)
14:29:08  * dmkbotjoined
14:32:30  <indutny>piscisaureus: ?
14:32:57  <indutny>good morning, btw
14:34:58  <piscisaureus>good morning indutny
14:42:13  <bnoordhuis>piscisaureus: had enough of the weather or the taxes?
14:42:35  <piscisaureus>bnoordhuis: no this -> http://www.dumpert.nl/mediabase/1717191/616251d0/ontknapen_met_de_npo.html
14:44:23  <bnoordhuis>piscisaureus: what's so bad about that? sad you only now discovered it?
14:44:39  <piscisaureus>lol
14:44:53  <piscisaureus>it's so incredibly pathetic
14:45:06  <bnoordhuis>oh well
14:45:15  <bnoordhuis>better this than having him die a virgin
14:45:23  <indutny>god thanks I know only English/Russian
14:48:06  <bnoordhuis>indutny: i bet you're at least a little curious
14:50:06  <indutny>omg
14:50:19  <indutny>is that on TV?
14:50:39  <bnoordhuis>yep
14:50:43  <bnoordhuis>paid for by the taxpayer
14:50:52  <indutny>better leave this country :P
14:50:55  <piscisaureus>yes
14:51:01  <piscisaureus>I would live in russia
14:51:05  <piscisaureus>to watch this: http://player.omroep.nl/?aflID=13128310&start=00:04:13&wmv=true
14:51:32  <indutny>piscisaureus: ubuntu, no silverlight
14:51:36  <indutny>:)
14:51:40  <piscisaureus>wmv?
14:52:44  <bnoordhuis>"Je hebt Microsoft Silverlight 2.0 nodig om deze Uitzending Gemist video te kunnen bekijken"
14:52:48  <piscisaureus>meh
14:52:49  <bnoordhuis>fucking public broadcast service
14:52:58  <piscisaureus>meybe they have it in flash as well
14:53:05  <piscisaureus>let me see
14:53:06  <bnoordhuis>that's my tax money they're handing over to MSFT!
14:55:28  <piscisaureus>http://beta.uitzendinggemist.nl/afleveringen/1111543#00:04:13 <-- has flash
14:56:01  <indutny>1 sec
14:57:12  <indutny>they ain't russians
14:57:25  <bnoordhuis>indutny: it's called parody
14:57:26  <indutny>:)
14:57:30  <indutny>aah
14:57:31  <indutny>ok
14:57:51  <bnoordhuis>not great parody perhaps
14:58:20  <piscisaureus>no it's awesome
14:58:54  <indutny>haha :)
14:59:11  <indutny>very expressive guys
15:00:09  <indutny>but I don't understand dutch
15:00:50  <bnoordhuis>you and 99.99% of the world population both, brother
15:02:08  <indutny>hahaha
15:02:52  <indutny>can't say the same about the chinese
15:07:47  * spasqualijoined
15:09:41  * spasqualipart
15:13:11  * dmkbotquit (Remote host closed the connection)
15:13:15  * dmkbotjoined
15:16:25  <bnoordhuis>piscisaureus: re those benchmarks: you're benching raw iocp performance i.e. without libuv, right?
15:16:57  <piscisaureus>bnoordhuis: no, igor was going to do that
15:17:15  <piscisaureus>bnoordhuis: but we found some issues with my benchmark so we want to run it again
15:17:32  <bnoordhuis>piscisaureus: okay, so the two of you are testing with and without libuv?
15:17:52  <piscisaureus>bnoordhuis: yes, the multiprocess thing is tested with libuv.
15:18:11  <piscisaureus>bnoordhuis: hmm oh, I thing igor actually was using libuv as well
15:18:25  <bnoordhuis>oh okay
15:18:39  <bnoordhuis>i wanted to test both with and without, to see how much overhead we incur
15:19:29  <piscisaureus>bnoordhuis: I can imagine, but the multiprocess benchmark is pretty complicated. Testing that without libuv would mean I would have to write something like libuv
15:19:42  <piscisaureus>doesn't make sense
15:19:49  <bnoordhuis>is your code available somewhere?
15:20:10  <piscisaureus>bnoordhuis: yes, the prefork branch
15:20:18  <piscisaureus>on node/libuv
15:20:40  <piscisaureus>bnoordhuis: hasn't been rebased atop of multplicity btw
15:20:48  <bnoordhuis>aw
15:21:02  <piscisaureus>bnoordhuis: doesn't matter much I think
15:28:31  <ryah>hello node people
15:29:08  <ryah>i did not get very far with my tty binding yesterday
15:29:13  <ryah>hopefully i'll make more progress today
15:29:26  <indutny>heya
15:29:37  <ryah>indutny: hey - thank you for all the fixes!
15:29:42  <indutny>ryah: np
15:29:44  <ryah>im testing them now
15:29:56  <indutny>that was pretty interesting
15:29:58  <ryah>indutny: when are we going to get a proper test suite for the debugger repl?
15:30:19  <indutny>ryah: I think I'll work on that once we stabilize it's functionality
15:30:29  <ryah>k
15:31:29  <bnoordhuis>ryah: want me to do the kqueue stuff?
15:31:32  <ryah>indutny: ctrl+d in "repl" doesn't work
15:31:41  <bnoordhuis>deja vu, i think i've asked that already
15:31:42  <indutny>oh
15:31:44  <ryah>bnoordhuis: yes
15:31:58  <ryah>bnoordhuis: probably requires reaching inside ev_loop, beware
15:32:09  <bnoordhuis>oh dear, how so?
15:32:11  <indutny>ryah: strange, it wfm
15:33:38  <ryah>indutny: from the internal repl?
15:33:45  <indutny>ryah: from both
15:33:55  <ryah>indutny: from 'debug>' ctrl+d works but from the internal one it doesn't
15:33:59  <ryah>hm
15:34:08  <ryah>indutny: okay - i guess i'll have to debug it
15:34:48  <indutny>ryah: are you on win?
15:34:51  <indutny>or on linux
15:35:28  <ryah>indutny: osx
15:35:33  <CIA-53>node: Fedor Indutny master * rb20c98e / lib/_debugger.js : fix 'null' mirroring (+6 more commits...) - http://git.io/4bTpiA
15:35:51  <indutny>ryah: strange...
15:43:49  <ryah>bnoordhuis: any luck with the benchmarking yet?
15:44:30  <bnoordhuis>ryah: haven't really done anything yet, been discussing it with piscisaureus
15:46:20  <bnoordhuis>and we should finish that discussion...
15:46:40  <piscisaureus>bnoordhuis: ok
15:46:43  <piscisaureus>15 minutes
15:46:50  <bnoordhuis>piscisaureus: cool
15:46:52  <bnoordhuis>irc or skype?
15:47:06  <piscisaureus>choose
15:47:08  <piscisaureus>skype?
15:47:15  <bnoordhuis>yeah, that's probably easiest
15:47:29  <ryah>can i listen in?
15:47:35  <ryah>or do you guys want to speak dutch?
15:47:47  <piscisaureus>I'm fine
15:48:06  <piscisaureus>I don't know if it's going to be interesting, because I don't know what bnoordhuis wants to discuss :-)
15:48:44  <piscisaureus>we'll add you
15:48:53  <bnoordhuis>well, mostly what the point of the prefork benchmark is (well, i know) and what we should emulate of that on the unices
15:49:22  <ryah>im on skype now
15:49:58  * isaacsjoined
15:50:05  * bnoordhuisgets a drink
15:50:26  <piscisaureus>10 minutes and counting :-)
15:50:57  <ryah>isaacs: linda is having some problems with the hostrouter
15:52:55  <ryah>bnoordhuis: v0.5.8 - what should be in it? definitely we should nail down this TTY shit
15:54:25  <bnoordhuis>ryah: tty, lion fs fixes, file watcher stuff, improved gyp?
15:54:56  <bnoordhuis>i have a hunch that the lion issues are caused by apple's switch from gcc to llvm btw
15:55:04  * pieternquit (Quit: pietern)
15:55:16  <bnoordhuis>maybe not everything but it's at least part of it
15:55:31  <ryah>switch from gcc to llvm?
15:55:38  <ryah>what does that mean?
15:55:54  <ryah>like ln -s /usr/bin/clang /usr/bin/gcc ?
15:55:57  <bnoordhuis>yes
15:56:02  <ryah>no way
15:56:33  <ryah>bnoordhuis: v0.5.8 due date - when do you want it?
15:56:37  <ryah>I suggest next wednesday
15:56:51  <bnoordhuis>sure, that should be time enough
15:56:53  <bnoordhuis>why no way?
15:58:36  <piscisaureus>bnoordhuis: ryah: I'm back - call now?
15:58:44  <bnoordhuis>piscisaureus: sure, start it up
15:59:14  * ryahtopic: v0.5.8 https://github.com/joyent/node/issues?milestone=5&state=open
16:07:40  * piscisaureus_joined
16:08:41  <piscisaureus_>piscisaureus3:~ piscisaureus$ gcc -v
16:08:41  <piscisaureus_>Using built-in specs.
16:08:41  <piscisaureus_>Target: i686-apple-darwin11
16:08:41  <piscisaureus_>Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~25/dst-llvmCore/Developer/usr/local
16:08:42  <piscisaureus_>--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
16:08:42  <piscisaureus_>Thread model: posix
16:08:42  <piscisaureus_>gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
16:16:48  * piscisaureus_quit (Quit: piscisaureus_)
16:19:29  * rmustaccjoined
16:29:32  * dmkbotquit (Remote host closed the connection)
16:29:36  * dmkbotjoined
16:35:45  * ericktjoined
16:53:33  * brsonjoined
17:11:39  <ryah>so it's not clang - it's the gcc frontend for llvm
17:11:49  <ryah>but - that's stilll awesome :)
17:11:57  <ryah><3 llvm
17:15:53  <ryah>https://gist.github.com/7ce1b0244b02a6c9a6c7 osx fials
17:25:33  * isaacschanged nick to isaacs[away]
17:29:56  * mikealjoined
17:36:23  * dmkbotquit (Remote host closed the connection)
17:36:27  * dmkbotjoined
17:56:01  * ericktquit (Quit: erickt)
17:59:12  <bnoordhuis>piscisaureus ryah: call?
17:59:16  <piscisaureus>callski timeski?
18:03:49  <igorzi>yepski :)
18:09:52  <indutny>are we going to have customFds working in next release?
18:10:03  <indutny>I meant child_process.spawn method's options
18:10:15  <ryah>indutny: a subset of customFds is working
18:10:36  <ryah>customFds: [0,1,2]
18:10:44  <indutny>ryah: have you tested this?
18:10:57  <indutny>ryah: last time I seen debugger failing on it
18:11:19  <indutny>ryah: because resulting ChildProcess instance didn't have a .stdout nor a .stderr properties
18:11:28  <indutny>(while it was running, of course)
18:17:50  <piscisaureus>we haven't resolved the pipe issue :-(
18:24:29  <igorzi>piscisaureus: the server is now booted into windows
18:24:41  <piscisaureus>ok good
18:26:00  * dmkbotquit (Remote host closed the connection)
18:26:04  * dmkbotjoined
18:32:58  <piscisaureus>#cooking
18:33:30  <ryah>indutny: hm - i think they shouldn't have stdout or stderr if you set customFds to [0,1,2]
18:33:39  <ryah>indutny: in the legacy system as well
18:35:48  <ryah>test/simple/test-child-process-set-blocking.js <-- test
18:36:11  <ryah>https://github.com/joyent/node/blob/b20c98e42708668c564d5f83bad83cf074cf4f58/test/simple/test-child-process-set-blocking.js
18:39:55  <ryah>piscisaureus, igorzi: https://github.com/joyent/node/blob/b20c98e42708668c564d5f83bad83cf074cf4f58/test/simple/test-child-process-custom-fds.js#L47
18:40:03  <ryah>^-- is this possible to do on windows?
18:40:29  <ryah>customFds: [-1, fd] means that stdin and stderr are pipes, but stdout is a file fd
18:40:42  <ryah>the fd comes from fs.open()
18:41:06  * dmkbotquit (Remote host closed the connection)
18:41:10  * dmkbotjoined
18:41:17  <ryah>(which presumably at some point could be a real HANDLE)
18:44:23  <igorzi>ryah: i think it should be possible.
18:46:03  <ryah>igorzi: what if the subprocess is a Node subprocess and it tries to do WriteConsole on stdout?
18:47:03  <ryah>well i guess it wouldnt do that..
18:47:10  <ryah>we detect the type of the stdout fd
18:47:33  <ryah>hm...
18:47:46  <igorzi>right, you would do detection (with GetConsoleMode i think), and then either do WriteConsole or WriteFile
18:48:52  <ryah>that reminds me...
18:49:31  <CIA-53>libuv: Ryan Dahl master * rc1374ba / (5 files in 4 dirs): Add uv_is_tty() - http://git.io/wc8NFA
18:52:35  <ryah>yeah. so we should (in the future) modify uv_spawn to also accept uv_file for stdio
18:53:09  <ryah>indutny: but your problem with customFds should be working currently
18:54:49  <piscisaureus>I presume we can support that
18:55:06  <piscisaureus>but it will prevent is from using FILE_FLAG_OVERLAPPED files in the future
18:55:07  * dmkbotquit (Remote host closed the connection)
18:55:22  * dmkbotjoined
18:55:27  <ryah>https://github.com/joyent/libuv/issues/192
18:55:42  <ryah>piscisaureus: can you explain?
18:55:44  <piscisaureus>since normally processes will not like it when their stdio is open in overlapped mode
18:56:14  <piscisaureus>ryah: if you're passing a file fd to a child process that's fine
18:56:46  <piscisaureus>ryah: but not so much if you have opened the file with FILE_FLAG_OVERLAPPED
18:57:13  <ryah>what if we change the overlapped file to an fd before sending it to the child?
18:57:35  <piscisaureus>ryah: you can't change the overlapped/nonoverlapped mode I think
18:57:35  <ryah>(does that change anything? probably not)
18:57:53  <piscisaureus>although we could just re-open the file and pass the new fd to the child
18:58:10  <ryah>so basicaly you're saying either uv_fs cannot support overlapped files OR we cannot support passing files to children
18:58:18  <piscisaureus>yes
18:58:32  <ryah>i think i'd rather have overlapped uv_fs methods :)
18:58:40  <piscisaureus>well...
18:58:56  <piscisaureus>it's still questionable whether that's ever going to work well enough
18:59:14  <piscisaureus>but it seems kind of stupid to shut that door forever at this point
18:59:19  <ryah>sure
18:59:27  <ryah>well we're not going to do this immediately anyway
18:59:33  <piscisaureus>okay
18:59:42  <ryah>i'll copy this text into the issue
19:00:05  <piscisaureus>there is also a function called ReOpenFile - we may be able to "duplicate" the file fd with that but have it in normal mode
19:00:13  <piscisaureus>but I think it's not supported on xp/3k
19:00:25  <piscisaureus>and there's some issues with it when used over a network share
19:01:41  <ryah>it's going to be nice to have this tty stuff in there
19:02:22  <ryah>i like that we're pushing the stdio type checking up to node
19:02:36  <ryah>makes it less magical
19:04:19  * piscisaureusresumes cooking
19:09:39  * dmkbotquit (Remote host closed the connection)
19:09:43  * dmkbotjoined
19:24:03  * mralephjoined
19:31:31  * mikealquit (Quit: Leaving.)
19:32:09  <bnoordhuis>piscisaureus: your prefork branch has a server but what are you using as the client?
19:34:53  <ryah>bnoordhuis: they're using a microsoft tool
19:35:20  <bnoordhuis>ryah: okay, thanks
19:35:44  <ryah>bnoordhuis: wcat, i think it was called?
19:36:07  <ryah>im trying to find his ntoes...
19:36:36  <ryah>https://gist.github.com/1220252
19:36:56  <ryah>"bench 200 7"
19:37:26  <bnoordhuis>i wonder why it works
19:37:41  <ryah>"b. On the controller machine, open a new cmd shell, and run “c:\wcat\bench.cmd virtualclients iterations”. Where virtualclients is the number of concurrent connections per each physical client machine (we have 3 client machines, so virtualclients=100 will run with 300 concurrent connections). Iterations is the number of times to repeat the benchmark. When the benchmark finishes it’ll show you output like below (tps is transactions per secon
19:37:42  <bnoordhuis>his code doesn't read the request first, just starts writing out the response immediately
19:37:53  <ryah>bnoordhuis: i think it's ignoring the request
19:37:58  <ryah>bnoordhuis: just assuming it gets it
19:38:18  <bnoordhuis>piscisaureus's prefork server doesn't, it never calls uv_read_start
19:38:38  <ryah>bnoordhuis: it doesn't need to
19:38:58  <ryah>(of course this won't work for keepalive)
19:39:06  <bnoordhuis>ryah: so we're going to use that msft tool as the client?
19:39:15  <ryah>bnoordhuis: yes
19:39:18  <bnoordhuis>okay
19:39:28  <bnoordhuis>saves me having to write a bench tool myself :)
19:40:03  <ryah>igorzi: just checking - that benchmark tool isn't trying to do keep-alive?
19:41:44  <bnoordhuis>https://github.com/bnoordhuis/libuv/compare/unix-prefork-server
19:43:41  <ryah>bnoordhuis: nice
19:45:22  <ryah>bnoordhuis: testing locally - are you able to see linear load increase with processes?
19:45:29  <mraleph>piscisaureus: bnoordhuis: so I see you are comming to aar instead of ryah for goto;
19:45:54  <bnoordhuis>mraleph: yes, we wanted this done properly
19:46:26  <bnoordhuis>ryah: well, linear... the load is evenly distributed over the listening processes
19:48:39  <ryah>bnoordhuis: good!
19:48:51  <ryah>bnoordhuis: i can't wait to hear the result from lab
19:49:00  <ryah>i guess igorzi is running his benchmark now
19:49:45  <piscisaureus>bnoordhuis: for the the load is also distributed evenly
19:49:57  <bnoordhuis>piscisaureus: ?
19:50:06  <piscisaureus>the total number of r/s just does not increase linearly with the number of processes
19:50:26  <bnoordhuis>piscisaureus: oh, like that
19:50:32  <piscisaureus>bnoordhuis: er, s/for/on windows/
19:51:11  <bnoordhuis>my laptop is a dual core machine, not a great test bed for this kind of thing
19:51:30  <bnoordhuis>but let's what igorzi says
19:51:31  <piscisaureus>bnoordhuis: I know my test is not calling uv_read_start, that's why we have to re-run it
19:51:52  <bnoordhuis>piscisaureus: oh, so it *should* do read_start?
19:51:55  <piscisaureus>bnoordhuis: yes
19:52:17  <piscisaureus>bnoordhuis: because otherwise you risk closing the connection before the client has written it's headers
19:52:18  <bnoordhuis>how do you determine the end of the request? or do you assume it fits in a single packet?
19:52:43  <piscisaureus>bnoordhuis: good question
19:53:04  <piscisaureus>maybe just scan for \r\n\r\n?
19:53:31  <bnoordhuis>piscisaureus: you can use http_parser and check for the on_message_complete event
19:53:40  <bnoordhuis>maybe that's overkill
19:53:47  <piscisaureus>bnoordhuis: overkill indeed
19:54:24  <ryah>well. you'll need that for keep-alive
19:54:39  <ryah>just read one packet :)
19:54:43  <ryah>assume that's the whole message
19:55:02  <bnoordhuis>should be a pretty safe bet
19:55:12  <ryah>or check the last 4 bytes are CRLFCRLF
19:55:21  <ryah>*shrug*
19:56:26  <piscisaureus>for (i = 0; i < nread; i++) {
19:56:26  <piscisaureus> char c = buf.base[i];
19:56:26  <piscisaureus> if ((c == 13 && (state | 0)) ||
19:56:26  <piscisaureus> c == 10 && !(state | 1)) {
19:56:26  <piscisaureus> client->state++;
19:56:26  <piscisaureus> }
19:56:26  <piscisaureus> client->state = 0;
19:56:27  <piscisaureus> }
19:56:27  <piscisaureus> if (client->state == 4) {
19:56:28  <piscisaureus> // Write!
19:56:28  <piscisaureus> }
19:56:29  <piscisaureus>}
19:56:53  <piscisaureus>^-- in read_cb
19:57:19  <piscisaureus>hmm (state | 0) should be (state | 1) obviously
19:58:01  <igorzi>ryah: the wcat tool could do keep-alive, but we're not using it for this benchmark
19:58:57  <ryah>piscisaureus: character literals are there for a reason
19:59:27  <bnoordhuis>oh snap!
19:59:34  <piscisaureus>ryah: ?
19:59:53  <bnoordhuis>piscisaureus: 10 == '\r', 13 == '\n'
20:00:02  <piscisaureus>oh
20:00:07  <piscisaureus>yes that code is kind of broken
20:00:25  <piscisaureus>let me put it in a gist
20:00:57  <bnoordhuis>err wait, other way around
20:01:15  <bnoordhuis>10 == '\n', 13 == '\r'
20:01:33  <bnoordhuis>anyway, what ryah meant was: use character literals instead of numbers
20:01:39  <igorzi>piscisaureus: do we actually need to that for this benchmark? i was just doing one read, and then writing out the response.
20:01:55  <piscisaureus>igorzi: yes I think that's actually fine :-)
20:02:38  <piscisaureus>this should be better anyway -> https://gist.github.com/1230165
20:02:42  <igorzi>piscisaureus: we need to make sure that we do the same thing in all 3 cases
20:02:53  <piscisaureus>yeah
20:03:05  <piscisaureus>ok - let's just read once
20:03:55  <ryah>this is so exciting :)
20:04:41  <ryah>i really hope bert's is on par with igorzi's
20:05:08  <piscisaureus>hardly double-blind research this is
20:06:14  <ryah>we're just wanting to weed out any massive differences
20:06:41  <ryah>i think 5%-10% doesn't matter
20:06:57  <ryah>would you agree?
20:07:37  <piscisaureus>yes
20:08:00  <piscisaureus>if igorzi's solution wins we have a problem
20:08:08  <ryah>true
20:08:41  <ryah>but at least we can stop guessing
20:08:51  <piscisaureus>indeed
20:09:13  <ryah>i think making node use isolates can be done in... 3 weeks
20:09:33  <piscisaureus>we also have to do difficult multiplicity stuff in windows then
20:09:42  <piscisaureus>because we cannot make all loops share one completion port
20:09:54  <piscisaureus>or at least that's far from ideal
20:10:10  <ryah>why
20:10:29  <piscisaureus>because we then need mutex-locked queues etc blabla
20:10:42  <piscisaureus>to effectively tie callbacks to a thread/vm
20:10:45  <ryah>right
20:11:44  <ryah>but with a single iocp we have no problem moving handles around
20:11:47  <ryah>which is nice
20:11:52  <igorzi>i think multiplicity would have to be totally redone (if we wanted to go that route). a handle/request can no longer be assigned to a loop (since that handle/request can pop up on any thread)
20:12:47  * ericktjoined
20:14:33  <CIA-53>libuv: Ryan Dahl master * r2ef8f35 / (src/unix/core.c src/unix/stream.c): tty fixes for unix - http://git.io/urnUSA
20:15:44  <bnoordhuis>piscisaureus: https://github.com/bnoordhuis/libuv/compare/unix-prefork-server <- is it roughly equivalent to yours?
20:16:09  <bnoordhuis>i only do a single malloc for the entire request btw
20:18:19  <piscisaureus>I noticed
20:18:38  <piscisaureus>I think igor and me are mallocing everything
20:18:59  <piscisaureus>that is, the read buffer and the write request are malloced separately
20:19:13  <bnoordhuis>so nick my obviously superior code :)
20:20:45  <igorzi>here's the multi-thread server code: https://github.com/igorzi/libuv/tree/multi-thread
20:22:26  <piscisaureus>igorzi: that works?
20:22:49  <piscisaureus>igorzi: loop->pending_reqs access etc is not threadsafe
20:23:55  <piscisaureus>nor is loop->timer_tree
20:24:33  <bnoordhuis>you know, i'm starting to like gyp more and more /offtopic
20:24:57  <piscisaureus>yes me too
20:25:08  <piscisaureus>actually when I have to set up a VS project I now do it with gyp
20:27:16  <igorzi>piscisaureus: yeah, i'm fixing that..
20:29:13  <igorzi>piscisaureus: only pending_reqs_tail and endgame_handles need to be synchronized (for this benchmark), right? (i'm not using timers)
20:29:19  <piscisaureus>I think you'll have better luck creating multiple uv_loop structs, then assign them all the same completion port
20:29:29  <piscisaureus>igorzi: probably
20:29:40  <piscisaureus>igorzi: but there are many accesses to both
20:33:53  <igorzi>piscisaureus: i wonder if i should put pending_reqs_tail into thread local storage instead of the loop (for this benchmark)?
20:34:13  <piscisaureus>igorzi: sure
20:34:22  <piscisaureus>igorzi: I think that's much easier anyway
20:34:32  <piscisaureus>igorzi: also, hack your way :-)
20:35:12  <igorzi>if you get a req - go ahead and process it on the same thread (instead of fighting for it with other threads)
20:35:34  <CIA-53>node: Ryan Dahl master * r6b98a63 / (13 files in 5 dirs): Upgrade libuv to 2ef8f35 - http://git.io/z2rdPQ
20:35:49  <piscisaureus>igorzi: I find it difficult to imagine where this might go wrong and where it works
20:36:08  <piscisaureus>my head is too small
20:36:49  <igorzi>piscisaureus: i think we'll find out if/when it doesn't work :)
20:36:59  <piscisaureus>sure
20:37:02  <piscisaureus>:-)
20:37:17  <piscisaureus>let's expose ourselves to the threading monster
20:40:12  <CIA-53>node: Ryan Dahl master * rc1ae6ea / (5 files in 3 dirs): Add TTYWrap - http://git.io/xKv3wg
20:44:04  <piscisaureus>^-- that's faster than expected
20:44:16  <piscisaureus>ryah += 1
20:47:56  <bnoordhuis>igorzi: are we going to merge the file watcher stuff?
20:48:09  <bnoordhuis>i mean, merge into master?
20:49:28  <ryah>bnoordhuis: if you guys are okay with it, you should merge
20:49:40  <igorzi>bnoordhuis: yeah, i think it's ready.. piscisaureus, did you have a chance to review the windows file watcher stuff
21:29:18  <piscisaureus>igorzi: sure. what was the branch name again?
21:29:59  <igorzi>piscisaureus: https://github.com/joyent/libuv/tree/file_watcher
21:30:07  * piscisaureusreviews
21:30:15  <ryah>look at this hilarious comment:
21:30:15  <ryah> if (isatty(STDIN_FILENO)) {
21:30:16  <ryah> // XXX selecting on tty fds wont work in windows.
21:30:16  <ryah> // Must ALWAYS make a coupling on shitty platforms.
21:30:16  <ryah> int r = -1;
21:31:04  <ryah>very early comment - i actually thought i was making Node cross-platform in the beginning
21:31:07  <ryah>so foolish
21:36:30  * mikealjoined
21:37:47  * brsonquit (Quit: leaving)
21:37:54  * brsonjoined
21:54:40  <piscisaureus>igorzi: lgtm ...
21:55:15  <piscisaureus>igorzi: in the future we should optimize the case where the user is watching multiple individual files in the same directory
21:56:13  <igorzi>piscisaureus: with a single ReadDirectoryChangesW call?
21:56:19  <piscisaureus>igorzi: yes
21:56:33  <piscisaureus>probably we need some sort of hash tree for this
21:56:34  <igorzi>piscisaureus: ok, i'll add an issue.. thanks
21:57:19  <piscisaureus>igorzi: also currently it is not possible to watch a directory itself - watching a directory now implies watching the contents of it
21:57:28  <piscisaureus>this is more of an api issue
21:57:39  <piscisaureus>but this should be carefully aligned with the other backends
21:59:40  <CIA-53>libuv: Ryan Dahl master * rc03d426 / src/unix/stream.c : More tty on unix fixes - http://git.io/L0PGUw
21:59:57  <DrPizza>igorzi: https://github.com/joyent/libuv/commit/19132b2a0924fc49e3002c4400647c0ba971c384#L2R69 should use constant uv_directory_watcher_buffer_size
22:01:06  <piscisaureus>I didn't care enough :-)
22:01:18  <DrPizza>and the buffer should be 64k
22:01:33  <piscisaureus>hmm
22:02:12  <piscisaureus>I considered that as well - but that means that if you're watching a lot of files you're wasting a lot of memory
22:02:40  <igorzi>DrPizza: thanks.. will fix.
22:02:51  <piscisaureus>Maybe we can do 0-reads there as well :-)
22:02:52  <DrPizza>there are issues with network watches
22:02:59  <DrPizza>but I think 64k is the largest that SMB1 can return
22:03:49  <igorzi>hmm, maybe we can have one size for files and another size for directories?
22:05:26  <piscisaureus>why do we need such a big buffer anyway - I mean we're not reporting the changed filename anyway atm
22:05:32  <piscisaureus>knowing that something changed is enough right?
22:07:08  * mikealquit (Quit: Leaving.)
22:08:51  <piscisaureus>igorzi: I am also afraid *sigh* that ReadDirectoryChangesW might report the 8.3 name
22:08:59  <piscisaureus>http://blogs.msdn.com/b/ericgu/archive/2005/10/07/478396.aspx
22:09:21  <piscisaureus>so we could be dropping events when filtering on a specific file name
22:10:51  <igorzi>oh.. ok, i'll add an issue for that as well
22:10:54  <piscisaureus>cross-platform file watching is even more rad than cross-platform async networking
22:10:59  <piscisaureus>:-)
22:11:03  <piscisaureus>add issue and forget
22:11:24  <ryah>:)
22:11:25  <piscisaureus>Issue trackers mean slow death
22:11:32  <igorzi>piscisaureus: no, i'll get that in this week.. i just don't want to block the merge
22:12:11  <ryah>it's kind of amazing how primative the file event stuff is
22:12:28  <ryah>on every platform it seem - not exactly what you want
22:12:32  <piscisaureus>igorzi: I was just half kidding :-)
22:12:46  <piscisaureus>How Jira Killed My Project
22:13:08  <rmustacc>ryah: Just wait till you try to integrate network file systems into that mess.
22:13:29  <ryah>rmustacc: we were discussing that today
22:17:12  <rmustacc>Well, at least some of them support notifications.
22:22:39  * mralephquit (Quit: Leaving.)
22:26:38  <CIA-53>libuv: Ben Noordhuis master * r9f8bc7b / uv.gyp : build: add test-tty to gyp file list, unbreaks build - http://git.io/XtV9IQ
22:29:11  * piscisaureuspart
22:29:16  * piscisaureusjoined
22:29:26  <piscisaureus>Is someone using the bench cluster?
22:29:45  <bnoordhuis>rmustacc: ran some tests tonight, inotify + nfs is still no go
22:30:01  <bnoordhuis>nfs doesn't transmit changes so the inotify watcher never wakes up
22:30:21  <igorzi>piscisaureus: go ahead.. the multi-thread server will take longer
22:30:27  <bnoordhuis>at least with the nfds i tested it with
22:30:31  <piscisaureus>igorzi: is it on atm?
22:30:31  <bnoordhuis>*nfsd
22:30:42  <piscisaureus>igorzi: NDJS-Win4.ep.interop.msftlabs.com:303 looks down from here
22:31:13  <bnoordhuis>Stay-at-home workers also said getting dressed for the day was far too strenuous: 41 per cent of women and 22 per cent of men � a third in total � stayed in their PJs.
22:31:18  <bnoordhuis>^ haha, seriously?
22:31:26  <bnoordhuis>from http://www.theregister.co.uk/2011/09/20/pjs_every_day/
22:33:45  <piscisaureus>bnoordhuis: http://theoatmeal.com/comics/working_home
22:35:08  <igorzi>piscisaureus: the server is back up now
22:35:17  <piscisaureus>ok nice
22:35:37  <bnoordhuis>the degradation of social skills part is spot on
22:35:48  <bnoordhuis>i dunno when i last changed my underwear
22:35:54  <bnoordhuis>(i kid, i kid!)
22:36:04  <bnoordhuis>shaving however...
22:36:19  <piscisaureus>bnoordhuis: you need to shave your underwear?
22:36:28  <bnoordhuis>odd that, innit?
22:39:28  <piscisaureus>bnoordhuis: http://s3.amazonaws.com/theoatmeal-img/comics/working_home/9.png <-- even more spot on
22:39:42  <bnoordhuis>hah, yeah
22:40:11  <piscisaureus>I think me, you and DrPizza are hit hard by that
22:40:22  <DrPizza>haha
22:43:38  <ryah>working at an office does not preclude one from working weekends and nights
22:44:24  <ryah>it just means you can't not work during 9-5 :)
22:46:22  <igorzi>heh, i'm actually a lot more productive before 9 and/or after 5 :)
22:46:34  <ryah>me too :)
22:47:15  <CIA-53>libuv: Ben Noordhuis master * r78f4aca / uv.gyp : build: fix freebsd gyp build - http://git.io/x9G3Pg
22:47:15  <CIA-53>libuv: Ben Noordhuis master * rc455f37 / src/unix/fs.c : unix: freebsd doesn't have fdatasync, do a full fsync instead - http://git.io/SPCeGA
22:49:09  <CIA-53>libuv: Igor Zinkovsky file_watcher * r421801e / src/win/fs-event.c : windows: use uv_directory_watcher_buffer_size - http://git.io/YUaeXA
22:51:00  <bnoordhuis>building node on freebsd with gyp
22:51:04  * bnoordhuiscrosses fingers
22:58:03  <ryah>piscisaureus: im not actually going to break the windows build
22:58:07  <ryah>piscisaureus: i'll put it in a branch
22:58:16  <piscisaureus>ok
22:59:07  <CIA-53>node: Ryan Dahl master * rae0dd0d / src/tty_wrap.cc : Remove extra method declaration - http://git.io/MwPx0g
22:59:27  <CIA-53>node: Ryan Dahl new-tty-binding * rbb88ba7 / (6 files in 3 dirs):
22:59:28  <CIA-53>node: Initial pass at new TTY js layer
22:59:28  <CIA-53>node: This breaks Windows. - http://git.io/NmJILA
23:00:10  <ryah>^-- REPL works
23:00:34  <ryah>it's still depending on src/node_stdio.cc in a few places - but i'll have those hammered out in a few hours
23:01:19  <ryah>so we'll be able to remove lib/tty_win32.js lib/tty_legacy.js lib/tty_posix.js src/node_stdio.cc src/node_stdio_win32.cc
23:01:27  <ryah>once this is complete
23:03:17  <piscisaureus>igorzi: are you sure all bench servers are up?
23:04:07  <piscisaureus>igorzi: it looks like NDJS-WIN6 is down
23:07:12  * ircretaryquit (*.net *.split)
23:07:38  <CIA-53>libuv: Ben Noordhuis master * r236b96a / src/unix/internal.h : unix: define HAVE_FUTIMES on freebsd - http://git.io/EmpeNA
23:07:39  <CIA-53>libuv: Ben Noordhuis master * r2dae0c9 / test/test-fs.c : test: remove futimes sub-second precision checks, unreliable on freebsd - http://git.io/tYmZAw
23:07:45  <igorzi>piscisaureus: checking..
23:14:57  <bnoordhuis>piscisaureus: you should merge those platform_windows patches for node if they're any good now
23:15:24  <piscisaureus>bnoordhuis: you mean the ones that this dude did?
23:15:30  <bnoordhuis>piscisaureus: yes
23:15:36  <piscisaureus>bnoordhuis: yes I should -
23:15:55  <piscisaureus>let me put that on my todo list for tomorrow
23:16:01  <piscisaureus>I think they're fine
23:16:22  <piscisaureus>haven't had a chance to review the last version of the cpuinfo patch
23:16:40  <piscisaureus>and there's this habit of calling perror everywhere
23:16:47  <piscisaureus>but we can fix that later
23:18:00  * mralephjoined
23:19:43  <igorzi>piscisaureus: NDJS-WIN6 is back up.. it was rebooted, and booted into linux
23:19:55  <bnoordhuis>http://theoatmeal.com/comics/sriracha <- it's true, i have that stuff in the fridge *always*
23:19:59  <piscisaureus>igorzi: thanx
23:20:09  <bnoordhuis>it's like angel dust, it makes even my girlfriend's cooking bearable!
23:25:42  * mralephquit (Quit: Leaving.)
23:27:22  * mralephjoined
23:33:55  <piscisaureus>ooh
23:34:11  <piscisaureus>bnoordhuis: be nice to her
23:35:15  <piscisaureus>http://piscisaureus.no.de/uptime
23:51:44  <piscisaureus>hmm. weird
23:52:17  <piscisaureus>now that we're reading before sending an answer performance got even worse
23:52:58  <piscisaureus>not with lower number of concurrency (0, 1, 2 forks are the same) but it doesn't get much better beyond 2 forks
23:53:41  <piscisaureus>I'd really like to see performance numbers of the other strategies - bnoordhuis, got anywhere?
23:53:41  <bnoordhuis>piscisaureus: on windows?
23:53:44  <piscisaureus>yes
23:53:58  <bnoordhuis>i haven't run the benchmarks yet
23:54:11  <bnoordhuis>igorzi's been hogging that cluster >:(
23:54:27  <piscisaureus>bnoordhuis: you can go now
23:54:59  * isaacs[away]quit (Quit: isaacs[away])
23:55:15  <igorzi>piscisaureus: bnoordhuis: reboot into linux?
23:55:22  <bnoordhuis>igorzi: yes please
23:56:28  <CIA-53>node: Ben Noordhuis master * r1e7a0aa / tools/gyp/pylib/gyp/generator/make.py : gyp: revive sunos support, lost in 6b98a63 - http://git.io/32Y8eg
23:56:29  <CIA-53>node: Ben Noordhuis master * r0f077a7 / tools/gyp/pylib/gyp/generator/make.py : gyp: add freebsd support - http://git.io/cXOMMg
23:56:29  <CIA-53>node: Ben Noordhuis master * r52037d8 / (5 files in 3 dirs): uv: upgrade to 2dae0c9 - http://git.io/Dr6D8w
23:56:29  <CIA-53>node: Ben Noordhuis master * rdecd818 / node.gyp : build: fix freebsd gyp build - http://git.io/lG9iFw
23:58:55  <CIA-53>node: Ben Noordhuis master * rb185751 / src/node_crypto.cc : crypto: fix read of potentially uninitialized variable - http://git.io/_qcaKQ
23:58:55  <CIA-53>node: Ben Noordhuis master * r320cf72 / src/node_crypto.cc : crypto: fix delete of potentially uninitialized pointer - http://git.io/YJ3kmA
23:59:34  <bnoordhuis>hey, i've passed isaac in # of commits
23:59:35  <bnoordhuis> 2200 Ryan Dahl
23:59:35  <bnoordhuis> 536 Ryan
23:59:35  <bnoordhuis> 209 Bert Belder
23:59:35  <bnoordhuis> 170 Ben Noordhuis
23:59:35  <bnoordhuis> 167 isaacs
23:59:58  <bnoordhuis>work harder, piscisaureus, i'm catching up!