00:06:02  <rmustacc>bnoordhuis: I'll have to polk around and figure out a better way to get the memory.
00:08:07  <bnoordhuis>rmustacc: i suppose we could read it from /proc/<pid>/psinfo - that's how node does it
00:08:17  <bnoordhuis>but i don't know, feels unclean
00:08:59  <rmustacc>Well, you're trying to figure out the total system memory, not the processes, right?
00:12:14  <bnoordhuis>right
00:12:21  <bnoordhuis>i think we stripped that code from node altogether
00:14:56  <rmustacc>Well, there's nothing in an individual processes /proc entry to determine that.
00:15:06  <rmustacc>At least not that I remember.
00:16:46  <bnoordhuis>no, i was mistaken about that
00:17:57  * creationix|workpart
00:20:36  <rmustacc>bnoordhuis: I don't have time to play around with it right now, but it may be simpler (and more correct i.e. container aware) to do sysconf(_SC_AVPHYS_PAGES)...
00:20:46  <rmustacc>Not really sure in practive, only in theory from a man page.
00:22:35  <rmustacc>bnoordhuis: Looking at the impl it appears to be more container aware if there's a cap on the zone.
00:25:31  <bnoordhuis>okay, let's go with that
00:26:32  <rmustacc>Okay, cool.
00:26:38  <rmustacc>You want me to play around and get a patch for that?
00:27:54  <CIA-53>libuv: Ben Noordhuis * re0a4e72 / (src/unix/sunos.c test/test-get-memory.c): sunos: look up free memory with sysconf(_SC_AVPHYS_PAGES) - http://git.io/gWY_Yg
00:28:06  <bnoordhuis>rmustacc: ^ :)
00:37:00  <rmustacc>Looks much nicer now! Now all I can do is go on my rant about double return values.
00:43:14  <bnoordhuis>yeah, i'm not too happy with that either
00:43:33  <bnoordhuis>but i'll safe that for another day
00:48:29  <rmustacc>I'd spend some cycles to help you out with that one.
00:51:23  <bnoordhuis>sure - probably all that's needed is to replace the doubles with uint64_t
00:54:46  * piscisaureusjoined
01:03:31  <piscisaureus>ryah: just saw your email
01:03:41  <piscisaureus>afternoon is not going to work :-)
01:03:51  <piscisaureus>let's have it tomorrow night (morning in your case)
01:04:01  <piscisaureus>right now it doesn;t work because I am too drunk
01:11:49  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:14:46  * AvianFluquit (Quit: Leaving)
01:16:51  * ericktquit (Quit: erickt)
01:22:55  <CIA-53>libuv: Igor Zinkovsky * r72fb469 / src/win/fs.c : windows: check for fd==-1 in uv_fs functions - http://git.io/8yaXug
01:26:49  <bnoordhuis>weirdest bug on sunos...
01:26:55  <bnoordhuis>this -> r = uv_fs_write(loop, &req, file, test_buf, sizeof(test_buf), -1, NULL);
01:27:05  <bnoordhuis>looks like this in gdb -> uv_fs_write (loop=0x80f4460, req=0x8047590, file=10, buf=0x80afca0, length=13, offset=4294967295, cb=0x8069296 <run_test_fs_symlink+94>)
01:27:24  <bnoordhuis>cb != NULL...
01:28:17  <ryah>igorzi_: thanks
01:28:39  <CIA-53>node: Igor Zinkovsky * rf164704 / doc/api/fs.markdown : fs.watch documentation - http://git.io/LFy42g
01:34:54  <ryah>bnoordhuis: big offset?
01:35:04  <bnoordhuis>yes
01:35:06  * brsonquit (Ping timeout: 244 seconds)
01:35:28  <bnoordhuis>'-D_LARGEFILE_SOURCE' '-D_FILE_OFFSET_BITS=64' <- was missing for run-tests
01:40:58  <ryah>ah - yeah
01:41:05  <ryah>that's a bitch
01:41:26  <ryah>reminds me how much i hate computers
01:41:30  <bnoordhuis>heh
01:42:36  <CIA-53>libuv: Ben Noordhuis * r014394d / uv.gyp : build: compile all targets with large file support - http://git.io/M2rfpw
01:45:22  <bnoordhuis>[% 100|+ 74|- 7]: Done. <- sunos
01:45:44  <ryah>bnoordhuis++
02:08:53  <CIA-53>libuv: Ben Noordhuis * r721ad8c / (4 files in 2 dirs): sunos: implement uv_fs_futime() - http://git.io/-bpsiQ
02:10:22  <bnoordhuis>and with that i'm off to bed
02:10:36  * bnoordhuisquit (Quit: Leaving)
02:42:23  * sh1mmerquit (Quit: sh1mmer)
02:44:17  * sh1mmerjoined
02:53:26  * sh1mmerquit (Quit: sh1mmer)
03:03:28  * bradleymeckjoined
04:41:15  * bradleymeckquit (Ping timeout: 258 seconds)
04:41:50  * bradleymeckjoined
05:12:47  * bradleymeckquit (Ping timeout: 248 seconds)
05:23:31  * isaacsjoined
05:28:46  * mjr_joined
05:39:16  <igorzi_>ryah: https://github.com/igorzi/node/commit/f808270ccde98920728b08b209598461a21256f2
05:39:31  <igorzi_>^-------- fixes simple/test-fs-utimes.js on windows
05:40:28  <CIA-53>node: Ryan Dahl * r2b46959 / (benchmark/throughput-child.js benchmark/throughput.js): Add throughput benchmark - http://git.io/JjD_1A
05:47:22  * isaacsquit (Quit: isaacs)
05:50:01  <ryah>igorzi_: thanks
05:51:48  <CIA-53>node: Igor Zinkovsky * r99757cb / test/simple/test-fs-utimes.js : fix simple/test-fs-utimes.js on windows - http://git.io/d4v44g
06:01:56  * AvianFlujoined
06:02:04  * creationixjoined
06:02:08  <creationix>evening
06:02:35  <creationix>I'm wrapping uv_spawn and I have a question about the stdin/stdout/stderr fields in the options struct
06:03:45  <creationix>what fd am I supposed to use to initialize the "initialized uv_pipe_t structs"
06:03:54  <creationix>?
06:04:51  <ryah>creationix: none - just do uv_pipe_init
06:04:58  <ryah>on some uv_pipe_t
06:05:03  <ryah>it will come back with the fd filled in
06:05:14  <ryah>(please feel free to contribute documentation patches!)
06:05:20  <creationix>so null or no arg at all?
06:05:47  <ryah>int uv_pipe_init(uv_loop_t*, uv_pipe_t* handle, int ipc);
06:06:01  <creationix>oh nevermind, I had it confused with tty
06:06:09  <creationix>pipe's arg is the ipc flag not a fd
06:06:14  <creationix>:/
06:08:22  <ryah>nope. just set that to 0 for now
06:15:52  <creationix>can windows_verbatim_arguments just be NULL
06:15:58  <creationix>I don't even build on windows yet
06:19:07  <ryah>yes
06:19:33  <creationix>ryah, do you know of a good code example for building the char** array needed for args (and I assume cwd)
06:19:49  <creationix>I have the lua table and API to iterate over it and get char* for each item
06:20:13  <creationix>I guess I could look at node's C++, it can't be that different
06:21:29  <ryah>creationix: checkout src/process_wrap.cc in node
06:22:35  <creationix>heh, I doubt `new char*[argc + 1];` works in plain C
06:24:51  <ryah>char** x = malloc(argc + 1)
06:27:38  * mralephjoined
06:29:01  <creationix>no way to stack allocate it?
06:31:33  <ryah> no
07:05:10  <creationix>hmm, seems I can stack allocate, but other stuff isn't working
07:05:15  <creationix>thanks for the help
07:05:47  <ryah>people advocate against dynamic stack allocations
07:06:06  <creationix>isn't malloc really slow
07:06:22  <creationix>(but I guess compared to spawning a process it's not that bad)
07:06:48  <ryah>yeah - i wouldn't worry about it too much until it shows up in a profile
07:07:26  <creationix>I malloc all over the place and it doesn't seem to hurt much
07:07:33  <creationix>the thing that's really slow in luajit is string concat
07:07:46  <creationix>like when building a larger string piecemeal
07:08:07  <creationix>v8 keeps it as a list internally, but lua seems to re-allocate the entire string every time it's changed
07:09:07  <ryah>mraleph: lua doesn't have constrings?
07:10:44  <creationix>ryah: sweet, I've got processes executing
07:10:47  <creationix>but my streams aren't emitting any events
07:10:57  <creationix>I don't need to call bind or open or anything on the pipes do I?
07:11:20  <creationix>I just pass in three initialized pipes in the options struct and then listen for data on them
07:11:22  <ryah>creationix: you have to call read_start
07:11:29  <creationix>ahh
07:11:41  <creationix>and do I need to call close on stdin
07:11:50  <creationix>or is that up to the user of spawn
07:12:09  <ryah>yeah - after the process dies close those pipes
07:12:51  <creationix>that worked, thanks
07:15:02  <creationix>hmm, I'm getting stdout's end after the main process emits exit
07:15:12  <creationix>if I close in exit, I never get end on stdout
07:15:29  <creationix>s/main process/child process/
07:15:46  <mraleph>ryah: no
07:16:27  <mraleph>ryah: all lua strings are interned and are real strings.
07:16:52  <creationix>mraleph: think I should make a buffer type for luvit?
07:17:07  <mraleph>creationix: also concat operator aborts the trace last time I checked.
07:17:07  <creationix>for things like building a binary protocol a byte at a time
07:17:21  <creationix>mraleph: luajit or lua5.1?
07:18:06  <mraleph>both have the same strings inside; but trace thingy obviously applied only to the jit
07:18:26  <mraleph>luajit uses more effecient string hash though I think
07:18:33  <mraleph>compared to lua one
07:18:37  <creationix>I see
07:18:56  <creationix>mraleph: did we ever get anywhere with adding 8-bit strings to v8
07:19:48  <creationix>where they hold opaque binary data and have no encoding
07:19:55  <creationix>just treat their contents like 8-bit ascii
07:20:16  <mraleph> javascript strings are ucs-2. you can't go around that. internally we have ascii strings to optimize for space and effeciency.
07:20:43  <creationix>right, I'm thinking about a C++ API that node could use for binary data
07:20:57  <creationix>but still share String's methods and interface
07:21:36  <creationix>your current ascii strings can't have the 8th bit set if I remember right
07:21:41  <mraleph>you can't use + on custom objects so it makes little sense afaik
07:22:04  <mraleph>well ascii strings consist of ascii characters :-)
07:22:29  <creationix>right, they would be real strings to the javascript that has them, but the backing store would be a vanilla 8-bit string
07:22:45  <creationix>it's probably a big change since the js api assumes ucs-2
08:06:15  * creationixchanged nick to creationix|aslee
08:06:32  * creationix|asleechanged nick to creationix|sleep
09:41:35  * mikealquit (Ping timeout: 248 seconds)
09:59:04  <CIA-53>node: Ryan Dahl * r87339a2 / (lib/net.js src/node.cc src/node.js lib/cluster.js): introduce node cluster - http://git.io/06OXxQ
10:08:10  * mikealjoined
10:09:43  * piscisaureusjoined
10:11:36  <indutny>cluster: meh
10:18:18  <ryah>:)
10:18:27  <ryah>people love shit like this
10:18:38  <ryah>we must make them happy
10:18:54  * igorzi_quit (Ping timeout: 252 seconds)
10:40:02  <indutny>:)
10:40:08  <indutny>we already have cluster module
10:40:17  <indutny>this is for user-land
10:40:31  <indutny>we wasn't pulling many shit that users seems to love
10:40:37  <indutny>but we're going to pull this
10:40:42  <indutny>that's not right
10:40:49  <indutny>we're just API providers
10:40:57  <indutny>not software
10:42:09  <indutny>probably it would be better to collaborate with tjholowachuk to improve node's API
10:42:19  <indutny>so cluster will benefit from 0.6.x branch
10:43:03  <indutny>ryah: ^
10:43:04  <indutny>;)
11:11:01  * piscisaureusquit (Ping timeout: 240 seconds)
11:40:58  * mralephquit (Read error: Connection reset by peer)
11:41:00  * mraleph1joined
11:49:49  * Casanjoined
12:02:48  * piscisaureusjoined
12:10:43  <piscisaureus>does this mean that we get `node --cluster 4` in .6 already?
12:10:49  <piscisaureus>that would be really nice
12:11:39  <indutny>piscisaureus: no it wouldn't be
12:11:40  <indutny>:)
12:11:46  <indutny>https://github.com/learnboost/cluster
12:11:54  <indutny>why do we need same thing as in user-land?
12:12:15  <indutny>anyway it won't allow you to do zero down-time updates
12:12:26  <indutny>and it's very high-level
12:12:30  <piscisaureus>hmm
12:12:33  <piscisaureus>Ik kind of agree
12:12:52  <piscisaureus>but is seems very nice to have it in core
12:13:35  <piscisaureus>because people can immediately start "practicing" for their scalable app setup
12:13:58  <indutny>heh
12:13:59  <piscisaureus>and stop whining about not using all cores and stuff
12:14:05  <indutny>ahaha :)
12:14:08  <indutny>hm....
12:14:12  <indutny>last one is nice point
12:16:19  <indutny>I think `node cluster` should print message
12:16:50  <indutny>"Yeah node is running on one core, but you can use all cores with modules like cluster"
12:17:02  <indutny>and even more
12:17:07  <indutny>"Dude it's event-loop
12:17:13  <indutny>fck multi-core env"
12:17:14  <indutny>:D
12:21:58  * piscisaureusquit (Ping timeout: 244 seconds)
12:25:06  * mikealquit (Quit: Leaving.)
12:29:09  * piscisaureusjoined
12:37:55  * mralephjoined
12:38:51  * mraleph1quit (Read error: Connection reset by peer)
12:56:05  * mraleph1joined
12:56:41  * mralephquit (Read error: Connection reset by peer)
13:02:14  * bnoordhuisjoined
13:02:47  * piscisaureusquit (Ping timeout: 244 seconds)
13:03:28  * mralephjoined
13:03:54  * mraleph1quit (Read error: Connection reset by peer)
13:19:27  * piscisaureusjoined
13:24:00  * piscisaureusquit (Ping timeout: 252 seconds)
13:48:11  <CIA-53>node: Ben Noordhuis * r752571c / src/node.cc : Remove --use-legacy switch from --help section. - http://git.io/5IklsA
14:04:43  * bradleymeckjoined
14:38:40  * piscisaureusjoined
14:54:05  * CoverSlideis listening to Bert Belder on Herding Code
14:58:36  * piscisaureusto beer time
15:03:11  * piscisaureusquit (Ping timeout: 248 seconds)
15:19:38  * ericktjoined
15:30:30  <CIA-53>libuv: Ben Noordhuis * r197f591 / (include/uv.h src/unix/error.c src/uv-common.c): common: add UV_ENOTDIR error code - http://git.io/J7qYtg
15:30:31  <CIA-53>libuv: Ben Noordhuis * r25a177a / (test/test-fs.c test/test-list.h test/fixtures/empty_file): test: assert that readdir on file raises UV_ENOTDIR - http://git.io/s--Nhg
15:30:37  <bnoordhuis>^ broken on windows right now
15:30:57  <bnoordhuis>FindFirstFile() returns ERROR_PATH_NOT_FOUND, uv__translate_sys_error() converts that to ENOENT
15:38:08  <CIA-53>node: Ben Noordhuis * rc82828e / test/simple/test-readdir.js :
15:38:08  <CIA-53>node: test: add test for #1869
15:38:08  <CIA-53>node: fs.readdir() on file should raise ENOTDIR, not UNKNOWN. - http://git.io/tWVGxQ
15:38:08  <CIA-53>node: Ben Noordhuis * rbc96302 / (17 files in 7 dirs):
15:38:08  <CIA-53>node: uv: upgrade to 25a177a
15:38:09  <CIA-53>node: Fixes #1869. - http://git.io/g56msg
15:45:22  <CIA-53>node: Ben Noordhuis * r6ed8d41 / doc/api/child_processes.markdown : docs: fix child_process.send() example - http://git.io/i2wuQw
15:50:59  * creationix|sleepquit (Quit: creationix|sleep)
16:03:37  * ericktquit (Quit: erickt)
16:21:50  * creationix|workjoined
16:23:51  * isaacsjoined
16:31:09  * Casanquit (Ping timeout: 252 seconds)
16:31:43  * bradleymeckquit (Ping timeout: 248 seconds)
16:42:56  * creationix|workpart
16:48:41  * AvianFluquit (Quit: Leaving)
17:00:13  * piscisaureusjoined
17:17:25  * ericktjoined
17:27:23  * igorzijoined
17:38:42  * bradleymeckjoined
17:40:27  * Casanjoined
17:45:33  <CIA-53>libuv: Igor Zinkovsky * r2216d38 / (src/win/fs.c test/test-fs.c test/test-list.h): windows: enable uv_fs_open to open directories - http://git.io/nsP6Qg
17:50:46  * brsonjoined
17:53:00  <ryah>bnoordhuis, igorzi: call in 10 or in an hour?
17:53:09  <bnoordhuis>ryah: 10?
17:53:36  <piscisaureus>call me too
17:53:46  <ryah>ok
17:54:07  <piscisaureus>I have not done anything (I'm still in aarhus) but I'd like to keep up to date
17:54:53  <piscisaureus>So maybe when we meet next week I know where we are at :-)
17:55:40  <igorzi>i'm good in 10
17:56:32  <igorzi>we need to discuss the pending accepts with multi-proc servers
17:57:10  * AvianFlujoined
17:57:25  <ryah>did you guys try "node cluster benchmark/http_simple.js" ?
17:58:39  <ryah>it auto-shares the servers
18:03:42  <igorzi>i haven't tried it.. does cluster work with the new ipc api?
18:10:38  <ryah>https://github.com/aikar/wormhole/blob/06b37c294318346da86b5c661025d019418627a5/testperf.js
18:16:00  <bnoordhuis>piscisaureus: 'bash' is not recognized as an internal or external command,
18:16:00  <bnoordhuis> operable program or batch file.
18:16:00  <bnoordhuis> js2c, and also js2c_experimental
18:16:18  <ryah>bnoordhuis: how do you reproduce that?
18:16:46  <bnoordhuis>ryah: create .vcxproj files with gyp, open d8.sln, build
18:16:55  <bnoordhuis>s/vcxproj/sln/
18:18:48  <bnoordhuis>also, you'll need the patch here: http://code.google.com/p/v8/issues/detail?id=1760
18:36:39  * bnoordhuistries scons
18:37:38  <CIA-53>libuv: Igor Zinkovsky * r81303a7 / src/win/fs.c : fix fs_readdir_file on windows - http://git.io/YzptKg
18:38:06  <bnoordhuis>igorzi: ^ good work
18:40:55  <bnoordhuis>piscisaureus: https://gist.github.com/a70bb3633886b3e3752f <- scons seems to think there's nothing to do
18:41:29  <piscisaureus>bnoordhuis: what about adding "sample=shell" to the command?
18:41:50  <piscisaureus>bnoordhuis: we can also screen share if you're interested (and the hotel wifi can handle it)
18:42:30  <bnoordhuis>piscisaureus: same with sample=shell
18:42:57  <bnoordhuis>screen share might be tricky to set up, i'll play with it some more
18:43:57  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:59:27  * mjr_quit (Quit: mjr_)
19:00:13  * mralephquit (Read error: Connection reset by peer)
19:01:45  * AvianFluquit (Ping timeout: 255 seconds)
19:03:04  <CIA-53>node: Bert Belder * r3fd951e / lib/net.js : Make Socket.write optimizable - http://git.io/y8TjYw
19:03:19  * piscisaureus_joined
19:03:34  * mralephjoined
19:03:34  * mralephquit (Client Quit)
19:06:46  <CIA-53>node: Bert Belder * ra73384e / lib/net.js : Make Socket.write optimizable - http://git.io/t9bbfA
19:06:48  * AvianFlujoined
19:08:17  <piscisaureus_>ryah: —^
19:18:27  <ryah>https://github.com/joyent/node/issues/1869 <-- piscisaureus_, igorzi
19:19:05  <ryah>piscisaureus_: didn't i already do that optimization? :/
19:19:18  <piscisaureus_>ryah: oh, did you?
19:19:27  <ryah>huh - :/
19:19:31  <ryah>somehow it's not there
19:19:39  <ryah>shit i thought i merged that perf branch
19:19:42  <ryah>maybe i didn't
19:19:47  <piscisaureus_>oh fuck
19:20:04  <piscisaureus_>maybe that's why aikar is having this problem :-)
19:21:22  <ryah>https://github.com/joyent/node/commit/29ec85047842dc4fc1a6127f90dc1110f7c5483e
19:21:24  <ryah>:/
19:21:47  <piscisaureus_>yes I know
19:21:49  <piscisaureus_>merge that
19:21:51  <bnoordhuis>ffs, why does '\v' in python come out as '\x0b'? who makes up that stuff?
19:22:03  <igorzi>ryah: https://github.com/joyent/node/issues/1869 should be fixed in libuv now
19:22:22  <ryah>piscisaureus_: that's in master
19:22:30  <ryah>piscisaureus_: what happened to those changes? :/
19:22:32  * isaacsquit (Quit: isaacs)
19:22:41  <ryah>igorzi: oh great - i'll upgrade libuv
19:24:13  <piscisaureus_>ryah: well then somehow you must've reverted it
19:25:13  <ryah>shit. okay
19:25:36  <ryah>let me figure out what happened then we'll get this back in
19:25:42  <ryah>no wonder our benchmarks were fucked up
19:27:09  <CIA-53>libuv: Ryan Dahl * rc903bc3 / src/unix/stream.c : unix: fix a few compiler warnings - http://git.io/qfB3JQ
19:28:09  <CIA-53>node: Ryan Dahl * rb896687 / (6 files in 4 dirs): Upgrade libuv to c903bc3 - http://git.io/m43ySw
19:28:40  <ryah>indutny: you going to do uv_cpus() ?
19:28:42  <ryah>indutny: :)
19:29:55  <CIA-53>node: Ryan Dahl * r16e1d5b / benchmark/http_simple.js : Remove uname and git-rev detection from http_simple.js - http://git.io/nx4OiA
19:30:38  <ryah>=== release test-pump-file2tcp-noexist ===
19:30:38  <ryah>Path: simple/test-pump-file2tcp-noexist
19:30:38  <ryah>pump!
19:30:38  <ryah>util.pump's callback fired
19:30:38  <ryah>Command: out/Release/node /Users/ryan/projects/node/test/simple/test-pump-file2tcp-noexist.js
19:30:41  <ryah>--- CRASHED ---
19:30:44  <ryah>:<
19:30:46  <ryah>OSX ---^
19:34:07  <bnoordhuis>wfm on linux
19:37:16  <ryah>bnoordhuis: which version of gdb did you compile?
19:37:34  <ryah>bnoordhuis: for sunos
19:37:55  <bnoordhuis>ryah: 6.8
19:38:10  <ryah>why not latest?
19:38:18  <bnoordhuis>because it was pretty broken
19:38:42  <bnoordhuis>had to hack the build and then it wouldn't boot because it couldn't identify the arch it was running on
19:40:50  <ryah>http://github.com/joyent/node/commit/12486a6437c7615af52f3d239f0b5a3000aee45d <-- this appears to be the fuck up
19:41:17  <ryah>sorry about that guys..
19:41:56  <bnoordhuis>oh well
19:42:07  <bnoordhuis>now we know who buys the beers next week
19:42:45  <ryah>:)
19:52:47  <CIA-53>node: Ryan Dahl * r25ff181 / lib/net.js :
19:52:48  <CIA-53>node: Revert some changes made in 12486a6
19:52:48  <CIA-53>node: Some of the perf improvements from many-writes-fix branch were accidentally
19:52:48  <CIA-53>node: undone in that commit. This puts them back in. - http://git.io/BdU5Og
19:54:11  <ryah>bnoordhuis: do you have a patch for the gdb 6.8 build on sun?
19:54:16  <ryah>bnoordhuis: someone is tyring to build it here
19:54:42  <ryah>bnoordhuis: or maybe just the source tree would work
19:54:55  <bnoordhuis>ryah: i didn't have to patch anything
19:55:06  <bnoordhuis>but i can upload the source
19:55:36  <bnoordhuis>ftp://sourceware.org/pub/gdb/releases/gdb-6.8a.tar.bz2 <- that's the one
19:55:44  <bnoordhuis>no need to upload
19:57:35  <ryah>bnoordhuis: was this on sunos 121?
19:58:01  <bnoordhuis>ryah: yes
20:02:20  * dapjoined
20:07:09  <ryah>latest numbers: https://gist.github.com/1282375
20:07:43  <ryah>dap: welcome
20:07:57  <dap>ryah: greetings. thanks!
20:08:33  <ryah>(dap is also a joyeur)
20:16:22  <dap>ryah, I'm trying gdb because I was hoping that since I'm using a debug build it would be able to show me the C++ structures or something. is that a reasonable hope?
20:16:37  <dap>I mean, are you able to use gdb to inspect C++ state of node?
20:16:45  <bnoordhuis>dap: yes
20:16:50  <bnoordhuis>and hi btw :)
20:16:55  <dap>hi! thanks.
20:17:37  <dap>okay, so I've attached gdb to a core file I created and it can't even see the stack. does this happen to others sometimes or am I in some weird state?
20:17:51  <dap>like "bt" says "Cannot access memory at address 0x0"
20:17:56  <bnoordhuis>the core file comes from node_g?
20:18:14  <dap>actually d8_g, in this case. not strictly a node question, I suppose
20:18:29  <bnoordhuis>ah okay
20:18:39  <bnoordhuis>with what arguments did you start gdb?
20:18:53  <dap>~/gdb v8/d8_g core.119703
20:19:37  <bnoordhuis>right, that should work
20:19:40  <bnoordhuis>this is on sunos, right?
20:19:41  <dap>this is on smartos. I have no idea how well gdb is known to work. I usually use mdb, but AFAIK that doesn't understand DWARF.
20:19:43  <dap>yeah.
20:21:05  <bnoordhuis>just tried it (sanity check), works for me
20:21:11  <bnoordhuis>what version of gdb are you using?
20:21:25  <dap>6.8a
20:21:33  <dap>well, it reports 6.8, but I downloaded 6.8a.
20:21:57  <bnoordhuis>ah, you're the guy ryah was talking about
20:22:04  <dap>yep, that's me :)
20:22:10  <dap>this core was generated from gcore, FWIW, not a crash.
20:23:10  <bnoordhuis>hrm, maybe that's the issue - i don't know if gdb handles that
20:23:47  <bnoordhuis>maybe just run it with `gdb --args v8/d8_g`?
20:23:59  * AvianFluquit (Ping timeout: 252 seconds)
20:25:33  <CIA-53>libuv: Igor Zinkovsky * r72b5976 / (5 files in 2 dirs):
20:25:33  <CIA-53>libuv: windows: support utf8 in uv_fs functions
20:25:33  <CIA-53>libuv: fixes #201 - http://git.io/CJvVRg
20:25:34  <bnoordhuis>dap: just checked, i have the same issue with gcore generated cores
20:26:39  <dap>that's too bad. unfortunately, I'm doing something a little unusual. I'm trying to figure out how to get a stack trace from an arbitrary snapshot in time, rather than debug something. I suppose I could still run it under gdb and stop it at some random point.
20:28:37  <dap>okay, now I've got a stack, it's just a bunch of hex addresses and no args. is that common while running JS code?
20:29:07  <dap>the program is basically just an infinite loop and I CTRL-C'd it to break into gdb while it was running.
20:31:41  <bnoordhuis>dap: unfortunately yes
20:32:03  <bnoordhuis>there is/was a gdbjit patch for v8 but i don't think it ever worked really well
20:33:20  <bnoordhuis>seems it's still supported: scons gdbjit=on
20:33:39  <dap>I heard that only worked on linux, though?
20:34:14  <ryah>only linux, yes
20:34:25  <bnoordhuis>darwin too, i think?
20:34:36  <ryah>also need gdb 7 for that, i think
20:37:19  * AvianFlujoined
20:38:26  <ryah>http://arlolra.no.de/bench/ab-hello-world-buffer-1024 <-- you can see perf improvement on ubuntu_lucid
20:38:37  <dap>ah, I can print static variables, and that's proving pretty helpful.
20:40:54  * isaacsjoined
20:41:07  <dap>one more thing: is there a way to print a structure with its offsets? I'd love something like what mdb can do for C structs, but for C++ classes: https://gist.github.com/ef8293fd25249a224519
20:44:52  <bnoordhuis>dap: not sure what you mean
20:44:56  <bnoordhuis>`set print pretty`?
20:45:40  <dap>I basically want a pretty-printed struct, where each member is prefixed with its actual address so I can see how the object is layed out in memory. does that make sense?
20:46:24  <dap>(if there's another way to figure that out, even better. I'm just trying to figure out how an instance of an arbitrary class is layed out in memory.)
20:46:38  <dap>but it would be sufficient to get just the offset of each member
20:46:53  <bnoordhuis>`set print address`?
20:47:20  <dap>I thought so too, but that doesn't actually change teh pretty-print output.
20:47:31  <dap>I think it affects stack traces and other forms of output.
20:48:34  <piscisaureus_>bnoordhuis: I think Aikar needs the string concat optimization
20:48:53  <piscisaureus_>bnoordhuis: his bottleneck is clearly the write path and he's queuing a lot of small string writes
20:49:06  <piscisaureus_>ryah: ^ that
20:49:25  <ryah>piscisaureus_: oh yeah, probably
20:49:25  <piscisaureus_>bnoordhuis: I am talking to you because I thought you were working on that
20:49:36  <ryah>bnoordhuis has a patch floating around
20:49:46  <ryah>we should try to get aikar to try it
20:49:59  <piscisaureus_>yeah
20:50:03  <piscisaureus_>where's that patch?
20:50:24  <bnoordhuis>somewhere in my fork, let me look it up
20:50:35  <bnoordhuis>dap: sorry, don't know
20:50:48  <ryah>dap: i dont know either
20:51:01  <dap>bnoordhuis: no worries. I'll poke around some gdb forum :) thanks for the help.
20:52:12  <ryah>./node test/pummel/test-net-write-callbacks.js 4.82s user 2.28s system 100% cpu 7.083 total
20:52:23  <bnoordhuis>piscisaureus_: https://gist.github.com/a7182192d0bf451c1cd0
20:52:35  <bnoordhuis>my pleasure, dap
20:53:06  <bnoordhuis>don't know if that patch still applies...
20:54:09  <ryah>bnoordhuis, piscisaureus_ : https://gist.github.com/1282512
20:54:34  <ryah>./node test/pummel/test-net-write-callbacks.js 0.34s user 0.13s system 99% cpu 0.470 total
20:54:37  <ryah>:P~
20:54:54  <bnoordhuis>ah, sweet
20:56:35  * AvianFluquit (Ping timeout: 260 seconds)
20:57:40  <piscisaureus_>bnoordhuis: yes, that patch does it :-)
21:04:20  <ryah>:)
21:05:51  <piscisaureus_>kewl. 0.6 can really be faster than 0,4 :-)
21:07:16  <ryah>but that patch needs some fixing - it's breaking http_simple at least
21:08:07  <bnoordhuis>it wasn't remotely finished
21:08:18  <bnoordhuis>just a quick test to see if it makes a difference
21:08:28  <bnoordhuis>seems it does :)
21:09:08  <piscisaureus_>bnoordhuis: try to not concat up strings without limits
21:09:27  <piscisaureus_>bnoordhuis: at most a few kilobytes or so
21:09:41  * AvianFlujoined
21:09:44  <piscisaureus_>bnoordhuis: otherwise we are causing v8 too much pain in dealing with cons strings
21:10:02  <bnoordhuis>piscisaureus_: so what is the sweet spot?
21:10:17  <piscisaureus_>bnoordhuis: I don't really know (yet). We should figure it out.
21:10:27  <piscisaureus_>bnoordhuis: go for 1kb for the moment
21:10:39  <piscisaureus_>or 2 or 8
21:10:41  <piscisaureus_>not more
21:10:46  <piscisaureus_>1kb should be fine
21:12:26  <piscisaureus_>bnoordhuis: v8 will either flatten the string (which means 1 extra memcopy + extra gc pressure) or write from a cons string (which has this O(n^2) behavior w.r.t the number of pieces)
21:12:31  <CIA-53>node: Ryan Dahl * r08cb8fc / src/node.cc :
21:12:31  <CIA-53>node: Remove process.ARGV
21:12:31  <CIA-53>node: Use process.argv instead. - http://git.io/wy60tA
21:19:49  <CIA-53>node: Ryan Dahl * rde7fb33 / (doc/api/_toc.markdown doc/api/cluster.markdown): Add some docs for node cluster - http://git.io/HdTgUw
21:23:56  <piscisaureus_>ryah: did you already do blocking stdout on unix?
21:24:33  <ryah>piscisaureus_: yeah
21:27:45  <CoverSlide>blocking stdout ?? why ??
21:29:06  <ryah>CoverSlide: easier
21:29:29  <CoverSlide>:/
21:29:48  <CoverSlide>is there a flag or something to change that?
21:29:56  <ryah>no - what's your concern?
21:32:32  <bnoordhuis>ryah: can we make ObjectWrap::Ref() and Unref() public?
21:32:34  <CoverSlide>i would think that affects performance if you're outputting to stdout a lot
21:33:11  <ryah>bnoordhuis: mmm
21:33:24  <ryah>bnoordhuis: why?
21:33:57  <bnoordhuis>ryah: the zlib bindings need to keep the buffer objects alive while it's running in the thread pool
21:34:06  <bnoordhuis>i can make the buffer Persistent of course
21:34:10  <ryah>CoverSlide: it also effects performs if you don't properly throttle your output
21:34:17  <bnoordhuis>but i think i like Ref() / Unref() better
21:34:31  <ryah>bnoordhuis: can't it just attach those its object?
21:34:54  <ryah>bnoordhuis: SetHiddenProperty or whatever
21:35:17  <bnoordhuis>ryah: you mean req_wrap->object_->SetHiddenProperty()
21:35:25  <bnoordhuis>i suppose so...
21:35:26  <ryah>yeah
21:35:34  <piscisaureus_>ryah: I think there is an issue with blocking stdout though atm
21:35:46  <piscisaureus_>ryah: maybe you still set the nonblocking flag
21:35:51  <ryah>piscisaureus_: possible
21:35:58  <ryah>piscisaureus_: what's happening?
21:35:59  <bnoordhuis>but we're already spending like 8% of our time in LookupProperty() :/
21:36:13  <piscisaureus_>ryah: because when I write a lot then some messages are discarded
21:36:18  <piscisaureus_>and when I do this
21:36:30  <piscisaureus_>`node writealot.js | cat`
21:36:44  <piscisaureus_>I get
21:36:55  <piscisaureus_>blablablablablablabstdout: Resource temporarily unavailable
21:37:00  <ryah>piscisaureus_: mm
21:37:42  <ryah>piscisaureus_: yes, it's possible we're not flushing properly
21:40:07  <ryah>i want to do requrie('os').cpus() for windows
21:40:10  <ryah>what function should i use?
21:40:21  <bnoordhuis>we have a pull request for that
21:40:43  <piscisaureus_>yeah, from felixge's intern
21:40:43  <bnoordhuis>https://github.com/joyent/node/pull/1664
21:41:02  <ryah>oh great
21:41:14  <bnoordhuis>really? you never did merge it, piscisaureus_ >:(
21:41:37  <piscisaureus_>oh shit
21:41:44  <piscisaureus_>yeah I totally forgot
21:41:57  <piscisaureus_>did the network interfaces patch get merged btw?
21:42:39  <piscisaureus_>https://github.com/joyent/node/pull/1652
21:42:43  <piscisaureus_>nope, neither
21:42:52  <bnoordhuis>only if you merged it, bertje...
21:42:52  <piscisaureus_>ryah: you want to add it do libuv or node
21:43:07  <piscisaureus_>because for node we can just land the above :-)
21:43:47  <ryah>we'll just land in node
21:43:51  <piscisaureus_>yeah
21:43:57  <ryah>indutny is in the process of abstracting that
21:44:01  <piscisaureus_>let me check them for the last time
21:44:05  <ryah>his patch is broken.. but i can fix
21:44:23  <ryah>or probably better if bert does it
21:44:30  <ryah>hKey undefined
21:45:05  <piscisaureus_>In his second patch he indents everything
21:45:06  <piscisaureus_>:-/
21:45:56  <piscisaureus_>hkey should just be key I think
21:46:24  <piscisaureus_>I think aarhus is on fire
21:46:40  <piscisaureus_>There dozens of fire trucks passing under my windows
21:46:47  <piscisaureus_>like they are doing a street race
21:47:28  <ryah>are you in this hotel on the canal?
21:47:43  <bnoordhuis>isaacs: https://github.com/bnoordhuis/node/commit/bd6c789 <- review?
21:47:59  <bnoordhuis>you guys are free to review it too, of course
21:48:33  <ryah>bnoordhuis: is there a test that demos that issue?
21:48:53  <bnoordhuis>ryah: not reliably
21:49:46  <isaacs>bnoordhuis: why not just have the zlib.js hang onto a reference to it or something?
21:50:03  <isaacs>i mean, we know exactly when the buffer goes to c-land, and exactly when it's done with it
21:50:27  <bnoordhuis>that would work too
21:50:39  <bnoordhuis>but this also catches the case where someone calls the bindings directly
21:51:05  <isaacs>bnoordhuis: i think we should go out of our way to make sure that never happens.
21:51:45  <isaacs>bnoordhuis: i'd even be ok with putting a guard in process.binding that the first item in the stack must be a native module.
21:51:52  <bnoordhuis>oh, i remember - we discussed this before
21:52:09  <CIA-53>node: Ryan Dahl * r73b4b86 / node.gyp : Add cluster.js to node.gyp - http://git.io/dDdaEA
21:52:13  <bnoordhuis>it wouldn't work in the case where both the zlib and buffer objects are gc'ed but the thread pool worker hasn't finished yet
21:52:28  * piscisaureus_quit (Remote host closed the connection)
21:52:33  <isaacs>bnoordhuis: no, i mean, have the code in zlib.js attach it to a module-local cache of objects.
21:52:45  <isaacs>bnoordhuis: then null it onceit comes back
21:52:51  <bnoordhuis>ah, like that
21:52:57  <bnoordhuis>hrm... let me ponder that for a bit
21:54:51  <bnoordhuis>isaacs: i think it'll be awkward
21:55:02  <bnoordhuis>you can't use buffers as object keys (they'll get stringified)
21:55:02  <isaacs>bnoordhuis: so, i'm looking at the js stuff...
21:55:10  <bnoordhuis>and arrays are slow, slow, slow
21:55:27  <isaacs>bnoordhuis: we can just create a random id when we call binding.write, and clear it out in the cb
21:55:33  <isaacs>but.... doesn't the callback itself trap it?
21:55:46  <isaacs>can you get this error to occur *ever*?
21:56:57  <bnoordhuis>you're starting to make me doubt myself :(
21:57:08  * piscisaureus_joined
21:57:09  <bnoordhuis>what callback are you referring to, isaacs?
21:57:32  <bnoordhuis>i'm talking about the obj.write() path
21:57:33  <isaacs>the callback function in zlib.js, in teh _process function
21:57:44  * piscisaureus_quit (Client Quit)
21:57:54  <isaacs>thething that calls binding.write()
21:58:22  <isaacs>around line 290 or so in zlib.js
21:58:31  <isaacs> function callback(availInAfter, availOutAfter, buffer) {
21:59:17  <bnoordhuis>hmm okay, that looks like it should enclose it
21:59:18  <ryah>hm
21:59:26  <ryah>bert - i need that cpus patch
21:59:34  <ryah>i wonder if he went away for the night
22:00:02  <bnoordhuis>ryah: probably running for higher ground now
22:00:10  <ryah>heh
22:00:23  <bnoordhuis>isaacs: i see what you mean
22:00:40  * piscisaureusjoined
22:00:49  <ryah>piscisaureus: i need that cpus patch - are you still working on it?
22:00:50  <isaacs>bnoordhuis: if not... you could do something like this: https://gist.github.com/1282775
22:00:56  <isaacs>bnoordhuis: but i thin kit might be unnecessary.
22:01:03  <bnoordhuis>but that doesn't seem to catch the case where the zlib instance itself is gc'ed
22:01:03  * piscisaureusquit (Read error: Connection reset by peer)
22:01:07  <ryah>gr
22:01:26  * piscisaureusjoined
22:01:30  <ryah>damn third world countries
22:01:38  <isaacs>bnoordhuis: so... myZ = new zlib.Deflate(); myZ.end("foo"); myZ = null
22:01:43  <bnoordhuis>Math.random() :(
22:01:50  <bnoordhuis>you hear that sound?
22:01:58  <isaacs>bnoordhuis: yeah, guess an incrementing number would be better or something.
22:01:58  <bnoordhuis>that is baby jesus, crying
22:02:01  <isaacs>haahah
22:02:29  <piscisaureus>ryah: what about 3rd world countries? :-/
22:02:56  <bnoordhuis>isaacs: the global cache approach should work
22:03:08  <isaacs>bnoordhuis: but it's unnecessary
22:03:10  <bnoordhuis>isaacs: but i'll sleep better if this is also handled at the binding layer
22:03:25  <isaacs>bnoordhuis: also, we shouldn't assume that the binding is ever used outside of node-core.
22:03:31  <isaacs>and we should preach the gospel of never ever using process.binding
22:03:39  <isaacs>or maybe even find some way to make it *actually* private.
22:03:45  * isaacsis a recovering process.binding user.
22:03:51  <bnoordhuis>me too :)
22:04:00  <isaacs>so far, it has always resulted in pain.
22:04:03  <isaacs>100% of the time.
22:04:27  * AvianFluquit (Ping timeout: 252 seconds)
22:04:38  <isaacs>so... here's the thing: that callback function gets called later. the callback function traps a reference to the req object, *and* to the zlib object.
22:04:51  <isaacs>the zlib object *can't* be gc'ed while a request is out to the binding, because there's a reference to it
22:05:00  <isaacs> var self = this;
22:05:05  <isaacs>the cb can see that.
22:05:22  <isaacs>so "self" can't be gc'ed, so self._processing can't be gc'ed, so self._processing.buffer can't be gc'ed.
22:06:25  <isaacs>same with self._buffer and self._offset
22:06:51  * AvianFlujoined
22:07:03  <bnoordhuis>hmm, i suppose that's true
22:07:16  <isaacs>of course, if you're using the binding directly, you're in shark-infested waters without a cage.
22:07:28  <CIA-53>node: Daniel Ennis * r59be975 / lib/child_process.js :
22:07:28  <CIA-53>node: Improve IPC performance.
22:07:28  <CIA-53>node: Reading of JSON data off the buffer, 10-15% performance increase.
22:07:28  <CIA-53>node: Fixes #1864. - http://git.io/TpWYmA
22:08:59  <bnoordhuis>now i wonder why valgrind sometimes complains
22:09:34  <bnoordhuis>but it's one of those 1-in-a-1000 things and valgrind is way too slow to run a 1000 times in a row....
22:11:06  * bnoordhuiswill ponder this over a late-night snack
22:11:09  <CIA-53>node: Karl Skomski * r9557020 / src/platform_win32.cc :
22:11:09  <CIA-53>node: New win32 platform function: GetCPUInfo
22:11:09  <CIA-53>node: Fixes #1644 - http://git.io/3gA1gA
22:13:33  <isaacs>bnoordhuis: if you can get it to break ever, i'd love to be proven wrong.
22:13:45  <isaacs>bnoordhuis: the more certain i am, the more exciting it is to find out i'm mistaken :)
22:15:13  <bnoordhuis>isaacs: it never crashed so far but valgrind sometimes complains about reads from / writes to unowned memory
22:15:39  <bnoordhuis>next time it happens i'll save the log
22:16:29  <isaacs>k, thnaks
22:16:52  <DrPizza>I don't suppose any of you remember that link to the LLVM mailing list where there was the discussion of the bytecode and its unsuitability for various applications
22:16:59  <DrPizza>due to implicit and explicit platform dependencies, etc.
22:17:55  <DrPizza>aha found it
22:17:56  <DrPizza>http://thread.gmane.org/gmane.comp.compilers.llvm.devel/43769
22:19:55  * bradleymeckquit (Ping timeout: 256 seconds)
22:21:09  <ryah>that post was bit of cold water in the face for me
22:21:26  <ryah>because i've always imagined llvm as the solution to all the world's problems
22:21:33  <piscisaureus>oh shit ryah ran ahead of me
22:21:36  <DrPizza>ryah: heh
22:21:38  <piscisaureus>sorry I had to recompile everything
22:21:50  <piscisaureus>I was just about to push it
22:21:50  <DrPizza>ryah: it certainly changed my understanding of LLVM
22:21:58  <DrPizza>ryah: though in retrospect, it made sense, I think
22:24:33  <ryah>so 'node cluster benchmark/http_simple.js' works on win32 now
22:25:00  * kuebk^joined
22:25:03  <kuebk^>hai
22:25:30  <piscisaureus>nope
22:25:40  <ryah>kuebk^: is interested in adding cpu affinity settings for libuv processes
22:25:48  <ryah>s/://
22:26:22  <ryah>piscisaureus: no it doesn't work?
22:26:43  <piscisaureus>Just a sec
22:26:48  <piscisaureus>ryah: so impatient today
22:27:06  <kuebk^>yea
22:27:10  <kuebk^>i wanted to add
22:27:15  <kuebk^>uv_set_affinity
22:27:18  <kuebk^>and uv_get_affinity
22:27:29  <kuebk^>but i'm not sure yet about how the api should look like
22:27:43  <DrPizza>char array bit mask
22:28:39  <kuebk^>yea
22:28:47  <kuebk^>that's about what i wasnt sure
22:28:52  <kuebk^>should it look like
22:29:20  <kuebk^>you just said DrPizza
22:29:50  <kuebk^>so uv_set_affinity(int pid, char array)
22:29:50  <piscisaureus>D:\node3>debug\node cluster benchmark\http_simple.js
22:29:50  <piscisaureus>Detected 8 cpus
22:29:50  <piscisaureus>Worker 4376 online
22:29:50  <piscisaureus>Worker 1508 online
22:29:50  <piscisaureus>Worker 6476 online
22:29:50  <piscisaureus>... etc
22:29:53  <piscisaureus>ryah : ^^
22:30:10  <DrPizza>kuebk^: probably need an array size too
22:30:16  <kuebk^>yea
22:30:16  <DrPizza>arrays are a pain in the ass in C
22:30:25  <kuebk^>sec
22:30:26  <DrPizza>but I don't know a better way to represent it
22:30:33  <DrPizza>since the number of cores is runtime-dependent
22:30:40  <piscisaureus>ryah: creating 8 workers may be a bit too much
22:30:45  <kuebk^>array of cores would be the best
22:30:46  <piscisaureus>considering that I only have 4 cores
22:30:56  <kuebk^>since user will have to put them in similar way in js
22:31:08  <DrPizza>kuebk^: so one char per core?
22:31:12  <piscisaureus>hmm windows says 8, maybe because of hyperthreading
22:31:24  <DrPizza>piscisaureus: 2600K?
22:31:29  <kuebk^>yea
22:31:39  <kuebk^>my current function prototype looks like
22:31:39  <kuebk^>int uv_set_affinity (int pid, int **core, int core_size)
22:31:53  <piscisaureus>DrPizza: 2600K?
22:31:59  <DrPizza>piscisaureus: your processor
22:32:03  <DrPizza>what is it
22:32:06  <piscisaureus>core i7
22:32:21  * AvianFluquit (Ping timeout: 255 seconds)
22:32:46  <DrPizza>kuebk^: using one whole int per CPU offends me, but it doesn't really matter I suppose
22:33:39  <piscisaureus>D:\node3>debug\node -e "console.log(require('os').cpus()[0].model)"
22:33:39  <piscisaureus>Intel(R) Core(TM) i7-2635QM CPU @ 2.00GHz
22:33:39  <piscisaureus>^-- DrPizza
22:33:46  <kuebk^>i talked with friend of mine and he told me too to user char instead of int
22:33:47  <DrPizza>oh a laptop
22:34:24  <DrPizza>piscisaureus: yeah, hyperthreaded
22:34:26  <DrPizza>4C8T
22:34:26  <ryah>piscisaureus: i think it's reasonable to start two nodes for a hyperthreded core..
22:34:46  <DrPizza>you are almost always better off treating hyperthreaded threads as real cores, these days
22:34:49  <DrPizza>it's not like the days of the P4.
22:35:08  * AvianFlujoined
22:35:22  <ryah>we definitely need an option to specify how many nodes you want
22:35:33  <DrPizza>there are still cases where turning hyperthreading off in the BIOS is better
22:35:41  <DrPizza>(not many, mind you)
22:35:47  <DrPizza>but if it's enabled, you're better off using it
22:36:26  <ryah>~/node> ./Release/node.exe
22:36:26  <ryah>> require('os').cpus()
22:36:27  <ryah>[ { model: 'Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz',
22:36:27  <ryah> speed: 2521,
22:36:27  <ryah> times:
22:36:28  <piscisaureus>ryah: I think `node cluster` is too chatty though
22:36:29  <ryah> { user: 0,
22:36:31  <ryah> nice: 0,
22:36:34  <ryah> sys: 0,
22:36:36  <ryah> idle: 0,
22:36:37  <piscisaureus>yes
22:36:39  <ryah> irq: 0 } },
22:36:41  <ryah> { model: 'Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz',
22:36:44  <ryah> speed: 2521,
22:36:46  <ryah> times:
22:36:49  <ryah> { user: 0,
22:36:51  <ryah> nice: 0,
22:36:54  <ryah> sys: 0,
22:36:56  <ryah> idle: 0,
22:36:58  <piscisaureus>ryah: indeed, the counters are all 0
22:36:59  <ryah> irq: 0 } } ]
22:37:01  <ryah>piscisaureus: on stdout?
22:37:09  <piscisaureus>just, always
22:37:37  <piscisaureus>with counters I mean nice, user, sys, irq etc
22:37:40  <DrPizza>we could do something about that, of course
22:37:46  <piscisaureus>go aheah
22:37:52  <piscisaureus>skomski didn't manage
22:38:19  <piscisaureus>ryah: oh - yeah I mean it's too chatty on stdout
22:38:32  <DrPizza>piscisaureus: oh yeah, I was waiting until I got back from the US to look at it
22:38:59  <ryah>DrPizza: are you in sf?
22:39:08  <DrPizza>no, back in the UK
22:40:06  <piscisaureus>doing AB to myself I get Requests per second: 10302.32 [#/sec] (mean)
22:41:37  <piscisaureus>but ab maxes out 1 core and that's it
22:41:38  <ryah>not so impressive
22:42:55  <piscisaureus>Indeed
22:43:14  <piscisaureus>especially considering that only 1 node does Requests per second: 7378.56 [#/sec] (mean)
22:43:19  <ryah>would be interesting to try in the MSFT lab
22:43:24  <kuebk^>DrPizza so I would also have to extend uv_process_options_t
22:43:31  <kuebk^>affinity
22:43:33  <kuebk^>and affinity_size
22:43:50  <DrPizza>kuebk^: hm, maybe
22:43:51  <DrPizza>maybe not
22:43:56  <DrPizza>you can change affinity after the fact
22:44:54  <piscisaureus>ryah: actually, 7378 #/sec is not bad at all
22:45:16  <piscisaureus>ryah: maybe in your unix world it is :-)
22:45:25  <kuebk^>what you mean DrPizza
22:45:34  <ryah>i want to rename 'node cluster' to something else
22:45:40  <ryah>so it doesn't conflict with TJ's program
22:45:43  <DrPizza>kuebk^: affinity doesn't have to be set at process start time afaik
22:45:46  <ryah>any suggestions?
22:46:02  <kuebk^>no it doesn't have to
22:46:05  <kuebk^>but it might be
22:46:08  <piscisaureus>ryah: node balance?
22:46:20  <kuebk^>balancer?
22:46:23  <piscisaureus>node multi
22:46:24  <DrPizza>ryah: node forkbomb
22:46:40  <piscisaureus>node moar
22:46:41  <ryah>node fork server.js ?
22:46:49  <piscisaureus>node many
22:47:01  <DrPizza>ryah: I know, inspect argv[0]
22:47:03  <piscisaureus>I am not in love with fork
22:47:06  <DrPizza>node -> one instance
22:47:11  <DrPizza>nodes -> multiinstance
22:47:19  <DrPizza>it's very unix.
22:47:29  <DrPizza>unix loves changing behaviour based on argv[0]
22:47:45  <piscisaureus>yeah but you don't want to have multiple binaries or what?
22:47:54  <DrPizza>piscisaureus: hard link
22:47:59  <piscisaureus>meh
22:48:59  <piscisaureus>ryah is secretly working on the fork patch already
22:49:07  <DrPizza>piscisaureus: for example
22:49:13  <DrPizza>drpizza@lunix:/bin$ diff bzcat bunzip2
22:49:13  <DrPizza>drpizza@lunix:/bin$
22:49:22  <piscisaureus>igorzi: ++ for wchar files btw
22:49:24  <DrPizza>all the bzip programs are one binary with multiple names
22:49:46  <ryah>node dup server.js ?
22:50:03  <piscisaureus>short is goof
22:50:06  <piscisaureus>good
22:50:30  <ryah>node net server.js
22:50:32  <DrPizza>node multi
22:50:33  <ryah>:/
22:50:43  <DrPizza>node hydra
22:50:53  <ryah>node multi is not so good because https://github.com/kriszyp/multi-node
22:50:54  <piscisaureus>node octopus :-p
22:51:00  <ryah>node hyper ?
22:51:02  <piscisaureus>node many
22:51:15  <piscisaureus>node distribute
22:51:18  <piscisaureus>node dist
22:51:20  <ryah>node fork server.js ...sounds good...
22:51:41  <piscisaureus>people have expectations when you say fork
22:51:46  <DrPizza>yeah
22:51:51  <DrPizza>expectations like "it won't work on windows2
22:51:53  <ryah>node dist server.js
22:51:59  <piscisaureus>but since it's called child_process.fork too the name may be okay
22:52:01  * mikealjoined
22:52:06  <piscisaureus>node dist is also fine
22:52:46  <piscisaureus>node split
22:52:48  <ryah>cluster is really the best name..
22:52:52  <piscisaureus>yeah
22:52:59  <piscisaureus>maybe node --cluster
22:53:18  <piscisaureus>that's obviously better because it doesn't get in the way of cluster.js
22:53:47  <piscisaureus>same is true for `node debug` btw
22:53:57  <ryah>*shrug*
22:54:04  <ryah>i dont think it should be a flag
22:54:13  <piscisaureus>node share
22:54:20  <ryah>let's just keep cluster for now
22:54:21  <ryah>:)
22:54:25  <piscisaureus>:-)
22:54:34  <piscisaureus>cluster will be useless anyway :-p
22:54:52  <ryah>cluster gives you nice graphs
22:55:24  <DrPizza>I think it should be a flag
22:55:30  <piscisaureus>igorzi is awesome - he moved the file system functions over to unicode
22:55:37  <DrPizza>O_O
22:55:40  <DrPizza>CreateFileW?
22:57:25  <piscisaureus>yes
22:57:37  <piscisaureus>I think we're now using _wstat instead of stat
22:57:42  <piscisaureus>so we gotta fix that at some point
22:57:48  <piscisaureus>but it can wait indefinitely :-)
22:58:08  <DrPizza>so we can do full 32k paths?
22:58:21  <piscisaureus>welll... I don't care much about those
22:58:30  <piscisaureus>just because I don't like the crt heh
22:58:37  <DrPizza>heh
22:58:38  <piscisaureus>plus _stat doesn't understand symlinks and stuff
22:58:46  <DrPizza>well ditching the CRT would be nice in general
22:58:55  <piscisaureus>which is obiviously not going to bother many people
23:00:30  <piscisaureus>oh shit I have to go
23:00:42  <piscisaureus>5 hours sleep left
23:00:44  <ryah>lock test/pummel/test-exec.js
23:00:44  <DrPizza>lol
23:01:44  <piscisaureus>ryah: seems to pass on windows
23:02:24  <piscisaureus>I want to do coding again
23:02:29  <piscisaureus>I am hoping for next week
23:02:35  <piscisaureus>in the city of code
23:06:02  <ryah>piscisaureus: yep - that's what we're going to do
23:06:04  <ryah>:)
23:06:05  * AvianFluquit (Ping timeout: 260 seconds)
23:06:15  <ryah>bug fighting week
23:06:31  <ryah>we're going to be 100% on all platforms by next friday
23:06:58  <piscisaureus>:-)
23:07:02  <piscisaureus>I like that
23:08:03  <ryah>just start working PST time so it's not a big switch :)
23:12:41  <CIA-53>node: Ryan Dahl * r651b8a0 / (lib/child_process.js test/pummel/test-exec.js): Fix test/pummel/test-exec.js - http://git.io/__2cIw
23:13:10  <DrPizza>suggestion: just delete any test that doesn't pass
23:13:17  <ryah>yep
23:16:28  * ryahlocks test/pummel/test-watch-file.js
23:18:18  * AvianFlujoined
23:20:10  <CIA-53>node: Ryan Dahl * r7b4370e / (lib/fs.js test/pummel/test-watch-file.js): Fix test/pummel/test-watch-file.js - http://git.io/U4gWRg
23:28:44  <ryah>python tools/test.py pummel
23:28:44  <ryah>[01:42|% 100|+ 23|- 0]: Done
23:28:47  <ryah>^-- osx
23:57:41  * kuebk^quit
23:59:24  <CIA-53>node: Ryan Dahl * re911171 / (4 files in 2 dirs): Move some slow tests to pummel - http://git.io/GIN2qA