00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:14  * mikealquit (Quit: Leaving.)
00:00:16  <trevnorris>um... yeah, ok. that's a fun one.
00:01:45  <trevnorris>and wth is the new "zen mode" github has?
00:04:16  <tjfontaine>trevnorris: https://github.com/blog/1379-zen-writing-mode
00:07:10  <trevnorris>tjfontaine: cool, thanks for googling that for me ;-)
00:07:11  <trevnorris>now if they'd only listen to torvalds and enforce good/better commit msg practices with edits done in the browser.
00:09:13  <tjfontaine>trevnorris: heh, i didn't actually google it, I remember seeing it in my google reader earlier today
00:10:12  <trevnorris>ah, duh. I need to go clean mine out. get like ~100/day.
00:10:36  <tjfontaine>I have severe inbox0 syndrome
00:11:06  <tjfontaine>and I get more like 50~75/hr
00:15:26  * TheJHquit (Ping timeout: 245 seconds)
00:17:18  <isaacs>i used to use google reader
00:17:30  <isaacs>then i realized it was actually more effective to hire someone to just throw newspapers at my face.
00:17:33  <loladiro>piscisaureus_: ping
00:18:01  <isaacs>and he and i didn't get along, so i fired him
00:18:16  <tjfontaine>hah
00:29:07  <trevnorris>after that stupid ia32 snan clang thing been a little paranoid and started testing against clang/gcc ia32/x64.
00:30:36  <tjfontaine>trevnorris: I meant to ask is your clang stack with libc++?
00:30:49  * mikealjoined
00:30:56  <trevnorris>tjfontaine: um... how would I figure that out?
00:31:04  <trevnorris>i'm a total newb to the whole cc programming thing
00:31:28  <tjfontaine>well, you would have done it as part of your setup, so if you don't remember it you weren't
00:32:08  <tjfontaine>there are 2 c++ stdlibs out there, libstdc++ (the gnu/gcc version commonly installed for everyone) and then libc++ (the one the llvm/clang crowd are creating)
00:32:45  <trevnorris>does it matter that I built it? that's probably what you meant by "setup"
00:33:18  <tjfontaine>ya, I'm saying if you didn't check it out as part of your building of llvm/clang then you are just using the libstdc++ version
00:33:24  * mikeal1joined
00:34:28  * mikealquit (Read error: Connection reset by peer)
00:34:44  <tjfontaine>I'm slightly curious to know if something similar happens when used with libc++ or if it's purely a matter of clang ia32 libstdc++ issue
00:40:04  * bradleymeckjoined
00:40:34  <trevnorris>tjfontaine: building libcxx now. see how this goes.
00:41:09  <tjfontaine>trevnorris: heh, I didn't mean to send you further down the rabbit hole :)
00:41:38  <trevnorris>no worries. help me learn.
00:41:53  <trevnorris>javascript has become to warm and cuddly. need a harsh reality check.
00:42:19  <tjfontaine>well diving into compiler toolchains is certainly one way to wanna run to safety
00:42:56  <trevnorris>yeah. i have a tendency to jump in the deep end.
00:44:03  * loladiroquit (Quit: loladiro)
00:46:05  <trevnorris>tjfontaine: took me ~2 hours to follow code and get the full exec chain for `->NumberValue()`: http://git.io/cfZwwg
00:46:16  <trevnorris>but now I know why that stupid call is so expensive.
00:46:29  <tjfontaine>heh, you're a better man than I
00:47:17  <tjfontaine>on the plus side, you now know a lot about v8 internals, which makes you valuable :P
00:48:34  <trevnorris>thanks. though when indutny or piscisaureus_ get talking feel like curling up in the fetal position.
00:48:42  * perezdjoined
00:49:22  <tjfontaine>heh, the more you're here and watching the more you'll learn merely by osmosis, it only gets better I promise :)
00:49:59  <MI6>joyent/node: Andy Burke master * 595b597 : Add bytesWritten to tls.CryptoStream This adds a proxy for bytesWritten - http://git.io/Xwg9BQ
00:52:37  <trevnorris>isaacs: fwiw, been testing the benchmarks i'm changing and there's at least 1 that's regressed since the initial streams2 merge.
00:52:51  <isaacs>trevnorris: awesome
00:52:53  <isaacs>which one?
00:52:58  <isaacs>any idea what the regression is?
00:53:01  <isaacs>er, where it is
00:53:09  * mikeal1quit (Quit: Leaving.)
00:53:47  <trevnorris>net-pipe.js shows ~5% less data transfer on v0.9.8
00:54:19  <trevnorris>still figuring out the benchmark sets that will narrow it down.
00:55:02  <trevnorris>since those are hard to make micro tests for (like buffer methods) need to write a few that test slightly different things. then find the common parts when they regress.
00:57:24  * bnoordhuisjoined
00:57:36  * c4miloquit (Remote host closed the connection)
00:58:00  <trevnorris>isaacs: and not to make your day suck, but there's a ~40% regression between v0.8.18 and master for net-pipe.js
01:00:32  <isaacs>trevnorris: yeah, i'm aware of that
01:00:38  <isaacs>trevnorris: that's the same thing that's eating http_simple
01:00:50  <isaacs>it's possible some recent stuff in the stream api changes affected it.
01:01:19  <isaacs>trevnorris: we've had a bunch of libuv/binding/v8 changes since the initial streams2 merge
01:01:50  <trevnorris>isaacs: have there been any api changes?
01:01:58  <isaacs>trevnorris: not at the binding layer
01:02:09  <isaacs>trevnorris: at least, not in the binding layer since streams2 landed
01:02:20  <isaacs>there've been some since 0.8
01:02:56  <trevnorris>isaacs: ok. also wanted to create builds with different versions of v8/libuv/etc. and see if there are any changes there.
01:03:08  <isaacs>trevnorris: cool
01:04:16  <trevnorris>glad I can turn out a full build in 40 sec. makes it easy to test.
01:06:55  <trevnorris>isaacs: yeah. what I'm not getting is: 77ed12f - 5.9 Gb/s; cd51fa8 - 5.2 Gb/s; master - 4.7 Gb/s
01:07:17  <trevnorris>so there's almost equally large % regression since the streams2 merge.
01:10:13  * mikealjoined
01:15:03  <isaacs>trevnorris: interesting
01:15:21  <isaacs>trevnorris: what if you branch from master, and then do `git checkout 77ed12f -- lib`
01:15:43  <isaacs>trevnorris: ie, use the JS from 77ed12f, but the bindings etc from master
01:15:54  <isaacs>trevnorris: (that's what i've been calling my "streams1" branch)
01:16:04  <trevnorris>isaacs: tried. there's an error about node.cc trying to use an unknown variable. so I'm stepping back my release to identify where it was introduced.
01:16:19  <trevnorris>oops. nm. that's something else.
01:17:00  <MI6>joyent/node: Sugendran Ganess master * 83154aa : doc: Connecting debugger to existing node process - http://git.io/lQ3bVA
01:17:04  <trevnorris>isaacs: ok some `uv_run` was introduced to node.cc between v0.9.6 and v0.9.7 which causes compilation error. will work around that.
01:17:38  <isaacs>trevnorris: wait... why does that affect what's in lib?
01:17:40  * isaacsupdating streams1
01:17:56  <trevnorris>isaacs: it doesn't. i was checking out different versions of deps/uv
01:18:03  <isaacs>oh, ok
01:18:10  * bradleymeckquit (Quit: bradleymeck)
01:19:41  <trevnorris>isaacs: from just swapping libuv, saw a regression between v0.9.7 and v0.9.8
01:20:01  <trevnorris>small, but it's there. (e.g. 5.1 Gb/s vs 4.8 Gb/s)
01:21:04  <MI6>joyent/node: isaacs created branch streams1 - http://git.io/QMTBsw
01:21:05  <isaacs>trevnorris: ^
01:21:31  <isaacs>trevnorris: about to benchmark master now
01:22:25  <trevnorris>yeah. that's giving me about 85% of the regression we're seeing.
01:22:48  <trevnorris>ok. so i'll focus on testing the js parts of streams. that narrows it down a lot.
01:23:32  <trevnorris>out. be on later
01:23:33  * trevnorrisquit (Quit: Leaving)
01:25:49  <MI6>joyent/node: isaacs v0.8 * 72dd3b4 : benchmark: Port http.sh from master - http://git.io/fpYUiw
01:29:45  * abraxasjoined
01:30:43  <isaacs>ircretary: tell trevnorris https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=1
01:30:44  <ircretary>isaacs: I'll be sure to tell trevnorris
01:30:53  * loladirojoined
01:33:36  * c4milojoined
01:35:32  * perezdquit (Quit: perezd)
01:37:34  * mikealquit (Quit: Leaving.)
01:49:27  * dapquit (Quit: Leaving.)
01:49:54  * wavdedjoined
01:50:35  * bnoordhuisquit (Ping timeout: 252 seconds)
01:52:06  <wavded>could someone explain a little more why it doesn't make sense to use epoll/kqueue/etc for reading/writing files but rather using a thread pool?
01:55:03  <wavded>at one point i thought it was because they are all blocking calls and no async way to do it, is that correct? registering a file descriptor with epoll doesn't provide any events to read/write its contents?
01:56:24  <tjfontaine>actually libuv uses both, a threadpool and epoll/etc
01:59:00  <wavded>right, epoll for watching files for changes, but threadpool for everything else (or stat() watching) is what I understand, but epoll/etc can't do other file operations, like reading/writing?
02:00:03  * sblomquit
02:01:59  <wavded>another way to ask my question is: what about epoll/kqueue/etc makes it a bad model for most file system operations?
02:02:33  * c4miloquit (Remote host closed the connection)
02:02:55  * c4milojoined
02:03:12  <wavded>my motivation is Bert's libuv talk where he mentioned how epoll/kqueue/etc didn't make sense for reading/writing etc of files, he didn't really expand on that in the video so hence my question/curiousity
02:03:18  * c4miloquit (Remote host closed the connection)
02:03:44  * c4milojoined
02:06:11  <CoverSlide>because bert said so
02:06:38  <wavded>CoverSlide: ;)
02:06:39  * c4miloquit (Read error: No route to host)
02:06:54  * c4milojoined
02:07:47  * mikealjoined
02:13:21  * ericktquit (Quit: erickt)
02:15:58  * AvianFluquit (Remote host closed the connection)
02:18:24  <tjfontaine>wavded: I would imagine because you're receiving those notifications in the main loop, which makes it hard to parallelize requests, it's probably not much of a difference on small read/writes on a few files, but as you start streaming more it probably doesn't scale well
02:19:42  * lohkey_joined
02:23:28  * lohkeyquit (Ping timeout: 252 seconds)
02:24:18  * lohkey_quit (Ping timeout: 276 seconds)
02:33:51  * rvaggquit (Quit: ta ta)
02:34:15  * wolfeidauquit (Remote host closed the connection)
02:34:36  <tjfontaine>TooTallNate: btw, you can close that ffi issue with stanley
02:34:52  <TooTallNate>ya?
02:35:06  * wolfeidaujoined
02:35:27  <tjfontaine>pretty sure anyway, I've got him mostly sorted, nothing there will end up being an ffi problem in my estimation
02:35:48  <TooTallNate>what did you end up doing?
02:35:54  <TooTallNate>was he on #node.js?
02:36:29  <tjfontaine>he was, but spent most of the time in privmsg with me debugging
02:37:09  <tjfontaine>he's done working on it for tonight, but mostly I'm chalking this up to a misbheaving library
02:37:56  <tjfontaine>he's going to open without RTLD_NOW for now, and hope he doesn't hit a method that tries to use an unresolved symbol :)
02:38:26  <TooTallNate>sounds like the best bet
02:39:36  * wolfeidauquit (Ping timeout: 245 seconds)
02:47:15  * ericktjoined
02:47:37  * rvaggjoined
02:52:27  * c4miloquit (Remote host closed the connection)
03:06:51  * stagasquit (Ping timeout: 276 seconds)
03:13:08  * jmar777quit (Remote host closed the connection)
03:13:17  * loladiroquit (Quit: loladiro)
03:13:43  * jmar777joined
03:18:07  * wavdedquit (Quit: WeeChat 0.4.0)
03:18:12  * jmar777quit (Ping timeout: 248 seconds)
03:27:07  * piscisaureus_quit (Ping timeout: 246 seconds)
03:37:30  * piscisaureus_joined
03:47:43  * loladirojoined
03:51:48  * brsonquit (Ping timeout: 248 seconds)
03:53:35  * lohkeyjoined
04:06:30  * lohkeyquit (Quit: lohkey)
04:13:57  * mikealquit (Quit: Leaving.)
04:15:39  * sblomjoined
04:16:40  * ericktquit (Read error: Connection reset by peer)
04:17:21  * ericktjoined
04:24:10  * c4milojoined
04:39:14  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:40:18  * c4miloquit (Remote host closed the connection)
04:40:55  * c4milojoined
04:44:13  * mikealjoined
04:45:22  * sblomquit (Ping timeout: 252 seconds)
04:45:42  * c4miloquit (Ping timeout: 264 seconds)
04:46:18  * piscisaureus_quit (Ping timeout: 276 seconds)
04:50:07  * c4milojoined
04:53:03  * mikealquit (Ping timeout: 252 seconds)
04:53:25  * mikealjoined
04:53:47  * mikealquit (Client Quit)
05:00:05  * c4miloquit (Remote host closed the connection)
05:07:11  * TheJHjoined
05:12:19  * brsonjoined
05:19:23  * TheJHquit (Ping timeout: 255 seconds)
05:23:13  * wolfeidaujoined
05:23:57  * mikealjoined
05:40:38  * wolfeidauquit (Remote host closed the connection)
05:44:49  * brsonquit (Ping timeout: 240 seconds)
05:45:04  * brsonjoined
05:45:57  * ericktquit (Quit: erickt)
06:13:30  * bradleymeckjoined
06:15:39  * lohkeyjoined
06:23:46  * wolfeidaujoined
06:28:30  * c4milojoined
06:33:06  * c4miloquit (Ping timeout: 264 seconds)
06:40:25  * mikealquit (Quit: Leaving.)
06:58:09  * loladiroquit (Quit: loladiro)
07:03:50  * mikealjoined
07:19:07  * loladirojoined
07:25:13  * felixgejoined
07:26:13  * lohkeyquit (Quit: lohkey)
07:26:51  * rendarjoined
07:28:46  * brsonquit (Ping timeout: 245 seconds)
07:30:06  * `3rdEdenjoined
07:30:06  * felixgequit (Ping timeout: 276 seconds)
07:30:57  * brsonjoined
07:33:20  * paddybyersjoined
07:47:26  * paddybyers_joined
07:49:44  * paddybyersquit (Ping timeout: 252 seconds)
07:49:44  * paddybyers_changed nick to paddybyers
08:04:03  * brsonquit (Ping timeout: 256 seconds)
08:26:36  * bradleymeck_joined
08:28:54  * bradleymeckquit (Ping timeout: 264 seconds)
08:28:54  * bradleymeck_changed nick to bradleymeck
08:36:52  <indutny>morning
08:36:54  <indutny>evening
08:36:55  <indutny>:)
08:45:00  <rendar>hi
08:45:02  <rendar>:)
09:08:22  * bradleymeckquit (Quit: bradleymeck)
09:22:27  * felixgejoined
09:58:48  * philips_quit (Excess Flood)
10:17:52  * philips_joined
10:19:09  * bnoordhuisjoined
10:32:30  * rumpquit (Quit: rump)
10:35:05  * stagasjoined
10:35:31  * loladiroquit (Quit: loladiro)
10:44:24  * abraxasquit (Remote host closed the connection)
10:49:37  * loladirojoined
10:50:02  * stagasquit (Ping timeout: 255 seconds)
10:54:31  * stagasjoined
10:55:50  * loladiroquit (Quit: loladiro)
11:00:29  <bnoordhuis>indutny: any luck with the performance regressions?
11:02:16  <indutny>hello
11:02:18  <indutny>no, not really
11:02:20  <indutny>bnoordhuis: what about you? :)
11:02:26  <indutny>still busy with your enterprise stuff
11:02:27  <indutny>?
11:02:28  <indutny>;)
11:02:29  <bnoordhuis>me neither
11:02:30  <bnoordhuis>and yes
11:02:37  <bnoordhuis>with taxes too
11:02:52  <indutny>oooh
11:02:54  <indutny>taxes
11:02:57  <indutny>don't remind me about that
11:03:05  <indutny>its a BIG PITA
11:03:15  <indutny>bnoordhuis: I'll look into it today
11:03:25  <bnoordhuis>yeah, me too (hopefully)
11:03:41  <bnoordhuis>i have half a mind to release with a threadpool of size=1
11:03:52  <bnoordhuis>that seems to give the best numbers on our benchmarks :)
11:04:52  <bnoordhuis>on a tangential note, i have high hopes for native aio with 3.7+ kernels
11:04:55  <bnoordhuis>but that's a v0.12 thing
11:05:28  <rendar>bnoordhuis: for posix aio_* apis?
11:05:44  <bnoordhuis>rendar: no, not posix. native kernel api
11:06:12  <rendar>bnoordhuis: i see, but what about those aio* apis? some people say that they don't work properly on linux
11:06:31  <bnoordhuis>you mean the libaio stuff? that's just another threadpool :/
11:06:46  <bnoordhuis>if you mean the native api, it used to be effectively broken
11:06:53  <bnoordhuis>but it's been greatly improved in 3.7 and 3.8
11:07:06  <rendar>no i mean those aio* posix apis that should do real async read/write..
11:07:33  <bnoordhuis>ah, right. glibc implements it as a threadpool
11:07:34  <rendar>oh, why they're so broken? and what about other posix systems?
11:07:46  <indutny>bnoordhuis: interesting
11:08:05  <bnoordhuis>rendar: i posted an overview to the ML a while ago, let me find it
11:08:29  <indutny>bnoordhuis: so linux is exposing some kernel level apis for asynchronous io?
11:08:38  <rendar>indutny: it seems so
11:08:43  <bnoordhuis>http://groups.google.com/group/nodejs/browse_thread/thread/b3a710e2eaff9373/d649a4955e25544f <- there
11:08:50  <rendar>indutny: and let me say: finally :)
11:08:57  <rendar>bnoordhuis: thanks man
11:09:13  <indutny>bnoordhuis: and will it outperform epoll?
11:09:20  <indutny>I mean, have you benchmarked it?
11:09:33  <rendar>hmm, i think they will be used with epoll toghether
11:09:36  <bnoordhuis>indutny: epoll? completely unrelated :)
11:09:43  <indutny>nono
11:09:48  <indutny>I mean epoll+sync io vs aio
11:09:50  <indutny>who wins
11:09:58  <bnoordhuis>err
11:10:03  <bnoordhuis>you mean sync io in a threadpool?
11:10:18  <indutny>yes
11:10:19  <rendar>shouldn't it be epoll+sync/threadpool vs epoll+aio ?
11:10:31  <indutny>guys
11:10:33  <bnoordhuis>indutny: we won't know until we benchmark it
11:10:39  <indutny>that's what I'm asking
11:10:43  <indutny>and you've answered
11:10:44  <indutny>:)
11:10:48  <rendar>:-)
11:12:20  <MI6>joyent/node: Trevor Norris master * cbe3941 : buffer: error and misc cleanup Changed types of errors thrown to be more (+2 more commits) - http://git.io/0-Cn3w
11:21:06  * rumpjoined
11:24:12  * rumpquit (Client Quit)
11:24:21  <rendar>bnoordhuis: i read that discussion, and it seems that macosx is the worst OS for aio
11:24:29  <bnoordhuis>it is
11:24:44  <bnoordhuis>but then os x is the worst for just about everything
11:25:22  <rendar>there are also other problems?
11:26:01  <bnoordhuis>many :)
11:26:09  <rendar>:)
11:26:28  <bnoordhuis>from a system programming perspective, os x / darwin / xnu is a joke
11:26:30  <rendar>bnoordhuis: well, solaris seems the more solid and reliable, but as you said nobody uses it
11:27:09  <rendar>or btw very few people, compared to linux/win/etc
11:27:15  <bnoordhuis>yes, same for freebsd
11:27:22  <rendar>yep
11:28:12  <bnoordhuis>wavded_: re epoll + file fds, it doesn't work because file fds are always reported as readable/writable even when they're not
11:28:18  <rendar>but a cloud company that want to provide high i/o and reliable app, could distribute node.js in freebsd/solaris for the maximum exploiting of the aio and other advanced server stuff, as joyent is doing with SmartOS, i guess
11:28:49  <bnoordhuis>rendar: yes, but joyent doesn't really pour many resources in node
11:29:02  <rendar>i see, but why?
11:29:14  <bnoordhuis>why they don't invest many resources?
11:29:15  <rendar>i guess node is a very importand slice of their stack, isn't?
11:29:22  <rendar>yes
11:29:49  <bnoordhuis>i don't know, really
11:30:00  <bnoordhuis>i can speculate though :)
11:30:22  <rendar>node is so popular, and gains more and more new users
11:30:31  <bnoordhuis>one reason probably is that the former cio had a big interest in node
11:30:41  <rendar>hmm
11:30:51  <bnoordhuis>but then he left for mozilla and node at joyent languished
11:31:02  <rendar>i see
11:31:40  <bnoordhuis>joyent still gets the credit even if most of the work is done by other companies
11:31:40  <rendar>bnoordhuis: as a paradox, seems that microsoft is more interested in node than joyent actually, lol
11:31:43  <bnoordhuis>so they played that well
11:31:46  <bnoordhuis>yes, true
11:36:27  * stagasquit (Ping timeout: 276 seconds)
11:46:54  * c4milojoined
11:51:42  * c4miloquit (Ping timeout: 264 seconds)
12:11:54  <indutny>bnoordhuis: apparently my mbp hangs when I run benchmark/http
12:14:35  <indutny>I've no other choice but to run node in VM
12:21:15  <bnoordhuis>hah what?
12:21:20  <bnoordhuis>hangs as in locks up?
12:21:27  <indutny>yes
12:21:35  <indutny>completely non-reposible
12:21:40  <indutny>i tried it twice
12:24:59  <bnoordhuis>time for a real OS, fedor
12:25:25  <indutny>bnoordhuis: heh
12:25:31  <indutny>QNX?
12:25:49  <bnoordhuis>i was thinking of VMS or CP/M
12:26:19  <bnoordhuis>i did some contract work for the dutch tax office a few years ago
12:26:26  <bnoordhuis>and they were still using VMS in places
12:26:33  <indutny>my condolences
12:26:44  <bnoordhuis>well, it was interesting if rather archaic
12:31:32  <indutny>I believe you
12:37:07  * c4milojoined
12:37:07  <indutny>bnoordhuis: ready for some reviewieng?
12:37:12  <indutny>reviewing*
12:37:16  <indutny>bnoordhuis: https://github.com/joyent/node/pull/4663
12:37:19  <bnoordhuis>i'm already doing that
12:37:39  <bnoordhuis>get in the queue :)
12:42:06  * c4miloquit (Ping timeout: 264 seconds)
13:10:29  * qmx|awaychanged nick to qmx
13:15:51  <bnoordhuis>tmp/struct.cc:12:18: error: expected a constant of type ‘void (*)(int)’, got ‘void (*)(int)’ <- compilers...
13:16:30  <indutny>yeah
13:16:35  <indutny>I guess you solved it?
13:16:41  <indutny>if no - publish some code as gist
13:17:02  <bnoordhuis>nah, it's not that important
13:17:10  <bnoordhuis>it's just a very dumb error message
13:17:21  <indutny>it's error anyway
13:27:45  <txdv>http://www.clahub.com/ - did you see this?
13:57:55  * c4milojoined
14:01:23  * jmar777joined
14:22:04  <txdv>who is on windows? :D
14:25:57  * c4milo_joined
14:30:42  * c4milo_quit (Ping timeout: 264 seconds)
14:52:28  * c4miloquit (Remote host closed the connection)
15:02:44  <indutny>bert
15:02:52  <indutny>and sblom
15:10:20  * AvianFlujoined
15:14:16  * piscisaureus_joined
15:18:11  * bradleymeckjoined
15:26:37  * c4milojoined
15:29:00  * hzjoined
15:29:16  <txdv>every 5 commits a new release
15:29:21  <txdv>when will 0.10 come?
15:31:35  <indutny>when we'll stop with doing 0.9.x releases
15:33:59  <txdv>/with//
15:35:50  <txdv>indutny: do you like reviewing code/
15:37:03  <indutny>sometimes
15:46:18  * felixgequit (Quit: felixge)
15:48:06  * paddybyersquit (Ping timeout: 264 seconds)
15:55:50  <txdv>starting windows is such a pain
15:55:53  <txdv>maaaan
16:01:05  * qmxchanged nick to qmx|brb
16:01:29  <isaacs>bnoordhuis: the main reason why joyent doesn't spend more resources on Node is that joyent doesn't spend much resources.
16:01:48  <isaacs>bnoordhuis: and it's split between SmartOS, operations, support, etc
16:02:13  <isaacs>we are hiring tjfontaine, and i hope to get another one or two hires later this year maybe.
16:03:05  <isaacs>bnoordhuis: but mostly, node is like another node user. they find bugs and send patches, but mostly it just works for them, and they're happy with it.
16:03:13  <isaacs>er, *joyent is like another node user
16:03:58  <isaacs>rendar: also, "solaris" is effectively dead. there is only illumos now.
16:05:37  <rendar>isaacs: i see
16:05:53  <rendar>isaacs: so for new softwares, supporting solaris is unuseful?
16:06:07  <indutny>well
16:06:14  <indutny>illumos is essentially the same thing
16:06:17  <indutny>just with different name
16:06:38  <rendar>i see, but is it still owned by oracle?
16:06:56  <indutny>no
16:07:02  <indutny>god thanks, no
16:07:06  <rendar>lol
16:07:14  <indutny>they've forked sunos
16:07:18  <rendar>i wonder why oracle bought Sun?
16:07:18  <indutny>before it has died
16:07:22  <isaacs>rendar: solaris is owned by oracle
16:07:23  <rendar>i see
16:07:31  <indutny>rendar: Java?
16:07:34  <isaacs>rendar: and is no longer open in any sense of the word
16:07:37  <indutny>and all rights
16:07:37  <rendar>oh right
16:07:47  <isaacs>rendar: oracle bought sun so that they could sue google for using Java
16:07:54  <indutny>and all other people
16:07:56  <isaacs>yes
16:08:01  <indutny>not that google is so good people
16:08:02  <rendar>yeah exactly
16:08:07  <indutny>but anyway
16:08:14  <isaacs>basically, oracle is the bottom feeder that prunes near-death technologies
16:08:31  <isaacs>they saw a weakness in the java community, and they're out to destroy it, sucking any value out of it in the process that they can.
16:08:39  <isaacs>it's a service, really. part of evolution.
16:08:52  <isaacs>we should all be thankful of Oracle, and very very afraid.
16:09:50  <rendar>nice analysis
16:09:51  <rendar>:)
16:10:00  * TheJHjoined
16:14:55  <rendar>i was thinking to a thing: what about libuv executes callback in the external thread context, and not in the "main thread" context? would this make node.js multithreaded?
16:16:41  <indutny>errr???
16:18:25  <rendar>lol, well i mean: when libuv executes stuff in the async way, often the background threads completes the i/o and tells to the main thread to call the callback completion (e.g. on_read), what about if libuv doesn't tell to the main thread to call on_read, but it call itself from the background thread that effecitvely executed read(); ?
16:22:17  * qmx|brbchanged nick to qmx
16:22:35  * felixgejoined
16:22:36  * felixgequit (Changing host)
16:22:36  * felixgejoined
16:24:29  <isaacs>rendar: then you'd have issues with the fact that node itself (the js bits) is not thread-safe
16:28:53  * `3rdEdenchanged nick to `3E|FOODING
16:29:18  <indutny>rendar: also messing with threads is slow
16:34:42  * stephankquit (Quit: *Poof!*)
16:36:14  <rendar>indutny: i see
16:36:32  <rendar>indutny: you mean having 1 process with N threads would be far slower than N process with 1 thread
16:37:01  <indutny>not exactly this
16:37:22  <indutny>I mean that running callbacks in different threads implies some sort of synchronization
16:37:26  <indutny>for this thing to work
16:37:31  <indutny>at price for this isn't cheap
16:38:01  <rendar>hmm yeah, right
16:45:33  * stephankjoined
16:46:57  * TheJHquit (Ping timeout: 252 seconds)
16:48:13  <txdv>THANK GOD FOR libuv.so
16:48:21  <txdv>or better the one who did it
16:56:15  * c4miloquit (Remote host closed the connection)
17:05:06  * sblomjoined
17:05:48  * sblomquit (Client Quit)
17:11:40  * bradleymeckquit (Quit: bradleymeck)
17:14:46  * dapjoined
17:17:09  * qmxchanged nick to qmx|lunch
17:29:24  * trevnorrisjoined
17:37:13  * `3E|FOODINGquit (Remote host closed the connection)
17:48:20  <trevnorris>bnoordhuis: so you think it would be possible to do something like tell v8's garbage collector to watch over a segment of external memory?
17:48:26  <trevnorris>then I think a larger pool could be allocated. have benchmarks that show creating a massive pool makes small buffer allocations ~3x's faster.
17:56:10  * c4milojoined
18:02:30  * rumpjoined
18:05:15  <trevnorris>isaacs: that's good information. thank.
18:06:07  * `3rdEdenjoined
18:11:20  * qmx|lunchchanged nick to qmx
18:19:38  * brsonjoined
18:21:20  * TooTallNatejoined
18:37:55  * mikealquit (Quit: Leaving.)
18:39:26  <TooTallNate>isaacs: i want to backport https://github.com/joyent/node/commit/16bbecc to v0.8 - any objections?
18:42:20  <isaacs>TooTallNate: yeah, that looks fine
18:42:24  <isaacs>no new api, just a bugfix
18:42:28  <TooTallNate>yup
18:43:23  <MI6>joyent/node: Trevor Norris v0.8 * 65249cc : buffer: slow buffer copy compatibility fix Fix issue where SlowBuffers c - http://git.io/KHLc7g
18:44:03  <bnoordhuis>trevnorris: yes, i think it should be relatively straightforward to implement
18:48:14  * lohkeyjoined
18:49:48  <trevnorris>bnoordhuis: awesome.
18:50:02  <trevnorris>oh, i'm sure you saw, but llvm has already fixed the snan problem.
18:50:19  <trevnorris>that was a lot faster than I thought it'd be.
18:50:20  <bnoordhuis>trevnorris: what was the link to the issue?
18:50:40  <bnoordhuis>oh nvm, found it
18:52:03  * Ralt_joined
18:52:12  * lohkeyquit (Client Quit)
18:52:47  <bnoordhuis>+ // For x87 extended precision, we want to make a NaN, not a special NaN if
18:52:47  <bnoordhuis>+ // the input wasn't special either.
18:52:47  <bnoordhuis>+ if (!X86SpecialNan && semantics == &APFloat::x87DoubleExtended)
18:52:47  <bnoordhuis>+ APInt::tcSetBit(significandParts(), semantics->precision - 1);
18:52:59  <bnoordhuis>^ that's the full change :)
18:53:25  <trevnorris>heh, yeah. there were a bunch of tests too. but that was the fix.
18:56:09  * Ralt_quit (Remote host closed the connection)
18:56:16  <tjfontaine>hey, they're at least a nice group of folk to deal with, just so long as you don't bring up licenses
18:57:32  <trevnorris>tjfontaine: i'll keep that in mind.
18:57:39  <trevnorris>they're really down to business. not even a comment on the bug. just a cc and then fix.
18:57:58  <trevnorris>probably due to bnoordhuis awesome test case. very easy to see what was going on.
18:58:15  <tjfontaine>trevnorris: did you interact with d0k in channel? they may also have done some conversation on their phabricator install
18:59:44  <trevnorris>tjfontaine: give me a sec to google phabricator
19:00:00  * brsonquit (Read error: Operation timed out)
19:00:07  * mikealjoined
19:00:10  <tjfontaine>trevnorris: http://llvm-reviews.chandlerc.com/
19:00:24  * bradleymeckjoined
19:03:28  <trevnorris>tjfontaine: well that's cool. is that how they track code changes and reviews?
19:04:17  <tjfontaine>trevnorris: well, that's how the google contingent is pushing to handle code reviews, mostly though they still handle reviewing on the mailing list
19:05:14  * brsonjoined
19:06:58  <indutny>bnoordhuis: floating point spec is just fucked
19:08:48  <indutny>brb
19:29:08  <txdv>it's all fucked up, so what you wanna do
19:32:54  * c4milo_joined
19:40:05  * loladirojoined
19:42:24  * c4miloquit (*.net *.split)
19:47:47  * brsonquit (Ping timeout: 255 seconds)
19:48:17  * brsonjoined
20:01:04  * bradleymeckquit (Quit: bradleymeck)
20:02:17  * bradleymeckjoined
20:05:01  * `3rdEdenquit (Remote host closed the connection)
20:07:06  <trevnorris>isaacs: just because that joyent header is screwing git's ability to track file changes, i'm going to go with "or substantial portions" and say the unit tests aren't included there.
20:08:24  * jmar777quit (Read error: Connection reset by peer)
20:08:46  * jmar777joined
20:09:07  * rumpquit (Quit: rump)
20:16:56  * `3rdEdenjoined
20:17:42  * c4milo_quit (Remote host closed the connection)
20:22:14  * jmar777quit (Remote host closed the connection)
20:22:51  * jmar777joined
20:23:30  * jmar777quit (Read error: Connection reset by peer)
20:24:03  * jmar777joined
20:29:49  * paddybyersjoined
20:35:10  * Ralt_joined
20:35:44  * Ralt_quit (Remote host closed the connection)
20:43:05  <bnoordhuis>trevnorris: looks like the snan thing is really fixed, doesnn't it? very nice
20:43:23  * c4milojoined
20:45:18  <trevnorris>bnoordhuis: yeah. nice test script btw. that was a slick example.
20:45:23  <trevnorris>should a note be made in the tests or somewhere about that?
20:49:05  * Ralt_joined
20:49:47  <bnoordhuis>trevnorris: it's worth mentioning in the release notes / on the wiki
20:50:00  <bnoordhuis>we don't really have a KNOWN BUGS section anywhere though
20:50:00  <trevnorris>good idea.
20:55:31  <trevnorris>bnoordhuis: when "slab buffer" is used, do they just mean a buffer that's been allocated by the SlabAllocator class?
20:55:40  <bnoordhuis>trevnorris: yes
20:55:43  <trevnorris>cool
20:58:29  <bnoordhuis>trevnorris: fwiw, the slab allocator's algorithm is rather simplistic
20:58:43  <trevnorris>think I might have gone overboard. anyone mind reviewing my api write up on the new benchmark api: http://git.io/-g0zJQ
20:59:11  <trevnorris>bnoordhuis: so internally node doesn't allocate buffers directly, but allocates slabs?
20:59:31  <bnoordhuis>trevnorris: in the case of udp, tcp and pipe data, yes
20:59:42  <trevnorris>interesting, thanks.
20:59:48  <bnoordhuis>it works like this: libuv calls node and says "hey, i need xxx kb of memory"
21:00:18  <bnoordhuis>node allocates that memory from the current slab and passes it to libuv
21:00:38  <bnoordhuis>when the data has been read, the slab allocator tries to reclaim the memory
21:00:52  <bnoordhuis>but that only works if no other memory has been claimed in between
21:01:05  <bnoordhuis>iow, it only knows how to reclaim the last allocation
21:01:23  <bnoordhuis>another speed vs memory trade-off
21:01:45  <bnoordhuis>==25220== Conditional jump or move depends on uninitialised value(s)
21:01:45  <bnoordhuis>==25220== at 0x81FDBF: v8::internal::String::NonAsciiStart(char const*, int) (objects.h:7487)
21:01:49  <bnoordhuis>==25220== by 0x8210D3: v8::internal::Heap::AllocateStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) (heap-inl.h:90)
21:01:52  <bnoordhuis>==25220== by 0x80F2D7: v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) (factory.cc:209)
21:01:55  <bnoordhuis>==25220== by 0x7855FD: v8::String::New(char const*, int) (api.cc:4847)
21:01:57  <bnoordhuis>==25220== by 0x7050B6: node::Buffer::Utf8Slice(v8::Arguments const&) (node_buffer.cc:266)
21:02:00  <bnoordhuis>^ um
21:02:03  <bnoordhuis>that's valgrind -q out/Debug/node test/simple/test-buffer.js
21:02:33  <trevnorris>bnoordhuis: do you use any flags? if so, what are they?
21:02:44  <bnoordhuis>trevnorris: just -q in this case
21:02:46  * mikealquit (Quit: Leaving.)
21:06:22  <trevnorris>bnoordhuis: so is that a problem with v8 or node?
21:06:40  <bnoordhuis>trevnorris: probably node. i'll look into it
21:07:18  * mikealjoined
21:07:27  * jmar777quit (Remote host closed the connection)
21:08:02  * jmar777joined
21:09:07  * Ralt_quit (Remote host closed the connection)
21:10:54  * jmar777_joined
21:11:02  * jmar777quit (Read error: Connection reset by peer)
21:31:08  <piscisaureus_>trevnorris: so where is the bug/patch for this llvm fix?
21:32:15  <trevnorris>piscisaureus_: http://git.io/gN8D2w
21:32:44  <trevnorris>above is the link to the bug itself.
21:32:54  <tjfontaine>http://llvm-reviews.chandlerc.com/rL173459
21:32:54  <piscisaureus_>trevnorris: Saw that. Thanks!
21:33:53  * hzquit
21:34:47  <MI6>joyent/node: Ben Noordhuis master * 00b4b7b : buffer: remove minor Buffer::Copy deoptimizations * Omit ToObject() call - http://git.io/qRSOXg
21:35:14  <trevnorris>bnoordhuis: just a reminder, probably want to port that to v0.8
21:35:27  <bnoordhuis>trevnorris: nathan cherry-picked your patch?
21:35:32  <trevnorris>bnoordhuis: yeah
21:35:51  <bnoordhuis>ah well, it doesn't really matter - it's a micro optimization thing
21:36:19  <TooTallNate>bnoordhuis: we could cheery pick that one too
21:36:20  <trevnorris>bnoordhuis: 65249cc
21:36:33  <TooTallNate>bnoordhuis: but i don't think v0.8 branch has the Buffer::Data with Value smarts
21:36:41  <bnoordhuis>TooTallNate: "cheery pick" <- i like that one, i'm gonna use that myself :)
21:36:47  <TooTallNate>hahaha
21:36:49  <TooTallNate>whoops
21:36:57  <TooTallNate>hahaha
21:37:59  <trevnorris>TooTallNate: neither did master. Uint32Value seems to convert undefined to 0
21:38:07  <trevnorris>though it's really really slow about it.
21:38:22  <trevnorris>so if you're going to use it, just make sure you always pass in all the args.
21:38:46  <TooTallNate>trevnorris: i meant the first line of bnoordhuis' patch just now - removing the ToObject() part
21:38:49  <bnoordhuis>trevnorris: it uses a checked conversion because simply doing static_cast<uint32_t>(NaN) is undefined
21:40:10  <trevnorris>TooTallNate: whoop. see what you mean.
21:40:48  <trevnorris>bnoordhuis: shouldn't it be `Local<Value> target = args[0]->toObject();`
21:41:38  <bnoordhuis>trevnorris: the cast to object isn't necessary here because we're not doing anything that requires it to be an object
21:42:28  <trevnorris>bnoordhuis: ah, ok. see what you mean.
21:44:49  <trevnorris>on the side, would it be ~trivial to check if two buffers overlap and use a "faster" copy method if they don't?
21:44:57  * loladiroquit (Quit: loladiro)
21:45:11  <trevnorris>something like, check if they have the same slow buffer parent or something
21:46:42  <trevnorris>and if they do, check their offset+lengths
21:46:56  <bnoordhuis>trevnorris: maybe. you mean because we use memmove now?
21:47:28  <trevnorris>bnoordhuis: sure. i'm just going by the comment "need to use slightly slower memmove"
21:47:44  <trevnorris>but I don't have enough experience to know how much slower that actually is.
21:47:53  <bnoordhuis>trevnorris: i don't think it really matters but you're free to try
21:48:28  <bnoordhuis>if i were a glibc hacker, i'd first check if the src and the dst actually overlap
21:48:43  <bnoordhuis>and if they don't, go all out
21:49:20  <trevnorris>bnoordhuis: cool. (what does glibc have to do with it?)
21:49:23  * felixgequit (Quit: felixge)
21:49:42  <bnoordhuis>trevnorris: memmove is a libc function (unless gcc uses it builtin version)
21:49:58  <bnoordhuis>but i don't think gcc actually has a builtin memmove
21:50:38  <tjfontaine>I think it may
21:50:38  <trevnorris>interesting. thanks. I'll keep that in mind.
21:50:57  <bnoordhuis>tjfontaine: i might very well be wrong here. i know it has a builtin memcpy
21:51:18  <bnoordhuis>and indeed it does
21:51:20  <tjfontaine>well, this bug makes me think there is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21602
21:51:32  <bnoordhuis>yeah, just grepped the gcc tree :)
21:51:42  <tjfontaine>though oddly not listed in http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Other-Builtins.html
21:52:22  <bnoordhuis>git log says it was added in 2003
21:52:33  <tjfontaine>ya google agrees with the patch date
21:52:37  <trevnorris>hm. we're already using memcpy in buffer.cc
21:53:42  <tjfontaine>"Is there truly a performance penalty to this patch?" a question for the bug submitter to answer indeed
21:56:19  <trevnorris>really newb question. is it safe to compare two pointers by `source->data_ != target->data_`?
21:56:30  * bradleymeckquit (Quit: bradleymeck)
21:57:03  <bnoordhuis>buf.write('あいうえ', 'utf8'); <- apparently causes the "Conditional jump or move depends on uninitialised value" warning
21:57:12  <bnoordhuis>but not, alas, in isolation...
21:57:33  * jmar777_quit (Remote host closed the connection)
21:57:40  <bnoordhuis>trevnorris: you mean if they're equal / not equal?
21:57:54  <trevnorris>bnoordhuis: if the pointers are pointing to the same location.
21:58:04  <bnoordhuis>trevnorris: yes, that's safe
21:58:04  <trevnorris>figured that would be the easiest way to see if they use the same slowbuffer.
21:58:07  <trevnorris>cool
21:58:08  * jmar777joined
21:58:37  <bnoordhuis>trevnorris: but fastbuffers don't have a data_ field
21:58:43  <bnoordhuis>they're pure v8 objects
22:02:18  * jmar777quit (Ping timeout: 240 seconds)
22:07:49  * `3rdEdenquit (Quit: Zzzzzzzzzzz)
22:07:57  <trevnorris>bnoordhuis: ok. going off what little I know, is it possible|safe to set a hidden field to the pointer on fast buffer instantiation?
22:07:58  <trevnorris> (more because i'm curious, not because it'd be a good solution)
22:10:08  <trevnorris>bnoordhuis: or couldn't we `args[0]->ToObject()->GetIndexedPropertiesExternalArrayData()`?
22:11:52  <bnoordhuis>trevnorris: GetIndexedPropertiesExternalArrayData is what you want
22:12:25  <trevnorris>cool. i realize the cost of that will be way more than just using memmove. but good to know.
22:16:11  <bnoordhuis>"gdb crashed with SIGSEGV in _IO_feof()". sigh
22:19:17  <trevnorris>hm. nother newb question. returning `return scope.Close(Integer::New(*((int64_t*)source->data_)));` from copy. fast buffers give me a value. slowbuffers always return 0.
22:20:24  <bnoordhuis>trevnorris: what is `source`? it can't be a fastbuffer because that's not a c++ object
22:20:39  <trevnorris>bnoordhuis: `Buffer *source = ObjectWrap::Unwrap<Buffer>(args.This());`
22:20:46  <isaacs>bnoordhuis: Did you see https://github.com/isaacs/node/commit/ede65922cf37882fc580fe3b93d7820bf8859871?
22:20:59  <isaacs>bnoordhuis: regarding that NODE_MODULE_M thing, but without requiring an API change.
22:21:19  * jmar777joined
22:21:20  * piscisaureus_quit (Read error: Connection reset by peer)
22:21:23  <bnoordhuis>isaacs: yes, saw it. i kind of dislike that it throws away type safety but templates won't help here
22:21:35  <bnoordhuis>so i guess it's the lesser of two evils if you want to land such a thing
22:21:53  <isaacs>bnoordhuis: well, i ilke it better than asking people to use two different macros
22:21:54  <bnoordhuis>trevnorris: okay, so it's a slowbuffer
22:22:02  * piscisaureus_joined
22:22:08  <bnoordhuis>isaacs: yeah, it's a better approach
22:22:10  <trevnorris>bnoordhuis: yeah.
22:22:12  * piscisaureus_quit (Client Quit)
22:22:33  <isaacs>bnoordhuis: if you give it a function that can't be cast to the right signature, it'll still complain, won't it?
22:22:41  <isaacs>like something that takes an int or something
22:22:42  * piscisaureus_joined
22:23:14  <bnoordhuis>isaacs: it won't. you're telling the compiler to shut up there :)
22:23:19  <isaacs>oh, i see
22:23:26  <isaacs>well, whatever. computers should shut up and do what they're told.
22:23:37  <bnoordhuis>that's exactly the problem
22:23:39  * isaacswill probably cause the matrix uprising or something
22:24:38  <isaacs>ok, i'm gonna land it, with rvagg's doc updates
22:25:47  * loladirojoined
22:28:41  <MI6>joyent/node: isaacs master * bdc7251 : doc: fix line wrapping in addons.markdown (+2 more commits) - http://git.io/OZqMXA
22:29:50  <trevnorris>isaacs: i've written a new spec for the benchmark api (http://git.io/-g0zJQ). it's a lot more extensive an will allow for hooks like writing the results to disk, customizing the msg, etc.
22:30:15  <trevnorris>but at this rate it could practically become it's own lib.
22:30:38  <isaacs>rvagg: so, i'm deeply suspicious of benchmark "libs" and utilities
22:30:43  <isaacs>which sucks, because you kind of need something like that
22:30:57  <isaacs>node-bench pushes it about as far as it can be pushed, i think, and it's not very super
22:31:04  <trevnorris>isaacs: was that meant for me?
22:31:11  <isaacs>trevnorris: oh, right
22:31:18  <isaacs>rvagg: thanks, landed your thing
22:31:47  * isaacsa little overheated. oakland decided today is summer
22:32:24  <isaacs>trevnorris: i'll review this. i want your special benchmarks, and i super want benchmarks that we can track programmatically
22:32:44  <isaacs>trevnorris: but yes, it perhaps ought to be its own lib, and fair warning, i might be leaning on you to remove features and make it simpler.
22:33:08  <isaacs>trevnorris: the problem is, like with ab, you can very easily get into situations where it's unclear whether a regression is because of the benchmark tool doing something wierd, or actually the code under test.
22:33:22  <trevnorris>isaacs: totally. this is for node benchmarks.
22:33:59  <rvagg>isaacs: cheers for landing it
22:34:13  <isaacs>trevnorris: just as an object-example in this area: jsperf.
22:34:24  <rvagg>isaacs: what are you using for line wrapping? do you have something that's wrapping automatically or a line margin in your editor?
22:34:29  <isaacs>trevnorris: jsperf is the most useless thing in the world for actual javascript performance analysis
22:34:38  <trevnorris>isaacs: and fwiw I have extensive testing to make sure the api doesn't affect the outcome. (e.g. shouldn't show up when running the test w/ `--trace-opt --trace-inlining --code-comments`)
22:34:39  <rvagg>isaacs: cause I'm just guessing (cause I frankly don't care in my own docs)
22:34:40  <isaacs>rvagg: i use vim. gq<move> and it auto-wraps nicely
22:34:54  <rvagg>isaacs: cool, will try and remember that
22:35:07  <isaacs>rvagg: normally i would have squashed it against your commit, but i accidentally wrapped a few other lines, and didn't want extra noise in that diff.
22:35:59  <rvagg>isaacs: and we're doing 80 chars as the max line length?
22:36:01  <isaacs>trevnorris: i have confidence in your goals :)
22:36:16  <isaacs>rvagg: as the absolute max. personally, i try to stay well under 70
22:36:23  <isaacs>rvagg: except for C++, where that's just not possible :)
22:38:06  <isaacs>rvagg: also: gq<move> does absolutely the wrong thing with code blocks in markdown, and list items in markdown.
22:38:10  <isaacs>rvagg: be warned :)
22:38:16  * c4miloquit (Remote host closed the connection)
22:39:42  * c4milojoined
22:39:57  * c4miloquit (Remote host closed the connection)
22:39:58  * rendarquit
22:41:13  <trevnorris>rvagg: fwiw, here's my vimrc (http://git.io/D8JNIw). look at lines 67, and if you are truly word wrapping lines 137,138.
22:41:53  <rvagg>mm, I've switched to ST2 these days for most of my code editing but vim still gets a bit of a workout
22:42:38  <rvagg>trevnorris: set colorcolumn=81 is pretty neat!
22:43:04  <trevnorris>rvagg: yeah. it saves my butt.
22:43:43  <mmalecki>https://github.com/mmalecki/vim-node.js is a nice addition.
22:44:04  <rvagg>arr, gq<move> is neat with select mode; I wonder if I'll actually remember it
22:44:36  <trevnorris>mmalecki: nice. it's the simple things that make vim awesome.
22:45:14  <trevnorris>i've also extended vim-javascript to highlight all the node specific parts: https://github.com/trevnorris/vim-javascript
22:45:21  <isaacs>rvagg: https://github.com/isaacs/.vim is mine
22:45:51  <tjfontaine>good god.
22:46:00  <isaacs>yeah, it's a godawful nightmare
22:46:08  <mmalecki>I also have a cb<tab> snippet, which is like function (err, ...) { ... }
22:46:13  <mmalecki>pretty damn useful.
22:47:02  <rvagg>nice
22:47:08  <trevnorris>isaacs: hm. never used textwidth before. nice.
22:47:18  <isaacs>hm, there's a lot of stuff in my .vim tha's not tracked in that repo. i guess i lost the .git on it at somepoint.
22:47:31  <rvagg>I've been using a mostly vanilla Janus these days, but the CSV crazyness gets me down
22:47:46  <isaacs>i kinda realized that i don't like janus so much
22:47:52  <isaacs>it's optimized for MacVim which i don't use.
22:48:12  <isaacs>i guess vimperator is the hotness now
22:48:17  <isaacs>that's what the kids tell me
22:48:57  <tjfontaine>I'm simpleton, I just want syntax on, ts=2, expandtab, and ruler :)
22:50:29  <isaacs>i especially like shift+JKLH mapped to scrolling the buffer, and <ctrl>+jklh mapped to moving focus around panes
22:50:40  <isaacs><ctrl>w is too far away
22:51:02  <tjfontaine>heh
22:51:42  <isaacs>i just embrase hjkl a bit more than vim itself, that's all :)
22:52:34  * jmar777quit (Remote host closed the connection)
22:52:48  <trevnorris>isaacs: yeah. to get over using u/d/l/r, mapped them to nothing. still took me a while to get used to.
22:53:11  * jmar777joined
22:53:46  * jmar777quit (Read error: Connection reset by peer)
22:54:19  * jmar777joined
22:58:00  * jmar777quit (Remote host closed the connection)
22:58:29  <isaacs>trevnorris: well, i mean, i'm not a monster.
22:58:33  <isaacs>i stil use arrow keys
22:58:38  * jmar777joined
22:58:50  <trevnorris>heh.
22:59:07  <isaacs>just not as much, since hjkl are so close, and they also do other "move around" stuff
22:59:48  <trevnorris>worked w/ a linux guru that had taught at red hat. only allowed vim on the servers i helped sys admin.
23:00:02  <trevnorris>that was baptism by fire.
23:00:51  * isaacstopic: liberally using vim ~ https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10 ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
23:01:02  <tjfontaine>trevnorris: that's the only way to learn to sysadmin (baptism by fire)
23:01:22  <trevnorris>tjfontaine: heh, true true.
23:01:28  <isaacs>trevnorris: you had a bleeding heart teacher, i see.
23:01:35  <isaacs>trevnorris: smartos installs with just vi by default
23:01:43  <tjfontaine>nvi?
23:01:54  <isaacs>trevnorris: no, proper old-school vi
23:02:09  <tjfontaine>evil.
23:02:10  <isaacs>trevnorris: of course, the zone that joyent deploys actually has vim by default
23:02:15  <isaacs>but the global zone, it's only vi
23:02:40  <isaacs>the editor with two modes: the one that scrambles your text, and the one that beeps.
23:02:48  * jmar777quit (Ping timeout: 252 seconds)
23:02:49  <trevnorris>I remember the first time I accidentally shutdown a production server 1 hour before the store opened.... yeah.
23:03:21  <tjfontaine>luckily since I also had to maintain hp-ux 10.20 and aix 5.3 I'm used to braindead vi's
23:03:41  <trevnorris>oh vi. how I learned to hate you.
23:03:44  * mikealquit (Quit: Leaving.)
23:04:19  <tjfontaine>trevnorris: did you learn get a more verbose PS1 after that shutdown experience? or to alias shutdown out of the way? :)
23:06:21  <trevnorris>tjfontaine: i'll blame it on being up until 2am doing a schema update for an oracle database.
23:06:54  <tjfontaine>heh
23:06:57  <trevnorris>there are few things I hate more than oracle 10gR2
23:09:48  <trevnorris>tjfontaine: i never got used to vi. after learning the niceties of vim, just couldn't do it.
23:12:20  * bnoordhuisquit (Ping timeout: 252 seconds)
23:19:42  * isaacstopic: liberal utopian vacation ~ https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10 ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
23:19:50  * isaacschanged the topic back to the *real* meaning of libuv
23:20:06  <trevnorris>indutny: yo. i remember you talking gibberish about some old space/new space technique. have a doc or two I could read about that?
23:23:28  * hzjoined
23:31:37  <trevnorris>isaacs: re bench lib: i'll have it done by mon, and will post comparative tests against a minimal implementation.
23:31:40  <trevnorris>feel free to work backwards from there and let me know what you don't want.
23:31:48  <isaacs>trevnorris: kewl
23:31:56  <isaacs>trevnorris: a standalone module is probably worthwhile
23:34:51  * mikealjoined
23:39:54  * mikealquit (Ping timeout: 276 seconds)
23:42:34  * loladiropart
23:42:57  * loladirojoined
23:44:59  * loladiropart
23:46:40  * loladirojoined
23:47:16  * paddybyersquit (Read error: Connection reset by peer)