00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:12  <TooTallNate>i think he's wanting to make a Buffer instance hold multiple pointers to different places in memory
00:00:14  <tjfontaine>oh
00:00:24  <TooTallNate>but it *acts* as if it's one continuous array
00:00:33  <TooTallNate>trevnorris: i think the answer is *no* though unfortunately
00:00:43  <tjfontaine>well
00:00:47  <trevnorris>exactly! thanks TooTallNate for explaining past my stupidity.
00:02:50  <tjfontaine>trevnorris: talk to me more about your use case for such a thing
00:04:40  <trevnorris>tjfontaine: using sudo syntax, char* C = A, B; then Local<Object> data; data->...ToExternalArrayData(data,...);
00:05:13  <tjfontaine>oh
00:05:52  <trevnorris>so as far as v8's concerned it's a contiguous chunk of memory, but it's not underneath.
00:06:32  <tjfontaine>ya, if you were dealing with c++ types there are some things you could do
00:07:29  <trevnorris>ooohh. do tell.
00:08:39  * indexzerojoined
00:19:12  * stagasquit (Ping timeout: 256 seconds)
00:30:03  * karupaneruraquit (Excess Flood)
00:30:20  * karupanerurajoined
00:33:38  <tjfontaine>trevnorris: well there's all sorts of things you can do with operator overloading
00:38:37  <isaacs>trevnorris: which argument?
00:39:07  <trevnorris>isaacs: like the (new TCP()).oncomplete.
00:39:14  <isaacs>trevnorris: oh, i see.
00:39:16  <isaacs>trevnorris: so just call it
00:39:23  <isaacs>without the obj.Has(fn)
00:39:25  <isaacs>thing
00:39:47  <trevnorris>there's a callback_v->IsFunction() check for every MakeCallback call.
00:40:09  <trevnorris>which the callback should always be a function since it's handled internally
00:40:20  <trevnorris>and v8 will throw an error anyways if you don't
00:49:01  <isaacs>trevnorris: oh, sure.
01:10:42  <trevnorris>is it possible for v8 to monitor memory and take notice once data has been written, when using ...ExternalArrayData...?
01:12:49  * mikealquit (Quit: Leaving.)
01:15:27  <rje>piscisaureus_: yt? interesting windows fs unlink question for you. can the unlink return success but finish asynchronously?
01:15:55  <piscisaureus_>rje: yes
01:16:27  <piscisaureus_>rje: so if a file is opened with "FILE_SHARE_DELETE" it can be deleted while it's open
01:16:38  <piscisaureus_>but windows won't actually remove the directory entry until the file has been closed
01:17:11  <piscisaureus_>cygwin works around this by trying to move the file first but it's too brittle (and slow too). So we decided not to go for that.
01:18:04  <rje>piscisaureus_: so we have this test that works 98% of the time https://github.com/luvit/luvit/blob/master/tests/test-fs-readfile-unlink.lua
01:18:24  <rje>in the fail case, the rmdir returns dir not empty
01:19:25  <rje>only happens when i'm not watching it ;/ is there a good way to ensure that unlink is actually done?
01:19:41  * trevnorrisquit (Quit: Leaving)
01:22:45  <piscisaureus_>rje: ah. this is just windows oddness
01:23:02  <piscisaureus_>rje: unless you mean you're watching it with uv_fs_watcher
01:23:20  <piscisaureus_>rje: in general I would recommend to just wait for 10ms and try again
01:23:23  <rje>piscisaureus_: no, just figure of speech.
01:24:08  <piscisaureus_>rje: you can't really get notified when the file is actually gone unfortunately. The only way is by trying to stat the file (you'll get ENOENT when it's really gone and EACCESS/EPERM when delete is pending)
01:24:19  <piscisaureus_>but if you're just trying to delete a dir, just retry that
01:24:29  <rje>yeah that's evil but not unheard of. seeing some of that using buildbot.net on windows too.
01:24:31  <piscisaureus_>I know NPM ran into this asl well
01:25:07  <piscisaureus_>ok, heading out.
01:25:08  <rje>thanks, glad to know we can all share pain together.
01:29:20  * piscisaureus_quit (Ping timeout: 252 seconds)
01:43:06  * mikealjoined
01:51:41  * mikealquit (Ping timeout: 245 seconds)
01:53:26  * abraxasjoined
02:07:04  * dapquit (Quit: Leaving.)
02:07:05  * sblomquit (Ping timeout: 276 seconds)
02:18:59  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:19:22  * mikealjoined
02:53:19  * jmar777quit (Remote host closed the connection)
03:54:11  * brsonquit (Ping timeout: 245 seconds)
03:56:33  * CoverSlidequit (Remote host closed the connection)
03:56:40  * CoverSlidejoined
04:31:05  * bradleymeckjoined
04:54:27  * bradleymeck_joined
04:57:35  * bradleymeckquit (Ping timeout: 260 seconds)
04:57:35  * bradleymeck_changed nick to bradleymeck
05:25:23  * AvianFluquit (Remote host closed the connection)
05:54:17  * bradleymeckquit (Quit: bradleymeck)
06:14:43  * piscisaureus_joined
06:24:51  * benoitcquit (Excess Flood)
06:29:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
06:34:14  * trevnorrisjoined
06:34:19  * benoitcjoined
06:35:43  * mikealquit (Quit: Leaving.)
06:41:53  <trevnorris>isaacs: you around?
06:45:57  * mikealjoined
06:50:18  * benoitcquit (Excess Flood)
07:01:49  * benoitcjoined
07:06:54  * wolfeidauquit (Remote host closed the connection)
07:14:46  * stagasjoined
07:16:57  * perezd_quit (Quit: perezd_)
07:32:56  * `3rdEdenjoined
07:36:25  * rendarjoined
07:39:14  * benoitcquit (Excess Flood)
07:41:49  * benoitcjoined
08:01:43  * benoitcquit (Excess Flood)
08:02:42  * loladiroquit (Quit: loladiro)
08:06:50  * benoitcjoined
08:17:38  * loladirojoined
08:39:41  * V1joined
08:44:30  * V1quit (Ping timeout: 260 seconds)
08:46:02  * loladiroquit (Quit: loladiro)
08:51:17  * hzjoined
08:54:26  * bnoordhuisjoined
09:01:09  * loladirojoined
09:06:26  * stagas_joined
09:07:33  * stagasquit (Ping timeout: 256 seconds)
09:10:10  * stagasjoined
09:11:50  * stagas_quit (Ping timeout: 244 seconds)
09:28:05  * loladiroquit (Quit: loladiro)
09:38:36  * abrenerjoined
09:50:05  * wolfeidaujoined
10:12:15  * stagas_joined
10:13:19  * stagasquit (Ping timeout: 244 seconds)
10:13:24  * stagas_changed nick to stagas
10:15:20  * hzquit
10:30:48  * abraxasquit (Remote host closed the connection)
10:44:23  * csaohjoined
10:46:48  <csaoh>hello, i'm looking for some help on mac os compilation. within the libuv folder I try this command: "gcc test.c -I ./include -L. -luv" and I get "ld: library not found for -luv" even though the uv.a file is within the same folder… is it normal ? am i missing something ?
10:50:28  <csaoh>after renaming uv.a to libuv.a, i get the following error: "Undefined symbols for architecture x86_64:
10:50:29  <csaoh> "_AbsoluteToNanoseconds", referenced from:
10:50:30  <csaoh> _uv_hrtime in libuv.a(darwin.o)
10:50:30  <csaoh>ld: symbol(s) not found for architecture x86_64"
10:52:35  <indutny>csaoh: what osx version are you using?
10:53:09  <csaoh>indutny: 10.8.2
10:53:13  <indutny>ok
10:53:15  <indutny>interesting
10:53:25  <indutny>so, first of all
10:53:31  <indutny>libuv.a is a static library
10:53:36  <indutny>as far as I get it
10:53:52  <indutny>so
10:54:03  <indutny>you should probably try gcc test.c -l ./include libuv.a
10:54:04  <indutny>and
10:54:06  <indutny>try adding
10:54:27  <indutny>-framework CoreServices
10:54:37  <indutny>gcc -framework CoreServices test.c -l ./include libuv.a
10:54:42  <csaoh>YES
10:54:43  <indutny>hopefuly this should work
10:54:47  <csaoh>thanks a lot ! :)
10:54:50  <indutny>np
10:54:50  <indutny>:)
10:56:38  <trevnorris>indutny: will maintainers be cool with event emitters getting a much needed cleanup?
10:56:58  <indutny>trevnorris: erhm... idk, we did it some time ago
10:57:03  <indutny>what do you want to change?
10:58:00  <trevnorris>indutny: um... variable logic paths. need to, and i mean need to add a _listenerLength method. calling, splicing and returning just to check length is bs.
10:58:13  <trevnorris>made that change and http benchmarks increased by ~5%
10:58:48  <indutny>interesting
10:58:59  <indutny>please open pull request
10:59:05  <trevnorris>indutny: using faster variable checks. removing so many array manipulations.
10:59:07  <indutny>and attach benchmark results proving that its useful
10:59:13  <trevnorris>um, need to get apply the hell out of there.
10:59:19  <indutny>ahaha
10:59:19  <indutny>again
11:00:01  <trevnorris>yeah. i'll do a pr.
11:02:55  <indutny>kewl
11:04:36  <trevnorris>indutny: using isaacs most recent benchmarks. http in my machine is up from ~14500 to ~15600 just with the event emitter changes.
11:05:48  <indutny>good
11:06:17  <trevnorris>well, it's 3am here and need to get up with the kid tomorrow. later.
11:06:23  <indutny>haha
11:06:26  <indutny>later
11:06:29  <indutny>get some sleeping
11:06:58  <trevnorris>will do
11:06:59  * trevnorrisquit (Quit: Leaving)
11:07:14  * hzjoined
11:38:18  * indexzeroquit (Quit: indexzero)
11:44:20  <MI61>joyent/node: Ben Noordhuis v0.8 * aec6e93 : doc: add tools/ dir to CONTRIBUTING.md verboten list - http://git.io/t47hIA
11:49:27  * csaohquit (Quit: csaoh)
11:57:04  * stagasquit (Read error: Connection timed out)
11:58:55  * nculturesjoined
11:58:55  * nculturespart
12:16:44  * csaohjoined
12:22:31  * bradleymeckjoined
12:30:05  * sgallaghjoined
12:35:48  * qmx|awaychanged nick to qmx
12:38:43  * bnoordhuisquit (Ping timeout: 260 seconds)
12:53:12  * qmxchanged nick to qmx|brb
12:59:02  * jmar777joined
13:03:34  * abrenerquit
13:03:45  * abrenerjoined
13:03:47  * abrenerpart
13:04:32  * abrenerjoined
13:04:50  * bnoordhuisjoined
13:13:14  * bnoordhuisquit (Ping timeout: 255 seconds)
13:16:22  * qmx|brbchanged nick to qmx
13:18:28  * bnoordhuisjoined
13:19:28  * benoitcquit (Excess Flood)
13:35:50  * benoitcjoined
13:58:04  <csaoh>i have some trouble grasping the general loop concept. When i use uv_run(loop), is it blocking ? or is the loop executed within another thread ?
13:58:43  <csaoh>could I be able to modify something within the loop structure while it's running ?
14:13:00  * bradleymeckquit (Quit: bradleymeck)
14:23:47  * csaohquit (Quit: csaoh)
14:24:23  * csaohjoined
14:26:16  * AvianFlujoined
14:31:34  <bnoordhuis>csaoh: depends on how you invoke uv_run
14:31:47  <csaoh>how so ?
14:32:00  <bnoordhuis>in master, it takes a second arg that tells it what to do: block indefinitely, block once or poll
14:32:24  <csaoh>i guess, i would need to poll
14:34:46  <bnoordhuis>do what you have to, young grashopper
14:35:05  <csaoh>haha
14:35:13  <csaoh>indeed, i wasn't looking at master
14:36:36  <csaoh>i'm looking how to suspend and resume a loop
14:37:00  <csaoh>thanks !
14:37:10  <indutny>csaoh: why do you need it?
14:38:29  <csaoh>indutny: i'm trying to make the php binding of libuv to work with php-react, but react uses stop and resume methods for event loops
14:38:38  <indutny>oh
14:39:56  <indutny>well
14:39:57  <csaoh>i managed to implement the uv_fs functions already, but now i'm blocking on this stop and resume thing
14:40:10  <indutny>you can just call uv_run_once() in a loop
14:40:23  <csaoh>i was thinking about it, actually :D
14:40:31  <csaoh>haven't tried yet though
14:42:45  <csaoh>and anyway, if my php uv_run function calls uv_run_once() in a loop, it's blocking, and i still can't see how to throw a uv_stop within… unless the second arg bnoordhuis mentioned can allow it
14:43:04  <indutny>well
14:43:08  <indutny>you can use uv_async_t
14:43:13  <indutny>to break it
14:43:29  <indutny>and yes
14:43:34  <indutny>second argument should work too
14:44:03  <csaoh>thanks, will look into it !
14:54:03  * stagasjoined
15:02:38  * bradleymeckjoined
15:05:37  * philips_quit (Excess Flood)
15:09:40  * philips_joined
15:14:08  * stagas_joined
15:15:13  * stagasquit (Ping timeout: 248 seconds)
15:15:18  * stagas_changed nick to stagas
15:16:48  <csaoh>indutny: i'm trying the second argument thing, by writing "b" after i call uv_run and "a" within the uv_run function. i made sure the loop makes at least 100 iterations. I still get stuff like "aaaaaaaaaaaab", even though i use the UV_RUN_NOWAIT mode. Is it normal ? Shouldn't I have the b somewhere in between the a's ?
15:20:50  * abrenerquit
15:28:28  <bnoordhuis>call in 30 minutes?
15:38:07  <indutny>bnoordhuis: huh?
15:41:53  <bnoordhuis>it's thursday right?
15:47:56  <indutny>it seems like
15:48:03  <indutny>but I don't think I'm going to join
15:48:07  <indutny>st. Valentine's day
15:48:09  <indutny>you know
15:51:53  * TooTallNatejoined
15:58:13  * c4milojoined
15:59:30  * sblomjoined
16:01:29  * qmxchanged nick to qmx|lunch
16:06:00  <bnoordhuis>no call then, i guess
16:06:08  * jmar777quit (Read error: Connection reset by peer)
16:06:30  * jmar777joined
16:06:54  <indutny>haha
16:14:38  <isaacs>good morning
16:15:10  * isaacsslept too late
16:15:24  <isaacs>my guess is that piscisaureus is sleepign off his jet-lag
16:16:59  <isaacs>bnoordhuis: we can have a call if you'd like though :)
16:17:12  <isaacs>bnoordhuis: you can tell me you've been working on bugs, and i can tell you i've been working on benchmarks
16:17:13  <bnoordhuis>nah, i don't really have anything to say
16:17:21  <bnoordhuis>exactly :)
16:17:40  <isaacs>i think we should definitely push the call back an hour, though
16:17:51  <isaacs>it's not as if we need to work around the c9 standup any more.
16:18:05  <bnoordhuis>the strongloop call is at 7 though
16:18:10  <isaacs>and 8am is too early for californians
16:18:22  <TooTallNate>indeed :D
16:18:30  <sblom>isaacs: anyone on the west coast, really.
16:18:34  <TooTallNate>when's that daylight savings thing happen again?
16:18:46  <isaacs>sblom: yes, i just call the whole west coast "california" becuase i'm a chauvinist
16:18:51  <sblom>Heh.
16:19:08  <tjfontaine>TooTallNate: lets not wish for losing anohter hour
16:19:31  <isaacs>bnoordhuis: you should talk to your boss about moving the strongloop call
16:19:31  <TooTallNate>haha
16:19:49  <isaacs>maybe we can work something out
16:19:57  <bnoordhuis>shouldn't be a problem
16:20:24  <bnoordhuis>i think the goal was to move it to 8 eventually anyway
16:20:30  <isaacs>kewl
16:20:45  <isaacs>found a really interesting bug last night.
16:20:51  <isaacs>you know that ECONNRESET thing we changed lately?
16:20:59  <bnoordhuis>yes?
16:21:03  <isaacs>well... let's say you write to a socket a bunch of times.
16:21:19  <isaacs>er, s/socket/http response or request/
16:21:35  <isaacs>if you get 8 false returns in a row, you go "Ok, this guy isn't listening" and destroy the socket.
16:21:45  <isaacs>when you get a 'close' event, you remove it from your "write to these guys" list.
16:22:18  <isaacs>turns out, if an ECONNRESET has happened, then the socket was already destroyed, and never emitted an error, and the 'close' event happens before you attach your listener
16:22:34  <isaacs>so, you writewritewrite destroy(), but destroy() is now a noop
16:22:50  <csaoh>sorry for being annoying with it, but i really don't get this UV_RUN_NOWAIT thing. Is it supposed to run the loop in another thread ?
16:22:58  <isaacs>AND! when you write() to a OutgoingMessage whose socket doesn't have a _handle? it pushes into an array.
16:23:10  <bnoordhuis>csaoh: no, it just polls without blocking
16:23:15  <isaacs>RSS goes up for an hour, and hten the process dies.
16:23:24  <isaacs>moral of the story: Hiding ECONNRESET = really fucking stupid.
16:23:56  <sblom>csaoh: It just means "return directly to me if you don't have any work to do"
16:24:02  <isaacs>also, i think OutgoingMessage should not assume that no handle = connecting
16:24:52  * bnoordhuisis afk for a bit
16:26:00  <csaoh>than i guess i don't fully understand the concept of polling….
16:27:55  <sblom>csaoh: It's to support a situation where you have your own main loop, and each time through the loop you want to give libuv a chance to make progress on its own queue.
16:28:55  <csaoh>hmmm… okay, thanks
16:29:15  * bnoordhuisquit (Ping timeout: 260 seconds)
16:31:06  * mikealquit (Quit: Leaving.)
16:32:21  * `3rdEdenquit (Remote host closed the connection)
16:41:18  * saghulquit (Ping timeout: 252 seconds)
16:42:06  * saghuljoined
16:47:37  * bnoordhuisjoined
16:50:46  * hzquit
16:53:17  * bnoordhuisquit (Ping timeout: 255 seconds)
16:58:42  * sblomquit (Ping timeout: 252 seconds)
17:09:27  * bradleymeckquit (Quit: bradleymeck)
17:14:39  * mikealjoined
17:15:45  * hzjoined
17:17:47  * bnoordhuisjoined
17:27:00  * dapjoined
17:30:11  * bnoordhuisquit (Ping timeout: 252 seconds)
17:30:35  * qmx|lunchchanged nick to qmx
17:32:10  * trevnorrisjoined
17:37:45  <trevnorris>anyone here compile node in windows?
17:44:25  <TooTallNate>trevnorris: isaacs does ;)
17:47:31  <TooTallNate>trevnorris: i've done it in the past
17:48:01  <trevnorris>TooTallNate: thanks. i just want to make sure that msvc will handle the changes i'm making to the ticker.
17:48:23  <trevnorris>TooTallNate: ran into this problem last time i made cc level changes, and don't want to make the mistake again. =)
17:49:53  <tjfontaine>last time it was bit twiddling though, this should be a safer world :)
17:50:36  <isaacs>trevnorris: yeah, occasionally
17:51:30  <trevnorris>tjfontaine: i've never used `struct` before, and bnoordhuis suggested i use one. so `struct {...} stuff;`. but msvc docs says it doesn't support anonymous structs. does that only mean anonymous structs within structs?
17:51:52  <trevnorris>"i use one" -> "i use an anonymous struct"
17:52:18  * tjfontainelooks at patch again
17:53:16  * mikealquit (Quit: Leaving.)
17:53:27  * jmar777quit (Remote host closed the connection)
17:54:00  * jmar777joined
17:55:59  <tjfontaine>trevnorris: well anonymous structs work in other structs, but I will relent to not knowing the answer for msvc
17:56:50  <trevnorris>tjfontaine: yeah. just going on what I found http://msdn.microsoft.com/en-us/library/z2cx9y4f.aspx
17:56:54  <TooTallNate>trevnorris: anonymous means defined without a name
17:57:57  <TooTallNate>oh no, that looks like something different
17:58:00  <TooTallNate>weird
17:58:14  * jmar777quit (Ping timeout: 252 seconds)
17:58:30  * csaohpart
17:59:05  * sblomjoined
18:01:51  <indutny>isaacs: sad fix
18:02:41  <isaacs>indutny: i think we should raise a createHangUpError
18:02:55  <isaacs>since that actually happens anyway, if the close happens in the first request
18:04:29  <sblom>On https://github.com/joyent/node/issues/4674, turns out that Node 0.9 just doesn't like being asked to spawn() nonexistent things.
18:04:39  <sblom>I assume we were happy with 0.8's behavior in this case?
18:05:56  * c4miloquit (Remote host closed the connection)
18:07:08  <sblom>(Which was to return a ChildProcess with a bunch of zeros, falses, and nulls.)
18:07:59  * loladirojoined
18:12:24  <isaacs>sblom: yeah, it should raise an ENOENT error
18:12:40  <isaacs>sblom: whatever it does on unix, assume that's correct :)
18:17:09  <sblom>So ENOENT is new behavior for 0.9. 0.8 didn't do that.
18:17:16  <sblom>isaacs^
18:17:22  <isaacs>oh, ok
18:17:24  <isaacs>sure.
18:17:25  <sblom>Maybe that's intentional.
18:18:24  <isaacs>> child_process.spawn('this-does-not-exist', []).on('exit', function(code,sig){console.log('exit', code, sig)}).on('error',console.log);1
18:18:27  <isaacs>1
18:18:28  <isaacs>that's correct behavior
18:18:30  <isaacs>^
18:18:32  <isaacs>> { [Error: spawn ENOENT] code: 'ENOENT', errno: 'ENOENT', syscall: 'spawn' }
18:18:32  * bradleymeckjoined
18:18:47  <sblom>Okay--cool. I'll make it do that everywhere.
18:18:54  <isaacs>so, we should get a 'error' event, butno 'exit' event
18:19:02  <isaacs>and definitely should not try to start reading from any sockets.
18:19:18  <isaacs>i think we do that in unix by trapping the errno==127 in the fork() call
18:19:23  <isaacs>or some such
18:19:28  <sblom>makes sense
18:19:29  <isaacs>of course, it's wildly different on windows :)
18:19:32  <sblom>Yeah.
18:20:14  <sblom>thanks
18:20:53  <TooTallNate>is there anyone licensing savvy in the house?
18:21:21  * bnoordhuisjoined
18:21:39  <sblom>licensing savvy how?
18:21:53  <isaacs>indutny: what do you think about this? https://github.com/isaacs/node/commit/727cad503f30c47b7c78a23d33ef331d28fc00fa
18:22:24  <indutny>isaacs: oh man, not right now
18:22:30  <indutny>I can take a look at it tomorrow, though
18:22:33  <isaacs>hahah
18:22:33  <isaacs>ok
18:22:36  <isaacs>sounds good :)(
18:22:40  <indutny>I'm preparing slides for my tomorrow's presentation at yandex
18:22:48  <indutny>last minute call :)
18:23:27  <TooTallNate>isaacs: i want to write bindings to libfaad2, but the AAC codec is patent-encumbered
18:23:31  * mikealjoined
18:23:54  <TooTallNate>isaacs: i just want to make sure that, writing a library and not an application, i can write this module without worrying about royalties
18:24:09  <TooTallNate>and leave that part up to the people using the module ;)
18:24:33  <tjfontaine>will you be distributing libfaad2 in binary form?
18:24:46  <TooTallNate>tjfontaine: no
18:24:50  <TooTallNate>tjfontaine: source, bundled
18:25:15  <tjfontaine>then so long as you adhere to the source license you should be relatively insulated
18:25:30  <TooTallNate>tjfontaine: however, that leaves an interesting point: one day we want to set up a native addon prebuild farm… so we *wouldn't* be able to offer binary forms of this module in that place
18:26:01  <TooTallNate>lest joyent or whoever hosts the binaries would have to pay royalties?
18:26:05  <tjfontaine>yes, the binary form of distribution becomes a more grey place
18:26:11  * TooTallNateis just trying to understand
18:26:18  * TooTallNatelaws are lame
18:26:30  <tjfontaine>binary distrubtion should definitely not be done by joyent proper, imho
18:26:47  <tjfontaine>if they're built on a joyent farm, maybe that's ok
18:32:30  <isaacs>TooTallNate: call a lawyer
18:32:41  <isaacs>TooTallNate: stuff on the npm registry is your problem, not mine/joyent's
18:33:03  <isaacs>TooTallNate: if anyone has a problem with it, they can submit a DMCA (or whatever) to me, and i'll just delete it.
18:33:09  <isaacs>TooTallNate: so far, that's never happend.
18:33:12  <tjfontaine>it will be an interesting test of safe haven if anyone complains
18:33:20  <TooTallNate>isaacs: ya i know that part, me and tjfontaine were talking about the hypothetical situation where we start installing prebuilt binaries someday
18:33:26  <isaacs>right
18:33:30  <isaacs>meh, that could get hairy
18:33:33  <isaacs>we'll deal with it
18:33:47  <TooTallNate>since binaries are a lot different than source
18:33:50  <tjfontaine>could have a patentEncumbered flag that prevents binary building :)
18:33:55  <TooTallNate>as far as the GPL is concerned
18:34:08  <TooTallNate>tjfontaine: ya i was thinking that same thing :)
18:34:20  <tjfontaine>not that everyone will follow it
18:34:33  <TooTallNate>ya but then it's their problem
18:34:36  <tjfontaine>oh look I'll just fork your package, remove the flag, and resubmit with a new name :)
18:35:26  <isaacs>trevnorris: you know what sucks about benchmarks? jitter: http://static.izs.me/node-jitter.html
18:35:37  <isaacs>trevnorris: that's comparing two identical node binaries.
18:35:49  <isaacs>fs/write-stream-throughput.js dur=1 type=asc size=2: ./node-jitter-test: 0.01837 ./node: 0.0081436 .. 125.58%
18:35:52  <isaacs>wtf.
18:36:25  <trevnorris>isaacs: lol, yeah. i'm going to sit down with one of our statisticians today and discuss how to get around this.
18:36:49  <trevnorris>basically it comes down to running the test enough to get a proper sample, then removing the outliers. then recalculating.
18:37:02  <trevnorris>pain in the ass, but only way to do it for consistent results.
18:37:21  * stagas_joined
18:37:21  <tjfontaine>even still I'm not sure there's much you're going to do about fs jitter
18:37:40  <isaacs>yeah
18:39:06  <isaacs>also, it means that running benchmarks takes for damn ever.
18:39:11  <isaacs>and that sucks.
18:39:14  * qmxchanged nick to qmx|away
18:39:15  <isaacs>because that menas we won't run them
18:39:24  <isaacs>it's already too slow.
18:39:29  * stagasquit (Ping timeout: 248 seconds)
18:39:31  * stagas_changed nick to stagas
18:39:48  * jmar777joined
18:39:58  <isaacs>maybe we could remove some of them, and like, instead of running with dur=1 and dur=3, we just run with dur=5, since that'll bounce around less.
18:40:23  <isaacs>and then run them in a server somewhere, so we can just look, rather than have to feel the heat on our laps.
18:42:04  <tjfontaine>and hopefully compare between virtualized and baremetal
18:42:22  <isaacs>trevnorris: the long and short of it is, i have absolutely no idea whether your ticker rethink is good.
18:42:26  <isaacs>trevnorris: in theory, it should be.
18:42:40  <isaacs>trevnorris: according to my measurements, it's somewhere between infinitely faster, and infinitely slower.
18:42:43  <MI61>joyent/node: Ben Noordhuis v0.8 * 3e2be6f : doc: clarify child_process.exec() stdio option It only works for stdin, - http://git.io/pIccUQ
18:42:52  <trevnorris>isaacs: lol.
18:42:57  <isaacs>bnoordhuis: thoughts on https://github.com/joyent/node/pull/4775?
18:42:58  <bradleymeck>does bert still show up in here, havent seen him in a few days
18:43:07  <isaacs>bradleymeck: yes, occasionally
18:44:03  <trevnorris>isaacs: you're going to see an improvement in tcp_raw because it's now not unnecessarily calling to js from cc ~10,000x's a second.
18:44:29  <trevnorris>isaacs: but only a little improvement for http or fs because those use nextTick like crazy. so it needs to call out anyways.
18:44:31  <isaacs>trevnorris: yeah, that's the "in theory" i was talking about :)
18:45:26  <bnoordhuis>isaacs: ask me in 36 hours when i'm in SF, i'm about to sign off :)
18:45:53  * bnoordhuisquit (Quit: leaving)
18:46:18  <isaacs>okie dokie
18:46:33  <isaacs>ircretary: tell bnoordhuis to check out https://github.com/joyent/node/pull/4775 when he gets back
18:46:33  <ircretary>isaacs: I'll be sure to tell bnoordhuis
18:49:46  <TooTallNate>isaacs: p.s. i updated readable-stream to v0.9.9 code last night
18:49:53  <TooTallNate>isaacs: you should publish a v0.3.0 release
18:49:54  <isaacs>ya, i saw, thanks!
18:50:18  <isaacs>$ npm owner ls readable-stream -s
18:50:18  <isaacs>isaacs <[email protected]>
18:50:18  <isaacs>tootallnate <[email protected]>
18:50:32  <TooTallNate>kewl, thanks
18:50:36  <isaacs>go nut!
18:50:39  <isaacs>s
18:50:41  <isaacs>multiple nuts.
18:50:45  <isaacs>going just one nut is crazy.
18:54:08  <trevnorris>isaacs: talking w/ the statistician in charge of correcting firefox's benchmarks. i'll write it up when i'm done.
18:56:45  * c4milojoined
18:58:55  * brsonjoined
19:00:51  <isaacs>kewl
19:01:06  <isaacs>trevnorris: so, really, for our purposes, we only care about net,http,fs,tls
19:01:31  <isaacs>trevnorris: other things should be tracked for significant regressions, but they're not likely to regress, and they're so fast that there's little value in cranking on them.
19:02:08  <isaacs>it's much easier to talk about "requests per second" than "milliseconds per request"
19:02:22  <isaacs>or "Gbits per second" instead of "nanoseconds per bit"
19:02:32  <isaacs>"faster" should be a bigger number.
19:02:55  * stagas_joined
19:03:08  <isaacs>because, what we're actually talking about is speed, not duration. duration is just how you measure speed. but the "number" should be how fast we are.
19:03:20  <isaacs>because, we don't usually have some fixed amount of work to do
19:03:26  <isaacs>it's always variable.
19:03:41  <isaacs>if you have a fixed task, it makes sense to talk about duration
19:04:23  <isaacs>trevnorris: but like, every http benchmarking tool in the world talks about q/s, not s/q
19:04:35  * jmar777quit (Remote host closed the connection)
19:05:13  * jmar777joined
19:05:30  * stagasquit (Ping timeout: 264 seconds)
19:05:35  * stagas_changed nick to stagas
19:08:55  * stagas_joined
19:09:42  * jmar777quit (Ping timeout: 256 seconds)
19:10:15  * stagasquit (Ping timeout: 240 seconds)
19:10:20  * stagas_changed nick to stagas
19:11:38  <trevnorris>isaacs: that discussion was about something else. the statistical analysis doesn't care about how those values are presented. as long as the measurements are consistent.
19:11:51  <isaacs>oh, ok
19:12:12  <isaacs>well, they are mostly consistent.
19:12:24  <isaacs>i mean, all the throughput tests are gigabits, all the http tests are requests
19:12:31  <trevnorris>i mean consistent as in they're all the same unit. yeah exactly.
19:12:41  <isaacs>it's just the misc tests that are kinda insane.
19:12:47  <isaacs>but like, they're doing purely in-memory cpu stuff, mostly
19:12:59  <isaacs>it's useful to test that suff, just to track changes, but it's not gonna make or break your program
19:13:11  <isaacs>if buffer speed regresses, but io is faster, i could care less.
19:13:17  <trevnorris>yeah. if I had realized my buffer improvements were only saving 100 ns per call, probably won't have worked almost 3 weeks on those.
19:13:30  <isaacs>but, if io regresses, and buffer speed regresses at the same *time*, then that's VERY interesting
19:13:59  <isaacs>trevnorris: yeah, so, the presentation of this data needs to be such that it encourages people (ie, us) to work on the right things.
19:14:01  <trevnorris>so a quick overview before I head to lunch. we'll have to sit down with each test and test the test until we know it's "stable" (i'll explain what that means later)
19:14:04  <isaacs>the best bang for the buck
19:14:14  <isaacs>right
19:14:31  <isaacs>if we can work out a program that can do this in less than an hour or so, we can jsut ahve it running on smartos and linux in the cloud
19:14:42  <isaacs>and just keep those cpus spinning round the clock
19:15:01  <trevnorris>so we should only need 1, maybe 2, tests for things like http throughput. as long as many tests are stable.
19:15:10  <isaacs>right
19:15:13  <isaacs>that makes sense.
19:16:03  <isaacs>again, let's not forget the overall goal here: fix what's actually making us slower than v0.8
19:16:14  <isaacs>so, we might have to accept "beter" before "perfect"
19:16:24  <isaacs>ok, it's lunch time. i'm gonna head out as well.
19:16:28  <trevnorris>there's some other stuff that I can handle to determine this, like calculating a student t or welch's t test
19:16:32  <trevnorris>on N iterations
19:16:43  <isaacs>ok, that's exciting :)
19:16:56  <trevnorris>cool. see ya after lunch
19:17:03  * trevnorris&
19:17:03  <LOUDBOT>JACK-O-LANTERNS WERE NAMED SO BECAUSE THEY'RE THE CLOSEST THING TO HAVE AS MUCH FACE WORK DONE AS MICHEAL JACKSON
19:17:03  <isaacs>also, just from personal experience replacing the dur=1/dur=3 tests with a single dur=5 test is a big win
19:17:21  <isaacs>and takes about the same amount of time anyway
19:32:38  * loladiroquit (Quit: loladiro)
19:34:03  <isaacs>trevnorris: CRAZY idea... not ideal, but probably the 80/20 on work/reward:
19:34:18  <isaacs>trevnorris: the benchmark function runs each test 5 times, throws out the high and low, and reports the mean.
19:34:54  <isaacs>trevnorris: i bet the jitter comes down below 5% on all tests with that change. of course, now the tests take 5 times as long to run, so we need to probably have fewer of them
19:35:35  * `3rdEdenjoined
19:46:23  * stagasquit (Read error: Connection reset by peer)
19:48:28  * stagasjoined
19:51:29  * stagas_joined
19:53:07  * stagasquit (Ping timeout: 248 seconds)
19:53:08  * stagas_changed nick to stagas
20:12:25  * stagas_joined
20:13:15  * stagasquit (Ping timeout: 256 seconds)
20:13:20  * stagas_changed nick to stagas
20:14:16  * wolfeidauquit (Remote host closed the connection)
20:24:34  * trevnorrisfg
20:24:35  * sblomquit (Ping timeout: 256 seconds)
20:26:31  <trevnorris>isaacs: you're on the right track, except before we can determine N we need to test each one.
20:27:47  <trevnorris>isaacs: run all tests in 5 sets of 100, then look at the means/stdevs. if it's not obvious they're consistent then we'll run a student t.
20:28:33  <trevnorris>isaacs: once we can verify that the test _can_ be stable at higher values, we then cross compare all tests to see if they show similarities.
20:28:59  <isaacs>trevnorris: you realize that "5 sets of 100" is like, weeks of work, right?
20:29:39  <trevnorris>isaacs: (e.g. for fs tests, if the number of bytes written/sec is linear as the chunk size increases)
20:30:32  <isaacs>right, but running the benchmarks takes several minutes. times 500 = a lot longer than is reasonable.
20:30:38  <trevnorris>isaacs: um, hu? `time `../node http/cluster.js type=bytes length=4 c=50: 23409` -> 0.36s
20:30:56  <isaacs>trevnorris: yeah, but we have way more than that
20:31:16  <isaacs>and the fs tests take for damn ever.
20:31:18  <trevnorris>isaacs: dude, this isn't every time. this is for preliminary analysis to understand how these benchmarks will look.
20:31:19  <isaacs>and tcp
20:31:21  <isaacs>oh, ok
20:31:28  <isaacs>let's do 5 sets of 10 first :)
20:31:42  <trevnorris>once we can understand what type of distribution tendency they have then we can run many fewer.
20:32:05  <trevnorris>isaacs: you understand a confidence interval?
20:32:09  <isaacs>yes
20:33:38  <trevnorris>10 is only a 32% confidence interval. not near enough to let us know the central tendency of each benchmark.
20:34:29  <trevnorris>the preliminary will be a bitch, but once we find if the benchmarks have a linear fit as variables are changes (e.g. size of buffer) then we can scrap most of the tests.
20:35:49  <isaacs>we still need to have tests that use big and small buffers.
20:36:01  <isaacs>even if we're linear today
20:37:08  <trevnorris>yes, because it may not be linear tomorrow. just like the strangeness we're seeing with tiny buffers for fs writes.
20:37:11  <isaacs>they exercise different code paths.
20:37:14  <isaacs>right
20:37:23  <isaacs>and it's easy to break one while fixing the other :)
20:38:37  <isaacs>however, in the short term, i have real questions to answer. like "should i land your tick callback patch or not"
20:38:56  <isaacs>forthat, i don't need 95% confidence intervals, i need "yes, this is probably better and not ruining anything"
20:39:11  <isaacs>which means that i need to just reduce the jitter below the diff so that i can see if it's a net win or lose.
20:39:22  <isaacs>in the meantime, yes, let's get a baseline and build something nicer.
20:39:47  <isaacs>contrary to many opinions, the perfect and the good can be friends :)
20:40:21  <isaacs>trevnorris: does that sound like a reasonable line of attack?
20:41:32  <isaacs>assuming that the imperfect "run 5 times, throw out max/min, take mean" approach reduces the jitter to less than the diffs, and we can remove some of the tests that are just too jittery still, it's still much better than our ad-hoc "run a few benchmarks, and assume that's enough" approach.
20:41:49  <isaacs>trevnorris: so we can get *something* that's at least somewhat stable landed in master, and start using it.
20:42:48  * stagas_joined
20:45:18  * stagasquit (Ping timeout: 252 seconds)
20:46:34  <trevnorris>isaacs: i have a js statistical lib that i'll tie into your most recent benchmarks (not for pr) and do the computations. give me a few.
20:46:44  <isaacs>kewl
20:47:02  <isaacs>trevnorris: so this would just be something that you run `make bench` into and have it tell us some stuff?
20:47:44  * stagas_quit (Ping timeout: 255 seconds)
20:48:34  <trevnorris>isaacs: shouldn't need to package the stat lib (jStat is pretty large). just a couple methods.
20:48:54  <isaacs>trevnorris: i mean, it can live outside of node-core?
20:48:59  <trevnorris>yeah
20:54:46  <trevnorris>isaacs: and i have another set of perf improvements in the works, but you're probably not going to like them.
20:54:59  <isaacs>hahah
20:55:14  <tjfontaine>the EE changes?
20:55:16  <isaacs>trevnorris: you see, i want nice benchmarks so that it doesn't matter what i like :)
20:55:17  <trevnorris>yeah
20:55:21  <trevnorris>lol ok
20:55:24  <isaacs>trevnorris: oh, you slicing up EE.emit?
20:55:37  <trevnorris>isaacs: well, haven't figured an elegant solution around that yet.
20:55:38  <isaacs>trevnorris: if so, i don't dislike that idea. in fact, i was kinda planning on doing it
20:55:50  <isaacs>trevnorris: if you can get that function to be much smaller, it'd be faster, i'm suspecting
20:55:57  <trevnorris>isaacs: has to do with using .listeners(arg).length
20:56:01  <isaacs>ah
20:56:12  <trevnorris>isaacs: running a splice just to get the length is bad to begin with
20:56:20  <trevnorris>but that is a high traffic function call
20:56:26  <isaacs>yep
20:56:45  <trevnorris>but that's for later. i'll get the reports done in a few.
20:56:48  <isaacs>trevnorris: if we have to give up our "no side effects" changes ot emit, then that's fine.
20:56:53  <isaacs>trevnorris: looking forward to it!
20:57:41  <trevnorris>isaacs: for users the api won't change. just how the internals manage themselves. no need to change a locked api.
20:58:29  <isaacs>trevnorris: that'd be rad.
20:58:38  <isaacs>trevnorris: check your pmsg
21:08:07  * jmar777joined
21:08:49  * jmar777quit (Remote host closed the connection)
21:09:23  * jmar777joined
21:13:19  * loladirojoined
21:13:39  * jmar777quit (Ping timeout: 248 seconds)
21:16:03  * sgallaghquit (Remote host closed the connection)
21:22:58  <isaacs>Host smartos HostName 165.225.128.184
21:38:43  * `3rdEdenquit (Remote host closed the connection)
21:43:15  * jmar777joined
21:46:01  <trevnorris>isaacs: want all my code and crap, or will a report do fine?
22:00:07  * bradleymeckquit (Quit: bradleymeck)
22:06:01  * rendarquit
22:07:34  * pooyajoined
22:28:05  * jmar777quit (Remote host closed the connection)
22:28:41  * jmar777joined
22:33:08  * jmar777quit (Ping timeout: 256 seconds)
22:44:28  * loladiroquit (Quit: loladiro)
22:46:03  * c4miloquit (Remote host closed the connection)
22:50:17  <isaacs>trevnorris: overview is fine
22:50:31  <isaacs>trevnorris: sorry for delay, had lunch meeting
22:52:03  <isaacs>trevnorris: so, the dirty "run 5 times, trim and mean" approach:
22:52:14  <isaacs>trevnorris: good enough for http_simple, but not enough for cluster
22:52:55  <isaacs>trevnorris: still around 10% jitter for cluster tests
22:53:23  <trevnorris>isaacs: yeah. almost have a script ready that will run the test N times and report all the stat information that we need.
22:54:04  <trevnorris>it's a complete hack, but hey. auto report generation is the shiz
22:54:58  <isaacs>yeah
22:55:17  <isaacs>trevnorris: are they any changes to `make bench` that would make it easier?
22:55:40  <isaacs>trevnorris: i'd be fine with making that take longer, and perhaps run fewer tests, if it gives us better data.
22:55:58  <isaacs>trevnorris: occasionally we will want to just run `make bench` to see if a patch maeks things better or worse, like we do with `make test`
22:56:02  * saghulquit (Quit: Bye!)
22:56:14  <trevnorris>isaacs: if there are, I can't identify them right now. i'll post what I get done and maybe it'll spark an idea.
22:56:21  <isaacs>kewl
22:56:23  <trevnorris>but seriously, don't judge when you see it. =)
22:56:31  <isaacs>ahah
22:56:55  <isaacs>if it gives us good data, that's an improvement
22:58:27  * saghuljoined
22:59:24  * saghulquit (Client Quit)
22:59:50  * saghuljoined
23:03:42  * LOUDBOTquit (Ping timeout: 264 seconds)
23:05:01  * trevnorrisquit (Ping timeout: 245 seconds)
23:08:58  * trevnorrisjoined
23:10:38  * hij1nxquit (Ping timeout: 252 seconds)
23:24:39  * jmar777joined
23:33:25  * jmar777quit (Remote host closed the connection)
23:34:03  * jmar777joined
23:38:11  * jmar777quit (Ping timeout: 248 seconds)
23:39:45  * piscisaureus_joined
23:39:59  <isaacs>piscisaureus_: https://github.com/joyent/node/pull/4775
23:42:09  * loladirojoined
23:43:21  <trevnorris>isaacs: here's my crazy script. it's running now, and i'll post the table once it's complete. https://gist.github.com/trevnorris/4957420
23:59:41  <isaacs>trevnorris: i am excited to see the results.