00:00:08  * ircretaryjoined
00:04:51  * defunctzombiechanged nick to defunctzombie_zz
00:06:10  <tjfontaine>ugh, I'm done with that issue
00:08:07  * isaacssigh
00:08:23  <isaacs>not enough time to get this http agent cut out. maybe tonight after yoga
00:08:35  <tjfontaine>enjoy your relaxation
00:09:27  <tjfontaine>winning comment thus far: " it should be aware of the performance constraints of that underlying system and should do the necessary work to not exacerbate them."
00:19:08  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
00:22:29  * AvianFluquit (Remote host closed the connection)
00:25:59  <trevnorris>tjfontaine: dude, i'm about to go ape shit on that guy
00:27:21  <tjfontaine>take a breath first :)
00:27:38  <tjfontaine>it would be interesting to see code, and perhaps an example string
00:28:44  <tjfontaine>it's possible that we could fix this, we already loop over the buffer as the underlying writeSync's happen, but the data being utf8 make it slightly difficult to interpret easily
00:29:10  <trevnorris>i'm already working on this
00:29:33  <trevnorris>but honestly the implementation is beyond what he'd be capable of understanding
00:30:23  <trevnorris>if it has the words "buffer" and "optimization" in it, there's a very high likelihood a fix is already in the mix
00:31:23  <tjfontaine>we don't really have enough information to know what's really going on right now
00:32:17  * qard1quit (Quit: Leaving.)
00:33:15  <trevnorris>I understand the issue, and have been working the last couple weeks on a fix for the general case.
00:34:23  <tjfontaine>I "understand" the issue, but having actual information would be helpful as well
00:35:46  <trevnorris>what type of information you asking for?
00:35:58  <tjfontaine>you should get the email notification shortly
00:37:07  <trevnorris>the issue is beyond writeFileSync, that's just a single manifestation of a larger thing
00:37:21  <tjfontaine>I dont' disagree
00:37:41  <tjfontaine>but it's good practice for people who submit issues to actually submit information with them
00:38:03  <tjfontaine>otherwise they might all say "make node go faster"
00:38:08  <trevnorris>oh, i see. so it's not for me to understand better. it's so he can understand his own issue better.
00:38:34  <tjfontaine>and for us to see he's interested in actually seeing this through :)
00:38:44  <trevnorris>ah yeah
00:40:13  <tjfontaine>still, he's doing it worng.
00:40:14  <tjfontaine>*wrong
00:40:15  <tjfontaine>:)
00:40:37  <trevnorris>been working on a response for the last 30 mins. one sec, almost done.
00:43:54  <tjfontaine>forogt I took the bus today, I'll catch your response from there, bbl
00:44:04  <trevnorris>coolio
00:44:20  * mralephjoined
00:50:26  <trevnorris>tjfontaine: now that I think of it, there shouldn't technically be a need to create a Buffer at all. Just dump the string to cc and use isaacs new StringBytes to write it out to a char* then clean that up afterwards.
00:50:31  <trevnorris>i'll try something out later
00:51:37  * kazuponjoined
00:56:19  * kazuponquit (Ping timeout: 264 seconds)
01:03:40  * c4milojoined
01:05:45  * bnoordhuisquit (Ping timeout: 240 seconds)
01:06:10  * kazuponjoined
01:06:34  * piscisaureus_quit (Read error: Connection reset by peer)
01:06:46  * amartensquit (Quit: Leaving.)
01:09:06  * mralephquit (Ping timeout: 264 seconds)
01:17:00  * inolenquit (Quit: Leaving.)
01:29:09  * defunctzombie_zzchanged nick to defunctzombie
01:29:34  * kazuponquit (Remote host closed the connection)
01:36:14  <cjd>make[7]: Entering directory `/home/user/wrk/play/openwrt/openwrt/build_dir/target-mipsel_r2_uClibc-0.9.33.2/cjdns-0.4-SNAPSHOT/libuv'
01:36:15  <cjd>cc1: note: someone does not honour COPTS correctly, passed 0 times
01:36:21  * cjdwags finger
01:38:06  * amartensjoined
01:42:02  * trapitoquit (Quit: Page closed)
01:47:05  * inolenjoined
01:56:50  * amartensquit (Quit: Leaving.)
02:03:16  * brsonquit (Read error: Operation timed out)
02:03:53  * amartensjoined
02:04:43  * dapquit (Quit: Leaving.)
02:11:56  * kazuponjoined
02:16:01  * amartensquit (Quit: Leaving.)
02:16:51  * kazuponquit (Ping timeout: 256 seconds)
02:24:17  * c4miloquit (Ping timeout: 252 seconds)
02:26:50  * amartensjoined
02:27:22  * c4milojoined
02:37:08  * saghulquit (Ping timeout: 241 seconds)
02:38:57  * saghuljoined
02:49:22  * saghulquit (Ping timeout: 276 seconds)
02:49:31  * mralephjoined
02:49:59  * saghuljoined
02:56:13  * kazuponjoined
03:01:41  * kazuponquit (Ping timeout: 252 seconds)
03:02:37  * timoxleyquit (Quit: Computer has gone to sleep.)
03:02:48  * amartensquit (Quit: Leaving.)
03:05:24  * brsonjoined
03:06:54  * amartensjoined
03:27:33  * c4milo_joined
03:27:42  * c4miloquit (Ping timeout: 264 seconds)
03:33:49  * timoxleyjoined
03:54:55  * kazuponjoined
04:08:19  * cjdquit (Ping timeout: 264 seconds)
04:09:45  * amartensquit (Quit: Leaving.)
04:12:00  * amartensjoined
04:13:46  * amartensquit (Client Quit)
04:24:06  * c4milo_quit (Ping timeout: 264 seconds)
04:55:24  * benoitcquit (Excess Flood)
05:01:14  * benoitcjoined
05:05:08  * cjdjoined
05:14:42  * amartensjoined
05:34:06  <trevnorris>tjfontaine: oh man. this is going to be fun.
05:34:48  * defunctzombiechanged nick to defunctzombie_zz
05:37:23  * mikealquit (Quit: Leaving.)
05:42:13  * mikealjoined
06:00:29  * kazuponquit (Read error: Connection reset by peer)
06:00:45  * kazuponjoined
06:21:42  * mikealquit (Read error: Connection reset by peer)
06:22:09  * mikealjoined
06:27:59  * hzjoined
06:36:53  * csaohjoined
06:37:33  * brsonquit (Quit: leaving)
06:41:50  * csaohquit (Quit: csaoh)
06:52:47  * mikealquit (Quit: Leaving.)
06:53:01  * timoxleyquit (Quit: Computer has gone to sleep.)
06:57:50  * rendarjoined
07:11:13  * paddybyersjoined
07:19:06  * amartensquit (Quit: Leaving.)
07:19:43  * bajtosjoined
07:30:32  * dominictarrjoined
07:32:55  * amartensjoined
07:33:06  * csaohjoined
07:42:19  * timoxleyjoined
07:49:27  * CoverSlidequit (Remote host closed the connection)
08:06:37  * amartensquit (Quit: Leaving.)
08:41:37  * `3rdEdenjoined
08:56:50  * timoxleyquit (Quit: Computer has gone to sleep.)
09:03:57  * timoxleyjoined
09:11:51  * loladirojoined
09:29:54  * dominictarrquit (Quit: dominictarr)
09:41:44  * bajtosquit (Quit: bajtos)
09:44:49  * stolsmajoined
09:47:55  * kazuponquit (Remote host closed the connection)
09:52:00  * kazuponjoined
09:53:34  * kazuponquit (Remote host closed the connection)
09:55:46  * hzquit (Ping timeout: 276 seconds)
09:55:51  * loladiro_joined
09:57:18  * hzjoined
09:57:18  * hzquit (Changing host)
09:57:18  * hzjoined
09:57:36  * hz_joined
09:57:36  * hz_quit (Changing host)
09:57:36  * hz_joined
09:57:36  * hzquit (Disconnected by services)
09:57:41  * hz_changed nick to hz
09:58:07  * loladiroquit (Ping timeout: 256 seconds)
09:58:08  * loladiro_changed nick to loladiro
10:06:05  * `3rdEdenchanged nick to `3E|BRB
10:13:33  * stolsma2joined
10:16:34  * stolsmaquit (Ping timeout: 276 seconds)
10:23:04  * timoxleyquit (Quit: Computer has gone to sleep.)
10:28:15  * hz_joined
10:28:15  * hz_quit (Changing host)
10:28:15  * hz_joined
10:28:15  * hzquit (Disconnected by services)
10:28:20  * hz_changed nick to hz
10:30:11  * bajtosjoined
10:31:15  * `3E|BRBchanged nick to `3rdEden
10:32:07  * paddybyersquit (Ping timeout: 256 seconds)
10:37:17  * timoxleyjoined
10:46:04  * csaohquit (Quit: csaoh)
10:48:11  * bnoordhuisjoined
10:59:17  * csaohjoined
11:08:02  <indutny>bnoordhuis: hey man
11:08:18  <indutny>bnoordhuis: wanna take a look at https://github.com/joyent/node/pull/5601
11:18:23  * kazuponjoined
11:23:30  * dominictarrjoined
11:31:46  <bnoordhuis>indutny: i was already looking :)
11:34:30  <bnoordhuis>indutny: i'm curious what kind of bug it is at its core: streams2 abuse or plain tls bug?
11:35:19  * kazuponquit (Read error: Connection reset by peer)
11:35:29  * kazuponjoined
11:37:06  * Kjerskiquit (Read error: Operation timed out)
11:41:24  * Kjerskijoined
11:42:22  * bajtosquit (Quit: bajtos)
11:45:05  <indutny>bnoordhuis: tls bug
11:45:09  <indutny>a number of bugs
11:45:13  <indutny>actually
11:46:35  <MI6>joyent/node: Fedor Indutny v0.10 * 9ee86b7 : tls: proper .destroySoon - http://git.io/Ign93w
11:46:40  <indutny>bnoordhuis: let it be then :)
11:52:29  * loladiro_joined
11:52:35  * loladiroquit (Ping timeout: 256 seconds)
11:52:36  * loladiro_changed nick to loladiro
11:58:42  <MI6>nodejs-v0.10: #219 UNSTABLE smartos-ia32 (1/588) linux-ia32 (1/588) linux-x64 (1/588) smartos-x64 (2/588) http://jenkins.nodejs.org/job/nodejs-v0.10/219/
12:05:27  <MI6>nodejs-v0.10-windows: #49 UNSTABLE windows-x64 (8/588) windows-ia32 (7/588) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/49/
12:08:18  * cjdpart
12:08:40  * kazuponquit (Remote host closed the connection)
12:11:33  * paddybyersjoined
12:24:31  * paddybyersquit (Ping timeout: 264 seconds)
12:30:56  * normanmjoined
12:37:35  * paddybyersjoined
12:38:22  <MI6>joyent/node: mscdex master * 510aef9 : buffer: return `this` in fill() for chainability - http://git.io/Ofep6w
12:39:34  <bnoordhuis>son of a...
12:40:26  <MI6>joyent/node: Brian White master * 6af8788 : buffer: return `this` in fill() for chainability - http://git.io/zmFxIQ
12:42:16  <MI6>joyent/node: Brian White v0.10 * 774b28f : repl: fix JSON.parse error check - http://git.io/u9mCTA
12:43:48  * piscisaureus_joined
12:44:55  * paddybyersquit (Ping timeout: 264 seconds)
12:49:05  <piscisaureus_>bnoordhuis: you're right that sig_atomic_t is an int
12:49:06  * normanmquit (Quit: Computer has gone to sleep.)
12:49:25  <piscisaureus_>bnoordhuis: I was suggesting it because the assumption is that the value can be updated atomically
12:49:51  <MI6>nodejs-master: #240 UNSTABLE smartos-x64 (7/604) linux-ia32 (1/604) smartos-ia32 (3/604) osx-x64 (2/604) osx-ia32 (1/604) linux-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-master/240/
12:50:02  <piscisaureus_>bnoordhuis: consider what would happen if it were an int64_t and running on a 32-bit platform
12:53:13  * hudgfactorjoined
12:55:40  <bnoordhuis>piscisaureus_: right, but that doesn't apply here
12:55:58  <piscisaureus_>bnoordhuis: you mean - it's not an int64_t -> true
12:56:03  * linusjoined
12:56:18  <linus>'ere we go.
12:56:42  <linus>Sorry for any stupid things happening with the patch, I'm not all used to git, as mentioned. :)
12:57:42  <MI6>joyent/node: Ryunosuke SATO master * 7ce5a31 : events: define properties on prototype - http://git.io/kFIing
12:58:09  <bnoordhuis>^ such a simple optimization
12:58:20  <bnoordhuis>hey linus
12:59:02  <linus>Hello there!
13:01:25  <linus>Removing those comments as piscis suggested, and fixing a minor glitch in coding style, then I think I've taken care of all comments
13:01:39  <MI6>nodejs-master-windows: #49 UNSTABLE windows-ia32 (15/604) windows-x64 (18/604) http://jenkins.nodejs.org/job/nodejs-master-windows/49/
13:01:40  <piscisaureus_>woo!
13:02:27  <MI6>nodejs-master: #241 UNSTABLE smartos-x64 (7/604) linux-ia32 (1/604) smartos-ia32 (2/604) osx-x64 (1/604) osx-ia32 (2/604) linux-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-master/241/
13:02:41  <piscisaureus_>linus: bnoordhuis: so pthread-fixes is still a public header
13:02:54  <piscisaureus_>I thought that would be moved to src/unix ?
13:03:00  <bnoordhuis>right, yes
13:03:11  <linus>Ah
13:03:13  <linus>Alright
13:05:00  <piscisaureus_>I know there's also https://github.com/joyent/libuv/blob/master/include/uv-private/stdint-msvc2008.h but I found no good way to work around that
13:05:00  <linus>Hm
13:05:22  <linus>I'm referencing it in uv-private/uv-unix.h though
13:06:04  <piscisaureus_>linus: what reference (the #include aside) ?
13:07:07  <linus>It defines the pthread_barrier_t that there's a typedef for
13:07:26  <piscisaureus_>ah scheisse
13:09:05  <linus>Could define that type directly in uv-unix under an ifdef android and include it from pthread-fixes.h instead, but I have no idea what I'd do to the license text
13:09:20  <linus>Your call, really. :q
13:10:06  <piscisaureus_>bnoordhuis: opinions
13:10:28  <piscisaureus_>linus: given the new circumstances, I'd say then just leave it in uv-private
13:10:29  <MI6>joyent/node: Kiyoshi Nomo v0.10 * 36e90da : doc: remove `bufferSize` option - http://git.io/R4JjKQ
13:10:37  <linus>Fair enough
13:10:46  <bnoordhuis>agreed
13:10:51  * timoxleyquit (Quit: Computer has gone to sleep.)
13:10:55  <piscisaureus_>although I'm not that concerned about the copyright on a 3-member struct :)
13:11:02  <linus>Truth. :)
13:11:07  <linus>Noticed I accidentally removed the EINVAL comment at iovcnt, so I'll add that back in again at least
13:15:03  <linus>There!
13:16:02  * Kjerskiquit (Ping timeout: 252 seconds)
13:19:16  <MI6>nodejs-v0.10: #220 UNSTABLE smartos-ia32 (1/588) smartos-x64 (2/588) http://jenkins.nodejs.org/job/nodejs-v0.10/220/
13:19:28  * kazuponjoined
13:21:18  <MI6>nodejs-master: #242 UNSTABLE smartos-x64 (6/604) linux-ia32 (5/604) smartos-ia32 (9/604) osx-x64 (1/604) osx-ia32 (2/604) linux-x64 (5/604) http://jenkins.nodejs.org/job/nodejs-master/242/
13:21:31  <linus>Are those smartOS failures a common occurrence?
13:23:41  <bnoordhuis>sadly yes
13:23:51  <bnoordhuis>smartos is kind of the lame duck of unices
13:24:07  * kazuponquit (Ping timeout: 260 seconds)
13:24:13  <bnoordhuis>or maybe 'ugly duckling' is a better choice of words
13:24:48  <bnoordhuis>ugly ducking in reverse, really. it used to be a beatiful swan, in the '90s
13:24:53  <bnoordhuis>*beautiful
13:26:52  <MI6>nodejs-v0.10-windows: #50 UNSTABLE windows-x64 (10/588) windows-ia32 (10/588) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/50/
13:28:38  <MI6>nodejs-master-windows: #50 UNSTABLE windows-ia32 (18/604) windows-x64 (14/604) http://jenkins.nodejs.org/job/nodejs-master-windows/50/
13:29:41  * pachetjoined
13:31:13  * bajtosjoined
13:33:16  * `3rdEdenquit (Remote host closed the connection)
13:34:31  * bajtosquit (Client Quit)
13:36:06  <linus>Sounds more like a Dodo-bird. :)
13:36:44  <linus>Anyhow, handled what you brought up so far
13:38:41  <linus>As I mentioned, you could pull getifaddrs from another project within android, but it's really going beyond the patch goal a bit. :)
13:39:23  * `3rdEdenjoined
13:39:58  * dominictarrquit (Ping timeout: 256 seconds)
13:40:26  * dominictarrjoined
13:40:30  <MI6>nodejs-v0.10: #221 UNSTABLE smartos-ia32 (1/588) linux-ia32 (1/588) linux-x64 (2/588) smartos-x64 (3/588) http://jenkins.nodejs.org/job/nodejs-v0.10/221/
13:49:06  <MI6>nodejs-v0.10-windows: #51 UNSTABLE windows-x64 (8/588) windows-ia32 (7/588) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/51/
13:53:58  <MI6>nodejs-v0.10: #222 UNSTABLE smartos-ia32 (1/588) smartos-x64 (2/588) http://jenkins.nodejs.org/job/nodejs-v0.10/222/
13:54:09  * paddybyersjoined
13:58:37  <MI6>joyent/node: Andrew Paprocki master * 49e3fcd : vm: fix race condition in watchdog cleanup - http://git.io/ML_GNQ
14:10:31  <MI6>nodejs-master: #243 UNSTABLE smartos-x64 (8/604) linux-ia32 (2/604) smartos-ia32 (4/604) osx-x64 (1/604) osx-ia32 (2/604) linux-x64 (2/604) http://jenkins.nodejs.org/job/nodejs-master/243/
14:13:14  * paddybyersquit (Ping timeout: 252 seconds)
14:14:47  * AvianFlujoined
14:15:40  * dominictarrquit (Ping timeout: 256 seconds)
14:16:32  * dominictarrjoined
14:21:04  * AvianFluquit (Ping timeout: 260 seconds)
14:21:33  * bajtosjoined
14:22:31  <MI6>nodejs-master-windows: #51 UNSTABLE windows-ia32 (20/604) windows-x64 (20/604) http://jenkins.nodejs.org/job/nodejs-master-windows/51/
14:23:58  <MI6>joyent/libuv: Ben Noordhuis master * a8da229 : build: remove CSTDFLAG, use only CFLAGS (+1 more commits) - http://git.io/m0gBmg
14:29:58  <MI6>libuv-master: #106 UNSTABLE smartos (2/189) windows (3/190) http://jenkins.nodejs.org/job/libuv-master/106/
14:30:23  <MI6>libuv-master-gyp: #44 UNSTABLE smartos-x64 (2/189) smartos-ia32 (2/189) windows-ia32 (4/190) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/44/
14:30:24  * dominictarrquit (Quit: dominictarr)
14:32:23  * paddybyersjoined
14:32:41  <isaacs>wow, lots of MI6
14:32:50  <isaacs>was a push-party this morning?
14:35:23  <bnoordhuis>yeah. you missed it, everyone was there
14:36:13  <MI6>joyent/libuv: Linus Mårtensson master * fc6a2ad : unix: support for android builds - http://git.io/IqCByg
14:37:09  <bnoordhuis>linus: ^
14:37:54  <isaacs>bnoordhuis: what's smartos being lame-duckey about?
14:38:41  <bnoordhuis>oh, not so much smartos as solaris
14:38:45  * AvianFlujoined
14:38:55  <bnoordhuis>it used to be king and now it's a joker
14:38:57  <isaacs>bnoordhuis: solaris is dead.
14:39:00  <bnoordhuis>(poetic, innit?)
14:39:02  <isaacs>bnoordhuis: oracle killed it
14:39:49  * paddybyersquit (Ping timeout: 276 seconds)
14:40:02  <isaacs>illumos is what has risen from the ashes.
14:40:22  <isaacs>smartos and omnios are illumos distros
14:40:27  <MI6>libuv-master: #107 UNSTABLE smartos (6/189) windows (4/190) http://jenkins.nodejs.org/job/libuv-master/107/
14:40:36  <bnoordhuis>apropos nothing, i was surprised to find out that many stock exchanges still run on solaris
14:40:50  <isaacs>yeah
14:41:05  <isaacs>stock exchanges need real-time zero-performance-overhead debugging
14:41:19  <isaacs>that doesn't bonk the kernel if you do the wrong thing
14:41:39  <isaacs>and they're not the kind of institutions that update their OS very regularly
14:41:47  <bnoordhuis>hm, i imagine stock exchanges are allergic to everything containing the word 'debug' :)
14:41:49  <isaacs>but i hear that some are looking at illumos
14:41:56  <bnoordhuis>hah, interesting
14:42:14  <isaacs>bnoordhuis: well, dtrace is basically a tool made specifically for their kind of use cases.
14:42:49  <MI6>libuv-master-gyp: #45 UNSTABLE smartos-x64 (2/189) smartos-ia32 (2/189) linux-x64 (1/189) windows-ia32 (4/190) windows-x64 (4/190) http://jenkins.nodejs.org/job/libuv-master-gyp/45/
14:42:58  <isaacs>it's kind of ironic that linux "won the cloud" like they have, since sunos really is designed from the ground up for high performance uses. it's an indictment of horrible sun/oracle managemetn, imo
14:42:59  <bnoordhuis>oh sure. but i doubt a stock exchange would be happy if it got as far as needing to debug a production site
14:43:30  <isaacs>they tend to not tolerate even modest latency
14:43:55  <isaacs>fort that, you need tools to detect and debug latency without introducing latency when you're not using them
14:45:22  <bnoordhuis>hm, i suppose so
14:45:50  <bnoordhuis>we used to have a lot of sun gear at my previous*3 job
14:46:12  <bnoordhuis>but it was a dog for a lot of things
14:46:20  <MI6>libuv-node-integration: #89 UNSTABLE linux-ia32 (3/604) osx-x64 (2/604) linux-x64 (1/604) smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (8/604) http://jenkins.nodejs.org/job/libuv-node-integration/89/
14:46:49  <bnoordhuis>only on really high-end hardware for really high-throughput don't-care-about-latency kind of tasks did it beat out linux
14:47:32  <bnoordhuis>i think it were sun niagara machines, at $20-40k per machine
14:48:18  <bnoordhuis>which easily got clobbered for most workloads by linux running on stock $8k dell machines
14:48:53  <bnoordhuis>that was when i realized this linux thing might not be all hype :)
14:48:55  * AvianFluquit (Ping timeout: 276 seconds)
14:51:58  * c4milojoined
14:59:28  * bajtosquit (Quit: bajtos)
15:00:48  <isaacs>heh
15:00:57  <isaacs>well, that's more about x86 vs sparc, i'd think
15:01:11  <isaacs>i mean, intel won.
15:01:44  <isaacs>sun just didn't recognize this soon enough, and did not have a clear vision as a company.
15:02:36  <MI6>libuv-node-integration: #90 UNSTABLE linux-ia32 (1/604) osx-x64 (2/604) linux-x64 (1/604) smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (7/604) http://jenkins.nodejs.org/job/libuv-node-integration/90/
15:03:23  <isaacs>this infographic is cool. it should mention LOC in npm as well, though.
15:03:42  <isaacs>since bugfixes there affect the node user experience pretty significantly.
15:10:44  * `3rdEdenquit (Quit: KTNXBAI)
15:11:08  <linus>bnoordhuis: Awesome! :D
15:13:01  <linus> bnoordhuis: Noted the gyp changes, fair point there. :)
15:13:41  * TooTallNatejoined
15:18:35  <linus>bnoordhuis: Noted one thing I didn't realize before, it might've been better to use __ANDROID__ rather than ANDROID as a define, apparently it's set in newer NDK versions...
15:19:59  <bnoordhuis>linus: oh, okay. we take pull requests :)
15:20:24  * bajtosjoined
15:20:56  <linus>Haha, fair enough. I'll pull and update. :)
15:29:06  * pachetquit (Write error: Broken pipe)
15:29:52  * pachetjoined
15:29:52  * pachetquit (Changing host)
15:29:52  * pachetjoined
15:29:56  * TooTallNatequit (Quit: Computer has gone to sleep.)
15:30:59  * dominictarrjoined
15:36:07  <trevnorris>bnoordhuis: more I think about it not sure I'm a fan of the .fill() return this. it's the only method that does, and feels kinda awkward.
15:36:35  <isaacs>bnoordhuis: yeah, i agree.
15:36:39  <isaacs>tjfontaine: ^
15:36:52  <isaacs>i'm thinking about how we could make it less awkward by moving forward, rather than back, though
15:36:56  <isaacs>what other Buffer methods could return this?
15:37:11  <tjfontaine>none, because they should return offsets
15:37:17  <isaacs>it IS rather nice to do `var b = new Buffer(100).fill('x')
15:37:37  <isaacs>yeah, and i guess toString(enc) returns a string
15:37:47  <isaacs>and slice() returns a new buffer..
15:37:50  <isaacs>i dunno, i'm torn
15:38:24  <trevnorris>and I've already agreed to implementing 3597 after buffer pr lands
15:38:41  <tjfontaine>knowing where to write next it's nice for it to return the new offset, if they want chanining they could use my buffercursor which moves the location in place
15:39:13  <tjfontaine>hmm saying that I'm not sure it returns this for write's
15:39:22  <tjfontaine>anyway, you can't chain read's so meh
15:40:14  <trevnorris>first one to lgtm this gets a purple unicorn :) 5600
15:45:03  <bnoordhuis>trevnorris: re buf.fill returning this, *shrug*
15:45:21  <bnoordhuis>i don't really care
15:45:45  <tjfontaine>I don't think any of us do :)
15:46:26  <trevnorris>yeah. and the pr didn't contain any docs changes or tests so i'm not feeling to beholden to it. :)
15:50:57  <isaacs>trevnorris: so, what's the point of the spinner then?
15:51:02  <isaacs>trevnorris: when does the tickspinner get used?
15:52:26  <trevnorris>isaacs: every time the nextTickQueue either empties out or errors
15:52:44  <trevnorris>isaacs: it's to kick back uv_idle and continue through the loop
15:53:13  <trevnorris>isaacs: had this conversation w/ bnoordhuis yesterday. he pointed out if we don't start/stop uv_idle node will constantly use 100% cpu
15:53:34  <isaacs>ok
15:54:02  <isaacs>so, if there's a throw, which is then handled so that the proc doesn't close, we kick the spinner and come back?
15:54:02  <bnoordhuis>trevnorris: that's not quite what i said :)
15:54:20  <bnoordhuis>if you don't _stop_ the idle spinner, then node will start consuming 100% cpu
15:54:51  * dapjoined
15:54:52  <trevnorris>yeah. so the spinner starts it, then it's stopped once we enter the callback queue
15:54:58  <bnoordhuis>you don't really need idle handles anyway
15:55:15  <bnoordhuis>you can easily emulate their behavior by calling uv_run() in a loop with either UV_RUN_ONCE or UV_RUN_NOWAIT
15:55:46  <trevnorris>so that way we could drop the spinner all together?
15:56:06  <bnoordhuis>yeah. not that idle handles are expensive. just thinking out aloud :)
15:57:05  <isaacs>bnoordhuis: well, not expensive in a memory/CPU sense, but expensive in the "more code to look at" sense :)
15:57:05  <trevnorris>it's mainly to address isaacs desire to drop the spinner. i'm not familiar enough w/ the pros/cons to care.
15:57:11  <trevnorris>heh
15:57:25  <isaacs>never discount the brain-cost :)
15:58:17  <bnoordhuis>just so we're on the same page, all an idle handle does is to stop libuv from blocking in epoll_wait() / kevent() / etc.
15:58:36  * dap1joined
15:58:50  <bnoordhuis>if you have > 0 idle handles active, libuv does epoll_wait(0) rather than epoll_wait(some_timeout)
15:59:22  * dapquit (Ping timeout: 256 seconds)
15:59:45  <trevnorris>hm. this sounds similar to the whole beforeExit emitter thing
16:00:12  <bnoordhuis>well, it's only tangentially related
16:00:51  <bnoordhuis>basically, you can emulate an idle handle by changing the run mode from UV_RUN_ONCE to UV_RUN_NOWAIT at the next call to uv_run()
16:01:12  * tjfontaineheads to office
16:01:15  * papertigersjoined
16:01:18  <trevnorris>but right now uv_run() is only called once
16:01:26  <trevnorris>so we'd have to setup a loop around it, right?
16:01:27  <papertigers>bnoordhuis: hey are you around?
16:01:46  <trevnorris>isaacs: took care of the horrible camel case ;-)
16:01:46  <bnoordhuis>trevnorris: yes. pretty trivial change though
16:01:58  <bnoordhuis>papertigers: would you believe me if i said 'no'?
16:02:05  <papertigers>bnoordhuis: yes ;) you're a bot!
16:02:17  <bnoordhuis>papertigers: DOES NOT COMPUTE. REDO FROM START?
16:02:19  <papertigers>bnoordhuis: https://github.com/joyent/node/issues/5443 <- I think we are hitting something like this, did you ever see a fix
16:02:21  <bnoordhuis>but yes, i'm here
16:02:29  <bnoordhuis>LOUDBOT apparently isn't...
16:02:54  <isaacs>LOUDBOT: yo
16:02:55  <LOUDBOT>isaacs: WATCHING TV IS LIKE A DIRECT SHIT-TO-BRAIN INTERFACE
16:03:12  <isaacs>BNOORDHUIS: LOUDS MUST BE ENTIRELY LOUD
16:03:13  <LOUDBOT>+USE IT THE SAME WAY YOU USE NUMBERS.
16:03:13  <bnoordhuis>papertigers: ah, that. no. i've never been able to reproduce it either
16:03:19  <bnoordhuis>haha
16:03:31  <isaacs>bnoordhuis: THIS IS NOT LOUD ENOUGH!
16:03:33  <isaacs>see?
16:03:47  <trevnorris>isaacs: does the needing to pass an argument to tickDone make sense?
16:03:50  <isaacs>LOUDBOT: search bnoordhuis
16:03:51  <LOUDBOT>isaacs: <lewellyn_:##turtles> BNOORDHUIS SHOULD SHUT THE FUCK UP
16:03:56  <isaacs>LOUDBOT: twitlast
16:03:57  <LOUDBOT>http://twitter.com/LOUDBOT/status/340136505500639232 (lewellyn_/##turtles)
16:04:01  <bnoordhuis>aww
16:04:14  <trevnorris>LOUDBOT: search trevnorris
16:04:15  <LOUDBOT>ALL THE RED BLINKING LIGHTS! THEY'RE CONSPIRING TO DRIVE ME INSANE!
16:04:29  <isaacs>bnoordhuis: did you upset lewellyn?
16:04:50  <bnoordhuis>isaacs: i don't even know who he/she/it is :)
16:05:05  <papertigers>bnoordhuis: we were definitely seeing 100% cpu usage and processes not responding. Using -nouse_idle_notification has helped but it seems like gc is still biting. I have a fancy flame graph if you wanna see it
16:05:20  <isaacs>bnoordhuis: wow, i guess someone in ##turtles is suggesting you not talk so much
16:06:43  <bnoordhuis>papertigers: i like fancy flame graphs
16:08:03  <bnoordhuis>isaacs: i was probably overloading LOUDBOT with choice quotes
16:08:09  <isaacs>bnoordhuis: haha
16:08:10  <isaacs>maybe
16:08:18  <isaacs>LOUDBOT: search isaacs
16:08:18  <LOUDBOT>isaacs: <jesusabdullah:#stackvm> IT ENDS WITH A STANDARD LIBRARY ISAACS
16:08:25  <isaacs>LOUDBOT: twitlast
16:08:25  <LOUDBOT>http://twitter.com/LOUDBOT/status/340137631339913217 (jesusabdullah/#stackvm)
16:09:54  <papertigers>ill post it here incase anyone else wants to look, http://zeller.voxer.com:8000/ but you can see the huge tower with the bright yellow hue, its all gc related
16:11:29  * pachetquit (Quit: leaving)
16:11:32  * defunctzombie_zzchanged nick to defunctzombie
16:18:02  * TooTallNatejoined
16:19:34  * loladiro_joined
16:20:04  <indutny>LOUDBOT: search indutny
16:20:05  <LOUDBOT>OH GOD IM IN A MALL THIS IS SO WEIRD I NEED O STAND HERE AND GAWK
16:20:12  <indutny>LOUDBOT: search isaacs
16:20:13  <LOUDBOT>indutny: <jesusabdullah:#stackvm> IT ENDS WITH A STANDARD LIBRARY ISAACS
16:20:33  <indutny>LOUDBOT: search money
16:20:33  <LOUDBOT>indutny: <yabanize:#dhpos> K.. IS THERE A WAY TO STOP TAX TOTAL PRINTING ON RECIEPTS (WE DONT HAVE TO HAVE TAX BECAUSE WE DONT MAKE ENOUGH MONEY)
16:20:54  <indutny>LOUDBOT: search truth
16:20:55  <LOUDBOT>indutny: <spiffytech:#ncsulug> YOU ALL NEED TO OPEN YOURSELVES UP TO THE TRUTH THAT THE N64 IS THE ONE TRUE CONSOLE
16:21:02  <indutny>LOUDBOT: search lies
16:21:02  <LOUDBOT>indutny: <jesusabdullah:#stackvm> IN MY CASE I AM DRINKING BOURBON SO I BELIEVE THE E APPLIES
16:21:42  <isaacs>LOUDBOT: next
16:21:42  <LOUDBOT>isaacs: <HighBit:##church-of-loudbot> ACHIEVEMENT UNLOCKED: TRUE LIES
16:21:45  <isaacs>LOUDBOT: next
16:21:45  <LOUDBOT>isaacs: <HighBit:##church-of-loudbot> TWO MORE HOMES BURGLED WHILE FAMILIES SLEPT
16:21:48  <isaacs>LOUDBOT: next
16:21:48  <LOUDBOT>isaacs: <YTZ:##church-of-loudbot> IF I WAS HARRY TASKER IN THE MOVIE TRUE LIES I WOULD HAVE DROPPED ELIZA DUSHKU'S ASS OFFA THAT PLANE.
16:22:31  * loladiroquit (Ping timeout: 276 seconds)
16:22:31  * loladiro_changed nick to loladiro
16:24:24  <trevnorris>isaacs: if you're only qualm w/ 5600 is that I dropped domain:null i'll throw that back in.
16:24:49  <isaacs>trevnorris: well, my other question was just trying to understand why we still have the spinner.
16:24:53  <isaacs>trevnorris: but tha'ts not a big deal.
16:25:10  <isaacs>trevnorris: but yes, put domain:null back in, and the nit about tickDepth_ arg being unnecessary
16:25:31  <trevnorris>isaacs: tickDepth_ is needed
16:25:37  <isaacs>what for?
16:25:45  <isaacs>i though you removed all the references to it?
16:25:59  <trevnorris>if a domain callback throws then we'll need to pick back up from the last callback
16:26:15  <trevnorris>that's why we pass infoBox[index] in the finally{}
16:26:22  <isaacs>wait...
16:26:25  <isaacs>then it's not tickDepth, is it?
16:26:28  <isaacs>it's tickIndex
16:26:32  <isaacs>that's not the same thing
16:26:45  <trevnorris>technically they serve the same purpose
16:27:06  <trevnorris>see, before each depth would clear out up to its queue
16:27:39  <trevnorris>so the size of the depth was also the index placement of where to pick back up
16:28:09  <trevnorris>without it domain tests don't pass
16:29:20  <isaacs>trevnorris: but you've removed the only line in tickDone where that arg is used
16:29:28  <isaacs> infoBox[depth] = tickDepth_;
16:29:49  <isaacs>trevnorris: so... what magic is this? how can that arg be relevant if it's not used?
16:29:52  <isaacs>;)
16:30:00  <trevnorris>the arg is used.
16:30:08  <trevnorris>one sec
16:30:17  <isaacs>where?
16:30:54  <trevnorris>so "depth" is no longer used. I just didn't bother to change the name of the argument variable in tickDone
16:31:09  <trevnorris>oh hell
16:31:14  <trevnorris>nm. I see what you're saying.
16:31:15  <isaacs>trevnorris: right, but "tickDepth_" isn't used in that function any more at all
16:31:25  <trevnorris>:-/
16:31:46  <isaacs>so... if you are intending to do somethign with the length to preserve it somehow in the call to tickDone, then there's a problem.
16:31:49  <isaacs>because tha'ts not happening
16:32:37  <isaacs>the infobox[index] is getting updated as you move forward, and only reset to 0 when we finish
16:33:07  <trevnorris>no. this is what happens writing a patch at 3am. I'm using index itself directly in tickDone so there's no need to pass it in.
16:33:15  <isaacs>right
16:33:26  <trevnorris>ok, fixed
16:33:30  <trevnorris>pushed
16:33:40  <isaacs>the only reason to pass depth around is that we had to know when to reset it manually.
16:33:48  <isaacs>but that doesn't exist any more.
16:34:00  <bnoordhuis>http://nodejsreactions.tumblr.com/post/51550909419/waiting-for-tj-to-deal-with-a-pull-request
16:34:37  * paddybyersjoined
16:34:41  <trevnorris>isaacs: yeah. didn't realize that I had pulled all uses of tickDepth_ in favor of checking infoBox[] directly.
16:34:43  <isaacs>bnoordhuis: i'm pretty sure that's tjholowaychuk, not our tj
16:34:56  <isaacs>trevnorris: kewl. the system is working :)
16:35:03  <bnoordhuis>isaacs: in that case: http://nodejsreactions.tumblr.com/post/51550344296/trying-to-pin-down-isaacs-coding-style
16:35:41  * saghulquit (Ping timeout: 252 seconds)
16:35:50  <trevnorris>isaacs: cool. so you good w/ it?
16:36:31  <isaacs>trevnorris: re-reviewing
16:36:36  <isaacs>bnoordhuis: ye, that's about me
16:36:45  <isaacs>bnoordhuis: it's pantsless. works on a lot of levels.
16:37:02  * saghuljoined
16:37:10  <trevnorris>bnoordhuis: ok, so uv_run goes in a while() loop. what's the check going to look like?
16:39:50  <bnoordhuis>trevnorris: what check?
16:40:41  <trevnorris>bnoordhuis: you mentioned to change UV_RUN_ONCE to UV_RUN_NOWAIT on the next loop. so I assume that means uv_run needs to be in a while loop or some such, right?
16:42:24  * CoverSlidejoined
16:43:40  * saghulquit (Ping timeout: 252 seconds)
16:43:54  * brsonjoined
16:46:07  <bnoordhuis>trevnorris: right. you'd have a uv_run_mode run_mode global that defaults to UV_RUN_ONCE
16:46:24  * saghuljoined
16:46:50  <bnoordhuis>where you'd normally start the idle handle, you'd set run_mode=UV_RUN_NOWAIT instead
16:47:52  <isaacs>trevnorris: hm... getting this failure: https://gist.github.com/isaacs/5679363
16:48:11  <trevnorris>isaacs: that's been failing for a day now.
16:48:37  <isaacs>trevnorris: indeed.
16:49:40  <isaacs>hmm... pases on 0.10, though
16:49:42  <isaacs>indutny: ping
16:49:47  <indutny>pong?
16:49:56  <indutny>I'm here, minon
16:49:57  <trevnorris>isaacs: 5601
16:50:00  <indutny>s/minon/minion/
16:50:16  <trevnorris>wait. nm
16:50:25  <isaacs>indutny: oh, i see... this was fixed in 0.10, but hte fix hasn't made it to master, yet
16:50:31  <indutny>yes
16:50:38  <indutny>another merge is required
16:50:39  <indutny>also
16:50:48  <indutny>after merge some logging in tls.js was overwritten
16:50:51  <indutny>like
16:50:51  <indutny>from:
16:50:57  <indutny>debug('my stuff %d', written)
16:50:57  <indutny>to:
16:51:01  <indutny>debu('my stuff ' + written)
16:51:05  * inolenquit (Quit: Leaving.)
16:51:06  <isaacs>indutny: right
16:51:10  <indutny>if you'll merge it again - please fix it
16:51:10  <isaacs>indutny: whatever.
16:51:17  <isaacs>indutny: sure, i'll do that
16:51:24  <isaacs>indutny: so, tls in 0.10. looks good to release?
16:51:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:51:32  <indutny>yes
16:51:36  <indutny>very good :)
16:51:36  <isaacs>awesome.
16:51:38  <isaacs>starting the release.
16:51:44  <indutny>lets just wait for bugs :P
16:51:45  <indutny>whatever
16:51:56  <isaacs>well, once i finish this npm patch :)
16:52:37  * qardjoined
16:53:55  * bnoordhuisquit (Ping timeout: 264 seconds)
16:55:03  * paddybyersquit (Ping timeout: 260 seconds)
16:55:50  <isaacs>man, the npm tests are so heinous
16:55:58  <isaacs>i need to replace them entirely.
16:56:54  <trevnorris>isaacs: 5600 good?
16:57:16  <isaacs>5600 lgtm
16:57:24  <trevnorris>sweet. thx
16:58:09  <isaacs>WHERES MY PURPLE UNICORN?
16:58:09  <LOUDBOT>WELL LOOKIE WHAT WE GOT HERE BROTHER OF MINE IT'S THE SAME IN EVERY TOWN
16:58:30  <MI6>joyent/node: Trevor Norris master * 9a6c085 : process: remove max tick check for domains (+2 more commits) - http://git.io/4TNH3g
17:00:25  <trevnorris>isaacs: will one of these do? http://amzn.to/140WYxF
17:01:02  * isaacsis satisfied
17:04:42  <trevnorris>isaacs: i'll throw in one of these when 4964 is done ;-) http://amzn.to/15lXvJN
17:05:49  * paddybyersjoined
17:06:17  <isaacs>trevnorris: 4964 is buffers?
17:06:23  <trevnorris>yeah
17:06:38  <isaacs>cool
17:06:41  <isaacs>that's the next thing on my list.
17:06:45  <isaacs>after 0.10.9
17:06:54  <trevnorris>coolio. :)
17:07:48  <trevnorris>isaacs: but you're right. we're probably going to need a blog post or wiki page dedicated to upgrading native modules from v0.10 to v0.12
17:08:19  <isaacs>trevnorris: yeah, it's gonna suck
17:10:19  <linus>Given a couple more fixes on android, I managed to get libuv building standalone as well, including tests: [% 100| +179|- 10|T 0| S 0]
17:11:32  <linus>Some errors are in disabled components, and some are - I believe - related to strange permission settings and missing capabilities in android
17:12:48  <linus>platform_output, pipe_connect_to_file, tty, tcp_close_while_connecting, process_title, getaddrinfo_fail, fs_chown, fs_event_watch_file_twice, fs_readdir_file, dlerror <= Failed tests
17:13:16  <MI6>nodejs-master: #244 UNSTABLE smartos-x64 (12/602) linux-ia32 (1/602) smartos-ia32 (7/602) osx-x64 (1/602) osx-ia32 (2/602) linux-x64 (1/602) http://jenkins.nodejs.org/job/nodejs-master/244/
17:14:19  <linus>I'll do some more cleanup and submit an updated PR tomorrow, hopefully
17:16:34  * sblomjoined
17:18:36  * csaohquit (Quit: csaoh)
17:19:58  <MI6>joyent/node: isaacs v0.10 * c86afa5 : npm: Upgrade to 1.2.24 - http://git.io/yBlybw
17:22:07  <MI6>nodejs-master-windows: #52 UNSTABLE windows-ia32 (16/602) windows-x64 (21/602) http://jenkins.nodejs.org/job/nodejs-master-windows/52/
17:24:49  * paddybyersquit (Ping timeout: 248 seconds)
17:25:19  * amartensjoined
17:26:25  * c4miloquit (Remote host closed the connection)
17:31:19  <MI6>joyent/node: isaacs created branch v0.10.9-release - http://git.io/IUEgeQ
17:35:49  * loladiro_joined
17:36:07  * loladiroquit (Ping timeout: 260 seconds)
17:36:08  * loladiro_changed nick to loladiro
17:36:28  * inolenjoined
17:37:40  <MI6>nodejs-v0.10: #223 UNSTABLE smartos-ia32 (1/588) smartos-x64 (3/588) osx-ia32 (1/588) http://jenkins.nodejs.org/job/nodejs-v0.10/223/
17:41:25  * sblomquit (Ping timeout: 252 seconds)
17:41:39  * brsonquit (Quit: leaving)
17:41:54  * brsonjoined
17:42:07  * sblomjoined
17:43:05  <MI6>nodejs-v0.10-windows: #52 UNSTABLE windows-x64 (8/588) windows-ia32 (7/588) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/52/
17:52:15  <tjfontaine>RIP GITHUB
17:52:15  <LOUDBOT>YES IT'S ABOUT PEOPLE WHO USE 'U' GETTING HANGED
17:52:24  <isaacs>huh?
17:52:31  <tjfontaine>they had an outage blip
17:52:39  <tjfontaine>10mins ago
17:52:44  <tjfontaine>https://status.github.com/messages
17:52:47  <linus>Feeling it. :(
17:53:03  <tjfontaine>oh right, linus, email I need to reply to
17:53:16  <linus>Ah, yes. :)
17:53:47  * c4milojoined
17:54:03  <tjfontaine>there short and sweet :)
17:54:39  * sblomquit (Ping timeout: 245 seconds)
17:55:37  * sblomjoined
17:55:48  <tjfontaine>looks like github flubbed their routes, or similar
17:56:30  <isaacs>osx and windows take for so long to build binaries
17:56:49  <tjfontaine>all that's really missing from having jenkins do it is the signing piece
17:57:09  <tjfontaine>not really sure what we want to do for those scenarios
17:57:22  <tjfontaine>I wish we could just sign the results
17:58:11  <isaacs>tjfontaine: for the mac app signing, it's not hard at all.
17:58:15  <linus>Ach, now I'm stuck here at 8PM again
17:58:24  <isaacs>tjfontaine: but the windows thing is a litlte trickier, i think
17:58:29  <isaacs>i don't really remember how we did it
17:58:41  <isaacs>you open some web page in MSIE and it hacks yoru registry or something
17:58:44  <tjfontaine>isaacs: even better the builds are happening on my macmini at home, so I'm ok with making that work there
17:58:52  <isaacs>haha, nice
17:59:10  <tjfontaine>signing from a windows machine in the cloud is slightly more worriesome
17:59:14  <linus>Giving up for tonight, will send an additional PR for libuv tomorrow to ensure a standalone build is possible
17:59:22  <isaacs>tjfontaine: i'll sneakernet you the key this afternoon
17:59:32  <tjfontaine>isaacs: ok
18:00:17  * bnoordhuisjoined
18:00:21  * sblomquit (Ping timeout: 256 seconds)
18:00:43  * sblomjoined
18:04:49  * bnoordhuisquit (Ping timeout: 248 seconds)
18:05:28  * sblomquit (Ping timeout: 256 seconds)
18:05:58  * sblomjoined
18:10:50  * mikealjoined
18:12:38  * pachetjoined
18:13:01  <MI6>joyent/node: isaacs created tag v0.10.9 - http://git.io/uaT0XQ
18:17:32  * brsonquit (Quit: leaving)
18:23:07  <isaacs>uhoh...
18:23:12  <isaacs>indutny: simple/test-tls-hello-parser-failure is timing out on smartos
18:23:41  <tjfontaine>hrm
18:24:41  <tjfontaine>dear jenkins I hate you
18:26:06  <tjfontaine>also I'm about hitting about 50% on if github will respond to my git operations
18:28:17  <MI6>joyent/node: isaacs v0.10 * ce54f4a : Now working on v0.10.10 (+2 more commits) - http://git.io/Z5nAUg
18:28:32  <isaacs>indutny: it's not a huge problem, i think, but the client never gets an error event after sending bonkers
18:39:24  <tjfontaine>LOUDBOT: DAP WANTS YOU TO RESPOND NOW
18:39:25  <LOUDBOT>tjfontaine: IT'S LIKE PEOPLE HAVE SOCIAL LIVES OR SOMETHING
18:40:20  * mikealquit (Quit: Leaving.)
18:41:37  * mikealjoined
18:59:20  * bnoordhuisjoined
19:02:28  * c4miloquit (Remote host closed the connection)
19:11:31  * hudgfactorquit (Ping timeout: 276 seconds)
19:22:45  * sblomquit (Ping timeout: 248 seconds)
19:27:49  * c4milojoined
19:32:21  * bajtosquit (Quit: bajtos)
19:39:27  * `3rdEdenjoined
19:48:24  <indutny>isaacs: hm… that's odd
19:48:40  <trevnorris>bnoordhuis: hm. just upgraded to clang 3.3 and still seems to be writing out a signaling nan
19:48:52  <isaacs>indutny: i haven't dug into it too closely
19:49:00  <isaacs>indutny: but i suspect it's a result of the finish/end/etc stuff?
19:49:06  <indutny>well...
19:49:08  <indutny>yeah
19:49:16  <indutny>odd that it isn't happening anywhere else
19:49:19  <isaacs>yeah
19:49:38  <isaacs>if you ssh root@smartos.nodejs.org you can test on there
19:51:24  <indutny>ok
20:07:26  * brsonjoined
20:10:40  * bnoordhuisquit (Ping timeout: 276 seconds)
20:11:33  * bnoordhuisjoined
20:18:46  * dominictarrquit (Quit: dominictarr)
20:25:18  * `3rdEdenquit (Remote host closed the connection)
20:35:05  <MI6>joyent/libuv: Ben Noordhuis master * 442d11d : unix: avoid extra read, short-circuit on POLLHUP - http://git.io/fPvxBw
20:35:12  <bnoordhuis>optimizing all the things
20:35:20  <tjfontaine>libuv --gofast
20:37:21  <bnoordhuis>libuv --speed=<x>
20:37:25  <bnoordhuis>where x goes to eleven
20:37:47  <bnoordhuis>are there patches i need to review? bugs i need to look at?
20:40:01  <tjfontaine>if you wan to look at #4964
20:40:04  <tjfontaine>*want
20:40:41  <MI6>libuv-master: #108 UNSTABLE smartos (2/189) windows (3/190) http://jenkins.nodejs.org/job/libuv-master/108/
20:40:47  * paddybyersjoined
20:41:05  <MI6>libuv-master-gyp: #46 UNSTABLE smartos-x64 (2/189) smartos-ia32 (2/189) windows-ia32 (4/190) windows-x64 (4/190) http://jenkins.nodejs.org/job/libuv-master-gyp/46/
20:43:39  * defunctzombiechanged nick to defunctzombie_zz
20:44:11  <bnoordhuis>ah, there's always #4964...
20:44:42  <tjfontaine>have to look at it sometime, otherwise trevor may show up with an automatic weapon and go after us all :)
20:46:01  * TooTallNatejoined
20:46:13  <bnoordhuis>fortunately he's on your side of the big pond, not mine :)
20:46:30  <tjfontaine>heh
20:55:01  <MI6>joyent/libuv: Bert Belder v0.10 * b9eb402 : include: remove lame comment from uv.h - http://git.io/LuLQjw
20:55:30  <bnoordhuis>haha
20:56:03  <bnoordhuis>piscisaureus_: the first three characters of the git.io path describe my thoughts exactly
20:56:56  <piscisaureus_>:-p
20:57:09  <piscisaureus_>it was not easy to find the right moment
20:57:24  <MI6>libuv-v0.10: #88 UNSTABLE smartos (2/186) windows (3/187) http://jenkins.nodejs.org/job/libuv-v0.10/88/
20:58:15  <piscisaureus_>I wonder if these services have a blacklist of some sorts
20:58:27  <piscisaureus_>I can come up with quite a few offensive 6-letter combinations
20:58:34  <bnoordhuis>that'd be a shame
20:58:58  <MI6>libuv-node-integration: #91 UNSTABLE linux-ia32 (1/602) osx-x64 (2/602) linux-x64 (1/602) smartos-ia32 (2/602) osx-ia32 (3/602) smartos-x64 (5/602) http://jenkins.nodejs.org/job/libuv-node-integration/91/
21:01:00  <MI6>libuv-v0.10-gyp: #50 UNSTABLE smartos-x64 (2/186) smartos-ia32 (2/186) windows-x64 (4/187) windows-ia32 (4/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/50/
21:01:02  * amartensquit (Read error: Connection reset by peer)
21:01:16  * amartensjoined
21:06:00  * c4miloquit (Remote host closed the connection)
21:10:46  * stolsma2quit (Ping timeout: 256 seconds)
21:10:55  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:14:42  * mikealquit (Quit: Leaving.)
21:14:44  * c4milojoined
21:16:31  <MI6>libuv-node-integration: #92 UNSTABLE linux-ia32 (1/588) osx-x64 (1/588) smartos-ia32 (1/588) osx-ia32 (1/588) smartos-x64 (2/588) http://jenkins.nodejs.org/job/libuv-node-integration/92/
21:19:22  * TooTallNatejoined
21:19:56  <isaacs>TooTallNate: what do you think about this? https://github.com/joyent/node/pull/5602
21:21:28  <bnoordhuis>piscisaureus_: how do i amend/superseed a patchset i uploaded to codereview?
21:22:17  <tjfontaine>does it work like gerrit where your initial push creates a branch you're supposed to work off of?
21:23:23  * mikealjoined
21:23:31  <bnoordhuis>hm, not sure but it doesn't look like it
21:32:23  * loladiro_joined
21:34:25  * loladiroquit (Ping timeout: 248 seconds)
21:34:25  * loladiro_changed nick to loladiro
21:36:16  * paddybyersquit (Ping timeout: 252 seconds)
21:38:04  * dominictarrjoined
21:40:49  * pachetquit (Quit: leaving)
21:44:01  <bnoordhuis>ah... --issue <id>
21:46:34  <trevnorris>bnoordhuis, isaacs: strange. so all I did was rip out the spinner and now only two tests are failing. PR 5605
21:46:39  <trevnorris>didn't expect that.
21:47:27  <trevnorris>is that just some kind of fluke?
21:50:19  * c4miloquit (Remote host closed the connection)
21:54:40  <piscisaureus_>bnoordhuis: yes, --issue. Also it is stored in your .git/config file I believe.
21:54:49  <trevnorris>isaacs: ok, nm. i've removed the spinner and got all the tests to pass.
21:55:21  <trevnorris>isaacs: that was strangely easy, and honestly not sure how I feel about it.
21:55:50  * piscisaureus_quit (Read error: Connection reset by peer)
21:56:20  <isaacs>trevnorris: lol
21:56:41  <isaacs>trevnorris: what happens when you throw in the middle of a nextTick? do the subsequent nextTick's get called?
21:57:26  <trevnorris>isaacs: yeah. I substituted that one necessary use with setImmedate and it continues calling the nextTicks on the next loop.,
21:57:39  <isaacs>trevnorris: fantastic
22:02:01  <trevnorris>ok. it's working every which way I can figure out how to poke it.
22:02:10  <kellabyte>what libuv branch should I get for a stable dependency?
22:02:28  <tjfontaine>v0.10
22:02:32  <tjfontaine>imo
22:02:42  <kellabyte>ok thanks :)
22:03:07  <tjfontaine>kellabyte: up to and until node v0.12 is released :)
22:03:25  <isaacs>trevnorris: setImmediate and the TickSpinner are semantically equivalent anyway, right
22:03:36  <isaacs>trevnorris: they're both idle notifier thingies
22:03:44  <isaacs>that run asap, but not until uv does a thing
22:04:13  * mikealquit (Quit: Leaving.)
22:04:53  * rendarquit
22:05:50  * mikealjoined
22:06:53  <trevnorris>isaacs: actually yes. they even both do uv_idle_start/_stop
22:07:01  <isaacs>trevnorris: ok, then
22:07:10  <isaacs>setImmediate is probably what we ought to have ben using in 0.10 already, then :)
22:07:21  * isaacsbbiab, commuting
22:07:22  * isaacs&
22:07:23  <LOUDBOT>I THINK YOU ARE BEING ROBFORMIST
22:08:31  <trevnorris>isaacs: yeah, you're right. just wasn't as apparent to me w/ the maxTickDepth stuff in the way.
22:18:28  * mikealquit (Quit: Leaving.)
22:21:47  * hzquit
22:25:07  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:31:17  * Benvie_quit (Read error: Connection reset by peer)
22:31:36  * Benvie_joined
22:33:04  * CAPSLOCKBOTquit (Ping timeout: 240 seconds)
22:34:17  * paddybyersjoined
22:34:17  * c4milojoined
22:38:44  * LOUDBOTquit (Ping timeout: 241 seconds)
22:39:31  * paddybyersquit (Ping timeout: 276 seconds)
22:43:26  * papertigersquit (Quit: papertigers)
22:46:45  * dapjoined
22:46:51  * dap1quit (Read error: Connection reset by peer)
22:48:58  <trevnorris>bnoordhuis: you prefer "delete [] data" or "delete[] data"?
22:50:05  <bnoordhuis>trevnorris: delete[] is obviously and provably superior to delete []
22:50:11  <trevnorris>ok :)
22:50:32  <trevnorris>these external string resources are fun.
22:50:39  <trevnorris>going to hack a few in and try out some benchmarks.
22:51:52  * TooTallNatejoined
22:53:01  * dominictarrquit (Quit: dominictarr)
22:55:49  * isaacsfg
22:56:34  * loladiroquit (Ping timeout: 252 seconds)
23:02:32  * piscisaureus_joined
23:02:41  * piscisaureus_quit (Client Quit)
23:03:50  * sblomjoined
23:06:44  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
23:08:41  <trevnorris>review anyone :) 5605
23:11:02  <isaacs>trevnorris: you should throw function Tock(cb) in there, as well
23:11:47  <trevnorris>isaacs: sorry, not following
23:12:24  <isaacs>trevnorris: instead of var obj = { callback: callback, domain: null };
23:12:45  <isaacs>trevnorris: instead of var obj = new Tock(callback, null)
23:12:50  <isaacs>er, the second one :)
23:13:02  <isaacs>function Tock(callback, domain) { this.callback = callback; this.domain = domain; }
23:13:18  <isaacs>trevnorris: but yeah, this lgtm
23:13:27  <isaacs>not tested, but you said that yo'uve been banging on it thoroughly
23:14:44  <trevnorris>isaacs: just want to make sure I understand. you think we should replace "var obj = {...};" with "var obj = new Tock(...);"?
23:17:24  <isaacs>trevnorris: yah
23:17:30  <trevnorris>isaacs: why's that?
23:17:42  <isaacs>trevnorris: because V8 <3s constructed objects.
23:17:54  <trevnorris>eh, ok. :)
23:18:16  <isaacs>trevnorris: probably not even a full 1% perf increase, but every little bit helps.
23:18:19  <isaacs>and it's a trivial addition
23:18:29  <isaacs>trevnorris: what's smalloc, exactly? your invention or some other thing?
23:19:18  <trevnorris>isaacs: yeah. forget exactly, but was supposed to mean like simple/small/stupid memory allocator
23:19:26  <sblom>Thoughts on whether https://github.com/joyent/node/issues/5595 is good because it makes Windows work like Posix does today?
23:19:29  <sblom>or bad because it takes a step away from the as-yet-unrealized 0.5 decision to make stdio async for pipes on all platforms?
23:19:45  <trevnorris>basically it's supposed to be the central point of all memory allocation for js objects.
23:20:37  <trevnorris>isaacs: fyi, i'm working on hacking in external memory strings.
23:21:23  <trevnorris>want to see if we can propagate the encoding all the way down to OnRead for streams and convert it immediately to what it'll need to be.
23:22:43  * inolenquit (Quit: Leaving.)
23:23:30  <trevnorris>bnoordhuis: did you say the current posix implementation for stdio pipes is here to stay?
23:24:24  <sblom>trevnorris, bnoordhuis: That'd make this question easy to settle. :)
23:24:34  <tjfontaine>I thought we weren't sync for stdio pipes
23:24:40  <bnoordhuis>trevnorris: i never commit to anything, just ask my girlfriend
23:24:45  <trevnorris>lol
23:25:07  <bnoordhuis>but yeah, there's no reason to change the unix implementation
23:29:02  <bnoordhuis>funny, when you call a %InternalFunction() with the wrong argument count from its builtin js code, v8 throws a runtime compilation error
23:29:05  <bnoordhuis>Extension or internal compilation error in native dataview.js at line 87.
23:29:11  <bnoordhuis>i wonder how it figures that out
23:29:48  <sblom>tjfontaine: We're definietly async for stdio pipes on Windows, but my understanding (probably time to read the code) is that this diverges from our *nix implementation.
23:30:07  <sblom>It's possible that the difference isn't sync/async, but instead some other delivery guarantee.
23:30:36  <sblom>Users are mostly complaining that they lose some log lines on stdout on windows if their process dies.
23:30:45  <sblom>I'll take a look at the posix code to see if I can tell.
23:33:40  * timoxleyjoined
23:33:53  <bnoordhuis>sblom: on unix, if stdout/err is a pipe, it's async/non-blocking
23:34:27  * timoxleyquit (Client Quit)
23:34:32  * inolenjoined
23:34:34  <bnoordhuis>else people would fill up the pipe in no time and block for an indefinite period of time
23:35:01  <bnoordhuis>until the other end consumes the data
23:35:07  <sblom>bnoordhuis: Got it.
23:35:50  <sblom>So aside from the universal confusion over stdio being async sometimes and sync sometimes, what our Windows users are complaining about is just the data loss.
23:37:20  <sblom>bnoordhuis: What does the buffering on unix if the write is submitted asyncronously and the pipe is full?
23:40:21  <isaacs>bnoordhuis: not only how it figures it out, but how do we get that for node code?
23:40:30  <isaacs>bnoordhuis: i can think of some cases where that'd be pretty rad.
23:40:44  <isaacs>myFunction.mustCallWithThisManyArgs(3) or something
23:41:15  <bnoordhuis>sblom: libuv tries to write it. when it gets EAGAIN it buffers it. node knows it got buffered because stream->write_queue_size is now > 0
23:41:38  <bnoordhuis>that's handle.writeQueueSize in js land
23:42:30  <bnoordhuis>isaacs: i don't know yet but i'll figure it out :)
23:42:45  <isaacs>bnoordhuis: have you taken a look at trevnorris's smalloc stuff?
23:42:58  <bnoordhuis>i got as far as `git am` :-/
23:43:17  <bnoordhuis>then i did `git diff --stat origin/master` and recoiled in horror
23:43:24  <trevnorris>lol
23:43:59  <bnoordhuis>i'm finishing up my v8 dataview patch
23:44:24  <bnoordhuis>if i'm still in the mood for hot steamy code after that, i'll look at trevor's patches
23:44:30  <isaacs>kewl
23:44:36  <isaacs>i kinda like it. i mean, it does simplify a lot of stuff.
23:47:52  <bnoordhuis>6 files changed, 400 insertions(+), 188 deletions(-)
23:48:14  <bnoordhuis>googlers are afraid of macros. but then, that's what you get
23:48:29  <bnoordhuis>afraid of macros... where have all the Real Men gone?
23:48:57  <tjfontaine>afraid of macros because gcc (until recently) sucked at locating errors when using them :)
23:49:10  <trevnorris>isaacs: simple preliminaries. creating a string from an external is at least 2x's faster for larger strings (e.g. > 32KB)
23:49:13  <trevnorris>isaacs: https://gist.github.com/trevnorris/5682127
23:49:48  <trevnorris>i'm going to try to tie this directly into streams so setEncoding automatically does this for large messages
23:50:29  <isaacs>trevnorris: exciting!
23:51:22  <sblom>bnoordhuis: (re: EAGAIN and buffering) So it seems like the same sort of losing-log-lines on process exit is possible. I think that's what our Windows users are complaining about. Is there a difference here that I'm not spotting?
23:51:38  <trevnorris>isaacs: ok. going to add the Tock() change as another commit and throw it on master, cool?
23:55:38  <trevnorris>anyone feel free to voice any last objections to 5605
23:55:44  <bnoordhuis>sblom: maybe it's more visible on windows?
23:56:02  <bnoordhuis>i assume most unix users run linux
23:56:22  <bnoordhuis>and the default pipe buffer is pretty big on that platform, just slightly less than 64k
23:56:49  * amartensquit (Quit: Leaving.)
23:57:01  <sblom>bnoordhuis: Okay. Makes sense.
23:57:32  <MI6>joyent/node: Trevor Norris master * 4b31a2d : process: use Tock for nextTickQueue items (+2 more commits) - http://git.io/1pA1Fw
23:58:24  * stagasjoined