00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:18:00  * AvianFluquit (Remote host closed the connection)
00:18:30  * AvianFlujoined
01:44:04  * wwicks_joined
01:46:01  * wwicksquit (Ping timeout: 246 seconds)
01:46:02  * wwicks_changed nick to wwicks
02:05:12  * wwicks_joined
02:06:14  * wwicksquit (Ping timeout: 240 seconds)
02:06:14  * wwicks_changed nick to wwicks
02:48:45  * AvianFluquit (Remote host closed the connection)
02:49:24  * AvianFlujoined
02:54:06  * abraxasquit (Ping timeout: 252 seconds)
02:57:37  * defunctzombie_zzchanged nick to defunctzombie
03:12:19  * brsonquit (Quit: leaving)
03:26:39  * wwicks_joined
03:28:57  * wwicksquit (Ping timeout: 272 seconds)
03:28:58  * wwicks_changed nick to wwicks
03:50:24  * defunctzombiechanged nick to defunctzombie_zz
04:24:38  * EhevuTovjoined
04:34:56  * Kakerajoined
04:42:11  * EhevuTovquit (Quit: This computer has gone to sleep)
04:42:50  * amartensjoined
04:43:04  * qmxquit (Read error: Connection reset by peer)
04:44:29  * qmxjoined
04:49:11  * bajtosjoined
04:53:01  * qmxquit (Remote host closed the connection)
04:58:14  * qmxjoined
04:58:48  * Kakeraquit (Ping timeout: 240 seconds)
04:59:42  * mikealquit (Quit: Leaving.)
05:11:45  * mikealjoined
05:27:02  * st_lukejoined
05:42:58  * st_lukequit (Remote host closed the connection)
06:30:21  * wwicksquit (Read error: Connection reset by peer)
06:30:38  * wwicksjoined
06:40:49  <MI6>nodejs-v0.10-windows: #259 UNSTABLE windows-ia32 (9/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/259/
06:40:57  <tjfontaine>NET 99280: onread -4095
06:40:58  <tjfontaine>NET 99280: EOF
06:40:58  <LOUDBOT>IT'S NOT DIFFERENT AT ALL, IS IT STEVE!!!?
06:41:01  <tjfontaine>that can't be right
06:47:06  <tjfontaine>ahh well that's not the scary part I guess
06:48:05  <tjfontaine>readableState has the left over bytes still in .buffer but streams api isn't flushing that data back out
06:51:43  * wwicks_joined
06:53:31  * wwicksquit (Ping timeout: 272 seconds)
06:53:32  * wwicks_changed nick to wwicks
07:05:48  <wolfeidau>trevnorris: late night hacking? :)
07:05:55  <wolfeidau>oops tjfontaine ^
07:06:05  <wolfeidau>to many t's in this channel
07:10:43  <tjfontaine>:)
07:11:18  <tjfontaine>finally had motivation and time to do more work on this ssl truncation issue
07:11:24  * rendarjoined
07:11:44  <tjfontaine>as it turns out we're reading everything through the tls_wrap socket fine and putting it all into js land
07:12:14  <tjfontaine>but when the socket is done and destroyed, if there's still some buffer's in readableState.buffer it doesn't flush those out before an unpipe
07:12:40  <tjfontaine>I added some more dtrace probes to verify some of these things, I'll probably making sure those go in
07:13:51  <tjfontaine>to take it the next mile I will have to learn more about the streams plumbing :)
07:36:02  <wolfeidau>tjfontaine: that mite be what i was seeing
07:36:07  <wolfeidau>?
07:38:04  <wolfeidau>tjfontaine: 5c87189f7a9 2515 21 ReadableState: highWaterMark, buffer, ... lots of those hanging around in my tests
07:44:31  * amartensquit (Quit: Leaving.)
08:09:12  * hzjoined
08:13:07  * wwicks_joined
08:15:19  * amartensjoined
08:15:29  * wwicksquit (Ping timeout: 272 seconds)
08:15:30  * wwicks_changed nick to wwicks
08:21:51  * amartensquit (Ping timeout: 245 seconds)
08:44:02  * AvianFluquit (Remote host closed the connection)
08:44:33  * AvianFlujoined
08:48:56  * AvianFluquit (Ping timeout: 245 seconds)
08:54:08  * wwicks_joined
08:56:11  * wwicksquit (Ping timeout: 246 seconds)
08:56:11  * wwicks_changed nick to wwicks
09:16:16  * wwicksquit (Ping timeout: 245 seconds)
09:19:56  * amartensjoined
09:28:27  * amartensquit (Ping timeout: 248 seconds)
09:47:17  <MI6>joyent/node: Ben Noordhuis master * 45885a1 : cluster: fix premature 'disconnect' event (+1 more commits) - http://git.io/qpA8rQ
09:59:41  <MI6>nodejs-master: #611 UNSTABLE smartos-ia32 (5/645) smartos-x64 (9/645) http://jenkins.nodejs.org/job/nodejs-master/611/
10:06:35  <MI6>nodejs-master-windows: #405 UNSTABLE windows-x64 (20/645) windows-ia32 (21/645) http://jenkins.nodejs.org/job/nodejs-master-windows/405/
10:08:15  * bnoordhuisjoined
10:13:08  * bajtosquit (Quit: bajtos)
10:14:17  * bajtosjoined
10:14:25  * bajtosquit (Client Quit)
10:15:52  <bnoordhuis>hrm, ssh://github.com down again?
10:16:12  <bnoordhuis>and back up again
10:16:30  <bnoordhuis>painfully slow though
10:16:53  <MI6>joyent/node: Ben Noordhuis v0.10 * 56c5806 : doc: document os.loadavg() behavior on windows - http://git.io/r3OCeQ
10:24:37  * amartensjoined
10:29:08  * amartensquit (Ping timeout: 256 seconds)
10:43:13  * piscisaureus_joined
10:47:55  <MI6>nodejs-v0.10: #1533 UNSTABLE smartos-x64 (4/601) smartos-ia32 (4/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1533/
10:57:46  <bnoordhuis>piscisaureus_: ping
10:57:52  <piscisaureus_>bnoordhuis: pong
10:58:25  <bnoordhuis>piscisaureus_: i was thinking about uv_read_t. you and isaac were discussing that the other day, right?
10:58:26  <piscisaureus_>bnoordhuis: http://www.youtube.com/watch?v=dqD1OohY2to
10:58:33  <bnoordhuis>more kabouter wesley?
10:58:54  <piscisaureus_>bnoordhuis: another way of saying pong
10:59:21  <bnoordhuis>ah, another attempt at humour?
10:59:28  <piscisaureus_>bnoordhuis: Sort of. I think uv_read with a callback would be better design than uv_read_start yeah
10:59:29  <bnoordhuis>i usually leave that to the professionals
10:59:49  <bnoordhuis>right, i was thinking the same thing. is there a reason we never implemented that?
11:00:01  <piscisaureus_>bnoordhuis: no time, no priority
11:00:20  <bnoordhuis>okay. but there is no fundamental IOCP shortcoming that makes that impossible?
11:00:27  <piscisaureus_>bnoordhuis: no
11:00:40  <bnoordhuis>okay, good. maybe i'll have a go at it
11:00:41  <piscisaureus_>bnoordhuis: (but the alloc cb complicates things)
11:00:56  <bnoordhuis>you'd pass the buffer to uv_read() right?
11:01:03  <piscisaureus_>bnoordhuis: well that is kind of sucky
11:01:09  <bnoordhuis>why?
11:01:11  <piscisaureus_>bnoordhuis: I think we'd want to keep the alloc cb
11:01:20  <piscisaureus_>bnoordhuis: if you have 100k connections open and they all have a read pending
11:01:31  <piscisaureus_>that will use 100k*64k memory
11:01:39  <bnoordhuis>okay
11:01:51  <bnoordhuis>but that's already kind of how it works with iocp right?
11:01:53  <piscisaureus_>bnoordhuis: upfront allocation needs to be avoided as much as possible
11:01:54  <rendar>piscisaureus_: hi, does libuv "reuse" OVERLAPPED packets for each read/write? i mean, after calling read_cb it can reuse the same OVERLAPPED instead of destroying it and allocating a new one
11:02:13  <piscisaureus_>bnoordhuis: not most of the time.
11:02:34  <bnoordhuis>oh? it doesn't actually do IOCP most of the time, or ...?
11:02:42  <piscisaureus_>bnoordhuis: usually the read is a 0-byte read and when it completes we do a nonblocking read to get the actual data out
11:03:01  <piscisaureus_>bnoordhuis: there is also a mode where it allocates upfront, but it is currently disabled
11:03:15  <bnoordhuis>right. i've seen that in there somewhere
11:03:30  <piscisaureus_>bnoordhuis: because the performance gains were barely significant and it didn't play well with the slab allocator
11:03:48  <piscisaureus_>bnoordhuis: but pipes and tty do allocate early
11:03:56  <piscisaureus_>bnoordhuis: (well, pipes do sometimes)
11:04:02  <piscisaureus_>bnoordhuis: because they read in a thread pool
11:04:16  <bnoordhuis>okay. so you'd get something like uv_read(uv_read_t*, uv_stream_t*, uv_alloc_cb, uv_read_cb)
11:04:23  <piscisaureus_>bnoordhuis: yes
11:05:18  <bnoordhuis>and because we like feature parity, you'd also get something like uv_listen(uv_listen_t*, uv_stream_t*, uv_preaccept_cb, uv_accept_cb)
11:05:30  <piscisaureus_>bnoordhuis: preaccept_cb?
11:05:38  <bnoordhuis>to alloc the new handle
11:05:44  <piscisaureus_>oh right yeah
11:05:45  <bnoordhuis>could also call it uv_new_handle_cb
11:06:01  <bnoordhuis>and then everything is request driven and balance will have been restored to the force
11:06:04  <bnoordhuis>i like it
11:06:28  <piscisaureus_>bnoordhuis: yes, although maybe we should call it uv_accept with a callbacl
11:06:45  <bnoordhuis>well okay, works for me too
11:06:48  <piscisaureus_>and uv_listen just makes the socket listening
11:06:53  <mmalecki>I love uv_preaccept_cb idea. could it be used to reject connections?
11:06:59  <bnoordhuis>what if there is no listen request in the queue?
11:07:04  <piscisaureus_>bnoordhuis: I have not much time to do it though...
11:07:07  <bnoordhuis>mmalecki: yeah, that was my thiking
11:07:08  <rendar>mmalecki: yes
11:07:08  <bnoordhuis>*thinking
11:07:10  <mmalecki>love it
11:07:30  <piscisaureus_>rendar: it does reuse in case of read_t yes
11:07:40  <rendar>piscisaureus_: what about write?
11:07:52  <mmalecki>piscisaureus_: bnoordhuis if neither of you have time to do this, I might take a stab
11:08:13  <piscisaureus_>rendar: the OVERLAPPED is embedded int the uv_write_t. If you reuse the uv_write_t the OVERLAPPED inside it gets reused.
11:08:41  <rendar>piscisaureus_: oh, i see
11:08:52  <bnoordhuis>mmalecki: i probably have time to work on it. you can do the windows side of things though :)
11:09:21  <mmalecki>bnoordhuis: I prefer leaving Windows work to professionals ;)
11:09:47  <bnoordhuis>yeah, that's the thing - everyone wants to do cool unix stuff, no one wants to write boring windows code
11:09:52  <rendar>piscisaureus_: so uv_write_t is allocated on heap, and is a kind of an "handle" of the read/write current streaming of the uv_stream_t ?
11:09:59  <bnoordhuis>i don't blame anyone, least of all me, but it is an issue
11:10:12  <bnoordhuis>okay, lunch - biab
11:11:31  <piscisaureus_>rendar: uv_read_t doesn't exist so far except internally
11:11:46  <rendar>piscisaureus_: oh, i see, and uv_write_t exist also externally
11:11:49  <piscisaureus_>rendar: uv_write_t is a handle to a "write op" in the background yes
11:11:57  <rendar>got it
11:12:08  <piscisaureus_>rendar: and uv_write_t is allocated wherever you allocate it, which would typically be on the heap indeed
11:12:30  <rendar>yeah, you allocate it whenever you want to start a write stream
11:12:42  <rendar>but why uv_read_t doesn't exist externally like uv_write_t ?
11:15:00  * bnoordhuisquit (Ping timeout: 265 seconds)
11:24:56  * amartensjoined
11:29:31  * amartensquit (Ping timeout: 248 seconds)
11:35:36  * stagasjoined
12:14:06  * bnoordhuisjoined
12:25:23  * amartensjoined
12:30:05  * amartensquit (Ping timeout: 272 seconds)
12:42:56  * bnoordhuisquit (Ping timeout: 245 seconds)
13:00:26  * kevinswiberjoined
13:09:51  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
13:09:58  * kevinswiberquit (Remote host closed the connection)
13:10:31  * kevinswiberjoined
13:10:53  * mikeal1joined
13:12:25  * mikealquit (Write error: Connection reset by peer)
13:15:03  * kevinswiberquit (Ping timeout: 252 seconds)
13:20:58  * bajtosjoined
13:26:06  * amartensjoined
13:30:27  * amartensquit (Ping timeout: 252 seconds)
13:45:01  * Kakerajoined
14:09:01  * bnoordhuisjoined
14:13:59  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
14:14:31  * AvianFlujoined
14:20:10  * inolenjoined
14:26:26  * amartensjoined
14:30:50  * amartensquit (Ping timeout: 245 seconds)
14:33:59  * bnoordhuisquit (Ping timeout: 268 seconds)
14:38:14  * defunctzombie_zzchanged nick to defunctzombie
14:42:48  * defunctzombiechanged nick to defunctzombie_zz
14:51:55  * AvianFluquit (Remote host closed the connection)
14:52:23  * AvianFlujoined
14:55:26  * indexzerojoined
14:57:25  * AvianFluquit (Ping timeout: 268 seconds)
14:59:09  * julianduquejoined
15:03:24  * indexzeroquit (Ping timeout: 256 seconds)
15:16:07  * mikeal1quit (Quit: Leaving.)
15:19:22  <MI6>nodejs-master: #612 UNSTABLE osx-x64 (1/645) smartos-ia32 (6/645) smartos-x64 (7/645) osx-ia32 (1/645) http://jenkins.nodejs.org/job/nodejs-master/612/
15:21:54  * bnoordhuisjoined
15:22:24  * mikealjoined
15:25:23  * piscisaureus_joined
15:26:46  * amartensjoined
15:31:10  * amartensquit (Ping timeout: 256 seconds)
15:34:42  * wwicksjoined
15:43:20  * wwicks_joined
15:45:20  * wwicksquit (Ping timeout: 256 seconds)
15:45:20  * wwicks_changed nick to wwicks
15:51:37  * AvianFlujoined
15:55:24  * bajtosquit (Quit: bajtos)
16:01:12  * dapjoined
16:04:22  * wwicks_joined
16:05:14  * TooTallNatejoined
16:05:26  * c4milojoined
16:05:37  * mcavagejoined
16:05:52  * wwicksquit (Ping timeout: 268 seconds)
16:05:52  * wwicks_changed nick to wwicks
16:06:42  * kevinswiberjoined
16:10:55  * indexzerojoined
16:12:48  * bnoordhuisquit (Ping timeout: 240 seconds)
16:18:56  * mikealquit (Quit: Leaving.)
16:21:00  * bajtosjoined
16:24:14  * wwicks_joined
16:24:17  * kevinswiberquit (Remote host closed the connection)
16:26:43  * wwicksquit (Ping timeout: 260 seconds)
16:26:44  * wwicks_changed nick to wwicks
16:27:05  * amartensjoined
16:28:57  * AvianFluquit (Remote host closed the connection)
16:29:54  * bnoordhuisjoined
16:31:42  * AvianFlujoined
16:31:44  <TooTallNate>anyone have any ideas what would cause node to show as "(Not Responding)" in osx's Activity Monitor?
16:31:51  * amartensquit (Ping timeout: 260 seconds)
16:31:53  <TooTallNate>the process is actually running fine...
16:31:56  <TooTallNate>and responding to requests
16:33:45  * indexzero_joined
16:33:45  * indexzero_quit (Client Quit)
16:37:08  * indexzeroquit (Ping timeout: 246 seconds)
16:38:30  <tjfontaine>TooTallNate: I've been noticing that for cloudup on 10.9 as well, but also chrome's pepper flash plugin -- I will sample the process and see where dtrace says it is
16:38:45  <TooTallNate>tjfontaine: i'd appreciate that :)
16:38:56  <tjfontaine>did you know you can invoke dtrace from the activity monitor?
16:39:16  <TooTallNate>the "Sample Process" thinggy?
16:39:18  <tjfontaine>aye
16:39:25  * Kakeraquit (Read error: Connection reset by peer)
16:39:55  <tjfontaine>https://gist.github.com/tjfontaine/89c8e61d1260cf6d430e
16:39:59  <tjfontaine>is where the process is atm
16:40:20  <tjfontaine>all things look pretty sane
16:40:38  * julianduquequit (Read error: Connection reset by peer)
16:41:24  <TooTallNate>tjfontaine: i'm thinking it's maybe a signal handler being overwritten by the process that maybe trips up Activity Monitor?
16:41:38  <TooTallNate>not really sure how it determines the Not Responding status in the first place though...
16:41:51  <tjfontaine>it's certainly possible, as most node processes don't show up this way, so it's not something node itself is doing
16:42:01  <tjfontaine>let me do some googling to see
16:44:45  * wwicks_joined
16:45:20  * Kakerajoined
16:47:04  * wwicksquit (Ping timeout: 265 seconds)
16:47:05  * wwicks_changed nick to wwicks
16:47:20  * inolenquit (Quit: Leaving.)
16:51:09  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
16:51:12  * dapquit (Quit: Leaving.)
16:51:43  * kenperkinsjoined
16:52:11  * Benviequit
16:53:13  * kenperkinsquit (Client Quit)
16:56:19  * lukjoined
17:00:11  * kenperkinsjoined
17:01:45  * lukquit (Remote host closed the connection)
17:02:20  * st_lukejoined
17:02:28  * st_lukequit (Read error: Connection reset by peer)
17:02:38  * st_lukejoined
17:04:51  * Benviejoined
17:10:34  <trevnorris>wolfeidau: heh, sort of. fell asleep while writing emails and stuff. woke up several hours later and finished up. :)
17:10:49  * brsonjoined
17:13:45  <trevnorris>morning all
17:13:49  <trevnorris>bnoordhuis: how things going?
17:14:03  <tjfontaine>TooTallNate: would be interesting if you just put a spurious wakeup that does some cpu time, the common thing between cloudup node and pepper is: __psynch_cvwait and semaphore_wait_trap (in my estimation)
17:14:32  <TooTallNate>tjfontaine: like a setInterval() kinda thing?
17:14:45  <tjfontaine>TooTallNate: so they're properly waiting for things, but I bet it's worried that because it's not seeing any wakeups and a lot of waits that it thinks the process is "deadlocked"
17:15:00  <tjfontaine>TooTallNate: ya, that's where I would start I think -- though that defeats the energy feature
17:15:18  <bnoordhuis>trevnorris: same old really
17:15:19  * bradleymeckjoined
17:15:26  <tjfontaine>trevnorris: gmorning to you sir as well
17:15:42  <trevnorris>bnoordhuis: good to hear. getting much sleep these days?
17:16:01  <bnoordhuis>trevnorris: i can't complain. my SO otoh...
17:16:20  <trevnorris>heh, yeah. I remember that.
17:22:57  <groundwater_>trevnorris: mind if i hit you up with some async-listener questions?
17:23:06  * dapjoined
17:23:17  <trevnorris>groundwater_: go for it :)
17:23:38  <groundwater_>what do you think of this?
17:23:38  <groundwater_>https://github.com/othiym23/async-listener/pull/5
17:24:07  <groundwater_>also, the last comment here https://github.com/othiym23/async-listener/issues/6#issuecomment-26270345
17:24:59  <trevnorris>groundwater_: That was part of the original specification, but unfortunately it's impossible.
17:25:17  <trevnorris>groundwater_: see, callbacks can be set while the async request is in flight
17:25:33  <trevnorris>so it's never definitive what will be called once the operation is complete.
17:26:16  <tjfontaine>TooTallNate: I have a theory, I am going to test it
17:26:32  <TooTallNate>:D
17:26:40  <groundwater_>trevnorris: ahh, do you want to quickly note that on the issue?
17:26:49  <trevnorris>groundwater_: in the process :)
17:26:59  <groundwater_>trevnorris: thanks!
17:27:08  <trevnorris>np, let me know if you have any other questions
17:27:22  <groundwater_>what do you think of my second link?
17:27:25  * amartensjoined
17:28:04  <tjfontaine>TooTallNate: bugger, quick test didn't work, but OOC is this particular process using fs.watch or fs.watchFile?
17:28:58  * mikealjoined
17:28:59  <TooTallNate>tjfontaine: nope
17:29:27  <trevnorris>groundwater_: as for error handling, each listener is unaware of whether the error has been handled by another listener. and regardless of whether one handles the error, all error callbacks will fire.
17:30:10  <tjfontaine>TooTallNate: ok well alright then, random theory pulled out of my ass is bunk, what types of things does it do? I wonder how quickly from start of process does it transition into this state
17:30:13  <groundwater_>trevnorris: so, does every listener have to "handle" the error in order to avoid crashing?
17:30:20  <trevnorris>groundwater_: no, only one.
17:30:40  <groundwater_>ahh okay, this is different behaviour than the polyfill, is there a test for this?
17:30:49  <groundwater_>if not, i can put one together
17:32:17  * amartensquit (Ping timeout: 272 seconds)
17:32:33  <TooTallNate>tjfontaine: that's a good thing to look out for... and overall it's basically an app server. it does some HTTP inbound + outbound traffic, spawns an HTTP and HTTPS server
17:33:10  <trevnorris>groundwater_: no I don't have a multi listener error check. that would probably be easy to create from the existing error check test: http://git.io/Yn3-jw
17:33:25  <tjfontaine>TooTallNate: hmm ok
17:33:41  <groundwater_>trevnorris: sure thing, i just want to make sure the polyfill behaves the same as your impl.
17:33:46  <groundwater_>thanks!
17:33:51  <trevnorris>np :)
17:46:08  * wwicksquit (Read error: Connection reset by peer)
17:46:26  * wwicksjoined
17:49:28  <groundwater_>trevnorris: actually looks like othiym23 fixed it in master already
17:50:13  <othiym23>groundwater_: yeah, the polyfill should behave almost exactly the same as core, down to the different behaviors for when there's a throw in an error handler or another async callback
17:50:22  <othiym23>mostly becuase I yoinked it straight out of trevnorris's patch
17:50:54  <othiym23>that said, we could use less simpleminded tests around the error-handling
17:53:02  <othiym23>the fact that the tests from trevnorris's were passing this whole time even though the polyfill was busted ;)
17:53:37  <MI6>libuv-master: #284 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/284/
17:56:50  <trevnorris>othiym23: yeah. I'm in the process of writing up docs and filling in the unit test gaps. on the later, anything you guys have to contribute is great. :)
17:58:33  <mmalecki>trevnorris: congrats :-)
17:58:44  <trevnorris>mmalecki: thanks :)
18:02:29  * defunctzombie_zzchanged nick to defunctzombie
18:03:14  * piscisaureus_quit (Ping timeout: 264 seconds)
18:06:43  * wwicks_joined
18:08:45  * wwicksquit (Ping timeout: 245 seconds)
18:08:45  * wwicks_changed nick to wwicks
18:09:15  * Kakeraquit (Read error: Connection reset by peer)
18:10:36  <MI6>libuv-node-integration: #269 UNSTABLE smartos-x64 (8/645) smartos-ia32 (5/645) http://jenkins.nodejs.org/job/libuv-node-integration/269/
18:26:09  <othiym23>so #6011 is going to land in 0.12?
18:26:12  <othiym23>awesome!
18:26:26  <groundwater_>\o/
18:27:06  * c4miloquit (Remote host closed the connection)
18:27:39  * c4milojoined
18:32:27  * c4miloquit (Ping timeout: 272 seconds)
18:37:55  <trevnorris>bnoordhuis: so, i've got to figure out what v8 is doing internally w/ their ArrayBuffer
18:37:56  <trevnorris>they can create really small ArrayBuffers (e.g. < 128 bytes) faster than we can create sliced Buffers.
18:38:21  <trevnorris>after around 1/2 KB we kick it to crap, but before that I can't figure out what's going on
18:42:02  * bajtosquit (Quit: bajtos)
18:50:25  <bnoordhuis>oh? interesting
18:51:18  <tjfontaine>don't they have some concept of a block allocator already? seems like that's what they could be leveraging there
18:51:53  <tjfontaine>not just in terms of the memory, but as far as object initialization
18:52:15  <MI6>nodejs-master-windows: #406 UNSTABLE windows-x64 (20/645) windows-ia32 (22/645) http://jenkins.nodejs.org/job/nodejs-master-windows/406/
18:52:51  * st_lukequit (Remote host closed the connection)
18:56:01  <bnoordhuis>hm, i don't know - it's just calling our custom allocator
18:57:20  * AvianFluquit (Remote host closed the connection)
18:57:26  <trevnorris>don't know a better way than to just trace through the code.
18:57:50  * amartensjoined
18:58:15  * AvianFlujoined
18:58:35  <trevnorris>bnoordhuis: i'm hoping it'll be easy to see, but you think it could be an indirect effect of the gc or some such?
18:58:37  * defunctzombiechanged nick to defunctzombie_zz
18:59:37  <bnoordhuis>trevnorris: i'm guessing that new char[n] where n < 128 is coming from a fast malloc arena
18:59:48  <bnoordhuis>trevnorris: on what os are you testing?
18:59:49  * EhevuTovjoined
19:00:13  <trevnorris>bnoordhuis: linux
19:00:27  <bnoordhuis>with glibc, i presume?
19:00:31  <trevnorris>yeah
19:00:49  <bnoordhuis>right. small allocations come from a thread-local arena
19:00:53  <tjfontaine>but if it's faster than a slice then our only allocs happening are js objects
19:01:19  <bnoordhuis>easy to verify right? just set a tracepoint on malloc() with perf
19:01:43  <trevnorris>cool.
19:02:51  * amartensquit (Ping timeout: 268 seconds)
19:03:22  <trevnorris>bnoordhuis: what I don't understand is how pre-allocating the memory on an array buffer, for > 1KB is still significantly slower. here's my test git.io/l8gHuw
19:09:06  * wwicks_joined
19:10:04  * wwicksquit (Ping timeout: 246 seconds)
19:10:05  * wwicks_changed nick to wwicks
19:14:36  <bnoordhuis>trevnorris: i'm not sure what you mean by preallocating
19:15:10  <trevnorris>bnoordhuis: so, ArrayBuffer has to zero fill. but i'm malloc'ing beforehand and telling ArrayBuffer to use that memory.
19:15:17  <trevnorris>so it doesn't have to be zero filled.
19:16:19  * EhevuTovquit (Quit: This computer has gone to sleep)
19:17:23  * EhevuTovjoined
19:18:18  <trevnorris>bnoordhuis: also, perf list doesn't show any tracepoint events. must not have something installed.
19:21:32  <bnoordhuis>trevnorris: wait, let me look up an article that explains it
19:21:45  <trevnorris>ok
19:22:07  <bnoordhuis>eh, i guess `perf probe --help` is okay
19:22:39  <bnoordhuis>none of the articles / blog posts i find with a quick search are much better
19:29:14  * wwicks_joined
19:30:14  * wwicksquit (Ping timeout: 240 seconds)
19:30:15  * wwicks_changed nick to wwicks
19:30:31  * amartensjoined
19:31:24  <trevnorris>bnoordhuis: eh, whatever. says -e probe_libc isn't supported.
19:32:45  * nrajlichjoined
19:32:50  * TooTallNatequit (Read error: Connection reset by peer)
19:34:09  * ecrjoined
19:34:51  <bnoordhuis>trevnorris: old kernel/perf? i think you need linux 3.7 or 3.8 for that
19:35:21  <trevnorris>ah, that must be it. have 3.5
19:35:47  <trevnorris>usually skip the kernel upgrade because it jacks my video card drivers. :P
19:36:27  <trevnorris>i'll just dtrace it
19:36:30  * c4milojoined
19:36:39  <trevnorris>or something else.
19:39:47  * indexzerojoined
19:40:09  * st_lukejoined
19:40:57  * indexzeroquit (Read error: Connection reset by peer)
19:41:23  * ecrpart
19:41:43  * indexzerojoined
19:47:57  <trevnorris>bnoordhuis: so I ran dtrace and created a distribution on malloc:entry and created 1e7 new ArrayBuffer(16). count: 4048075
19:51:30  * Kakerajoined
19:53:25  * Kakeraquit (Read error: Connection reset by peer)
19:56:35  * julianduquejoined
19:57:52  <bnoordhuis>trevnorris: 'sherlock holmes and the mystery of the missing malloc calls'?
19:58:14  <trevnorris>heh
20:03:10  * c4miloquit (Remote host closed the connection)
20:05:42  <trevnorris>bnoordhuis: interesting. did the same with 1 byte, and count is only 1103202 w/ 1e7 iterations.
20:07:45  * defunctzombie_zzchanged nick to defunctzombie
20:08:22  <trevnorris>bnoordhuis: have some insight to what the comment on ArrayBuffer::IsExternal() means: "Returns true if ArrayBuffer is extrenalized, that is, does not own its memory block."
20:10:04  <bnoordhuis>trevnorris: means you've called ArrayBuffer::Externalize() on the arraybuffer
20:10:10  * wwicks_joined
20:11:40  * wwicksquit (Ping timeout: 260 seconds)
20:11:40  * wwicks_changed nick to wwicks
20:11:44  <trevnorris>... oy, how'd I miss that. thanks for pointing it out.
20:13:21  * st_lukequit (Read error: Connection reset by peer)
20:13:33  * st_lukejoined
20:18:22  <trevnorris>bnoordhuis: and thanks for the -E trick. just saved me trying to mentally unfold 4 levels of macros in v8/src/factory.cc :)
20:21:44  <bnoordhuis>trevnorris: on a slightly tangential note, if you ever want to get the list of predefined macros -> gcc -E -dM - < /dev/null
20:22:15  <bnoordhuis>you can also pass -dD, -dN and -dI but they're less useful
20:22:22  <trevnorris>ooh. cool. thanks :)
20:23:37  <trevnorris>no idea why < /dev/null does that, but hey. I'll take it.
20:28:26  <bnoordhuis>trevnorris: the - tells gcc to read from stdin and the </dev/null gives it something to read from
20:28:54  <trevnorris>ah, interesting.
20:29:03  <bnoordhuis>omitting </dev/null and pressing ^D would've achieved the same thing
20:29:12  <bnoordhuis>but real men don't tolerate interactive programs
20:29:26  <trevnorris>haha
20:29:29  <trevnorris>now, to figure out what the hell is going on in Heap::AllocateJSObjectFromMap()
20:29:44  <trevnorris>i'm about a dozen methods deep trying to figure out how array buffer allocates
20:30:51  <trevnorris>hm. i want to put a trace on node::ArrayBufferAllocator::Allocate
20:32:01  <bnoordhuis>trevnorris: you probably want Runtime_ArrayBufferInitsomethingsomething in src/runtime.cc
20:32:17  <trevnorris>ah, thanks.
20:32:21  <bnoordhuis>Runtime_ArrayBufferInitialize, that's the one
20:33:14  <trevnorris>ah crap. I forget that calling the JS API has a different entry point than the v8 API.
20:33:25  <trevnorris>bnoordhuis: thanks for saving me from myself.
20:34:16  <bnoordhuis>np :)
20:38:30  <trevnorris>wtf. were are the malloc's going. new ArrayBuffer(n > 0) always calls V8::ArrayBufferAllocator()->Allocate(); which you set in node.cc.
20:38:44  <trevnorris>ok. want to put a trace on that and see how many times it's getting called.
20:41:32  * `3Echanged nick to `3E|SLIDEDECKDUT
20:43:58  <trevnorris>tjfontaine: is there a simple form to have dtrace count the number of times a specific method is called?
20:44:42  <tjfontaine>trevnorris: foo::method:entry { self->called += 1; } END { printf("foo called %d\n", self->called); }
20:44:45  <tjfontaine>or similar
20:46:56  <tjfontaine>oh
20:47:09  <tjfontaine>foo::method:entry { @[probefunc] = count(); }
20:47:14  <tjfontaine>that's probably the easiest
20:47:49  <trevnorris>but do I have to put the compiled jibberish, or can I use, like "node::ArrayBufferAllocator::Allocate"?
20:48:29  <tjfontaine>trevnorris: pid$target::*ArrayBufferAllocator*Allocate:entry
20:48:40  <trevnorris>ah, awesome. thanks.
20:48:44  <tjfontaine>trevnorris: but yes, otherwise a mangled name is required
20:48:47  * st_lukequit (Remote host closed the connection)
20:49:13  * st_lukejoined
20:49:16  * st_lukequit (Changing host)
20:49:16  * st_lukejoined
20:51:54  * st_lukequit (Read error: Connection reset by peer)
20:51:57  * st_luke_joined
20:55:33  * amartensquit (Quit: Leaving.)
21:04:33  <trevnorris>tjfontaine: eh, keeps telling me "no probes specified".
21:04:48  <tjfontaine>trevnorris: gist the command line?
21:06:25  <trevnorris>tjfontaine: well, the command line is just: sudo dtrace ./trace.d -c '../node/node test.js'
21:06:25  <trevnorris>and the script is just: pid$target::*Allocate*:entry { @[probfunc] = count(); }
21:07:06  <tjfontaine>trevnorris: add -Z which will try and resolve probes at runtime
21:07:12  <trevnorris>ah, ok.
21:07:57  <trevnorris>tjfontaine: awesome. that did it :)
21:09:27  <tjfontaine>well it allows dtrace to start, did it achieve what you wanted? :)
21:10:22  <trevnorris>well, I think it's tracing. just not printing anything.
21:10:44  <tjfontaine>well it won't print untilt he process exits or you exit dtrace
21:10:58  <tjfontaine>you could do: pid$target::*Allocate*:entry { @[probfunc] = count(); } tick-60s { exit(); }
21:11:06  <tjfontaine>which would make dtrace exit after 60 seconds
21:11:25  * indexzeroquit (Read error: Connection reset by peer)
21:11:38  <trevnorris>well, the process exits after about 5 sec.
21:11:53  <tjfontaine>and dtrace hasn't exited?
21:12:06  <trevnorris>it prints: dtrace: pid 13548 has exited
21:12:28  <trevnorris>i put an END { printf("done...\n"); }, and that's not showing up.
21:12:30  * indexzerojoined
21:15:31  * c4milojoined
21:15:51  * st_luke_quit (Remote host closed the connection)
21:16:18  * st_lukejoined
21:16:59  <trevnorris>tjfontaine: oop, i'm a dip. forgot the -s
21:17:25  <groundwater_>trevnorris: ping
21:18:12  <trevnorris>groundwater_: pong
21:20:00  <groundwater_>what's the desired behaviour if before/after throws?
21:20:26  <groundwater_>or even if error throws
21:20:37  <groundwater_>in the async listener
21:20:38  * st_lukequit (Ping timeout: 240 seconds)
21:20:57  <trevnorris>all the error callbacks get called then the program dies.
21:21:11  <trevnorris>there's no recovery from throwing from a before/after/error callback.
21:21:19  <groundwater_>ahhh, even if they return true?
21:25:09  <trevnorris>yeah
21:25:44  <groundwater_>and it looks like 'uncaughtException' is called if before/after throws, but not if error throws
21:25:55  <groundwater_>throwing in error is pretty much a death sentence
21:26:40  <trevnorris>yeah. it'll call error callbacks once more to let you know what happened, but then dies afterwards.
21:27:00  <trevnorris>it's either that or we set an arbitrary limit on how many times your error callbacks can error themselves.
21:27:10  <trevnorris>or else you get infinite recursive error callbacks calling
21:29:46  <groundwater_>i mean, i think throwing in your async listeners is dangerous anyways
21:30:10  <groundwater_>but i figure i should know exactly the intended behaviour
21:30:50  * nrajlichquit (Quit: Computer has gone to sleep.)
21:33:29  * amartensjoined
21:33:45  <trevnorris>yeah. this code is ridiculously close to the metal, and throwing from one of those callbacks is always going to be a show stopper.
21:37:11  <trevnorris>bnoordhuis: ok. well ArrayBufferAllocator::Allocate is called exactly 1e7 times. but malloc is only being called ~1million times.
21:38:06  <trevnorris>bnoordhuis: oh, does "new char" do something different than malloc?
21:39:52  <tjfontaine>it could use mmap or similar, but consider again if they have a block allocator for objects (which I am pretty sure they do) you won't see a 1:1 correlation
21:40:36  <bnoordhuis>tjfontaine: yeah, but an arraybuffer is a js object backed by external storage
21:40:37  <tjfontaine>or if object's get gc'd and that space will be reused
21:40:54  <tjfontaine>bnoordhuis: have they carved out a space specific to just array storage backend?
21:40:57  <bnoordhuis>err, external memory - we're not talking hard drives here
21:41:14  <bnoordhuis>tjfontaine: no, the embedder has to provide it
21:41:28  <tjfontaine>oh this is trevor making ArrayBuffer(new char[])?
21:41:32  <trevnorris>no
21:41:46  <trevnorris>it's from js. new ArrayBuffer(n);
21:42:13  <trevnorris>that calls RunTime::Runtime::SetupArrayBufferAllocatingData() which calls the function provided by the embedder.
21:42:15  <tjfontaine>right, so if since it zero's it out, v8 can't say "oh well I just gc'd an object of that size and type, let's just zero it again and give it back"
21:42:22  <tjfontaine>ah ok
21:42:24  <trevnorris>(scratch a RunTime::)
21:43:01  <trevnorris>and I verified with dtrace that it does in fact call that method the exact number of times in the loop
21:43:42  * ecrjoined
21:44:29  <trevnorris>tjfontaine: but when I loop SlowBuffer instead malloc is called ~6855912x's
21:44:55  * defunctzombiechanged nick to defunctzombie_zz
21:45:06  <trevnorris>but that's only 1/2 the number of iterations in the loop.
21:46:11  * rendarquit
21:46:16  * c4miloquit (Remote host closed the connection)
21:47:58  <tjfontaine>well, I guess the symbol name may not actually be malloc in that case
21:48:04  <trevnorris>must be
21:48:09  * st_lukejoined
21:48:36  <tjfontaine>spin up the process, then `dtrace -l -p <pid> | grep -i malloc`
21:48:58  <tjfontaine>will give you a list of probes that contain malloc
21:49:13  <trevnorris>damn it. how are they doing this. they have almost no setup time with their constructor call. but smalloc::Alloc is way expensive by comparison.
21:49:20  <trevnorris>tjfontaine: cool. thanks.
21:50:13  <tjfontaine>so I may get my wish of an arraybuffer backend yet :)
21:50:38  <tjfontaine>hmm pid's are not showing up in that
21:50:42  <trevnorris>heh, nope. once you get past 512 bytes Buffers are faster.
21:50:55  <trevnorris>and i'm talking slowbuffer allocations in comparison.
21:51:00  <trevnorris>not Buffer slices.
21:51:10  <bnoordhuis>trevnorris: the stuff in runtime.cc is a lot lighter than a full-blown callout to embedder bindings
21:51:26  <trevnorris>bnoordhuis: well, damn them for getting to use all the magic :P
21:51:33  <bnoordhuis>yeah, it's evil
21:51:40  * Kakerajoined
21:52:02  * bradleymeckquit (Quit: bradleymeck)
21:53:43  <trevnorris>bnoordhuis: seriously. even when I comment out every extraneous and unnecessary bit, it's still freakin slow.
21:53:43  <trevnorris>poop, I want access to that. think it might be possible?
21:53:56  <trevnorris>i mean, that they'd take a patch.
21:55:17  <bnoordhuis>trevnorris: unlikely. the list of functions is generated at compile time from a big x-macro
21:56:44  <groundwater_>trevnorris: am i able to catch an error thrown in the error callback? i'm trying to write a test around it
21:56:52  <groundwater_>any ideas?
21:57:12  * AvianFluquit (Remote host closed the connection)
21:59:51  * indexzeroquit (Quit: indexzero)
22:01:14  * Kakeraquit (Ping timeout: 265 seconds)
22:03:38  <trevnorris>groundwater_: you can't. spawn a child process that throws an error from the error callback with a specific message. if the error is received with the specific message then exit the child process with a specific error code.
22:04:00  <trevnorris>groundwater_: then assert the exit code matches what you were expecting.
22:04:08  <trevnorris>*with a specific exit code.
22:04:45  <trevnorris>bnoordhuis: bummer. well, thanks for helping me dig through that. :)
22:07:24  <bnoordhuis>np :)
22:13:53  <groundwater_>trevnorris: thanks, added
22:14:21  <trevnorris>groundwater_: great
22:17:47  <bnoordhuis>trevnorris: mozilla summit was earlier this month, right?
22:17:56  <trevnorris>bnoordhuis: yeah.
22:18:07  <bnoordhuis>okay. too bad
22:18:14  <trevnorris>wanted to go?
22:18:29  <bnoordhuis>to the one in brussels maybe
22:19:02  <trevnorris>maybe I can get you some shirts :)
22:19:32  <bnoordhuis>that'd be nice :)
22:19:48  <trevnorris>ah, dude. their use of macros in runtime.h makes env.h look trivial.
22:19:55  <trevnorris>coolio. what are you. xl?
22:20:18  <bnoordhuis>are you calling me fat?
22:20:29  <bnoordhuis>i think i'm a m
22:20:52  <trevnorris>hah, no. just tall. i the shirts were made for midgets I think.
22:21:12  <trevnorris>i'm wearing xl just so it reaches my pants.
22:21:47  * ecrquit (Quit: ecr)
22:22:27  <bnoordhuis>hah, okay. guess i'd better stick with xl too then
22:24:57  * st_lukequit (Remote host closed the connection)
22:25:28  * st_lukejoined
22:25:35  <trevnorris>bnoordhuis: wtf. so in runtime.h, class Runtime. they have a field "byte* entry" with the comment "The C++ (native) entry point"
22:27:16  * wwicks_joined
22:27:28  * wwicksquit (Ping timeout: 246 seconds)
22:27:29  * wwicks_changed nick to wwicks
22:27:30  <bnoordhuis>trevnorris: is that an implicitly voiced question or merely an observation?
22:28:52  <trevnorris>bnoordhuis: was going to be a question, but as I was writing it thinkg I figured out how it works. :)
22:29:22  <trevnorris>i just really want to hack something in and get it working.
22:29:24  <trevnorris>THE POWER!!!
22:29:25  <LOUDBOT>I DON'T HAVE ESP, I HAVE ESPECIALLY
22:29:57  * st_lukequit (Ping timeout: 272 seconds)
22:30:41  * wwicks_joined
22:31:18  <trevnorris>bnoordhuis: anyways, shouldn't you be asleep?
22:33:07  * wwicksquit (Ping timeout: 272 seconds)
22:33:22  * st_lukejoined
22:33:48  * wwicksjoined
22:35:01  <bnoordhuis>trevnorris: yeah, i guess i should. g'night then :)
22:35:10  <trevnorris>night :)
22:35:50  * wwicks_quit (Ping timeout: 245 seconds)
22:39:26  * bnoordhuisquit (Ping timeout: 240 seconds)
23:08:58  <trevnorris>isaacs: managed to dig your way out of all the emails?
23:13:45  * st_lukequit (Remote host closed the connection)
23:14:35  * indexzerojoined
23:30:48  * indexzeroquit (Quit: indexzero)
23:32:21  <trevnorris>tjfontaine: ah, wtf. v8's now at 3.22?
23:34:48  * hzquit
23:40:50  <trevnorris>tjfontaine: ping
23:44:59  <trevnorris>man, where is everyone.
23:45:51  * bnoordhuisjoined
23:50:26  <trevnorris>isaacs: ping
23:50:39  <isaacs>pong
23:50:50  * bnoordhuisquit (Ping timeout: 268 seconds)
23:51:14  <isaacs>trevnorris: i'm working on my realtime conf tal
23:51:15  <isaacs>k
23:51:36  <trevnorris>isaacs: so, for kicks I'm trying to upgrade to 3.22 to see if that fixes some of the perf hit I saw w/ smalloc.
23:51:37  <trevnorris>but now they have this new gyp variable of icu_gyp_path
23:51:57  <trevnorris>and it points to third_party folder. when checked out it's 350MB.
23:52:06  <trevnorris>i don't even know what it's for.
23:52:17  <trevnorris>oh, cool. what's your realtime conf talk about?
23:54:54  <trevnorris>isaacs: ok, so the question is. I don't see that icu folder in deps/v8 on master. so do we just compile w/o it?
23:55:20  <isaacs>icu folder??
23:55:39  <trevnorris>yeah. something to do with this: https://code.google.com/p/v8/wiki/I18NSupport
23:55:39  <isaacs>trevnorris: weird
23:55:47  <isaacs>trevnorris: no idea
23:56:24  <trevnorris>cool. well there's some optimizations that I want to try out so going to see if I can't figure this out.
23:57:25  <trevnorris>oh, it's part of a massive internationalization package that's part of the 402 spec. http://www.ecma-international.org/ecma-402/1.0/
23:58:10  * mikealquit (Quit: Leaving.)
23:59:33  <MI6>libuv-master-gyp: #224 FAILURE windows-x64 (4/196) windows-ia32 (4/196) http://jenkins.nodejs.org/job/libuv-master-gyp/224/