00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:03:28  * qardquit (Quit: Leaving.)
00:05:06  <MI6>joyent/node: Timothy J Fontaine v0.10 * 6160f9f : blog: v0.11.4 is unstable not stable - http://git.io/vg-d0g
00:06:12  <MI6>joyent/node: Timothy J Fontaine v0.10 * 875dd37 : blog: v0.11.4 is unstable not stable - http://git.io/l-3hgw
00:16:29  <MI6>nodejs-v0.10: #284 UNSTABLE linux-x64 (1/594) osx-x64 (1/594) smartos-x64 (1/594) http://jenkins.nodejs.org/job/nodejs-v0.10/284/
00:23:35  <isaacs>tjfontaine: pong
00:23:38  <isaacs>tjfontaine: re the blog?
00:23:47  <tjfontaine>aye
00:25:34  <MI6>nodejs-v0.10-windows: #112 UNSTABLE windows-x64 (8/594) windows-ia32 (9/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/112/
00:29:50  * groundwaterquit (Quit: groundwater)
00:30:08  <trevnorris>tjfontaine: well, because of the direct calls to cc for some of the write methods and since v8 is freakin slow at setting values, probably cant execute the later w/o significant performance regression. :-/
00:30:18  <trevnorris>still wonder why it's so slow to set object properties in cc
00:37:54  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:38:29  * loladirojoined
00:42:10  * mikealquit (Quit: Leaving.)
01:01:18  * TooTallNatejoined
01:07:09  * qardjoined
01:12:36  * mikealjoined
01:16:38  * mikealquit (Ping timeout: 240 seconds)
01:34:34  * karupanerurajoined
01:45:23  <tjfontaine>trevnorris: the latter of what?
01:50:48  <creationix>I see 0.11.4 has "native" typed arrays
01:51:07  <creationix>so we dumped our own implementation and used what is in V8 then?
01:51:29  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:51:43  <tjfontaine>creationix: indeed
01:51:51  <creationix>cool, did they get any faster I wonder
01:52:01  <creationix>the ones node had before seemed a lot slower than chrome on my box
01:52:12  <creationix>of course chrome and node aren't the same thing
01:52:38  * sblomquit (Ping timeout: 240 seconds)
01:54:41  * mcavagequit (Remote host closed the connection)
02:09:57  * mikealjoined
02:10:06  * mikealquit (Client Quit)
02:16:37  * wolfeidauquit (Remote host closed the connection)
02:22:58  * karupaneruraquit (Quit: ZNC - http://znc.in)
02:23:30  * karupanerurajoined
02:24:57  * jorgetessxjoined
02:26:22  * jorgetessxpart
02:28:45  * karupaneruraquit (Quit: ZNC - http://znc.in)
02:29:16  * karupanerurajoined
02:40:34  * mikealjoined
02:44:54  * mikealquit (Ping timeout: 240 seconds)
02:46:47  * dominictarrquit (Quit: dominictarr)
02:48:27  * dominictarrjoined
03:05:53  * pooyaquit (Quit: pooya)
03:07:18  * c4milojoined
03:18:52  * dominictarrquit (Quit: dominictarr)
03:19:26  * karupaneruraquit (Quit: ZNC - http://znc.in)
03:22:26  * dominictarrjoined
03:26:37  * groundwaterjoined
03:41:10  * mikealjoined
03:41:39  * groundwaterquit (Quit: groundwater)
03:45:34  * mikealquit (Ping timeout: 246 seconds)
03:56:52  * defunctzombie_zzchanged nick to defunctzombie
04:11:55  * mikealjoined
04:16:03  * mikealquit (Ping timeout: 245 seconds)
04:37:10  * wolfeidaujoined
04:38:14  * qardquit (Quit: Leaving.)
04:41:59  * wolfeidauquit (Remote host closed the connection)
04:42:32  * mikealjoined
04:46:49  * mikealquit (Ping timeout: 246 seconds)
04:51:00  * groundwaterjoined
04:52:07  * c4miloquit (Remote host closed the connection)
04:55:24  * wolfeidaujoined
04:58:04  * trevnorrisquit (Quit: IRCRelay - http://ircrelay.com)
05:00:57  * stuffnstuffjoined
05:01:04  * stuffnstuffquit (Client Quit)
05:02:49  * trevnorrisjoined
05:03:09  * trevnorrisquit (Client Quit)
05:04:33  * trevnorrisjoined
05:10:18  <trevnorris>tjfontaine: returning the buffer instance updating the internal pointer. doing that in cc is too slow.
05:12:15  * julianduquequit (Quit: leaving)
05:19:30  * defunctzombiechanged nick to defunctzombie_zz
05:21:57  * defunctzombie_zzchanged nick to defunctzombie
05:28:37  * groundwaterquit (Quit: groundwater)
05:41:30  * qardjoined
06:01:16  * mikealjoined
06:01:34  * mikealquit (Client Quit)
06:04:57  * mikealjoined
06:05:19  * mikealquit (Client Quit)
06:06:03  * mikealjoined
06:11:53  * defunctzombiechanged nick to defunctzombie_zz
06:13:50  * defunctzombie_zzchanged nick to defunctzombie
06:37:06  * mikealquit (Quit: Leaving.)
06:40:48  * qardquit (Quit: Leaving.)
06:54:08  * defunctzombiechanged nick to defunctzombie_zz
06:58:52  * wolfeidauquit (Remote host closed the connection)
07:08:45  * rendarjoined
07:18:50  * mikealjoined
07:48:38  * loladiroquit (Quit: loladiro)
08:04:01  * defunctzombie_zzchanged nick to defunctzombie
08:08:49  * wolfeidaujoined
08:13:20  * stagasjoined
08:13:48  * defunctzombiechanged nick to defunctzombie_zz
08:14:02  * hueniversequit (Read error: Connection reset by peer)
08:15:23  * hueniversejoined
09:11:37  * paddybyersjoined
09:20:43  * paddybyersquit (Ping timeout: 276 seconds)
09:26:28  * stagasquit (Ping timeout: 245 seconds)
09:35:30  * dominictarrquit (Quit: dominictarr)
09:48:26  * bnoordhuisjoined
10:14:19  * leonvvjoined
10:23:08  * bnoordhuisquit (Ping timeout: 245 seconds)
10:25:01  * leonvvquit (Remote host closed the connection)
10:33:39  * bnoordhuisjoined
10:59:33  * bnoordhuisquit (Ping timeout: 264 seconds)
10:59:55  * leonvvjoined
11:03:51  * st_lukequit (Remote host closed the connection)
11:06:12  * actjoined
11:54:58  * bnoordhuisjoined
11:58:27  * st_lukejoined
12:03:58  * hzjoined
12:04:17  * hzquit (Client Quit)
12:09:06  * leonvvquit (Remote host closed the connection)
12:14:27  <MI6>joyent/node: Ben Noordhuis master * 2c47030 : src: remove Buffer::Data(Persistent<T>&) - http://git.io/xSoGJA
12:20:54  * bnoordhuisquit (Ping timeout: 256 seconds)
12:28:25  <MI6>nodejs-master: #306 UNSTABLE linux-ia32 (1/612) smartos-ia32 (2/612) linux-x64 (1/612) smartos-x64 (9/612) http://jenkins.nodejs.org/job/nodejs-master/306/
12:35:49  <MI6>nodejs-master-windows: #112 UNSTABLE windows-ia32 (15/612) windows-x64 (14/612) http://jenkins.nodejs.org/job/nodejs-master-windows/112/
12:43:40  * st_lukequit (Remote host closed the connection)
12:49:50  * st_lukejoined
12:55:05  * M28quit (Read error: Connection reset by peer)
12:57:44  * M28joined
13:17:31  * icarotjoined
13:18:08  * icarotquit (Client Quit)
13:19:12  * txdv_quit (Read error: Connection reset by peer)
13:19:22  * txdvjoined
13:20:11  * icarotjoined
13:22:04  * st_lukequit (Remote host closed the connection)
14:06:52  * icarotquit (Ping timeout: 256 seconds)
14:13:19  * icarotjoined
14:21:52  * icarotquit (Ping timeout: 246 seconds)
14:29:23  * st_lukejoined
14:46:17  * mikealquit (Quit: Leaving.)
14:51:51  <tjfontaine>trevnorris: ah ok
15:04:13  * mikealjoined
15:04:47  * mikealquit (Client Quit)
15:10:38  * actquit (Ping timeout: 245 seconds)
15:15:43  <kellabyte>libuv in network throughput beast mode :) http://i.imgur.com/nfFXXpk.png
15:18:32  * leonvvjoined
15:20:19  * kellabytequit (Quit: Quit)
15:22:17  * mikealjoined
15:39:46  * icarotjoined
15:43:36  * paddybyersjoined
15:46:13  * st_lukequit (Remote host closed the connection)
15:47:16  * groundwaterjoined
15:47:58  * paddybyersquit (Ping timeout: 246 seconds)
15:51:00  * icarot2joined
15:53:26  * icarotquit (Ping timeout: 240 seconds)
15:53:48  * paddybyersjoined
16:00:49  * kellabytejoined
16:04:14  * paddybyersquit (Ping timeout: 240 seconds)
16:08:22  <tjfontaine>kellabyte: pretty graphs
16:14:47  * leonvvquit (Remote host closed the connection)
16:16:25  * hzjoined
16:22:50  * icarotjoined
16:24:34  * icarot2quit (Ping timeout: 256 seconds)
16:30:43  * kellabytequit (Changing host)
16:30:43  * kellabytejoined
16:31:07  <kellabyte>tjfontaine: :)
16:38:48  * groundwaterquit (Quit: groundwater)
17:00:14  * icarotquit (Ping timeout: 240 seconds)
17:03:54  * hzquit
17:04:18  * defunctzombie_zzchanged nick to defunctzombie
17:05:04  * bradleymeckjoined
17:10:31  * paddybyersjoined
17:13:36  * leonvvjoined
17:24:05  * loladirojoined
17:27:18  * icarotjoined
17:31:13  * paddybyersquit (Ping timeout: 246 seconds)
17:41:26  * icarotquit (Ping timeout: 240 seconds)
17:45:23  * defunctzombiechanged nick to defunctzombie_zz
17:56:58  * mikealquit (Quit: Leaving.)
17:58:38  * icarotjoined
18:00:10  * AvianFlujoined
18:08:57  * icarotquit (Read error: Connection reset by peer)
18:15:08  * mikealjoined
18:17:45  <ik>shitlord!
18:24:35  <isaacs>kellabyte: rad!
18:27:28  * qardjoined
18:27:47  * bnoordhuisjoined
18:28:42  <tjfontaine>hahah, sometimes my stupidity amazes me
18:30:26  * hzjoined
18:37:16  * defunctzombie_zzchanged nick to defunctzombie
18:55:19  * bnoordhuisquit (Ping timeout: 276 seconds)
18:55:59  * bnoordhuisjoined
19:00:43  * defunctzombiechanged nick to defunctzombie_zz
19:01:10  * bnoordhuisquit (Ping timeout: 246 seconds)
19:01:25  <isaacs>tjfontaine: oh?
19:02:25  <tjfontaine>isaacs: for another piece of software I am writing a small release script, which part of the routine was a `git clean -fdx` guess what I hadn't commited before testing it the first time?
19:02:34  * qardquit (Quit: Leaving.)
19:06:42  * defunctzombie_zzchanged nick to defunctzombie
19:08:36  * mikealquit (Quit: Leaving.)
19:10:23  * AvianFluquit (Read error: Connection reset by peer)
19:12:16  * AvianFlujoined
19:15:10  * M28quit (Read error: Connection reset by peer)
19:15:40  * M28joined
19:16:38  * toothrchanged nick to toothrot
19:20:36  * loladiroquit (Quit: loladiro)
19:22:14  * dominictarrjoined
19:24:55  * leonvvquit (Remote host closed the connection)
19:28:22  * dsantiag_quit (Quit: Computer has gone to sleep.)
19:29:08  * dsantiagojoined
19:45:06  * c4milojoined
19:54:12  * paddybyersjoined
19:55:27  * c4miloquit (Remote host closed the connection)
20:03:04  * bradleymeckquit (Quit: bradleymeck)
20:04:04  * mikealjoined
20:08:14  * mikealquit (Ping timeout: 240 seconds)
20:21:11  * defunctzombiechanged nick to defunctzombie_zz
20:33:34  * paddybyersquit (Ping timeout: 246 seconds)
20:37:19  * TooTallNatejoined
20:46:22  * hzquit (Ping timeout: 256 seconds)
20:46:59  * defunctzombie_zzchanged nick to defunctzombie
20:47:06  * hzjoined
20:56:32  * inolenquit (Quit: Leaving.)
21:05:45  * inolenjoined
21:10:40  * c4milojoined
21:22:55  * paddybyersjoined
21:25:59  * loladirojoined
21:29:23  * paddybyersquit (Ping timeout: 245 seconds)
21:44:38  * paddybyersjoined
21:47:31  <isaacs>tjfontaine: oh no
21:47:37  <tjfontaine>heh
21:48:25  <isaacs>tjfontaine: it sounds like we should probably clear the nextTick queue after each setImmediate callback.
21:49:01  <tjfontaine>as well for timers then?
21:54:02  <isaacs>tjfontaine: hmm.....
21:54:15  * rendarquit
21:54:15  <isaacs>right ,because multiple setTimeout(fn, n) will call them all in a row like that
21:54:18  <isaacs>on the same tick
21:54:41  <tjfontaine>right
21:55:28  <isaacs>and, actually, even for IO
21:55:53  <isaacs>or event emissions
21:56:01  <isaacs>ok, maybe not :)
21:56:09  <isaacs>i mean, maybe not a good idea for setImmediate to do that
21:56:30  <tjfontaine>which is why I keep feeling more and more like nextTick should be an internal thing :)
21:56:56  <isaacs>well, i don't know.
21:57:12  <isaacs>i mean, it DOES mean that no more IO can happen on any specific thing that has had IO happen
21:57:20  <isaacs>like, ok, we drain all the setImmediates
21:57:30  <isaacs>but if any of those *scheduled* a setImmediate, then a nextTick would interrupt
21:57:35  <isaacs>you know
21:57:36  <isaacs>?
21:58:02  <isaacs>so, basically, i'ts more like we drain the current stack and event queue, and THEN nextTick happens
21:58:32  <isaacs>i'll "fix the glitch" wiht a doc patch :)
21:58:37  <tjfontaine>hehe
22:06:35  * paddybyersquit (Ping timeout: 260 seconds)
22:17:37  * jmar777joined
22:17:43  * defunctzombiechanged nick to defunctzombie_zz
22:21:37  <MI6>joyent/node: isaacs created branch reviewme - http://git.io/8sikYQ
22:21:43  <isaacs>tjfontaine: ^
22:24:48  <tjfontaine>that is better, but I think we need to draw an ascii art version of flow like whats his name did
22:33:27  * defunctzombie_zzchanged nick to defunctzombie
22:36:28  * hzquit
22:40:07  * jmar777quit (Remote host closed the connection)
22:53:12  <kellabyte>does this mean I'm trying to send 0 bytes? this is valgrind output
22:53:14  <kellabyte>==22757== Syscall param write(buf) points to uninitialised byte(s)
22:53:16  <kellabyte>==22757== at 0x504AC40: __write_nocancel (syscall-template.S:81)
22:53:18  <kellabyte>==22757== by 0x413AEC: uv__write (stream.c:785)
22:54:17  <tjfontaine>it's certainly possible, it at least means in your uv_buf_t.base wasn't set to something :)
22:56:20  <kellabyte>strange, I have no idea how thats possible, I'm calloc(1024, 1) a buffer
22:59:11  <kellabyte>so I calloc() a buffer of 1024, then I insert some stuff in there, which may be 162 bytes, then I set the uv_buf_t.base to the buffer, and set the uv_buf_t.len to 162, does that sound okay?
22:59:37  <tjfontaine>yes
23:00:05  <kellabyte>damn. was hoping you'd say no so I would be doing something obviously wrong :P
23:00:45  <tjfontaine>hehe
23:00:57  <tjfontaine>I'm looking through this, Im' not yet entirely familiar with this code
23:01:59  <tjfontaine>man, sometimes the stuff we do is still pretty magical in this code
23:02:06  <kellabyte>I'm probably doing something stupid, as always
23:05:47  * loladiroquit (Ping timeout: 256 seconds)
23:05:49  * hzjoined
23:06:53  <tjfontaine>kellabyte: so looking through this, I would be surprised if that valgrind warning was bogus, but I yield to bnoordhuis' wisdom on the matter when he's back around
23:07:15  <kellabyte>yeah I don't think its an issue in libuv, I think its my code thats causing it
23:08:07  <tjfontaine>right I was just looking through to make sure my gut about what was going on in libuv was right
23:08:13  <kellabyte>hehe
23:11:59  <kellabyte>ok I think I might know what line is wrong but not sure why
23:12:09  <kellabyte>and the why is kinda important to understand how to fix it :P
23:12:27  <tjfontaine>no doubt, some would say it is the most important part :)
23:13:25  <kellabyte>haha
23:13:36  * loladirojoined
23:13:46  <kellabyte>I think I have a free that is free'ing the buffer if its timed right before libuv sends it all out
23:14:21  <tjfontaine>ah yes, that could certainly be the cause, are you not freeing it in the write request callback?
23:16:04  <kellabyte>I'm guessing I fubar'd that when I rewrote all that code, lemme check!
23:17:26  <kellabyte>do I get access to the uv_buf_t that I used in the callback or do I have to store that in the uv_write_t?
23:18:37  <kellabyte>uv_write_t.data I mean
23:19:25  * hzquit
23:19:51  * defunctzombiechanged nick to defunctzombie_zz
23:20:32  <kellabyte>ah maybe thats uv_write_t.bufs
23:22:44  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:23:14  <tjfontaine>well, it seems we do a bit of evil in node for this
23:24:28  <kellabyte>looks like I was wrong, looks like the buffer is sitting in uv_write_t->bufsml->base
23:24:46  <tjfontaine>what we pass in as uv_write_t is technically larger, and we store the extra information on that, and then when we get the cb we know that it's relatively safe to go beyond the uv_write_t boundary
23:25:58  <kellabyte>larger than what?
23:28:11  <tjfontaine>so it's kinda like struct foo { uv_write_t req; void *data; }, and then in the cb container_of(req, struct foo, data);
23:28:33  <tjfontaine>so when you do uv_write() you give it your struct foo instead of a generic uv_write_t
23:28:52  <tjfontaine>http://www.kroah.com/log/linux/container_of.html has some extra information about how that macro works
23:29:22  <kellabyte>but uv_write_t.data is something you can point to your foo struct no?
23:30:38  <kellabyte>like this: https://github.com/kellabyte/Haywire/blob/http_response_cache/src/haywire/http_server.c#L211
23:30:52  <tjfontaine>it's unclear to me, I would assume you could, but it's certainly not how we do it right now in node :)
23:31:16  <tjfontaine>I would guess the difference is generally it's ideal not to touch struct members, and instead treat them as an opaque object
23:31:46  <kellabyte>ok, I thought the .data member was created for exactly this purpose "put whatever you need on the flip side of the callback"
23:33:48  <tjfontaine>right, that's what I would assume, but if you're not sure how a library will use a struct member you wrap it and sacrifice the sizeof(void*) overhead :)
23:34:23  <tjfontaine>I don't see an obvious usage of the data member atm
23:36:13  <kellabyte>well its been working for that purpose, I did a free(req->bufsml->base); in the write callback and instruments and valgrind are reporting no leak
23:36:37  <kellabyte>except my process usually runs in 6MB and its now 64MB so.. there's a leak or something but I've never seen valgrind be wrong
23:36:45  <kellabyte>so now I'm scratching my head a little lol
23:36:51  <tjfontaine>heh
23:37:48  <tjfontaine>kellabyte: is the usage growing?
23:39:43  <kellabyte>doesn't seem to be, ran a few wrk runs and it seems stable
23:42:40  <kellabyte>maybe I introduced that elsewhere, I'll look at that later, seems all the valgrind errors are gone now
23:43:03  <tjfontaine>that's a good thing
23:43:11  <kellabyte>yup :)
23:43:33  <tjfontaine>it could be that you're able to read faster than write, and 64mb is your highwater mark? I haven't really looked closely at what you're doing
23:44:17  <kellabyte>what do you mean high water mark? shouldn't whatever memory used go away when the connection ends?
23:44:35  <kellabyte>request or connection
23:44:45  <tjfontaine>well, presuming you free it all in close cb etc
23:44:57  <kellabyte>if I didn't instruments or valgrind usually reports a leak
23:45:10  <tjfontaine>when you're doing your testing with valgrind, are you letting your process exit gracefully?
23:45:41  <kellabyte>I've been doing a ctrl-c, the http server doesn't exit, it just listens forever
23:45:57  <kellabyte>but I don't ctrl-c until after work is done and closed sockets
23:46:04  <kellabyte>err wrk
23:46:14  <tjfontaine>you could install a signal handler for sigint, and then close the listener
23:46:25  <tjfontaine>and disable anything else that might keep the loop open
23:46:56  <tjfontaine>that way when the process exits valgrind can look to see if you still had a valid reference to those pointers
23:47:20  <kellabyte>it still does that when you do a ctrl-c I believe, usually it always reports the leaks when I had some
23:47:32  <kellabyte>you hit ctrl-c and then it spits out all the leaks
23:47:35  <kellabyte>right now there's none
23:49:18  <kellabyte>interesting, if I put back the "bug" where I free the buffer too early before the callback my memory stays 6MB
23:49:37  <kellabyte>I should be free'ing the same buffers in both locations, just one too early and one properly
23:59:40  * dominictarrquit (Quit: dominictarr)