00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:16  * loladiroquit (Quit: loladiro)
00:03:13  * kazuponjoined
00:06:38  * loladirojoined
00:06:40  * loladiroquit (Client Quit)
00:07:39  * kazuponquit (Ping timeout: 252 seconds)
00:17:50  * wolfeidauquit (Remote host closed the connection)
00:17:52  * jmar777quit (Remote host closed the connection)
00:18:31  * jmar777joined
00:19:51  * loladirojoined
00:22:59  * jmar777quit (Ping timeout: 248 seconds)
00:26:18  * isaacsfg
00:26:24  * isaacscheeseburgered up
00:27:08  * jmar777joined
00:29:24  <isaacs>bnoordhuis: d'oh! 9bd9c546c87f29e12821de6c2e8bc7fa33903596 breaks the repl
00:32:45  * AvianFluquit (Remote host closed the connection)
00:40:17  <isaacs>TooTallNate: you around?
00:40:31  <TooTallNate>isaacs: i am
00:40:35  <isaacs>TooTallNate: i suggest we make \r behave like \n in readline, instead of like home
00:40:50  <isaacs>TooTallNate: TTY inputs give us a \r, not a \n
00:40:59  <isaacs>TooTallNate: because TTYs are jerks
00:41:12  <TooTallNate>isaacs: i thought that was what we were already doing?
00:41:28  <isaacs>no, actually, as of 9bd9c546c87f29e12821de6c2e8bc7fa33903596 we treat \r like home
00:41:35  <isaacs>but that's only what \r means when it's *written*
00:41:40  <isaacs>when you *read* \r, it should behave like \n
00:41:49  <isaacs>the thing is, if you get \r\n, it should behave like a single \n
00:41:53  <isaacs>not like \n\n
00:42:01  <isaacs>so, 9bd9c546c87f29e12821de6c2e8bc7fa33903596 is half right
00:42:23  <TooTallNate>it seems like we need to do a little bookkeeping
00:42:32  <TooTallNate>to keep track of if the previous char was "\r"
00:43:27  <isaacs>well, it just uses /\r?\n/ as the split instead of /\n/
00:43:29  <isaacs>in readline
00:43:36  <isaacs>but yes, it could get a \r and then later a \n
00:43:51  <TooTallNate>isaacs: that split part is for the "normal" readline though
00:43:54  <TooTallNate>not TTY readline
00:46:00  * indexzerojoined
00:46:37  <isaacs>right
00:46:40  <isaacs>what does TTY readline do?
00:46:45  <isaacs>/[\r\n]/?
00:51:05  <TooTallNate>isaacs: well this seems to fix it https://gist.github.com/f18ba69d227e103d822e
00:51:38  <trevnorris>isaacs: just to double check, benchmark/node_module/bench-timer is fine?
00:51:45  <trevnorris>(s)
00:51:47  <TooTallNate>isaacs: tty readline attempts to treat each "char" as it's own event
00:52:18  <TooTallNate>isaacs: not really sure if that patch needs anything else…
00:55:04  * paddybyersquit (Ping timeout: 272 seconds)
00:56:07  <isaacs>TooTallNate: yeah
00:56:17  <isaacs>i think that's the appropriate intention
00:56:43  <TooTallNate>isaacs: the double "return" bookkeeping would be good, but i don't think it would be common for that to happen
00:56:50  <isaacs>TooTallNate: do you think that RL needs to track if it's seen a \r at the eol, and if so, ignore a \n at the start of the next?
00:57:05  * kristatejoined
00:57:08  <isaacs>TooTallNate: it wouldn't be hard to do
00:57:10  <TooTallNate>isaacs: i do think it would be good
00:57:22  <isaacs>TooTallNate: (and i'd already done exactly that same patch in your gist)
00:57:24  <isaacs>k, one se
00:57:26  <TooTallNate>hahaha
00:57:27  <isaacs>*sec
00:57:27  <TooTallNate>:p
01:00:46  <trevnorris>isaacs: pull/4656 has the updated with bench-timer as an external lib
01:03:49  * kazuponjoined
01:03:53  * AvianFlujoined
01:05:08  <trevnorris>isaacs: it'll probably take me a week or more to hammer out how `make bench` should work. so imho don't think this PR should wait for that.
01:05:59  * indexzeroquit (Quit: indexzero)
01:07:27  * EhevuTovquit (Quit: This computer has gone to sleep)
01:09:00  * kazuponquit (Ping timeout: 272 seconds)
01:21:25  <isaacs>TooTallNate: we don't have to do any bookkeeping for \r. we already buffer everything pu until we get a \n, and since we split on \r?\n, it Just Works
01:22:03  <TooTallNate>isaacs: hmmm… i think you're confusing the "normal" code with the TTY code again...
01:22:09  <isaacs>oh, maybe
01:22:20  <isaacs>ah,yes, indeed.
01:26:40  * jmar777quit (Remote host closed the connection)
01:27:15  * jmar777joined
01:31:48  * jmar777quit (Ping timeout: 272 seconds)
01:33:10  * trevnorrisquit (Quit: Leaving)
01:35:15  <isaacs>TooTallNate: so, you think it's reasonable for \r to only be a relevant line ender in TTY mode?
01:35:30  * kristatequit (Remote host closed the connection)
01:35:49  <TooTallNate>isaacs: you mean ignore "enter"?
01:36:06  <isaacs>TooTallNate: no, i mean, foo\rbar\r is one "line" in non-tty mode
01:36:12  <isaacs>TooTallNate: but in tty mode, that's "foo","bar"
01:36:24  <TooTallNate>oh i see
01:36:29  <TooTallNate>well then yes
01:36:33  <isaacs>otherwise the non-tty splitting code gets more convoluted
01:36:41  <TooTallNate>i'd think those would be 2 "line" events
01:36:44  <TooTallNate>and we should be consistent
01:36:46  <isaacs>and right now, it's nicely simple.
01:36:47  <isaacs>ugh
01:36:47  <isaacs>ok
01:36:48  <TooTallNate>between the 2 modes
01:37:34  * abraxasjoined
01:38:30  * c4miloquit (Remote host closed the connection)
01:51:17  <isaacs>got a fix
01:51:24  <isaacs>it's not so bad
01:52:18  <isaacs>TooTallNate: https://github.com/joyent/node/pull/4683
01:52:48  <TooTallNate>isaacs: the capital T in the commit message is bugging me a tiny bit :p
01:52:54  * TooTallNate</ocd>
01:53:06  <isaacs>hahah
01:53:20  <isaacs>fixed
01:56:27  <TooTallNate>very nice
01:58:20  <isaacs>thoughts on the actual content?
02:01:00  <TooTallNate>trying it out now
02:01:32  <isaacs>k
02:02:41  <TooTallNate>damn, have to recompile from scratch
02:02:54  <TooTallNate>since i blew away my tree trying to help that guy cross-compile for arm :p
02:04:30  * kazuponjoined
02:05:10  * piscisaureus_quit (Read error: Connection reset by peer)
02:05:36  * piscisaureus_joined
02:07:06  * kazupon_joined
02:07:34  * kazupon_quit (Remote host closed the connection)
02:09:42  * kazuponquit (Ping timeout: 264 seconds)
02:14:03  * lohkeypart
02:15:14  <TooTallNate>isaacs: lgtm - pushing
02:21:50  <MI6>joyent/node: isaacs master * 60f18ed : readline: treat bare \r as a line ending Fixes #3305 - http://git.io/eXwLfw
02:23:58  <isaacs>TooTallNate: thanks :)
02:24:14  <isaacs>TooTallNate: so.. turns out crypto streams are still streams1
02:24:17  <TooTallNate>isaacs: thanks for writing the patch :)
02:24:22  <TooTallNate>ya i just saw that, haha
02:24:24  <isaacs>ugh.
02:24:31  <isaacs>v0.10 keeps pulling away from me.
02:24:40  <isaacs>releasing a new stable version of node is so much more work than you think.
02:24:56  <isaacs>even when you're right there, there's always like a million more little things
02:24:59  <isaacs>exhausting
02:27:05  * indexzerojoined
02:27:11  <TooTallNate>agree'd
02:27:18  <TooTallNate>there's lots of tiny little patches i want to get in
02:30:30  * wolfeidaujoined
02:30:52  * c4milojoined
02:34:21  * jmar777joined
02:34:47  * loladiroquit (Quit: loladiro)
02:35:20  * bradleymeckjoined
02:35:29  <isaacs>it sucks to stumble onto something like this that i just plain forgot for so long.
02:35:29  * dapquit (Quit: Leaving.)
02:35:43  <isaacs>the tiny patches are not so bad, they're just endless.
02:35:47  <isaacs>but this is kind of important.
02:35:51  * isaacsfeeling humble atm
02:36:34  * googoljoined
02:36:34  * c4miloquit (Remote host closed the connection)
02:40:50  * pooyaquit (Quit: pooya)
02:42:36  <piscisaureus_>sblom not here?
02:43:04  <piscisaureus_>I need someone to review https://github.com/joyent/libuv/pull/697 (indutny / bnoordhuis maybe?)
02:48:18  <isaacs>piscisaureus_: turns out that i forgot about CryptoStream
02:48:24  <isaacs>piscisaureus_: v0.10 will be a bit longer.
02:49:39  <piscisaureus_>ouch
02:49:39  <piscisaureus_>ok
02:49:45  * piscisaureus_signs off
02:49:45  * jmar777quit (Remote host closed the connection)
02:49:48  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:50:20  * jmar777joined
02:51:39  * piscisaureus_joined
02:51:54  <piscisaureus_>so who pinged sblom?
02:52:02  <piscisaureus_>I WANT TO SEE FINGERS!
02:55:24  * jmar777quit (Ping timeout: 272 seconds)
03:00:29  * c4milojoined
03:11:32  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:12:51  <isaacs>fuckit we should just release 0.10 with a streams1 cryptostream
03:13:08  <isaacs>no one actually uses that directly anyway
03:13:15  * isaacshalf-joking, i hope
03:13:21  <isaacs>ok, i'm off for the evening.
03:13:21  * isaacspart
03:13:25  * isaacsjoined
03:20:37  <bnoordhuis>ah, i broke the repl
03:21:01  * bradleymeckquit (Quit: bradleymeck)
03:23:05  <bnoordhuis>piscisaureus_: sblom reviewed it, right?
03:25:23  <MI6>joyent/node: Ben Noordhuis master * 3fe6aba : os: rename tmpDir() to tmpdir() for consistency Make the casing consiste - http://git.io/1ndWtw
03:28:04  <Raynos>isaacs: `Readable.wrap` the old crypto streams :D
03:29:32  * mikealquit (Quit: Leaving.)
03:29:32  * trevnorrisjoined
03:30:28  * indexzeroquit (Quit: indexzero)
03:54:03  * kazuponjoined
03:59:49  * mikealjoined
04:05:31  * abraxasquit (Remote host closed the connection)
04:06:03  * abraxasjoined
04:11:15  * abraxasquit (Ping timeout: 276 seconds)
04:12:59  <bnoordhuis>brson_: re async handles, under the hood they're pipes that get written to in one thread and read from in another thread
04:13:38  <bnoordhuis>regarding overhead, you incur two syscalls
04:20:18  <brson_>bnoordhuis: thanks, and interesting. I don't know how that compares performance wise to a mutex and condition variable but it sounds like it has more overhead. do you agree?
04:21:01  <bnoordhuis>brson_: probably yes, though outside of very tight loops it probably won't be noticeable
04:22:41  <bnoordhuis>on linux, we could switch to eventfds. you'd still have a read and a write but they'd be operating on fixed-size buffers
04:24:46  * kristatejoined
04:25:19  * indexzerojoined
04:26:54  * c4miloquit (Remote host closed the connection)
04:27:07  * TooTallNatejoined
04:27:35  <brson_>bnoordhuis: thanks for the advice. i'm glad this isn't obviously a bad idea. i'll make a point to do some performance comparisions before getting too deep into it
04:32:24  * brson_quit (Ping timeout: 276 seconds)
04:34:43  * c4milojoined
04:37:55  <trevnorris>bnoordhuis: catch any of the earlier conversation on performance regression in tcp_wrap?
04:38:21  * c4miloquit (Remote host closed the connection)
04:38:25  <bnoordhuis>trevnorris: yes. it's something i've observed as well. it's some kind of weak interaction between libuv and the slab allocator
04:38:43  <bnoordhuis>if you trace syscalls with strace -c, you'll find that things are mostly equal
04:39:16  <bnoordhuis>but when you profile it with massif or just /usr/bin/time, you'll find that peak memory usage is a lot higher
04:39:29  <bnoordhuis>with a corresponding increase in pagefaults, etc.
04:40:19  <bnoordhuis>i haven't been able to pinpoint it exactly but i suspect it's because of libuv's more aggresive approach to fetching events
04:40:58  <bnoordhuis>i.e. it's trying to be faster but that increases strain on other parts of node
04:42:55  <trevnorris>bnoordhuis: interesting. think there are any specifics I could benchmark?
04:44:49  * dapjoined
04:45:02  <trevnorris>in my benchmarks it shows that v0.8 is making 20% more calls and 53% more errors.
04:45:18  <bnoordhuis>yeah, that sounds about right
04:45:34  <bnoordhuis>i should've said that master doesn't make _more_ syscalls
04:45:56  <bnoordhuis>but try massif and compare the results in massif-visualizer
04:46:20  <bnoordhuis>for me, v0.8 heap usage is more or less flat
04:46:30  <bnoordhuis>while master has these massive spikes
04:47:17  <trevnorris>using strace -c, is the second column avg time spent on that syscall?
04:48:44  <bnoordhuis>trevnorris: yes
04:48:57  <bnoordhuis>err, third rather
04:49:06  <bnoordhuis>second one is total time spent in that syscall
04:53:16  * pooyajoined
05:08:13  <trevnorris>bnoordhuis: just ran the tests several dozen times to make sure. the write syscall on master is ~34% longer than on v0.8
05:08:45  <bnoordhuis>trevnorris: what test/benchmark are you profiling?
05:11:26  <trevnorris>bnoordhuis: have a PR for it (4656). here's the dir of tcp tests: http://git.io/0mdWkQ
05:12:16  <trevnorris>bnoordhuis: isaacs gave me a gist of these and I extended them.
05:12:31  <bnoordhuis>okay, but what test in particular are you benchmarking now?
05:12:50  <trevnorris>tcp_raw_c2s.js
05:12:54  * wolfeidauquit (Ping timeout: 252 seconds)
05:13:55  <bnoordhuis>trevnorris: have you checked nr of pagefaults? that could well explain why the write syscall is slower
05:14:29  <bnoordhuis>use /usr/bin/time for that btw, the bash builtin is rather basic
05:14:36  * loladirojoined
05:14:57  <trevnorris>thanks. one sec
05:17:10  <bnoordhuis>_ZTVN2v88internal20FastElementsAccessorINS0_31FastHoleyObjectElementsAccessorENS0_18ElementsKindTraitsILNS0_12ElementsKindE3EEELi4EEE <- c++ name mangling is so awful
05:20:02  <trevnorris>heh, seriously. always have a hard time reading those.
05:20:24  * mmaleckichanged nick to mmalecki[zzz]
05:20:37  <trevnorris>bnoordhuis: so not sure what's going on. v0.8 has 61% more minor page faults. neither have major page faults.
05:21:02  <bnoordhuis>you actually get less page faults?
05:21:14  <bnoordhuis>what's maxresident?
05:22:04  <trevnorris>master - 274,352; v0.8 - 176,424
05:22:27  <trevnorris>also master has 72% more "Voluntary context switches"
05:22:33  * abraxasjoined
05:23:28  <trevnorris>minor page faults: master - 115,550; v0.8 - 299,887
05:24:07  <trevnorris>voluntary context switches: master - 68,479; v0.8 - 18,830
05:24:26  <bnoordhuis>right, i've seen that as well
05:24:49  <bnoordhuis>but worse, more like 10x
05:25:28  <bnoordhuis>trevnorris: var timer = require('bench-timer'); <- what's that?
05:26:34  <trevnorris>bnoordhuis: the benchmark api i created for node.
05:26:50  <bnoordhuis>ah right
05:26:52  <trevnorris>bnoordhuis: isaacs had me make it an external: https://github.com/trevnorris/bench-timer
05:26:56  * mikealquit (Quit: Leaving.)
05:32:12  * qmxchanged nick to qmx|away
05:39:59  * brsonjoined
05:47:16  * loladiroquit (Quit: loladiro)
05:54:51  <trevnorris>whoa. that ms_print takes a bit to get used to.
05:55:42  <trevnorris>bnoordhuis: ok. so massif is telling me memory peaked at 256MB for master and 162MB for v0.8
05:56:13  <trevnorris>(if i'm reading it correctly)
05:58:33  <isaacs>Raynos: lolz
05:58:46  <isaacs>Raynos: Readable.wrap() is not a good idea here.
05:59:42  * mikealjoined
06:01:31  <trevnorris>isaacs: think i might be getting somewhere. bnoordhuis showed me massif, and the results are interesting. (or I could just be way confused by the ascii graphs)
06:02:52  <bnoordhuis>trevnorris: install massif-visualizer, it gives you pretty images
06:03:20  <trevnorris>bnoordhuis: ah. thanks. those ascii graphs were awesomely retro.
06:04:36  * brsonquit (Read error: Connection reset by peer)
06:04:44  * brsonjoined
06:08:47  * piscisaureus_quit (Ping timeout: 255 seconds)
06:10:28  * mikealquit (Ping timeout: 248 seconds)
06:12:22  * mikealjoined
06:14:37  <isaacs>nice
06:14:40  <isaacs>bnoordhuis: why are you up so early?
06:14:45  <isaacs>bnoordhuis: isn't it about dawn where you'er at?
06:15:06  <bnoordhuis>it is and i'm not up early, i'm up late
06:15:11  <isaacs>ouch
06:15:26  <isaacs>bnoordhuis: _ZTVN2v88internal20FastElementsAccessorINS0_31FastHoleyObjectElementsAccessorENS0_18ElementsKindTraitsILNS0_12ElementsKindE3EEELi4EEE <--it's like german
06:15:51  <isaacs>Java, C++, and Deutsch
06:15:57  <isaacs>just mash all the words together
06:16:17  <isaacs>AbstractFactoryFactoryBeanSingletonFactoryInterfaceBeanFactory
06:18:57  <trevnorris>master is spending a mother load of time in Buffer::Replace, which goes down to uv__stream_io, then uv__io_poll. but seriously don't know if this is useful.
06:19:22  * bradleymeckjoined
06:22:43  <trevnorris>isaacs: and fwiw, Buffer.byteLength is crazy slow on utf8 string.
06:28:21  <bnoordhuis>demangled names are not always an improvement... node::WrappedScript::EvalMachine<(node::WrappedScript::EvalInputFlags)0, (node::WrappedScript::EvalContextFlags)0, (node::WrappedScript::EvalOutputFlags)1>
06:31:26  <trevnorris>bnoordhuis: mean anything that master's peaking at 256MB where v0.8 at 162MB?
06:31:47  <bnoordhuis>trevnorris: yes, it means something is not okay
06:32:04  <bnoordhuis>it might be v8, i've noticed that the gc in 3.15 is a lot more passive
06:32:48  <bnoordhuis>trevnorris: http://code.google.com/p/v8/issues/detail?id=2483#c4
06:32:52  * paddybyersjoined
06:34:17  <trevnorris>bnoordhuis: yeah. that's the same % i'm seeing.
06:34:41  <bnoordhuis>so yeah, there's a lot of factors :)
06:35:02  <bnoordhuis>the good news is that whatever regression is in v8's gc seems to be fixed in 3.16
06:35:59  <trevnorris>bnoordhuis: mean anything that in v0.8 ~70% of time after heap allocation is spent in "v8::internal::Malloced::New", but in master it spends 99% time in "node::Buffer::Replace"?
06:36:07  <trevnorris>that's good to hear.
06:36:53  <bnoordhuis>yeah, only we're shipping 3.15 so it doesn't help right away
06:37:14  <bnoordhuis>re your question, i don't know. i don't think i've observed that
06:39:07  <trevnorris>bnoordhuis: https://gist.github.com/4671224
06:40:16  <trevnorris>let me updated that with equivalent timings
06:41:32  <trevnorris>bnoordhuis: whoops. nm
06:41:42  <bnoordhuis>bad benchmark? :)
06:42:09  <trevnorris>the parts I posted were at different times. so one shows process startup stuff.
06:42:22  <trevnorris>once I jumped to the same time spot they look pretty well the same.
06:42:33  <bnoordhuis>right, that makes sense
06:42:40  <trevnorris>though the total(B)
06:42:43  <trevnorris>is interesting
06:42:51  <trevnorris>like you said, in v0.8 it stays a lot more steady
06:43:02  <trevnorris>where in master it jumps from 256MB to 25MB
06:44:47  <trevnorris>i'll assume that just has to do with v8
06:44:54  <bnoordhuis>quite possibly
06:45:01  <bnoordhuis>but it could also be something that libuv does
06:45:34  <bnoordhuis>iirc i tried downgrading libuv and the issue was less severe
06:45:52  <bnoordhuis>though admittedly i'm not 100% sure if i'm remembering this correctly
06:46:53  <trevnorris>hm in master it goes: uv__stream_io -> uv__io_poll -> uv_run; in v0.8 it's uv__stream_io -> ev_invoke_pending -> uv__run -> uv_run
06:46:56  <trevnorris>that just an api change?
06:48:37  <trevnorris>other than that part, the call stack is exactly the same.
06:49:51  <bnoordhuis>yeah, api change. libev got dropped in master
06:50:03  <bnoordhuis>there was much rejoicing
06:50:14  <trevnorris>heh, awesome.
06:54:42  * dapquit (Quit: Leaving.)
06:55:23  <bnoordhuis>suspect-read,Object,"domain" <- i'm never sure what to make of these
06:55:34  <bnoordhuis>it means a LoadIC somehow failed
06:55:39  <bnoordhuis>but it also happens for builtins
06:55:54  <bnoordhuis>e.g. suspect-read,Array,"toJSON" (multiple times usually)
06:56:42  <bnoordhuis>there is no Array.prototype.toJSON, of course
06:56:46  <bnoordhuis>so i wonder where that comes from
06:58:32  * indexzeroquit (Quit: indexzero)
06:58:54  <bnoordhuis>ha, hm. looks like JSON.stringify([]) triggers it
06:59:58  <trevnorris>where's that called?
07:00:27  <bnoordhuis>not sure where it comes from in the first v8.log where i spotted it
07:00:51  <bnoordhuis>but if you run `node --prof --log_all -e 'JSON.stringify({})'` and grep the log for suspect-read
07:01:19  <bnoordhuis>you'll find what i mean. replace {} with [] or something else to observe the difference
07:01:57  <trevnorris>i'm running tcp_raw_c2s with `--trace-opt --trace-deopt --trace-inlining --code-comments`
07:02:13  <trevnorris>in v0.8 just has a lot of happy "marking ... for recompilation"
07:02:20  <trevnorris>but on master it pukes everywhere
07:02:31  <bnoordhuis>in what sense?
07:02:46  <trevnorris>**** DEOPT: process._makeCallback at bailout
07:02:53  <trevnorris>Did not inline apply called from process._makeCallback
07:02:59  <bnoordhuis>ah
07:03:17  <bnoordhuis>i think _makeCallback changed quite a bit between v0.8 and now
07:03:19  <trevnorris>also the use of call and apply is kicking us in the nuts
07:04:10  <isaacs>nice find!
07:04:18  <isaacs>yes, if makeCallback is sucking, then that is a huge nut kick
07:04:44  <trevnorris>isaacs: yeah. every half screen it's DEOPT
07:05:00  <isaacs>trevnorris: interesting
07:05:14  <isaacs>what can we do to get that not being deopted?
07:05:26  <trevnorris>i'll look at the code. give me a few.
07:06:56  <trevnorris>isaacs: also, v8 strangeness. if call or apply is in your function, even if it's not used, it will be marked as not inlineable
07:08:32  * indexzerojoined
07:10:08  <isaacs>trevnorris: weird.
07:10:26  <isaacs>stupid "this"
07:10:38  <trevnorris>yeah. v8 has really strange things. like the number of characters in your function also determines if it's inlineable
07:11:10  <isaacs>wild
07:11:19  <isaacs>would it be worth checking the arg count?
07:11:29  <isaacs>most of the time, makeCallback is called with 0 or 1 args
07:12:26  <trevnorris>probably not. i'm tracing the logic now.
07:12:47  <isaacs>i wonder if we could reduce reliance on the obj this-context as well.
07:13:20  * `3rdEdenjoined
07:14:16  * AvianFluquit (Remote host closed the connection)
07:15:43  <isaacs>trevnorris: oh, i'm dumb.
07:15:49  <isaacs>trevnorris: we can get the apply out of there.
07:15:54  <isaacs>trevnorris: quite easily, actually.
07:15:58  <trevnorris>awesome.
07:16:16  <isaacs>trevnorris: we just have to make sure we aren't passing any arbitrary methods in there, that aren't attached to the obj.
07:16:38  <isaacs>trevnorris: but most of the time, it's stuff like node::MakeCallback(handleObject, "oncomplete", argv);
07:20:38  <isaacs>testing now
07:21:33  <trevnorris>isaacs: v8 question. why is process_makeCallback a Persistent function when it's returned through scope.Close()?
07:21:50  <isaacs>um. i dunno
07:22:12  <isaacs>when is it returned through scope.Close?
07:22:37  <isaacs>i thought we just closed over the return value
07:23:32  <trevnorris>oh. just saw that process_makeCallback is declared at the top.
07:23:53  <isaacs>trevnorris: try this patch: https://github.com/isaacs/node/commit/mc-noapply
07:23:59  <isaacs>trevnorris: does that make things happier?
07:24:07  <trevnorris>it's returned through scope.Close() in MakeCallback (node.cc L964)
07:25:08  <isaacs>you mean this? return scope.Close(ret);
07:25:13  * felixgejoined
07:25:13  * felixgequit (Changing host)
07:25:13  * felixgejoined
07:26:10  <trevnorris>yeah
07:26:16  <trevnorris>wait. nm
07:26:26  <trevnorris>freaking. screen's starting to blur
07:26:35  <trevnorris>(well, my eyes are at least)
07:26:47  <isaacs>probably it's bedtime, i think
07:28:06  <isaacs>trevnorris: i can't see any massive change from this _makeCallback change, but it doesn't break anything
07:28:15  <isaacs>and it does remove a .apply() from some relatively hot code.
07:28:18  <isaacs>so that's probably good
07:28:22  <isaacs>i'll make an honest PR out of it
07:28:53  <trevnorris>yeah. sounds good. it's less noisy, so it's a start.
07:29:59  * felixgequit (Ping timeout: 252 seconds)
07:30:58  * rendarjoined
07:31:32  <isaacs>https://github.com/joyent/node/pull/4686
07:32:57  <isaacs>and with that, i'm off.
07:32:59  * isaacs&
07:34:47  <trevnorris>isaacs: still have .apply in the function. just because it exists it'll mark for deopt. stupid I know.
07:39:45  <trevnorris>um. shouldn't the end of node.js be with a `}());` or something (not a `});`) but guess it still works.
07:40:12  * felixgejoined
07:41:30  * paddybyersquit (Ping timeout: 264 seconds)
07:43:02  <indutny>whoa
07:43:03  <indutny>a lot of logs
07:43:06  <indutny>good morning
07:51:33  * kristatequit (Remote host closed the connection)
07:52:00  * bradleymeck_joined
07:53:34  * kristatejoined
07:54:38  * bradleymeckquit (Ping timeout: 255 seconds)
07:54:38  * bradleymeck_changed nick to bradleymeck
07:57:02  * paddybyersjoined
07:57:31  * pooyaquit (Ping timeout: 245 seconds)
07:57:41  <MI6>joyent/node: isaacs master * f64d1fe : lint - http://git.io/adJ09A
07:59:40  * indexzeroquit (Quit: indexzero)
08:11:04  <trevnorris>indutny: heh, nice bugzilla link
08:12:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
08:15:43  <indutny>trevnorris: that's what I'm doing in my free time
08:15:48  <indutny>filing issues everywhere
08:16:00  <trevnorris>heh, sounds like a blast.
08:17:36  <trevnorris>indutny: you understand _makeCallback?
08:17:42  <indutny>I think so
08:17:58  <trevnorris>why does it check for domain at the top, then again at the bottom?
08:19:10  <indutny>gtg :)
08:19:13  <indutny>will reply later
08:19:17  <trevnorris>ok np
08:22:43  * hzjoined
08:27:11  * paddybyersquit (Ping timeout: 240 seconds)
08:28:24  * paddybyersjoined
08:33:21  * bradleymeck_joined
08:34:35  <trevnorris>whoot! found most the regression!
08:34:41  <trevnorris>isaacs: ^
08:34:47  * kristatequit (Remote host closed the connection)
08:36:46  * bradleymeckquit (Ping timeout: 272 seconds)
08:36:46  * bradleymeck_changed nick to bradleymeck
08:37:54  <trevnorris>isaacs: those domain conditionals are causing a huge amount of bailout. comment those out and you should see a difference.
08:39:22  <trevnorris>sorry, shouldn't have said regression. should have said bailout.
08:41:44  <bnoordhuis>trevnorris: re _makeCallback and domains, it enters the domain and the top and exits again at, well, exit
08:41:59  <trevnorris>ah, ok.
08:52:54  * kazuponquit (Remote host closed the connection)
08:57:36  * googolquit (Ping timeout: 276 seconds)
08:58:41  * brsonquit (Ping timeout: 240 seconds)
08:59:50  <indutny>bnoordhuis: morning, ben
08:59:52  * wolfeidaujoined
08:59:59  <bnoordhuis>indutny: morning fedor
09:00:12  <indutny>how are you?
09:02:21  <bnoordhuis>i'm fine. you?
09:03:51  <indutny>fine too
09:08:33  * brsonjoined
09:15:42  <trevnorris>wtf? in process.nextTick we push an object to an array, then conditional immediately after to see if it has a length?
09:16:32  <indutny>and?
09:16:36  <indutny>what's up with this?
09:16:42  <trevnorris>if we push and object to it, then it will always have a length
09:16:47  <indutny>aah
09:16:49  <indutny>I see your point
09:17:00  <indutny>yes, pretty odd
09:17:20  <trevnorris>and that domain stuff is causing deopt bailouts all over the place.
09:17:30  <indutny>also my suggestion would be moving all scope variables inside process
09:17:35  <indutny>this should improve performance too
09:17:39  <trevnorris>good point
09:17:48  <trevnorris>also, we've got to loose splice.
09:35:35  <trevnorris>indutny: know what the argument "fromSpinner" could be on _tickCallback?
09:37:56  <indutny>trevnorris: `true`
09:38:28  <trevnorris>i'll assume that gets called from cc land?
09:44:29  <indutny>yes
09:44:30  <indutny>node.cc
09:44:38  <indutny>line 182
09:46:27  <trevnorris>awesome. thanks.
09:55:56  <trevnorris>indutny: also, why are we creating '{ callback: [callback] }'? why not just push the function and call it? don't see that object being used anywhere else.
10:15:48  * brsonquit (Ping timeout: 248 seconds)
10:24:51  * mmalecki[zzz]changed nick to mmalecki
10:56:25  * trevnorrisquit (Quit: Leaving)
11:05:24  * abraxasquit (Remote host closed the connection)
11:05:59  * abraxasjoined
11:11:00  * abraxasquit (Ping timeout: 264 seconds)
11:29:56  * wolfeidauquit (Remote host closed the connection)
11:45:51  * `3rdEdenquit (Remote host closed the connection)
11:46:23  * `3rdEdenjoined
11:46:48  * saghulquit (Quit: Bye!)
11:48:04  * qmx|awaychanged nick to qmx
11:58:28  * bradleymeckquit (Quit: bradleymeck)
12:19:45  * hzquit (Read error: Connection reset by peer)
12:22:39  * hzjoined
12:50:48  * sgallaghjoined
12:51:15  <bnoordhuis>the v8 people just landed a concurrent gc: https://github.com/v8/v8/commit/666d023
12:53:31  <indutny>huuuh
12:53:33  <indutny>concurrent gc?
12:53:35  <indutny>you kidding
12:53:40  <indutny>oh good
12:55:02  <indutny>still it needs to run mark-compact periodically
13:04:16  <indutny>which basically means synchronization
13:04:21  <indutny>whoa
13:04:32  <indutny>its still very interesting
13:16:40  * stephankquit (Ping timeout: 240 seconds)
13:56:31  * jmar777joined
14:41:03  * sgallaghquit (Remote host closed the connection)
14:45:46  * sgallaghjoined
15:16:50  * mikealquit (Quit: Leaving.)
15:38:32  * c4milojoined
15:57:07  * sgallaghquit (Remote host closed the connection)
15:57:26  * sgallaghjoined
15:59:04  * kristatejoined
15:59:38  * sgallaghquit (Remote host closed the connection)
16:03:06  * jokesterquit (Read error: Connection reset by peer)
16:03:36  * jokesterjoined
16:04:40  * qmxchanged nick to qmx|lunch
16:06:00  * pooyajoined
16:08:33  <isaacs>good morning
16:10:16  * sgallaghjoined
16:18:13  <bnoordhuis>evening isaac
16:18:22  * kristatequit (Remote host closed the connection)
16:19:43  * `3rdEdenquit (Remote host closed the connection)
16:21:44  <isaacs>bnoordhuis: thoughts on https://github.com/joyent/node/pull/4686?
16:22:50  <bnoordhuis>isaacs: looks okay to me in principle but i haven't benchmarked it or anything
16:23:35  <isaacs>yeah
16:23:43  <isaacs>i don't see much difference, really
16:24:23  <isaacs>we visit makeCallback a lot, but it's already pretty fast, deopt or not
16:40:45  * AvianFlujoined
16:43:57  <isaacs>So, I think the proposed date for 0.10 is going to have to be pushed back a bit. Looing at February right now.
16:44:01  <isaacs>*looking
16:44:06  <isaacs>Too much still to do, and we're still too slow.
16:44:20  <indutny>CryptoStream is a bit of pain :)
16:44:29  <isaacs>yes
16:44:30  <isaacs>it is
16:44:36  <isaacs>i'm thinking about it. i think tomorrow i can write it.
16:44:47  <indutny>well, I'd like to do it myself :)
16:44:53  <isaacs>oh, ok :)
16:44:55  <indutny>but if you can do it fast
16:44:56  <isaacs>be my guest :)
16:45:02  <indutny>probably its worth trying :)
16:45:14  <isaacs>we can have a race :) I think that the CleartextStream and EncryptedStream
16:45:15  <indutny>because I'll definitely waste some times
16:45:21  <isaacs>both need to be a Duplex, right?
16:45:27  <indutny>surely yes
16:45:43  <isaacs>and their write() side just has to be connected to the other guy's read buffer.
16:45:53  <indutny>erm... not exactly
16:45:54  * pooyaquit (Quit: pooya)
16:45:58  <isaacs>not exactly
16:46:00  <isaacs>but through openssl
16:46:04  <indutny>well, yes
16:46:24  <indutny>but not every write() results in addition to read buffer
16:46:47  <indutny>and not every addition to read buffer was caused by write()
16:47:00  <isaacs>right
16:47:02  <indutny>so... its more like two buffering streams
16:47:13  <indutny>and openssl reads and writes from/to both of them
16:47:26  <isaacs>write(chunk) pushes it down to openssl, and when openssl has data for us, we put it into the readable buffer side
16:47:52  * stephankjoined
16:48:01  <isaacs>we could even keep a very thing with the pair.cycle() function, and just attach the streams2 machinery on top of it, but it's a bit odd.
16:48:11  <isaacs>since cycle() will always pull as much as possible and always push as much as possible.
16:48:36  <isaacs>so it'd basically just need to do different stuff with where it puts the data
16:48:44  <indutny>I think so, yes
16:48:55  <indutny>basically every stream should try to pull on ._read()
16:49:01  <indutny>and should try to push on ._write()
16:49:05  <isaacs>yes
16:49:18  <isaacs>and when there's data, we do ret=stream.push(chunk) and if ret is false, we stop
16:49:27  <isaacs>that's like the _paused flag.
16:50:06  <indutny>you want to preserve most of the existing logic?
16:50:14  <isaacs>well, i mean, it works
16:50:19  * piscisaureus_joined
16:50:33  <indutny>yeah
16:50:38  <isaacs>we just have to change the surface interface, and that means we'll have to change when push/pull get called.
16:50:39  <indutny>this is good idea
16:50:45  <bnoordhuis>ssssh, bert's back
16:51:07  <indutny>isaacs: so I told them, you guys are morons
16:51:20  <indutny>and they told me "yeah, we're"
16:51:24  <indutny>piscisaureus_: hi!
16:51:45  * isaacswants to hear the rest of this fake conversation, it's way more interesting than talking about CryptoStreams
16:52:54  <indutny>man, don't tell me about interesting stuff
16:53:00  <indutny>I'm sitting alone in the car
16:53:07  <indutny>and will sit here for almost 1.5 hours
16:53:12  <isaacs>indutny: gathering benchmarks for mc-noapply now
16:53:12  <indutny>god thanks I've 3g internet with me
16:53:16  <isaacs>indutny: ??
16:53:19  <isaacs>indutny: i thought you had a home
16:53:35  <indutny>I'm waiting for my wife to get there
16:53:43  <indutny>and she'll come 1.5h later
16:56:01  <isaacs>ah
16:56:04  <indutny>about cryptostreams
16:56:12  <indutny>I just realized that tlsnappy doesn't have write callback
16:56:17  <indutny>interesting :)
16:56:33  <indutny>things are much simplier without it
16:56:34  <isaacs>we don't actually use that anywhere
16:56:40  <isaacs>but it was a part of the API early on
16:56:48  <isaacs>until streams2, it was used really inconsistently
16:56:51  <indutny>well, now its used in streams2
16:56:54  <isaacs>yeah
16:57:09  <isaacs>some streams called the cb when it was dispatched, others when it was flushed
16:58:26  * pooyajoined
16:58:46  <indutny>yes
16:58:50  <indutny>pretty inconsistent
17:00:49  <isaacs>indutny: re mc-noapply: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=8
17:00:55  <isaacs>only a 1.5% increase in http_simple
17:01:00  <isaacs>but i'm seeing it pretty consistently
17:01:21  <isaacs>so, not enough to look at and go WOW! but enough to be worth some ugly unrolled code, i guess.
17:02:48  <indutny>ok
17:03:00  <indutny>seems to be legit
17:04:21  <isaacs>lgty?
17:04:46  <indutny>let me take a look at code once again
17:06:01  <isaacs>oh, let me see if it's a bigger diff with a smaller buffer size
17:06:23  <indutny>sure
17:07:13  * indexzerojoined
17:08:18  <indutny>otherwise lgtm
17:08:45  <indutny>why have you removed one MakeCallback()?
17:10:44  <isaacs>because you call it now only with a string, never with a function reference
17:10:52  <isaacs>so we do obj[fn](arg, arg, arg)
17:10:56  <isaacs>instead of fn.apply(obj, args)
17:11:09  <isaacs>or fn.call(obj, arg, arg)
17:11:53  <isaacs>yeah, i'ts a 2.6% increase with LENGTH=1
17:12:03  <isaacs>which makes sense, since that's spending more time in JS and less in IO
17:13:47  <indutny>yep
17:13:51  <indutny>ok, lgtm
17:13:59  <indutny>I suppose test are passing
17:19:55  * dapjoined
17:25:15  <piscisaureus_>indutny: hi!
17:25:19  <piscisaureus_>bnoordhuis: oh shit
17:27:11  <isaacs>indutny: yes, all tests are passing
17:27:18  <MI6>joyent/node: isaacs master * 0168109 : node: Do not use fn.apply() in process._makeCallback - http://git.io/767Leg
17:27:59  <MI6>joyent/libuv: Bert Belder master * 3759d71 : win: get rid of early ipv6 support detection No longer explictly check w (+7 more commits) - http://git.io/BohVOw
17:30:12  * trevnorrisjoined
17:30:52  <isaacs>trevnorris: landed the no-apply thing
17:31:03  <isaacs>trevnorris: but it's not a huge improvement further up the stack
17:31:08  <trevnorris>isaacs: awesome.
17:31:19  <trevnorris>isaacs: the biggest problem with bailouts comes from those domain checks.
17:31:20  <isaacs>trevnorris: I suspect that tickCallback will be similar.
17:31:43  <isaacs>trevnorris: is there a way to get the same functionality without the bailouts?
17:32:07  <isaacs>i mean, it's nice to start hacking off features to get us 1-3% speed boosts, but people will be upset.
17:32:16  <trevnorris>isaacs: i'll look into it. right now I've just taken them out for testing.
17:32:27  <isaacs>if we were going to do that, we'd be better off ditching streams. (not streams2. streams entirely.)
17:32:44  <isaacs>good news! http is 80% faster!
17:32:49  <trevnorris>lol
17:32:57  <isaacs>(bad news: we've replaced require('http') with process.binding('http_parser')
17:33:21  <trevnorris>i think we can get that worked out.
17:33:55  <trevnorris>isaacs: if you can help me understand startup.nextTick better, think I can get there.
17:34:29  <isaacs>trevnorris: so, basicaly, if there's a domain, we enter it
17:34:35  <trevnorris>in PR-4687 what i'm trying to do is create an array or arrays. each one its own stack
17:34:45  <isaacs>trevnorris: sure, i saw that.
17:34:46  <isaacs>that's fine.
17:35:01  <isaacs>but it seems like you've replaced tickDepth with something different
17:35:15  <isaacs>the length of that array would be the number of nextTicks that were added, not the number of nextTicks that you have already seen
17:35:26  * AvianFlu_joined
17:35:39  <isaacs>process.nextTick(function(){ tickDepth=1; process.nextTick(function(){tickDepth==2}); }); tickDepth === 0
17:36:10  <isaacs>the thing is, if you do this: (function T(){process.nextTick(T)})()
17:36:16  <trevnorris>tickDepth was being used to determine how much of the nextTickQueue to splice off, right?
17:36:16  <isaacs>trevnorris: then that's going to spin forever.
17:36:22  <isaacs>no
17:36:47  <isaacs>it was being used to determine whether or not to defer the nextTick with teh spinner and print a warning, or just run the next tick cycle right away
17:37:21  <trevnorris>yeah. the part i'm not understanding is what a spinner is.
17:37:24  <isaacs>the splice controller is nextTickIndex
17:37:29  <isaacs>it's the old-style nextTick
17:37:32  <isaacs>which should be reomved in 0.12
17:37:39  <isaacs>basically, you can think of it a bit like a setImmediate
17:37:49  <isaacs>like, actually go to the event loop and come back
17:38:14  * AvianFluquit (Disconnected by services)
17:38:17  * AvianFlu_changed nick to AvianFlu
17:38:28  * pooyaquit (Quit: pooya)
17:38:58  <isaacs>trevnorris: when using the spinner, nextTick is like a slightly faster setTimeout(fn, 0)
17:39:22  <isaacs>trevnorris: but when we just process the tick right away, it's like a while()
17:40:20  <isaacs>trevnorris: also, we need to "tock" objet, beause you need to grab a ref to the domain when the nextTick is *scheduled*, not when it's *run*
17:41:06  <trevnorris>isaacs: on the side, there's a stupid check in process.nextTick. an object is pushed into nextTickQueue, then we check if it has a length.
17:41:13  <trevnorris>since we just pushed something, it will always have a length
17:42:35  <isaacs>oh, yeah
17:42:39  <isaacs>that's odd
17:43:06  <isaacs>since it's going to be processing the ticks at the end of that makeCallback, though... i think it's also just unnecessary.
17:43:38  <isaacs>hahah
17:43:44  <isaacs>ok, so, not *entirely* unnecessary
17:43:51  * isaacsremoved that line, then wondering why the tests are running SOOO FAST!!
17:45:07  <isaacs>trevnorris: it should call _needTickCallback if the length == 0, *before* pushing
17:48:46  <trevnorris>isaacs: right now my goal is to have as much of the callback stack inlined as possible. unfortunately the try/finally will prevent _tickCallback from being inliend.
17:48:53  <trevnorris>but it can still get optimized.
17:49:03  <trevnorris>though the splice action will have to go
17:49:34  <trevnorris>that's why i'm trying to use multiple callstack arrays. chopping off one of those is super easy.
17:49:47  <isaacs>oh, actually, that stupid push/length check CAN go entirely
17:50:24  <isaacs>just needs to have us call _needTickCallback once when we start up
17:50:31  <isaacs>those first nextTick()s to run the main module
17:52:31  <isaacs>ok, i was wrong.
17:52:36  <isaacs>that breaks a bunch of stuff
17:53:18  <isaacs>trevnorris: this works, thouh: https://gist.github.com/4675142
17:56:41  <trevnorris>isaacs: cool. left a comment.
17:57:03  <isaacs>agreed
17:59:40  <isaacs>trevnorris: any difference here? https://gist.github.com/4675202
18:00:32  <isaacs>trevnorris: or better yet: https://gist.github.com/4675213
18:01:37  * pooyajoined
18:03:15  <trevnorris>one sec
18:10:47  * felixgequit (Read error: Connection reset by peer)
18:11:33  <MI6>joyent/libuv: Bert Belder v0.8 * 034ea31 : win: get rid of early ipv6 support detection No longer explictly check w (+7 more commits) - http://git.io/RaxtXw
18:14:27  * `3rdEdenjoined
18:15:36  <trevnorris>isaacs: freakin a. the line `var domain = obj.domain;` is causing all the bailouts.
18:15:57  <trevnorris>think it'd be possible to pass a 4th argument like `domain_exists`
18:16:09  <trevnorris>(don't know if that would even help, but worth a shot)
18:16:10  <isaacs>wait, what?
18:17:14  <trevnorris>isaacs: yeah. I removed all the domain code then started to add it back line by line. just the `var domain = obj.domain` line is causing all the DEOPTs
18:18:33  <ryah>hey guys - this is probably a stupid question - but compiling a 64bit node and noticed that during the v8 build it was building the ia32 stuff
18:18:41  <ryah>has it always done that?
18:18:47  <ryah>eg ../deps/v8/src/ia32/full-codegen-ia32.cc
18:19:03  <isaacs>trevnorris: https://gist.github.com/4675379
18:19:12  <isaacs>trevnorris: is that better?
18:19:20  <isaacs>ryah: yeah, i remember seeing that
18:19:25  <trevnorris>isaacs: it's because we're trying to access a property on the object that isn't set. can we force set it to false before it gets sent?
18:19:26  <trevnorris>i'll try that out
18:20:32  * TooTallNatejoined
18:22:33  <trevnorris>isaacs: sorry, doesn't help. v8 will try to inline small functions. so the function call is the same as if it were in the main body.
18:23:12  <isaacs>trevnorris: probably we need to just make it so that .domain is always set to *something*
18:23:21  <trevnorris>yeah. exactly.
18:24:34  * qmx|lunchchanged nick to qmx
18:24:40  * indexzeroquit (Quit: indexzero)
18:25:12  * indexzerojoined
18:25:39  <isaacs>trevnorris: https://gist.github.com/4675445
18:25:43  <isaacs>try that ^
18:27:37  * indexzeroquit (Client Quit)
18:35:01  <trevnorris>isaacs: still doing it. trying to figure out why.
18:35:23  <trevnorris>_makeCallback gets hot and optimizes, then suddenly deopts.
18:37:47  <trevnorris>isaacs: domains existed in v0.8, right?
18:38:29  <isaacs>trevnorris: yeah
18:38:42  <trevnorris>isaacs: ok. for some reason v0.8 isn't deopting
18:38:49  <isaacs>wild
18:39:03  <isaacs>is anything actually throwing and getting caught by a domain?
18:39:06  <isaacs>because that code path changed.
18:39:27  <isaacs>otherwise, i'd suspect that it's justa V8 diff
18:39:42  <trevnorris>i'm running the net/tcp_raw_c2s.js
18:39:49  <trevnorris>freak, yeah. you're probably right.
18:41:52  <trevnorris>isaacs: _makeCallback doesn't exist in v0.8. why was it added?
18:43:08  <trevnorris>whoa. that whole section isn't even close to v 0.8
18:45:06  * AvianFluquit (Remote host closed the connection)
18:46:27  <trevnorris>isaacs: i'm going to give this another 30 or so then move on. PR-4656 is updated. let me know if there's anything else you'd like to see for the initial pull
18:48:04  * txdvquit (Read error: Connection reset by peer)
18:48:13  * txdvjoined
18:59:17  * brsonjoined
19:00:33  <trevnorris>isaacs: why do you check `if (nextTickQueue.length)` in _tickCallback, and `if (nextTickQueue.length === 0)` in nextTick, when they both run the same function afterwards?
19:07:26  * lohkeyjoined
19:08:15  * EhevuTovjoined
19:22:57  <isaacs>trevnorris: it's possible to get to tickDone without the queue being flushed
19:23:04  <isaacs>trevnorris: then we have to kick the spinner
19:25:13  <trevnorris>isaacs: ok. it's all coming together. thanks for the patience.
19:29:25  <isaacs>np
19:29:43  * sblomjoined
19:35:55  * loladirojoined
19:53:58  <trevnorris>isaacs: so Spin puts node in an idle state and waits for a callback. then Tick runs the callback?
19:54:32  <isaacs>yeah, that sounds right
19:58:52  * AvianFlujoined
19:59:10  <bnoordhuis>trevnorris: more precisely, the idle handle the spinner starts stops libuv from blocking in epoll_wait/kevent/etc.
19:59:34  <bnoordhuis>i.e. it still polls but with a zero timeout
20:00:41  <trevnorris>bnoordhuis: ah, thanks.
20:06:42  <tjfontaine>bnoordhuis: speaking of timeouts, setImmediate, should shigeki rebase the setImmediate uv_check modification, or shoudl I submit a different PR with the js fixup (https://github.com/joyent/node/pull/3872)
20:07:38  <sblom>Commit protocol question for https://github.com/joyent/node/pull/4694 : once it gets reviewed, should I land it as one patch with a hat-tip in the comments to the two other contributors? Or should I land it as 3 patches, one for each of the contributors? Or should I land the whole series? (Recognizing, bnoordhuis, that I'll need to change the commit messages in most of these cases :))
20:08:57  <bnoordhuis>sblom: i'd land that as three patches, one per contributor
20:10:39  <piscisaureus_>assert.equal(net.isIP('0'), 0);
20:10:44  <piscisaureus_>^-- does this fail on unix too?
20:10:59  <bnoordhuis>tjfontaine: mind if i punt on the answer for a bit? it seems i have a toddler that needs cheering up
20:11:29  <tjfontaine>bnoordhuis: I don't mind one bit this was just a reminder before we get to .10 :)
20:12:22  <trevnorris>so _makeCallback is only called by MakeCallback in node.cc?
20:12:53  <tjfontaine>> assert.equal(net.isIP('0'), 0);
20:12:53  <tjfontaine>undefined
20:12:57  <MI6>joyent/node: Bert Belder v0.8 * 1a87776 : deps: upgrade libuv to 034ea31 - http://git.io/YMjxbg
20:13:25  <tjfontaine>on .8.16
20:13:30  <trevnorris>nm, that's in isaacs's comments. =P
20:16:03  <isaacs>tjfontaine: if yo uknow what to do, go ahead and submit it
20:16:13  <isaacs>tjfontaine: or encourage shigeki to do so, if you'd like.
20:16:22  <isaacs>0.10 got pushed back a few weeks, so there's a bit of time :)
20:17:01  <piscisaureus_>tjfontaine: weird. On windows that assert fails on the 0.8 branch
20:17:49  <tjfontaine>isaacs: well, the way forward is still slightly up in the air, worst case scenario I vote for the js fix just so people don't get the nasty surprise that after their first issue of setImmediate every subsequent call gets delayed by 1ms :)
20:17:58  <piscisaureus_>tjfontaine: also on 0.16 for me
20:19:06  <tjfontaine>hm
20:23:05  <tjfontaine>piscisaureus_: not that this is news to you, but I can't see any platform differences that would indicate why that would happen
20:26:39  <trevnorris>so callback are added to the tick queue. and looks like their run FIFO.
20:27:02  <trevnorris>(just chatting out loud. don't know why this tick queue thing is evading me)
20:27:08  <piscisaureus_>tjfontaine: no, neither do i
20:30:59  * EhevuTovquit (Quit: This computer has gone to sleep)
20:32:32  <piscisaureus_>tjfontaine: actually, on 0.8, isIP calls ares_inet_pton under the hood
20:32:35  <piscisaureus_>on windows
20:32:37  <piscisaureus_>so that could be it
20:32:53  <tjfontaine>hmm I thought it was calling uv_inet_pton
20:33:26  <tjfontaine>oh defines at the top
20:37:49  <trevnorris>isaacs: in nextTick, why would you start tick spinner then push a callback? wouldn't it be called immediately?
20:38:07  <isaacs>trevnorris: i'm really not sure.
20:38:11  <isaacs>sorry, on another thing atm
20:38:14  <trevnorris>np
20:38:22  <isaacs>i don't think you'll get more than 2% on any benchmark by optimizing that function
20:38:53  <trevnorris>isaacs: heh, at this point it's my developer pride. must... solve... it....
20:39:04  <isaacs>trevnorris: i hear ya. that's a healthy impulse :)
20:39:23  <isaacs>trevnorris: but you could probably pointit at the other more relevant losses.
20:41:32  <trevnorris>isaacs: not sure how to follow up on regression in tcp_raw tests. libuv land scares me. i'll see what can be done about streams2.
20:41:49  <isaacs>trevnorris: so, here's a thing:
20:41:52  <isaacs>trevnorris: Readable.pipe()
20:41:59  <isaacs>trevnorris: right now, it's doing too much shit.
20:42:04  <isaacs>trevnorris: like, closures and other bs.
20:42:12  <isaacs>trevnorris: just because that was the fastest and easiest way tow rite it
20:42:37  <isaacs>but, i'd like Readable.push(chunk) to detect that we're already flowing in a pipe(), and be a bit more efficient about where it puts the data.
20:42:49  <isaacs>also, pipeOpts.chunkSize is stupid. we shouldn't do that.
20:42:55  <isaacs>no one wants that.
20:44:12  <trevnorris>cool. can do something about that
20:46:00  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:50:52  * wolfeidaujoined
20:50:58  <trevnorris>isaacs: anything need to be done to pull 4656? keep needing to checkout that benchmark folder to run my tests on changes against master.
20:50:58  * wolfeidauquit (Read error: Connection reset by peer)
20:51:35  * wolfeidaujoined
20:51:37  <isaacs>oh, right.
20:51:42  <isaacs>trevnorris: can you add `make bench`?
20:52:19  <isaacs>trevnorris: like, is it possible to use that stuff to output a reasonable "headline view" of performance that we should be aware of?
20:52:19  <trevnorris>isaacs: what was the exact functionality you wanted?
20:52:48  <isaacs>trevnorris: I want to know about http, net-pipe (all flavors), url parsing, etc.
20:52:48  <trevnorris>will be, but the benchmarks are still a mess.
20:52:52  <isaacs>trevnorris: yeah
20:53:02  <isaacs>"all the benchmarks" really means "all the new benchmarks that are pretty and nice";
20:53:08  <tjfontaine>in some sort of programmable output format :)
20:53:21  <isaacs>name: <number>
20:53:32  <isaacs>where "name" is the bench name, and "<number>" is some number of operations per time
20:53:35  <isaacs>that'd be fine
20:53:44  <isaacs>doesn't have to be lined up or anything
20:54:02  <isaacs>bigger number = better
20:54:45  <isaacs>and they don't all have to be the same metric, obviously. some could be Gbits/sec or requests/sec or whatever. you can even omit the labelson the number
20:55:02  <isaacs>if we know that bigger=better, then we can track it with a graph
20:55:15  <trevnorris>isaacs: definitely, but will take me a few days. (just going through it in my head)
20:55:21  <isaacs>also, it ideally should not take 20 minutes to run :)
20:57:12  <trevnorris>yeah. know exactly how i'll do it. but it'll take me a while.
20:58:06  <trevnorris>will have to build in a time lapse tester, which will run the test several times and increment the number of times it runs. until the threshold is reached.
20:58:16  <trevnorris>then it will run the test and report the value.
20:58:38  <trevnorris>if that doesn't happen then a test that takes 5 mins on my machine could take 15 on someone elses.
20:59:49  <trevnorris>then it'll store the results in json format, which can be saved to a file.
21:00:11  <trevnorris>then the tester will see if the file exists and cross compare the results with a new build.
21:00:41  <trevnorris>(ok... going overboard)
21:00:44  <tjfontaine>I'm not sure how much the cross compare matters
21:00:59  <trevnorris>tjfontaine: just so you can see the % difference between two builds.
21:01:10  * wolfeidauquit (Remote host closed the connection)
21:01:22  <tjfontaine>I understand, I just wouldn't kill myself over it
21:01:33  <trevnorris>yeah. i'll scratch that one off.
21:01:44  * sgallaghquit (Remote host closed the connection)
21:01:57  <trevnorris>so the basics would be to just run each test and output the results on stdout?
21:02:12  <tjfontaine>print'ing out json results { benchName: results, ... } is probabyl convenient enough
21:03:34  <trevnorris>tjfontaine: some tests are single run. others like the net tests run over several iterations. just output the avg/min/max/stdev etc?
21:04:45  <tjfontaine>trevnorris: hmm, I dunno, or only the most relevant number
21:05:09  <trevnorris>what's "the most relevant"?
21:05:38  * TooTallNatejoined
21:06:26  <tjfontaine>trevnorris: I would guess that depends on the bench, I'm not afraid of getting too much data returned to me, but for the people who will just be reading it you don't want to overwhelm them with data
21:07:28  <trevnorris>tjfontaine: figured if you want a lot of data, you'll run the tests individually. figured `make test` would be a short summary.
21:07:40  <tjfontaine>yup
21:14:50  <isaacs>trevnorris: if it runs *longer* on some machines than others, then that'sok
21:15:14  <isaacs>trevnorris: you can only reliably compare on the same machine anyway
21:15:26  * bnoordhuisquit (Ping timeout: 245 seconds)
21:15:29  <isaacs>trevnorris: most relevant usually = mean
21:15:36  <isaacs>i mean, it's not ideal, but it's just a baseline
21:15:46  <isaacs>that's what i usually look at first.
21:18:47  * loladiroquit (Quit: loladiro)
21:20:44  * EhevuTovjoined
21:27:46  * loladirojoined
21:29:21  * hzquit
21:34:04  <isaacs>piscisaureus_: what are your thoughts on this? https://github.com/joyent/node/issues/1776
21:38:07  * AvianFluquit (Remote host closed the connection)
21:38:37  * EhevuTovquit (Quit: This computer has gone to sleep)
21:40:33  * jmar777quit (Remote host closed the connection)
21:41:06  * jmar777joined
21:45:54  * jmar777quit (Ping timeout: 276 seconds)
21:46:09  * c4miloquit (Remote host closed the connection)
21:46:36  * c4milojoined
21:47:52  * c4miloquit (Read error: No route to host)
21:48:09  * c4milojoined
21:50:57  <trevnorris>isaacs: the net tests wont be bad. but what about the buffer tests. there are several variations for every Buffer method. should still output all those?
21:54:16  * AvianFlujoined
21:55:26  * rendarquit
22:02:20  * mralephjoined
22:11:13  * `3rdEdenquit (Remote host closed the connection)
22:20:17  <trevnorris>isaacs: done. you can now run `make bench` and it will output a simple table with results.
22:36:23  <sblom>Is it common for conversations about the holocaust to break out over on #node.js?
22:36:28  <sblom>:)
22:36:31  * paddybyersquit (Ping timeout: 244 seconds)
22:37:22  <tjfontaine>sblom: godwins law
22:37:26  <tjfontaine>or extension there of
22:37:43  <sblom>yeah--I suppose so
22:37:44  <isaacs>sblom: occasionally, yes.
22:37:51  <isaacs>sblom: anything we should be worried about?
22:37:58  <sblom>isaacs: don't think so
22:38:00  <isaacs>kewl
22:38:08  <isaacs>nazi propaganda is definitely not appropriate.
22:38:20  <isaacs>but academic discussions of histoery = perfectly kosher
22:38:48  <sblom>I'd say this is the latter. Just in a context I wasn't expecting. :)
22:39:10  <sblom>The tubes are a wondrous thing.
22:39:22  * paddybyersjoined
22:39:40  * kuebkjoined
22:40:17  * kuebkquit (Client Quit)
22:41:32  <trevnorris>isaacs: done with make bench. should I remove make bench-idle?
22:42:21  <trevnorris>(anyone else find the last example here unreadable: http://bit.ly/VrOyuv)
22:43:27  <sblom>trevnorris: yes--untterly incomprehensionable.
22:43:42  <sblom>It looks a little like lisp in the middle parts.
22:43:53  <sblom>(in that my eyes are going crossed trying to match up nested parens)
22:44:21  <trevnorris>same problem i'm having.
22:44:26  <trevnorris>way too much going on in a single line.
22:46:16  <tjfontaine>comprehensions always lead to people trying out for the oneliner olympics
22:46:27  <isaacs>trevnorris, sblom: first person to land an array comprehension in node gets a 50L drum of sewage delivered to their house.
22:46:56  <tjfontaine>I will personally help fill the drum up
22:47:20  <trevnorris>debugging that must be a bitch. when it prints the bad line, you're like "oh, it's my entire function"
22:48:06  <sblom>isaacs: I almost want to do it just to see your shitt^H^Hpping invoice.
22:48:14  <tjfontaine>groan
22:48:14  <isaacs>hahah
22:48:26  <isaacs>i'm just kidding.
22:48:36  <isaacs>we'll probably just revert it and make a >_< face in the commit message
22:48:40  <sblom>Yeah.
22:49:08  <trevnorris>can't imagine what will happen w/ any PR's containing that crap.
22:52:38  * loladiroquit (Quit: loladiro)
22:52:55  * wolfeidaujoined
22:53:51  <isaacs>oh, it's not hard to imagine. we'll reject them.
22:53:55  <isaacs>we reject a lot of pull requests.
22:53:55  <isaacs>it's o
22:53:57  <isaacs>*ok
22:54:53  <trevnorris>heh, yeah. just wonder how much heckling they'll get from the community.
22:54:57  <tjfontaine>comps make a ton of sense for people doing oneoff repl work
22:55:10  <tjfontaine>or to help illustrate things for others
22:55:48  <tjfontaine>or at least that's where I see their use cases being the most helpful
22:58:37  <trevnorris>tjfontaine: i'll take your word on that. just don't like to spend most my time figuring out what the syntax means.
22:58:40  * jmar777joined
22:59:20  <tjfontaine>trevnorris: I'm used to seeing it because of people loving to [ab]use them in python
22:59:48  <trevnorris>heh. and that's the reason why I could never get into python.
23:00:10  * wolfeidauquit (Remote host closed the connection)
23:01:37  <trevnorris>tjfontaine: and I can see what you're saying. if I was making a quick script, sure.
23:01:38  <trevnorris>but as soon as it needs to be maintained by a community, just has to go.
23:02:17  <tjfontaine>trevnorris: have you seen dictcomps?
23:02:38  <trevnorris>nope
23:03:43  <tjfontaine>as bad as list/array comps start to look, complex dict comps will make your eyes bleed http://www.python.org/dev/peps/pep-0274/
23:05:10  <trevnorris>wtf... can't stop staring
23:06:40  <trevnorris>i've never written a programming language before, but have to imagine writing the parser for that must have been painful.
23:23:34  <trevnorris>what do you guys think about exposing Buffer::kMaxLength as a read only property of Buffer?
23:29:35  <isaacs>trevnorris: We could export it as a "writing doesn't do anything" property :)
23:32:12  <trevnorris>ok. was just thinking it might be good to check value ranges (e.g. highWaterMark) against it (since stuff like ~~0xffffffff === -1)
23:32:31  <trevnorris>also, doesn't look like we're checking for negative values in ReadableStream.
23:36:01  * loladirojoined
23:38:20  * loladiroquit (Client Quit)
23:39:09  <isaacs>sure
23:40:12  * brsonquit (Remote host closed the connection)
23:41:52  <trevnorris>isaacs: have any feedback on my unified arg checking doc: https://gist.github.com/4670377
23:42:17  <trevnorris>there's a lot of different ways args of specific types are checked, and think it'd be nice to have a standard.
23:46:42  * brsonjoined
23:49:29  * EhevuTovjoined