00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:03  <trevnorris>bnoordhuis: lgtm. just going to run the patch on my box before I comment on the issue.
00:00:09  * ircretaryjoined
00:00:13  <MI6>libuv-master-gyp: #286 UNSTABLE smartos-ia32 (3/195) windows-x64 (4/195) smartos-x64 (3/195) windows-ia32 (4/195) osx-ia32 (1/196) http://jenkins.nodejs.org/job/libuv-master-gyp/286/
00:01:35  <trevnorris>bnoordhuis: run test/simple/test-dns-regress-6244.js and tell me what you get.
00:02:52  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:02:57  * mikealjoined
00:03:07  <trevnorris>bnoordhuis: think that failure has to do w/ you removing the context around uv_run. i'm double checking now.
00:03:38  <bnoordhuis>trevnorris: passes for me
00:03:43  <bnoordhuis>what happens for you?
00:03:48  <trevnorris>bnoordhuis: segfault
00:03:52  <trevnorris>i'll gist the info
00:04:49  <trevnorris>first let me make clean. want to make sure there isn't anything lingering around.
00:05:01  * Kakeraquit (Ping timeout: 252 seconds)
00:05:14  <MI6>nodejs-v0.10-windows: #312 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/312/
00:06:05  <MI6>nodejs-v0.10: #1591 UNSTABLE smartos-x64 (6/604) smartos-ia32 (5/604) osx-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1591/
00:08:35  <bnoordhuis>seriously, what's up with pummel/test-next-tick-loops-quick?
00:08:47  <bnoordhuis>FATAL ERROR: JS Allocation failed - process out of memory
00:08:52  <bnoordhuis>and it's been doing that for ages now
00:09:12  <trevnorris>bnoordhuis: https://gist.github.com/trevnorris/7422946
00:09:15  <trevnorris>getting more info now.
00:11:01  <trevnorris>bnoordhuis: reason that fails is because before nextTick would burp once in a while and allow the eloop to run. now it doesn't so it just runs until the nextTickQueue array overflows.
00:11:22  <bnoordhuis>yeah, i see that in the test
00:11:36  <bnoordhuis>it expects a timeout callback to run after 2s
00:11:45  <bnoordhuis>so, bogus test: null and void?
00:12:27  <trevnorris>remove it. there's now a benchmark to test the same thing.
00:12:51  <trevnorris>bnoordhuis: ok. in that gist. frame #7:
00:12:51  <trevnorris>(gdb) p wrap->env()->context()
00:12:52  <trevnorris>$5 = {
00:12:52  <trevnorris> <v8::Handle<v8::Context>> = {
00:12:52  <trevnorris> val_ = 0x1
00:12:54  <trevnorris> }, <No data fields>}
00:13:11  <bnoordhuis>well, that's odd
00:14:22  <bnoordhuis>i'm guessing that's a missing Context::Scope
00:15:04  <trevnorris>bnoordhuis: fwiw that's the test you fixed here: https://github.com/joyent/node/issues/6244
00:15:22  <trevnorris>oh, but for a completely different reason
00:15:46  <trevnorris>heh, funny how that works.
00:16:22  * dshaw_joined
00:16:39  <bnoordhuis>wait, let me write a quick patch
00:17:17  <trevnorris>bnoordhuis: ok. also, frame #8, same thing with this->env()->context()
00:17:38  <trevnorris>ah, I see what you're saying.
00:19:27  <bnoordhuis>trevnorris: can you try https://github.com/bnoordhuis/node/commit/6f84c7e ?
00:19:37  <trevnorris>sure thing
00:20:51  * dshaw_quit (Ping timeout: 260 seconds)
00:21:21  <trevnorris>bnoordhuis: real quick. this->env()->context() is bad from the call into QueryWrap::Callback. so setting the Context from it probably won't work.
00:21:21  <trevnorris>i'm trying it now.
00:22:10  <trevnorris>bnoordhuis: nm. that worked.
00:22:27  <trevnorris>strange. must have had to do w/ gdb. thanks :)
00:23:42  <trevnorris>ok, running tests one last time
00:24:28  <trevnorris>bnoordhuis: test/simple/test-debug-signal-cluster.js is consistently failing for me now. looking into it.
00:24:44  <bnoordhuis>that test has known issues
00:25:30  <bnoordhuis>though it does seem to be failing every time now
00:25:50  <trevnorris>eh, just delete it ;)
00:26:45  <bnoordhuis>i've toyed with the idea
00:27:40  <trevnorris>it seems to be a complete race condition.
00:27:51  <trevnorris>if anything each of the three tests should be broken up into their own scripts.
00:29:23  <trevnorris>bnoordhuis: ok. i'm signed off. you can do what you want w/ that test.
00:32:48  <trevnorris>heh, must have one strange build state. that test just gave me a "FATAL ERROR: v8::HandleScope::CreateHandle() Cannot create a handle without a HandleScope"
00:34:23  <tjfontaine>I think we should unconditionally abort in FatalError so you have a useful core file
00:35:26  <bnoordhuis>agreed
00:35:45  <trevnorris>DIE DIE DIE!!!
00:36:03  <bnoordhuis>i know what the (or at least a) issue with that test is: it calls EnableDebug() before v8 has initialized
00:36:30  <bnoordhuis>EnableDebug() emits an event to js land but only if there is a js land (which there isn't)
00:36:55  <trevnorris>heh, awesome.
00:37:36  <trevnorris>tjfontaine: don't we already?
00:37:48  <trevnorris>tjfontaine: I think you mean OnFatalError
00:38:50  <trevnorris>oh wait. i forgot that abort() was just to suppress compiler warnings.
00:41:47  * st_lukejoined
00:42:16  * brsonjoined
00:42:21  * brsonquit (Client Quit)
00:42:30  * brsonjoined
00:51:22  * st_lukequit (Remote host closed the connection)
00:51:50  * st_lukejoined
00:54:09  * sblomquit (Ping timeout: 252 seconds)
00:54:25  <bnoordhuis>okay, i'll fix that cluster debug test tomorrow. i know how to fix but i'm going to sleep for a few hours first :)
00:56:14  * st_lukequit (Ping timeout: 240 seconds)
01:00:30  * st_lukejoined
01:00:54  * bnoordhuisquit (Ping timeout: 246 seconds)
01:01:38  * mikealquit (Quit: Leaving.)
01:09:24  <trevnorris>heh
01:17:38  * dshaw_joined
01:20:04  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:21:54  * dshaw_quit (Ping timeout: 246 seconds)
01:32:03  * zz_karupanerurachanged nick to karupanerura
01:41:21  * c4milojoined
01:46:43  * c4miloquit (Ping timeout: 272 seconds)
01:48:04  * karupanerurachanged nick to zz_karupanerura
01:53:07  * zz_karupanerurachanged nick to karupanerura
02:01:15  <hueniverse>0.10.22 tomorrow?
02:02:49  * st_lukequit (Remote host closed the connection)
02:07:33  * bnoordhuisjoined
02:09:31  * abraxasjoined
02:11:57  * bnoordhuisquit (Ping timeout: 246 seconds)
02:13:16  * skabbesquit (Quit: skabbes)
02:18:03  * dshaw_joined
02:22:27  * dshaw_quit (Ping timeout: 246 seconds)
02:40:22  * st_lukejoined
02:41:43  <tjfontaine>hueniverse: that's my plan yes, presuming I am satisfied that I have found all places this may be happening
02:42:11  <robonerd>can anyone explain to me in no more than 2 sentences what libuv offers to a C application developer?
02:42:20  <robonerd>please :)
02:42:28  <hueniverse>tjfontaine: two of us need to go out and binge on some scotch after this
02:43:24  * jmar777quit (Remote host closed the connection)
02:51:09  <robonerd>bueller?
02:52:59  <hueniverse>robonerd: you should ask that in the am PT. that's when the core team is active and can help you out.
02:53:40  <robonerd>hueniverse hey thank you for the information. i will do that! :D
02:54:02  * abraxasquit (Remote host closed the connection)
02:54:18  <inolen>robonerd: between the highlights here https://github.com/joyent/libuv
02:54:23  <inolen>and http://nikhilm.github.io/uvbook/basics.html
02:54:30  <inolen>you should be able to get a good idea of what libuv is
02:55:53  <robonerd>inolen thankz for the links, reading.
02:55:56  <robonerd>..
03:01:36  <robonerd>looks like libuv's architecture is like erlang's vm
03:01:46  <robonerd>supervisor chain in form of process children
03:01:56  <robonerd>async, event riven
03:02:00  <robonerd>d
03:05:47  * bradleymeckjoined
03:07:36  <tjfontaine>hueniverse: sold.
03:09:08  * abraxasjoined
03:09:56  * skabbesjoined
03:13:19  <robonerd>damn, i can't possibly finish the video of bert bedler. it's taking so many words to say the meaning
03:13:27  <robonerd>no offense of course :D
03:19:00  * paulfryzeljoined
03:25:09  * abraxasquit (Remote host closed the connection)
03:29:35  * c4milojoined
03:29:47  * brsonquit (Ping timeout: 260 seconds)
03:31:26  * abraxasjoined
03:34:06  * c4miloquit (Ping timeout: 252 seconds)
03:38:30  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:40:13  * AvianFlujoined
03:41:05  * robonerdchanged nick to testr0n
03:48:48  * amartensjoined
03:51:00  * sblomjoined
03:55:55  * sblomquit (Ping timeout: 272 seconds)
04:01:04  * amartensquit (Quit: Leaving.)
04:11:04  * abraxasquit (Remote host closed the connection)
04:14:53  * abraxasjoined
04:19:47  * abraxasquit (Ping timeout: 260 seconds)
04:22:52  * amartensjoined
04:34:44  * brsonjoined
04:37:16  * abraxasjoined
04:43:10  * abraxasquit (Ping timeout: 244 seconds)
04:43:16  * brsonquit (Ping timeout: 268 seconds)
04:47:15  * brsonjoined
05:05:04  * abraxasjoined
05:05:51  * AvianFluquit (Remote host closed the connection)
05:06:42  * abraxasquit (Remote host closed the connection)
05:17:54  * c4milojoined
05:22:27  * c4miloquit (Ping timeout: 244 seconds)
05:27:45  * jmar777joined
05:36:07  * amartenspart
05:36:11  * amartensjoined
05:44:24  * stagasjoined
05:48:48  * st_lukequit (Remote host closed the connection)
05:55:01  * paulfryzelquit
05:58:01  * bradleymeckquit (Quit: bradleymeck)
06:02:27  * testr0nquit (Read error: Connection reset by peer)
06:02:59  * robonerdjoined
06:05:10  * robonerdquit (Read error: Connection reset by peer)
06:06:05  * robonerdjoined
06:10:46  * abraxasjoined
06:12:19  * defunctzombiechanged nick to defunctzombie_zz
06:17:05  * mikealjoined
06:24:04  * abraxasquit (Remote host closed the connection)
06:40:47  * jmar777quit (Remote host closed the connection)
06:41:17  <MI6>nodejs-v0.10-windows: #313 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/313/
06:58:09  * stagasquit (Quit: Bye)
07:06:19  * c4milojoined
07:10:43  * c4miloquit (Ping timeout: 252 seconds)
07:19:48  * abraxasjoined
07:25:39  * felixgejoined
07:25:42  * dshaw_joined
07:25:46  * felixgequit (Changing host)
07:25:46  * felixgejoined
07:31:24  * brsonquit (Read error: Connection reset by peer)
07:31:35  * brsonjoined
07:37:43  * rendarjoined
07:50:01  * bajtosjoined
08:10:54  * saghuljoined
08:15:24  * saghulquit (Ping timeout: 260 seconds)
08:33:43  * bajtosquit (Quit: bajtos)
08:42:16  * inolenquit (Quit: Leaving.)
08:52:03  * Kakerajoined
08:54:10  * bnoordhuisjoined
08:54:31  * c4milojoined
08:55:59  * hij1nxquit (Ping timeout: 240 seconds)
08:57:57  * brsonquit (Ping timeout: 268 seconds)
08:59:11  * c4miloquit (Ping timeout: 268 seconds)
09:00:57  * amartensquit (Quit: Leaving.)
09:01:20  * saghuljoined
09:09:09  * dshaw_quit (Quit: Leaving.)
09:13:01  * inolenjoined
09:14:49  * inolen1joined
09:14:49  * inolenquit (Read error: Connection reset by peer)
09:19:32  * inolen1quit (Ping timeout: 268 seconds)
09:56:21  * Kakeraquit (Ping timeout: 252 seconds)
10:08:23  * hzjoined
10:15:36  * inolenjoined
10:20:03  * inolenquit (Ping timeout: 244 seconds)
10:26:54  * deltalucajoined
10:37:57  <mmalecki>bnoordhuis: what's the reason process.send is sync anyway?
10:38:09  <mmalecki>bnoordhuis: (also, beers this week/weekend?)
10:38:57  * skabbesquit (Quit: skabbes)
10:39:12  <mmalecki>bnoordhuis: me being here is going to be bad for your Korsakoff's
10:40:26  <indutny>heya
10:40:42  <mmalecki>sup Fedor
10:42:51  * c4milojoined
10:47:25  * c4miloquit (Ping timeout: 244 seconds)
10:48:22  <bnoordhuis>mmalecki: ease of use, i guess
10:48:30  <MI6>nodejs-v0.10: #1592 UNSTABLE smartos-x64 (4/604) smartos-ia32 (4/604) osx-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1592/
10:48:36  <bnoordhuis>mmalecki: can't make it this weekend btw, i've a pretty full schedule
10:49:13  <bnoordhuis>man, the builtin debugger is so full of wtf
10:49:21  <mmalecki>bnoordhuis: np. let's get back to this the next week
10:51:49  * hij1nxjoined
10:53:13  <bnoordhuis>i've no idea what simple/test-debug-brk-no-arg is supposed to proof...
10:53:17  <bnoordhuis>mmalecki: yeah, sounds like a plan
10:55:40  * abraxasquit (Remote host closed the connection)
10:57:16  <bnoordhuis>indutny: pig
10:57:21  <indutny>what?
10:57:22  <bnoordhuis>hah, i mean 'ping'
10:57:27  <indutny>bnoordhuis: you, pig
10:57:28  <indutny>:)
10:57:39  <indutny>bnoordhuis: hello, anyway
10:57:40  <indutny>sup?
10:57:53  <bnoordhuis>hey. --debug-brk, that's supposed to block node until an external debug client connects, right?
10:59:01  <indutny>I guess yes.
10:59:24  <bnoordhuis>yeah, because it doesn't
10:59:46  <bnoordhuis>`node --debug-brk=1234` will drop you in the repl
10:59:49  * skabbesjoined
11:00:11  <bnoordhuis>the debugger _is_ listening on port 1234, that much is true
11:00:56  <bnoordhuis>so, bug or feature? seems like the former to me
11:01:48  <indutny>bnoordhuis: need to check v8 source first
11:01:55  <indutny>it might be something not that trivial
11:02:15  <indutny>I guess that we're inserting breakpoint at the top of the loaded module
11:02:24  <indutny>and debugger stops here and waits for the client
11:02:33  <indutny>and that just isn't happening to repl.js
11:03:15  <indutny>bnoordhuis: see?
11:03:16  <MI6>joyent/libuv: Fedor Indutny v0.10 * bbccafb : unix: fix reopened fd bug - http://git.io/hG-xVw
11:04:10  * skabbesquit (Ping timeout: 245 seconds)
11:04:46  <bnoordhuis>hrm, not sure
11:05:25  <bnoordhuis>i have a fix but the downside is that you can no longer kill the node process with ^C because the terminal is in raw mode
11:05:32  <indutny>heh
11:05:39  <indutny>bnoordhuis: going to merge v0.10 in master
11:05:41  <indutny>bnoordhuis: in libuv
11:05:44  <bnoordhuis>good
11:05:50  <indutny>btw
11:06:06  <indutny>forgot to reply to that PR thread. replacing watchers with loop->watchers won't work in that case
11:06:13  <indutny>because loop->watchers is NULL
11:06:29  <indutny>anyway
11:06:33  <indutny>it doesn't seem to be that bad
11:07:01  <indutny>oh wait
11:07:33  <indutny>why am I doing it there anyway
11:07:36  <indutny>https://github.com/joyent/libuv/compare/0c76cdb98ffa...bbccafbe7040#diff-4429fa62e3d0385de0bebfcd93980332R615
11:07:54  <indutny>it should be the other way around
11:07:57  <indutny>shit
11:08:01  <indutny>bnoordhuis: mind force pushing?
11:08:13  <indutny>or just a follow up commit?
11:08:28  <indutny>bnoordhuis: basically, going to negate condition there https://github.com/joyent/libuv/compare/0c76cdb98ffa...bbccafbe7040#diff-4429fa62e3d0385de0bebfcd93980332R614
11:08:35  <indutny>and use loop->watchers below it
11:09:01  <indutny>ah
11:09:02  <indutny>no
11:09:07  <indutny>even not that :)
11:09:19  <indutny>only condition should be negated
11:09:22  <indutny>bnoordhuis: yt?
11:09:34  <bnoordhuis>yep
11:09:58  <indutny>bnoordhuis: so force push or follow-up commit?
11:10:10  <bnoordhuis>the five minute timeframe has passed, has it not?
11:10:31  <bnoordhuis>on the other hand... just force-push it
11:10:31  <bnoordhuis>fixup commits are annoying
11:10:37  <indutny>ok
11:10:49  <indutny>running testes
11:10:52  <indutny>s/testes/tests/
11:12:24  <indutny>bnoordhuis: quick review, please https://gist.github.com/indutny/4f8f2cf75479a8e03776
11:12:33  <indutny>so the idea here
11:12:39  <indutny>is that if there were no watchers at all
11:12:46  <indutny>- we should not copy fake ones
11:12:50  <indutny>and if there were some - we should
11:13:01  <indutny>bnoordhuis: LGTY?
11:16:20  * inolenjoined
11:17:59  <indutny>bnoordhuis: ping?
11:18:30  <bnoordhuis>looking...
11:19:01  <bnoordhuis>indutny: in that case you can use loop->watchers
11:19:09  <bnoordhuis>btw, don't force-push after all
11:19:22  <bnoordhuis>we're way past the five minute window now
11:20:05  <indutny>bnoordhuis: I can't
11:20:09  <indutny>bnoordhuis: it was freed by realloc()
11:20:16  <indutny>well
11:20:21  <indutny>I can do it before realloc, on other hand
11:21:00  <bnoordhuis>that sounds better
11:21:07  <indutny>ok
11:21:09  * inolenquit (Ping timeout: 272 seconds)
11:21:12  <indutny>I'll push follow up commit soon
11:21:19  <indutny>bnoordhuis: btw, why is tty blocking?
11:21:31  <indutny>bnoordhuis: is there any serious reason for it?
11:21:40  <indutny>except console.log() not writing anything
11:22:08  <bnoordhuis>^ that. because people were losing log messages left and right
11:25:30  <MI6>joyent/libuv: Fedor Indutny v0.10 * f50ccd5 : core: fix fake watcher list and count preservation - http://git.io/yym0AQ
11:25:33  <indutny>bnoordhuis: haha
11:25:46  <indutny>bnoordhuis: do we have API method to make it non-blocking again?
11:26:30  <bnoordhuis>indutny: no
11:26:40  <indutny>bnoordhuis: mind if I'll add it?
11:26:50  <bnoordhuis>to libuv or node?
11:26:57  <indutny>at least to libuv
11:27:02  <indutny>and use it in node internally
11:27:06  <indutny>for child_process channel
11:27:12  <indutny>see https://github.com/joyent/node/issues/2598
11:27:27  <bnoordhuis>yeah, i know about that
11:27:42  <indutny>so
11:27:45  <indutny>yay or nay?
11:27:46  <bnoordhuis>there's a pretty big risk involved with making send() async
11:28:08  * indutnyis listening
11:28:09  <bnoordhuis>if the child isn't reading the data, or not fast enough, then it queues up in the master process
11:28:28  <bnoordhuis>right now, the master process blocks. not ideal either, of course
11:29:20  <bnoordhuis>okay, i'm going back to debugging debuggers
11:30:09  <indutny>bnoordhuis: okay
11:30:24  <indutny>bnoordhuis: I guess it should be fine in v0.11
11:30:32  <indutny>bnoordhuis: perhaps, too dangerous for v0.10
11:31:08  <MI6>joyent/libuv: Fedor Indutny master * 6149b66 : Merge branch 'v0.10' (+3 more commits) - http://git.io/8_7j_Q
11:33:09  <mmalecki>indutny: I'd love an API for making stdio async again
11:33:16  <indutny>well
11:33:23  <indutny>thinking about it now
11:33:35  <indutny>Perhaps, it could be async with some limitations
11:33:36  <indutny>like
11:33:43  <indutny>not queuing more than N write requests
11:33:52  <indutny>so, if child is too slow - it'll block anyway
11:34:00  <mmalecki>yeah. perhaps we could wait until it drains before exiting the process?
11:34:19  <indutny>I think that's what naturally should happen
11:34:25  <indutny>if you're not calling process.exit()
11:34:34  <mmalecki>right
11:34:54  <indutny>so
11:35:03  <indutny>the only problem is that all this writes will be blocking anyway
11:35:06  <indutny>but in another thread
11:35:23  <indutny>and
11:35:26  <indutny>will pile up
11:35:30  <indutny>until child will read them
11:37:42  <mmalecki>I'm wondering if you can make it non-blocking somehow
11:42:04  <indutny>oh btw
11:42:06  <indutny>it should not be blocking
11:42:08  <indutny>wtf
11:42:13  <indutny>it is a socketpair()
11:42:26  <indutny>ok, so its just requests that are piling up in parent's memory
11:45:45  <bnoordhuis>indutny: it's a socketpair so fds can be sent across (doesn't work with a regular pipe)
11:45:57  <indutny>indeed
11:46:01  <indutny>and its non-blocking socketpair()
11:46:02  * hzquit
11:46:07  <indutny>so my guess is that uv_write() is just looping
11:46:11  <indutny>uv__write()
11:47:06  <rendar>bnoordhuis, hmm isn't a socketpair a regular pipe?
11:47:28  <indutny>no
11:47:34  <indutny>rendar: it allows writing and reading on both sides
11:47:42  <rendar>oh, i see
11:47:55  <rendar>so socketpair() uses socket unix instead of pipes under the hood
11:48:02  <bnoordhuis>yep
11:48:32  <rendar>bnoordhuis, so with that socketpair i will ot have the problem of a full pipe? or not?
11:49:14  <bnoordhuis>same issue. there's no escape hatch here :)
11:49:49  <rendar>eheh
11:49:49  <indutny>heh
11:50:03  <indutny>bnoordhuis: exactly, but at least it won't loop in main thread :)
11:51:20  <rendar>bnoordhuis, what you think about the fact that libuv should use one inotify fd per-directory open, or a global inotify fd and then add directory to watch in that one? what is the best method?
11:51:24  <rendar>(in linux)
11:52:48  <bnoordhuis>rendar: libuv uses one inotify fd per event loop and multiplexes that for all file watchers
11:53:11  <bnoordhuis>we used to have a one-fd-per-watcher model but that way you quickly run out of inotify fds
11:53:32  <bnoordhuis>they're pretty limited (but iirc we discussed that a while ago so i'm not telling you anything new :)
11:55:34  <bnoordhuis>okay, gotta run. back in ~2 hours
11:56:39  <indutny>bnoordhuis: cya
11:56:41  <rendar>bnoordhuis, oh i see
12:03:08  * bnoordhuisquit (Ping timeout: 260 seconds)
12:08:05  * Kakerajoined
12:10:15  * skabbesjoined
12:16:14  * skabbesquit (Ping timeout: 240 seconds)
12:17:06  * inolenjoined
12:21:12  * inolenquit (Ping timeout: 240 seconds)
12:28:41  * brsonjoined
12:31:05  * c4milojoined
12:35:33  * c4miloquit (Ping timeout: 245 seconds)
12:45:09  * piscisaureus_joined
12:47:16  <piscisaureus_>http://en.wikipedia.org/wiki/Vacuum_catastrophe
12:56:20  * abraxasjoined
13:01:14  * abraxasquit (Ping timeout: 244 seconds)
13:17:51  * inolenjoined
13:22:26  * inolenquit (Ping timeout: 244 seconds)
13:40:30  <indutny>piscisaureus_: hey bert
13:40:39  <piscisaureus_>hey fedor
14:01:14  * karupanerurachanged nick to zz_karupanerura
14:02:14  * bnoordhuisjoined
14:10:47  * jmar777joined
14:17:43  <MI6>joyent/node: yangguo@chromium.org v0.10 * 007393a : v8: use correct timezone information on Solaris - http://git.io/xnQE4Q
14:18:34  * inolenjoined
14:19:24  * c4milojoined
14:19:30  <mmalecki>bnoordhuis: that ^ took a while ;)
14:22:45  * inolenquit (Ping timeout: 246 seconds)
14:23:53  * c4miloquit (Ping timeout: 245 seconds)
14:25:17  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
14:26:25  * saghuljoined
14:29:07  <MI6>nodejs-v0.10: #1593 UNSTABLE smartos-x64 (5/604) smartos-ia32 (4/604) linux-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1593/
14:32:08  <bnoordhuis>mmalecki: i landed that over a year ago in the v0.8 branch actually
14:32:40  <bnoordhuis>but the v8 in v0.10 turns out not to have the upstream commit and apparently it got lost when merging v0.8 into v0.10
14:34:19  * Kakeraquit (Ping timeout: 272 seconds)
14:58:11  * defunctzombie_zzchanged nick to defunctzombie
15:08:10  * AvianFlujoined
15:10:32  * hzjoined
15:17:07  <bnoordhuis>ffs... [pid 22830] +++ killed by SIGUSR1 +++
15:17:19  <bnoordhuis>our debugger really is one big cluster of wtfs
15:17:34  <bnoordhuis>i'm not even sure why i'm spending time on fixing it
15:17:39  <bnoordhuis>does anyone actually use it?
15:19:19  * inolenjoined
15:21:07  <MI6>nodejs-master: #694 UNSTABLE smartos-ia32 (6/675) linux-x64 (1/675) smartos-x64 (7/675) osx-ia32 (1/675) http://jenkins.nodejs.org/job/nodejs-master/694/
15:23:16  * inolen1joined
15:23:28  * inolenquit (Ping timeout: 245 seconds)
15:24:45  <indutny>bnoordhuis: :)
15:24:53  <indutny>bnoordhuis: I do quite regularly
15:25:01  <indutny>though, never seen any bugs myself
15:25:10  <indutny>but I kinda hate how its a bit different from gdb
15:25:11  <indutny>:)
15:28:39  <bnoordhuis>it's mostly that the way it's hooked up now is so incredibly brittle
15:28:55  <bnoordhuis>i've wasted most of the day trying to work around issues with it
15:29:01  <bnoordhuis>kind of fed up with that
15:32:07  <bnoordhuis>indutny: you really use it though? i either use node-inspector or netcat to port 5858
15:32:22  <indutny>yeah, I use it
15:32:34  <indutny>when debugging remotely
15:32:41  <indutny>and often locally too
15:35:49  * defunctzombiechanged nick to defunctzombie_zz
15:37:01  <bnoordhuis>hm, okay
15:37:26  <bnoordhuis>i'm going to poll the mailing list, see if anyone else uses it
15:37:30  <indutny>:)
15:37:37  <indutny>well
15:37:44  <indutny>it may be not a bad idea to remove it after all
15:44:51  * hzquit
15:45:07  * kevinswiberjoined
15:49:55  * wolfeidauquit (Ping timeout: 252 seconds)
15:50:38  * pachetjoined
15:50:38  * pachetquit (Changing host)
15:50:38  * pachetjoined
15:53:16  * wolfeidaujoined
15:53:42  <bnoordhuis>ffs, i have 3 hours of conference calls scheduled for tonight
16:01:55  * octetcloudjoined
16:04:43  * wolfeidauquit (Ping timeout: 245 seconds)
16:05:30  <indutny>:)
16:05:41  * brsonquit (Ping timeout: 252 seconds)
16:07:42  * c4milojoined
16:12:28  * c4miloquit (Ping timeout: 264 seconds)
16:15:51  * mikealquit (Quit: Leaving.)
16:17:03  * hzjoined
16:17:33  * bnoordhuisquit (Ping timeout: 272 seconds)
16:17:51  * wolfeidaujoined
16:32:02  * Kakerajoined
16:43:32  * c4milojoined
16:43:34  * defunctzombie_zzchanged nick to defunctzombie
16:46:46  <trevnorris>morning
16:48:56  * inolen1quit (Quit: Leaving.)
16:49:16  * mikealjoined
16:51:47  <indutny>morning
16:53:44  * c4miloquit (Remote host closed the connection)
16:58:05  * abraxasjoined
16:59:54  * sblomjoined
17:02:15  * bnoordhuisjoined
17:02:51  <bnoordhuis>call?
17:02:53  * abraxasquit (Ping timeout: 252 seconds)
17:03:27  <trevnorris>sure
17:04:49  <bnoordhuis>https://plus.google.com/hangouts/_/calendar/aXNhYWNzY2hsdWV0ZXJAZ21haWwuY29t._8gr32d1p611k8b9o6cr48b9k6op3eba18cr32b9k88s3cgpi8d2k8dq560
17:05:23  <bnoordhuis>c'mon everyone
17:05:45  <tjfontaine>on my way
17:10:49  <trevnorris>indutny: call?
17:10:54  <trevnorris>piscisaureus_: ?
17:10:54  <indutny>oh gosh
17:11:02  <indutny>5 minutes
17:11:45  * amartensjoined
17:12:09  * dap_joined
17:15:54  <bnoordhuis>so v8 lands my patch with "fixups" that then need fixing up in a follow-up commit...
17:16:13  <bnoordhuis>https://github.com/v8/v8/commit/b2e94b6 - they changed the clock id from -1 to 0 - which is a valid clock id...
17:16:45  <bnoordhuis>https://github.com/v8/v8/commit/54679da <- the fixup
17:17:27  * c4milojoined
17:18:43  <indutny>no, not joining
17:18:47  <indutny>sorry
17:19:07  * c4miloquit (Read error: Connection reset by peer)
17:19:12  * c4milo_joined
17:19:44  * inolenjoined
17:21:30  * inolenquit (Read error: Connection reset by peer)
17:21:32  * inolen1joined
17:22:56  * bnoordhu1sjoined
17:24:25  * c4milo_quit (Ping timeout: 272 seconds)
17:25:57  * inolen1quit (Ping timeout: 248 seconds)
17:27:30  * bnoordhu1squit (Ping timeout: 245 seconds)
17:31:03  <trevnorris>bnoordhuis: how about we add an ASSERT macro to util.h for checks we only want to go into debug mode?
17:31:30  <bnoordhuis>trevnorris: i'm very much in favor of that. i'd like to split out our asserts into ASSERTs and CHECKs
17:31:52  <bnoordhuis>ASSERT for debug-only stuff, CHECK for things that shouldn't fail
17:32:14  <trevnorris>cool. answered my question mid-type :)
17:32:19  <trevnorris>I like it.
17:34:12  * deltalucaquit (Ping timeout: 246 seconds)
17:34:17  * mmaleckichanged nick to mmalecki_
17:34:19  * mmalecki_changed nick to mmalecki
17:34:24  <bnoordhuis>othiym23: "I have used the debugger for several hundred hours in the last year alone." <- really? but it's so crappy
17:34:40  * bradleymeckjoined
17:34:53  * mikealquit (Quit: Leaving.)
17:35:16  <trevnorris>bnoordhuis: I think he enjoys self inflicted pain.
17:37:36  * c4milojoined
17:38:48  * kevinswiberquit (Remote host closed the connection)
17:39:23  * kevinswiberjoined
17:41:10  <trevnorris>is anyone else's screen jumping around everywhere when typing into a github comment box?
17:41:26  <trevnorris>or is it a plugin I have installed? very annoying.
17:41:57  * c4miloquit (Ping timeout: 248 seconds)
17:43:26  * kevinswiberquit (Ping timeout: 240 seconds)
17:48:10  * st_lukejoined
17:50:01  <trevnorris>bnoordhuis: so are you planning on adding back the context wrap around uv_run and landing your patch?
17:52:07  <bnoordhuis>trevnorris: probably, unless i can get this debugger bug fixed
17:52:29  <bnoordhuis>because it _is_ a bug; try running `node --debug-brk=1234`
17:52:51  <bnoordhuis>it's supposed to wait until the debug clients connects but instead it just drops you in a repl
17:53:32  <trevnorris>heh
17:54:32  <bnoordhuis>btw, i have that screen jumping thing too on github
17:54:44  <bnoordhuis>at first i thought it was vimperator but that doesn't seem to be it
17:54:52  <trevnorris>bnoordhuis: it's turtles all the way down dude. I think you've now entered but 4 or 5 from fixing a previous bug.
17:55:04  <bnoordhuis>yeah. it never ends...
17:55:09  <tjfontaine>that's what happens when you pull a thread
17:55:36  <trevnorris>hah
17:55:51  <trevnorris>i'm all for built-in debugger hooks and allowing people to build their own.
18:06:03  * TooTallNatejoined
18:13:53  * dshaw_joined
18:17:16  <hueniverse>tjfontaine: what's the chance of a new build before 3pm today?
18:22:54  <trevnorris>piscisaureus_: rough patch, still needs tests, docs, etc.: https://github.com/joyent/node/pull/6502
18:22:56  <trevnorris>groundwater_: ^
18:23:26  <trevnorris>also need to fix that stupid error event.
18:24:45  * inolenjoined
18:25:49  * AvianFluquit (Remote host closed the connection)
18:28:40  * dshaw_quit (Ping timeout: 246 seconds)
18:29:01  * AvianFlujoined
18:29:12  <tjfontaine>hueniverse: yes, there's a good chance of that
18:29:25  <groundwater_>trevnorris: ACK
18:29:39  <trevnorris>groundwater_: is that about what you'd need?
18:30:19  <hueniverse>tjfontaine: we got a big stress test tonight. would love to have some machines moved over to 0.10.22
18:34:00  <tjfontaine>hueniverse: right, ok
18:34:30  * piscisaureus_quit (Read error: Connection reset by peer)
18:34:50  * piscisaureus_joined
18:36:29  <tjfontaine>sblom, piscisaureus_: what's "\Device\Afd"? these hanging libuv tests have a ton of them as open files
18:37:30  <trevnorris>othiym23: just because I like you so much, i'm thinking of a reimplementation of async listeners. :)
18:37:46  <trevnorris>luckily it hasn't gone stable yet, so still have some wiggle room.
18:38:12  * dshaw_joined
18:38:21  <rendar>trevnorris, its the Ancillary Function Driver, basically all winsocks operations gets thorugh it :)
18:38:30  <trevnorris>tjfontaine: ^
18:38:47  <tjfontaine>rendar: thanks
18:38:48  <rendar>oh, sorry, i meant tjfontaine
18:38:50  <rendar>:-)
18:38:52  <trevnorris>tjfontaine: you seriously have to change your name man ;)
18:38:57  <rendar>lol
18:39:03  <tjfontaine>trevnorris: I was here first :P
18:39:20  <rendar>maybe to fontainetj
18:39:21  <tjfontaine>I was on freenode as tjfontaine when it was still OpenProjects :)
18:39:36  <rendar>tjfontaine, lol, was it 2001 or something?
18:39:39  <trevnorris>DAMN YOU!!!
18:39:40  <tjfontaine>indeed
18:39:49  * kevinswiberjoined
18:40:19  <trevnorris>tjfontaine: know of a way to see when a nick was registered?
18:40:23  <trevnorris>can't find the command
18:40:26  <tjfontaine>/msg nickserv info
18:40:28  <tjfontaine>*should* be
18:40:40  <tjfontaine>anyway, freenode started doing auto de-reg stuff
18:41:15  <tjfontaine>so when OPN turned into Freenode I lost my original date because I have been on OFTC since, the *only* reason I'm on freeload is because of node
18:41:15  <trevnorris>well poop. I only go back to 2009. :P
18:41:36  <tjfontaine>my oftc registration:
18:41:37  <tjfontaine>[11-12] 18:41:23 -NickServ(services@services.oftc.net)- Time registered: Thu 27 Jun 2002 13:30:47 +0000 (11y 4m 18d 05:10:36 ago)
18:41:51  <trevnorris>wtf. yeah. you have me there.
18:42:00  <tjfontaine>I've been on irc for a while.
18:42:22  <trevnorris>buy hey, at least I don' get confused with tjholowaychuk :P
18:42:36  <tjfontaine>sigh
18:42:57  <trevnorris>who sort of creeps me out, btw. maybe that'd change if I ever met the guy.
18:43:16  <MI6>libuv-v0.10: #129 FAILURE smartos (2/189) windows (7/190) http://jenkins.nodejs.org/job/libuv-v0.10/129/
18:43:34  <bnoordhuis>trevnorris: why is that? because he's canadian?
18:43:34  <tjfontaine>gah I'm back into too many tabs open again
18:44:06  <trevnorris>bnoordhuis: no. it's his hair style and lip ring.
18:44:10  <MI6>libuv-master: #332 FAILURE http://jenkins.nodejs.org/job/libuv-master/332/
18:44:25  <bnoordhuis>oh, he has one? that's so emo
18:44:43  <trevnorris>EXACTLY!
18:44:59  <MI6>libuv-master-gyp: #287 FAILURE http://jenkins.nodejs.org/job/libuv-master-gyp/287/
18:45:05  * st_lukequit (Remote host closed the connection)
18:45:23  <bnoordhuis>what's up with the failures?
18:45:26  <trevnorris>bnoordhuis: ok, i've been trying to do this constant's first in conditionals thing. for some reason it bends my brain logic a little.
18:45:38  * st_lukejoined
18:46:00  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:46:10  <bnoordhuis>test/run-tests.o:(.data+0x670): undefined reference to `run_test_tcp_close_accept' ...
18:46:11  * st_lukequit (Read error: Connection reset by peer)
18:46:26  * st_luke_joined
18:47:14  <trevnorris>bnoordhuis: you think you'll land 6499 before EOD?
18:47:23  <bnoordhuis>oh yeah, probably
18:47:35  <bnoordhuis>let me fix up libuv first, then i'll fix up that PR
18:47:35  <trevnorris>coolio. thanks.
18:47:47  <tjfontaine>doing a libuv 0.10 release
18:47:51  <bnoordhuis>there's a company meeting in between though
18:47:52  <tjfontaine>anything that needs to go in that?
18:48:05  <groundwater_>trevnorris: commented on issue
18:48:06  <tjfontaine>*else
18:48:09  <bnoordhuis>tjfontaine: let me check if it's not broken
18:48:21  <bnoordhuis>those jenkins failures are kind of worrisome
18:48:29  <trevnorris>man, all you and your meetings. I have two 30 min meetings a week and that's about all I can handle.
18:48:39  <tjfontaine>well, two tests are sporadically failing on windows
18:48:47  <tjfontaine>I can't get good repro's on them
18:48:59  <trevnorris>groundwater_: confusing people is part of the fun :P
18:49:27  <trevnorris>groundwater_: and if you think about it, we are adding a listener to the EE constructor itself, right? ;)
18:49:32  <bnoordhuis>trevnorris: yeah, this week is pretty extreme
18:49:48  <trevnorris>bnoordhuis: well, i'm mainly looking forward to seeing your example libuv app.
18:49:49  <groundwater_>trevnorris: technically you're right, but product-wise i think it's a bad idea
18:50:02  <bnoordhuis>trevnorris: you can see it now - it's in the samples branch :)
18:50:03  <tjfontaine>this week is joyent engineering all hands for me as well -- so the office is inundated with all our remote folk
18:50:12  <trevnorris>ooh, yeah!
18:50:19  <groundwater_>trevnorris: what about "addEventBridge" or something
18:50:41  <trevnorris>or, knowWhenShitHappens()
18:50:43  * st_luke_quit (Ping timeout: 246 seconds)
18:50:56  <groundwater_>let's just name it whatever LOUDBOT says next
18:51:02  <groundwater_>HOW DOES THAT SOUND
18:51:22  <trevnorris>ok. it will be EventEmitter.rinkoKikuchi()
18:51:31  <bnoordhuis>indutny: fedor, when you merge v0.10 into master, please make sure everything actually _builds_
18:51:42  <indutny>hm...
18:51:43  <indutny>it was
18:51:46  <bnoordhuis>nuh uh
18:51:50  <indutny>./gyp_uv.py -f ninja
18:51:54  <indutny>ninja -C out/Debug
18:51:56  <groundwater_>trevnorris: i am totally okay with that name
18:51:58  <indutny>I even run some tests
18:52:03  <bnoordhuis>../../test/test-tcp-close-accept.c:98:3: error: incompatible type for argument 3 of ‘uv_tcp_connect’
18:52:06  <trevnorris>groundwater_: awesome. that settles it.
18:52:17  <indutny>hm...
18:52:33  <indutny>I'd say its quite odd
18:52:36  <indutny>let me check/fix it
18:52:44  <bnoordhuis>if not to say enigmatic
18:52:49  <bnoordhuis>nm, i'll fix it up
18:52:57  <indutny>oh right
18:52:57  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:53:12  <indutny>bnoordhuis: sorry about that
18:53:14  <bnoordhuis>tjfontaine: v0.10 is good to go
18:53:19  <tjfontaine>bnoordhuis: thanks
18:53:20  <indutny>perhaps I was building without that test for some reasons
18:53:23  * st_lukejoined
18:53:27  <trevnorris>groundwater_: this implementation is making me rethink the asyncListener implementation. the way I'm keeping track via counters is wicked fast, and i'm wondering if I can use the same to speed up performance.
18:54:06  <bnoordhuis>indutny: well okay. just do a clean build next time. make sure you test both the gyp and the autotools build
18:54:16  * pooyajoined
18:54:19  <indutny>bnoordhuis: ok
18:54:24  <trevnorris>mraleph: so, my question about Function#{call,apply,bind} and IC was because for some strange reason I thought it might be that using those would force the code to bypass IC and enter the runtime again.
18:54:46  <trevnorris>mraleph: but after studying your blog post on IC implementation, think I understand it a bit better.
18:55:13  <groundwater_>trevnorris: if the tests still pass, i'll have nothing but praise for you
18:55:35  <MI6>joyent/libuv: tjfontaine created tag v0.10.19 - http://git.io/ablIAg
18:55:37  <MI6>joyent/libuv: Timothy J Fontaine v0.10 * 1578a5a : Now working on v0.10.20 (+1 more commits) - http://git.io/i1I1ug
18:55:40  * bnoordhu1sjoined
18:56:15  * octetcloudquit (Ping timeout: 245 seconds)
18:56:15  * st_lukequit (Read error: Connection reset by peer)
18:56:17  <trevnorris>groundwater_: thanks :) usually I _hate_ creating function closures but v8 has some optimization that if you pass the "arguments" object to .apply() it does some strange optimization magic.
18:56:35  * st_lukejoined
18:56:42  <trevnorris>groundwater_: so I can create a function closure then pass everything up to js in one swoop and run all the callbacks from js.
18:57:22  <trevnorris>groundwater_: thus bypassing the jumps. this should at least half the basic performance impact.
18:57:32  <trevnorris>*jump from c++ to js and back.
18:58:25  <groundwater_>do you just benchmark these by timing a tight loop, or are there better performance tools?
18:58:27  <trevnorris>groundwater_: for EventEmitter#on(), what information would you like to be passed? right now I'm just passing the context. would that be enough?
18:59:00  <trevnorris>groundwater_: here's a basic test: https://gist.github.com/trevnorris/7436683
18:59:05  * kellabytequit (Quit: Quit)
18:59:19  <trevnorris>groundwater_: that does leave out key things like switching up execution order, etc. but the basics are there.
18:59:20  * abraxasjoined
18:59:21  <MI6>libuv-v0.10-gyp: #100 FAILURE osx-ia32 (3/190) windows-x64 (8/190) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/100/
18:59:38  <trevnorris>groundwater_: and honestly the difference is sub 15ns/op so you won't even notice at the macro level.
18:59:39  <groundwater_>trevnorris: perhaps just a storage object, like the asyncListener function that runs whenever an async call is made
19:00:05  <groundwater_>trevnorris: actually let me think about it in detail
19:00:18  * octetcloudjoined
19:02:27  <MI6>nodejs-v0.10-windows: #314 UNSTABLE windows-ia32 (10/604) windows-x64 (12/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/314/
19:02:38  <trevnorris>groundwater_: is othiym23 around to chime in?
19:02:42  <tjfontaine>bnoordhuis, bnoordhu1s: lgty? https://gist.github.com/tjfontaine/7394912/raw/c33366d117ec3e5d10267e722d5a1dcf6845fdf5/0001-src-HandleWrap-OnClose-needs-HandleScope.patch
19:02:44  * TooTallNatejoined
19:02:59  <groundwater_>trevnorris: not yet, i'll ask him when he's in
19:03:06  <tjfontaine>I'm going to add more to the commit message
19:03:31  <tjfontaine>and there should be a block comment somewhere around MakeCallback or something
19:03:32  * bnoordhu1squit (Remote host closed the connection)
19:03:40  * abraxasquit (Ping timeout: 246 seconds)
19:03:49  <groundwater_>trevnorris: i'm trying to think of things to pass in which cannot be obtained in another way
19:03:56  <trevnorris>tjfontaine: lgtm, fww
19:03:58  <trevnorris>*fwiw
19:04:01  <tjfontaine>nod
19:04:28  <groundwater_>trevnorris: i suppose a reference to the EE
19:04:32  <tjfontaine>trevnorris: not sure if in reality it should be in the larger scope
19:04:55  <tjfontaine>I don't think there's any real harm in putting it in the wider scope
19:04:56  <trevnorris>groundwater_: for the "before" callback I was thinking possibly the callback type (e.g. 'data')
19:05:21  <groundwater_>trevnorris: yes, i think we should keep the same semantics as asyncListener
19:05:35  <groundwater_>the before callback should receive -> (data, context)
19:05:36  <trevnorris>tjfontaine: there's no harm, but imho no reason to place a handlescope in a greater scope than necessary.
19:06:35  <trevnorris>groundwater_: well, the before in asyncListener receives (context, value)
19:06:36  <tjfontaine>there's really not much overhead to a scope, anyway I'm not fussed either way, going to write this block comment for node.h and a longer commit message
19:06:46  <trevnorris>*context => "this" of the calling function
19:07:02  <trevnorris>tjfontaine: cool.
19:07:16  <groundwater_>trevnorris: right, well 'this' should prob. be the EE, what do you think?
19:07:19  <tjfontaine>[also why can't we just have a HandleScope in MakeCallback]
19:07:53  <tjfontaine>I guess unless we wan to enforce that objects created out of the MakeCallback should be owned by the calling scope and not MakeCallback's
19:07:58  <trevnorris>tjfontaine: i'm not sure. that's the way it operated when I started working w/ it so just left it that way.
19:08:08  <tjfontaine>it just seems very error prone
19:08:12  <trevnorris>probably ask ben about that.
19:08:28  <groundwater_>trevnorris: i think the only think these callback needs is a reference to the EE
19:08:30  <trevnorris>groundwater_: you mean the EE instance, or the require('events') object?
19:08:41  <groundwater_>trevnorris: the EE instance, sorry
19:08:51  <groundwater_>i should have said the emitter instance
19:08:52  <trevnorris>yeah, that's what the "this" is.
19:09:28  <groundwater_>trevnorris: so what are the possible callbacks, 'create', 'before', 'after', and 'on'?
19:09:35  <trevnorris>groundwater_: the patch contains a usage in domains. that should give reference to how it's to be used.
19:09:55  <trevnorris>groundwater_: sure. all but 'on' is already implemented.
19:10:23  <groundwater_>trevnorris: okay how about we call it EventEmitter.addGlobalObserver()
19:10:49  <groundwater_>i want to scare people away from the function unless they're REALLY SURE
19:11:14  <trevnorris>groundwater_: slight change. EventEmitter.addObservers(). since you can add multiple types, or observers.
19:11:47  <trevnorris>and it's still only on the EventEmitter, so I think Global is too, well, Global :P
19:11:55  <groundwater_>trevnorris: i still like the word "Global" or "Class", something that reinforces the idea that it's everywhere
19:12:32  <groundwater_>like, this observer doesn't just run on an instance, it's all EEs
19:12:56  <trevnorris>well, it's everywhere, for the EventEmitter. if it truly where everywhere then, imho, it'd also include the asyncListener stuff.
19:13:27  <groundwater_>is that your end-game?
19:13:44  <trevnorris>groundwater_: and I think that should be apparent since they're running EventEmitter.addStuff() instead of EventEmitter#addStuff()
19:13:59  <trevnorris>hell no. I want EE removed like an overgrown cyst.
19:14:03  <groundwater_>i think you give people too much credit
19:14:24  <groundwater_>let me put it this way, are you willing to buy me a beer every time someone confuses the two? LOL
19:14:55  <trevnorris>personally I think this is something people won't be using unless they actually understand. it's not like the stream API where everyone has to use it.
19:15:14  <groundwater_>how about "addObservers"?
19:15:18  <trevnorris>it's a very specific hook API useful for a very small portion of the the user base.
19:15:47  <trevnorris>heh
19:15:55  <trevnorris><trevnorris> groundwater_: slight change. EventEmitter.addObservers().
19:16:04  <trevnorris>yeah, i'm cool w/ that :)
19:16:05  <groundwater_>+1
19:16:25  <groundwater_>i would gladly commit that change with the message "groundwater has no faith in humanity"
19:16:43  <trevnorris>haha, ok.
19:16:59  <groundwater_>no i'm joking, it's all you buddy!
19:17:54  <MI6>nodejs-master-windows: #479 UNSTABLE windows-x64 (27/675) windows-ia32 (25/675) http://jenkins.nodejs.org/job/nodejs-master-windows/479/
19:18:32  <MI6>libuv-v0.10: #130 UNSTABLE smartos (3/189) windows (9/190) http://jenkins.nodejs.org/job/libuv-v0.10/130/
19:19:52  <trevnorris>groundwater_: ok, going to add one more, 'error'. that's a specific enough case, and listening for all before/after will completely kill performance.
19:20:32  <groundwater_>what will error catch? throws for listeners or 'error' events?
19:21:06  <trevnorris>dunno. still figuring out the details. also, this doesn't address catching when a listener is removed.
19:21:40  <trevnorris>groundwater_: and, are you, or are you not planning on the callback passed to EE#on() to also be passed to the 'on' callback?
19:23:14  <groundwater_>trevnorris: hmm...
19:24:34  <trevnorris>groundwater_: guess that's a rhetorical question. because the only reason to expect to receive the callback is to be able to return a wrapped version of the callback, which would remove the ability to properly have the callback removed, since it'd be a new function instance.
19:24:42  <trevnorris>so the callback can't be passed.
19:24:48  <trevnorris>well, it can, but it'd be useless.
19:25:41  <tjfontaine>https://gist.github.com/tjfontaine/fb0722bf620cf49a269e
19:26:12  <MI6>libuv-v0.10-gyp: #101 FAILURE windows-x64 (7/190) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/101/
19:26:23  <MI6>libuv-review: #84 FAILURE http://jenkins.nodejs.org/job/libuv-review/84/
19:26:48  <trevnorris>tjfontaine: lgtm
19:26:59  <tjfontaine>trevnorris: k thanks
19:27:15  <tjfontaine>have you also verified it fixes the memory leak? :)
19:27:26  * indexzeroquit (Quit: indexzero)
19:27:33  <trevnorris>nope. let me check that.
19:29:05  * kellabytejoined
19:30:28  * mikealjoined
19:32:53  * pooyaquit (Quit: pooya)
19:34:24  <trevnorris>tjfontaine: sec. the leak on v0.10 takes a little longer to reproduce.
19:34:26  <MI6>libuv-node-integration: #302 UNSTABLE smartos-x64 (4/604) smartos-ia32 (4/604) http://jenkins.nodejs.org/job/libuv-node-integration/302/
19:34:46  <tjfontaine>trevnorris: the question is how aggresive is the leak, or is normal stablization
19:35:16  <tjfontaine>I'm not seeing any heap growth now
19:35:36  <tjfontaine>but churn in the mmap regions, so that's likely v8 nonsense
19:36:45  <tjfontaine>ya, things are very stable here actually, based on umem caches (i.e. traditional heap)
19:38:12  <tjfontaine>ya *quite* stable
19:38:39  <tjfontaine>rss gets around 53M and holds
19:39:55  <othiym23>bnoordhuis: it's crappy but it's what I've got
19:40:24  <othiym23>bnoordhuis: until one of mdb, lldb or gdb gains the ability to step through V8's JS line by line, I need *something*
19:41:00  <tjfontaine>othiym23: that was actually a potential hack event idea, that dap almost got sold on last night
19:41:20  <othiym23>bnoordhuis: writing instrumentation is too hard to do with just print statements and tracing
19:42:12  <trevnorris>tjfontaine: not that it matters, but https://gist.github.com/trevnorris/7437358
19:43:05  <tjfontaine>are these allocs or valid mem pages/
19:43:11  <tjfontaine>the *count of allocs
19:43:15  <tjfontaine>or the size of valid pages
19:45:57  * felixgequit (Ping timeout: 252 seconds)
19:46:14  <trevnorris>tjfontaine: sec. i'll get some better output. those numbers are just counters.
19:46:42  <tjfontaine>ok, what we want to know are pages to valid
19:47:34  <trevnorris>tjfontaine: can you give me a google-able search to know exactly what you're talking about?
19:48:17  <tjfontaine>trevnorris: well, I mean while the process is running the actual like /proc/<pid>/maps I think it is
19:48:22  * felixgejoined
19:48:42  <tjfontaine>or maybe even smaps, but I don't think that will change much
19:49:03  <othiym23>trevnorris: https://github.com/othiym23/shimmer/blob/master/index.js#L86-L217
19:49:47  <othiym23>trevnorris: it's not as generic as the interface you and groundwater_ have been discussing, because I was trying to avoid scope creep
19:50:16  <othiym23>it's a big hairball as it stands, but mostly because it's used to monkeypatch individual EEs instead of monkeypunching the whole class
19:50:21  * saghuljoined
19:50:25  <othiym23>"class"
19:50:38  <othiym23>trying to break myself of the bad habit of talking about JS classes
19:54:06  * kellabytequit (Changing host)
19:54:06  * kellabytejoined
19:54:06  * kellabytequit (Changing host)
19:54:06  * kellabytejoined
19:55:12  <tjfontaine>trevnorris: we're basically looking to see -- over time -- how much, and what memory, is active for the process while it's running
19:56:01  <tjfontaine>trevnorris: for instance, I use `pmap -x $(pgrep -f test.js)` and then diff them
19:56:11  <tjfontaine>I run with --expose-gc and --always-compact
19:56:25  * mikealquit (Quit: Leaving.)
20:01:36  * c4milojoined
20:02:41  * defunctzombiechanged nick to defunctzombie_zz
20:02:43  <tjfontaine>https://gist.github.com/tjfontaine/7437666 over 6 cores, we have stable heap and v8 heap
20:02:46  <tjfontaine>I'm calling it done
20:04:20  <MI6>joyent/node: Timothy J Fontaine v0.10 * 16934d9 : src: add HandleScope in HandleWrap::OnClose (+1 more commits) - http://git.io/g5fQEw
20:04:39  * bnoordhu1sjoined
20:07:21  <bnoordhu1s>back
20:08:03  <trevnorris>othiym23: yeah. that's massive.
20:08:36  <bnoordhu1s>tjfontaine: what was that MakeCallback() call leaking? the return value?
20:09:00  <bnoordhu1s>lgtm at any rate
20:09:27  <tjfontaine>bnoordhu1s: the HandleScope data locations were mostly full of Undefined's
20:09:34  <trevnorris>probably. that might explain the bunch of undefineds tjfontaine was seeing, since almost no callbacks actually return anything.
20:10:21  <trevnorris>I think only in once place in core do we actually depend on the return value. and it's a very rare case it's used.
20:10:22  <tjfontaine>v0.10 changelog https://gist.github.com/tjfontaine/7437778 review please?
20:10:51  <trevnorris>tjfontaine: lgtm
20:11:04  <tjfontaine>oops slightly out of order, anyway
20:11:07  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:11:13  <tjfontaine>going to rename the debugger one
20:11:33  <tjfontaine>hm
20:11:35  <tjfontaine>nah I'll leave it
20:11:42  <bnoordhu1s>looking
20:11:55  <bnoordhu1s>the v8 patch is actually mmalecki's work :)
20:12:15  <tjfontaine>heh, ok
20:13:14  <bnoordhu1s>fedor's libuv patch is probably worth mentioning
20:14:05  <tjfontaine>GetCurrentProcess that one?
20:14:13  <bnoordhu1s>"unix: fix reopened fd bug" but that should probably be reworded
20:14:15  * bnoordhu1sthinks
20:15:03  <bnoordhu1s>"unix: fix assert for stale file descriptor events" or something like that?
20:15:14  <tjfontaine>sounds good
20:15:14  <MI6>nodejs-v0.10: #1594 UNSTABLE smartos-x64 (4/604) smartos-ia32 (4/604) osx-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1594/
20:15:54  <tjfontaine>should we mention that it doesn't go into "Not Responding" in mavericks anymore?
20:16:14  <bnoordhu1s>yeah, probably. i've heard several people mention that
20:16:57  <bnoordhu1s>or maybe "cluster, child_process: don't assert on stale file descriptor events"
20:16:59  <trevnorris>othiym23, groundwater_: please look over and give feedback about what else you're looking for: https://github.com/joyent/node/pull/6502
20:17:02  <trevnorris>piscisaureus_: you too: https://github.com/joyent/node/pull/6502
20:17:05  <bnoordhu1s>'tis a little on the long side
20:17:28  <bnoordhu1s>but that's the issue that most people actually reported
20:17:34  <tjfontaine>* darwin: Fix "Not Responding" in Mavericks activity monitor (Fedor Indutny)
20:17:35  <tjfontaine>?
20:17:40  <bnoordhu1s>yep
20:17:42  <indutny>yep
20:17:45  <trevnorris>just need to add "error" support somehow and i'll be happy w/ it.
20:17:54  <indutny>tjfontaine: that's it
20:17:58  <indutny>trevnorris: ask TooTallNate
20:18:02  <tjfontaine>I think I'm just going to go with "child_process" for the other one
20:18:13  <trevnorris>tjfontaine: another for you I think ^
20:18:50  <tjfontaine>https://gist.github.com/tjfontaine/7437778 updated
20:19:05  <tjfontaine>damn child_process is out of order, anyway
20:19:58  <MI6>nodejs-v0.10-windows: #315 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/315/
20:20:16  <tjfontaine>last call on changelog entries :)
20:22:29  <MI6>joyent/node: tjfontaine created branch v0.10.22-release - http://git.io/jn07DA
20:22:31  <tjfontaine>gone
20:22:34  <bnoordhu1s>tjfontaine: lgtm
20:22:36  <bnoordhu1s>oh, too late
20:22:50  <tjfontaine>:)
20:24:04  <MI6>node-review: #109 ABORTED http://jenkins.nodejs.org/job/node-review/109/
20:25:46  <tjfontaine>hueniverse: ping
20:26:08  <tjfontaine>hueniverse: the build is going, but do you depend on pkgsrc for node, or do you build your own?
20:26:25  <trevnorris>so close... i'm so close.
20:26:40  * trevnorrishuddles in the corner mumbling to himself.
20:29:08  <tjfontaine>my precious, my precious
20:29:45  * dshaw_quit (Quit: Leaving.)
20:31:23  <trevnorris>DAMN RIGHT LOUDBOT
20:31:29  <trevnorris>ooh, ouch.
20:32:03  <sblom>That's one of the better LOUDBOT exchanges of all time.
20:33:17  <trevnorris>groundwater_, othiym23, piscisaureus_: here you go bitches: https://github.com/joyent/node/pull/6502
20:33:22  * trevnorrisout
20:34:30  * c4miloquit (Remote host closed the connection)
20:35:11  * dshaw_joined
20:35:30  * defunctzombie_zzchanged nick to defunctzombie
20:37:45  <bnoordhu1s>othiym23: hrm, okay. wouldn't you be happier though with a decent external debugger? as it is, the builtin one doesn't get much love
20:37:59  <hueniverse>tjfontaine: we use the smartos dist
20:41:23  * piscisaureus_quit (Ping timeout: 245 seconds)
20:44:52  * defunctzombiechanged nick to defunctzombie_zz
20:45:00  * saghuljoined
20:50:14  <tjfontaine>hueniverse: hmm ok -- that may be harder to wrangle for 3pm, lemme see
20:50:58  * kuebkjoined
20:52:14  * mikealjoined
20:52:56  <MI6>joyent/node: tjfontaine created tag v0.10.22 - http://git.io/fWdO8g
20:53:49  <MI6>joyent/node: Timothy J Fontaine v0.10 * ac9cf00 : blog: Post for v0.10.22 (+3 more commits) - http://git.io/rYeXmg
20:53:53  * hzquit
20:56:31  <st_luke>what was the reason for moving away from scope.Close() in v0.11.x? (ref: https://github.com/joyent/node/blob/v0.10.21/src/node.cc#L1316 and https://github.com/joyent/node/blob/v0.11.8/src/node.cc#L1369)
20:56:44  <bnoordhu1s>st_luke: api change in v8
21:00:23  <hueniverse>tjfontaine: is 10.22 out?
21:01:28  <tjfontaine>hueniverse: it's out, and the pkgsrc stuff should be getting built
21:01:35  <hueniverse>sweet
21:01:43  <tjfontaine>I'm hoping it will be ready asap
21:02:47  <hueniverse>tjfontaine: thanks. I'll try to get it in for tonight but overall this is more a long term thing. so excited!
21:03:28  <tjfontaine>hueniverse: me too! everything that's left is hopefully not too much of node's fault :)
21:10:55  <MI6>nodejs-v0.10: #1595 UNSTABLE smartos-x64 (5/604) smartos-ia32 (5/604) linux-x64 (2/604) linux-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1595/
21:12:14  <MI6>node-review: #110 UNSTABLE smartos-x64 (6/604) centos-x64 (1/604) windows-x64 (10/604) osx-ia32 (1/604) windows-ia32 (11/604) centos-ia32 (1/604) smartos-ia32 (7/604) http://jenkins.nodejs.org/job/node-review/110/
21:13:51  <MI6>joyent/node: Ben Noordhuis master * 5235d71 : src: use Context::Scope objects in cares_wrap.cc (+4 more commits) - http://git.io/5C3qeg
21:18:22  <bnoordhu1s>trevnorris: ^
21:22:13  * dshaw_quit (Quit: Leaving.)
21:22:38  * st_lukequit (Remote host closed the connection)
21:26:09  <othiym23>bnoordhu1s: if there were an external debugger I could start from the cli that started quickly and gave me command-line access to all the essential bits of the debugger, I'd be fine
21:30:28  <MI6>nodejs-v0.10-windows: #316 UNSTABLE windows-ia32 (11/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/316/
21:31:31  * jmar777quit (Remote host closed the connection)
21:32:49  * mikealquit (Quit: Leaving.)
21:32:56  * mikealjoined
21:33:54  <trevnorris>bnoordhu1s: thanks :)
21:35:18  <MI6>nodejs-master: #695 UNSTABLE osx-x64 (1/675) smartos-ia32 (7/675) linux-x64 (1/675) smartos-x64 (12/675) osx-ia32 (1/675) linux-ia32 (2/675) http://jenkins.nodejs.org/job/nodejs-master/695/
21:36:41  * dshaw_joined
21:37:08  <MI6>nodejs-master-windows: #480 UNSTABLE windows-x64 (25/675) windows-ia32 (24/675) http://jenkins.nodejs.org/job/nodejs-master-windows/480/
21:37:35  <indutny>tjfontaine: thank you for release :)
21:39:06  <tjfontaine>indutny: thanks for all your hard work
21:39:24  <indutny>oh, not much work was really hard hand work :)
21:39:32  <indutny>I spent like 10 hours in my bank
21:39:37  <indutny>doing the paperwork
21:39:39  <indutny>it was really hard
21:45:18  <trevnorris>haha, bnoordhu1s went a little overboard on that libuv sample, eh?
21:47:49  * kevinswiberquit (Remote host closed the connection)
21:48:23  * kevinswiberjoined
21:48:39  <trevnorris>alright, any last objections to https://github.com/joyent/node/pull/6468 ?
21:51:52  * c4milojoined
21:52:38  * kevinswiberquit (Ping timeout: 240 seconds)
21:54:03  * kevinswiberjoined
21:56:48  * saghulquit (Ping timeout: 240 seconds)
21:58:16  <MI6>joyent/node: Trevor Norris master * 9b4aa35 : src: add comments about implicit dependencies (+3 more commits) - http://git.io/HemsGQ
22:00:49  * sblomquit (Ping timeout: 272 seconds)
22:01:49  <othiym23>trevnorris: #6468 looks good to me
22:02:10  <trevnorris>:)
22:02:30  <trevnorris>othiym23: how about my current implementation ideas behind https://github.com/joyent/node/pull/6502 ?
22:03:11  * pooyajoined
22:03:21  <othiym23>leaving some comments right now
22:03:56  <trevnorris>that should introduce almost unnoticeable overhead on applications that have light weight callbacks.
22:05:51  <othiym23>lgtm, I'll just need to take what I have in shimmer and turn it into another polyfill
22:06:19  <othiym23>the biggest difference between what I have in shimmer and what you're doing is that shimmer is applied to individual EEs rather than the prototype
22:07:02  <trevnorris>othiym23: eh? sorry, not following. I haven't applied anything to the prototype.
22:07:30  <trevnorris>in fact, i'm pretty sure isaacs would rip off my face if I tried to extend the EE prototype.
22:08:13  <othiym23>unless I'm misreading your patch, these listeners are getting run on *all* EEs once the handlers are registered, no?
22:08:52  <othiym23>but yes, it's not on the prototype, sorry for the imprecision
22:10:11  * kevinswiberquit (Remote host closed the connection)
22:10:46  * kevinswiberjoined
22:10:51  <trevnorris>yeah. unlike async listeners, they will fire the callbacks as long as the callbacks are registered.
22:10:58  <trevnorris>to EE that is
22:15:28  * kevinswiberquit (Ping timeout: 264 seconds)
22:17:34  <trevnorris>othiym23: honestly that decision is almost more out of spite since EE's are actually synchronous, but we bastardized them to work like they're asynchronous.
22:17:56  <trevnorris>ok, not really. the current implementation has zero performance hit, which is the most important.
22:17:57  <groundwater_>EEs are kind of like event boundaries
22:18:37  <trevnorris>event boundaries?
22:19:42  * defunctzombie_zzchanged nick to defunctzombie
22:20:35  <MI6>nodejs-master-windows: #481 UNSTABLE windows-x64 (25/675) windows-ia32 (27/675) http://jenkins.nodejs.org/job/nodejs-master-windows/481/
22:21:02  <groundwater_>othiym23: is giving me shit for that line, so i humbly back out of my previous statement
22:21:15  <trevnorris>haha
22:21:47  <trevnorris>oh, those windows tests are doing AWESOME!
22:23:46  * piscisaureus_joined
22:24:29  <MI6>nodejs-master: #696 UNSTABLE osx-x64 (1/675) smartos-ia32 (10/675) linux-x64 (1/675) smartos-x64 (12/675) osx-ia32 (2/675) linux-ia32 (2/675) http://jenkins.nodejs.org/job/nodejs-master/696/
22:24:55  <trevnorris>piscisaureus_: PING. have a moment to give this a quick review? https://github.com/joyent/node/pull/6502
22:25:31  <piscisaureus_>trevnorris: ok looking
22:25:52  <trevnorris>:)
22:26:05  <bnoordhu1s>if (!(this instanceof T)) return new (T.bind.bind(T, null).apply(null, arguments)); // any way of making this a little briefer?
22:26:18  <trevnorris>wtf are you trying to do?
22:26:46  <bnoordhu1s>have T invoke itself as a constructor if it isn't currently being called as one
22:27:05  <bnoordhu1s>that snippet above works but it's not very elegant
22:27:17  <piscisaureus_>very slow too
22:27:18  <trevnorris>and wicked ass slow.
22:27:21  <piscisaureus_>you should benchmark it
22:27:38  <trevnorris>bnoordhu1s: are you expecting N arguments?
22:27:48  <piscisaureus_>trevnorris: ok, did you get a thumbs up on this from isaacs or tjfontaine ?
22:28:01  <bnoordhu1s>trevnorris: it's variadic, hence the use of the arguments object
22:28:16  <trevnorris>piscisaureus_: nope. i still need to do some docs/tests/etc.
22:28:17  <piscisaureus_>trevnorris: I need it, but yesterday speaking to isaacs he seemed to want a much simpler thing.
22:28:22  <trevnorris>bnoordhu1s: but is there a max N?
22:28:36  <piscisaureus_>trevnorris: ok let me look if it actually fixes my issue
22:28:44  <piscisaureus_>trevnorris: actually that's very hard to do
22:28:48  <trevnorris>piscisaureus_: well, whatever. this has essentially zero hit if you don't use it, and very little if you do.
22:28:50  <piscisaureus_>trevnorris: and I want to go sleep...
22:28:52  <bnoordhu1s>trevnorris: that is yet to be determined. but what if it there is?
22:28:55  <piscisaureus_>trevnorris: no not that
22:28:59  <bnoordhu1s>er, -it
22:29:03  <piscisaureus_>trevnorris: I need a hook to implement tasks in userland
22:29:26  <othiym23>what's wrong with return T.apply(this, arguments)?
22:29:27  <piscisaureus_>trevnorris: so I was thinking to just monkeypatch EventEmitter.init
22:29:53  <piscisaureus_>trevnorris: and the constructor logic would move from funciton EventEmitter() to EventEmitter.init
22:30:06  * amartensquit (Quit: Leaving.)
22:30:37  <piscisaureus_>trevnorris: so - maybe your solution is more elegant/purposeful but I am not sure if it fixes *my* problem :)
22:30:45  <trevnorris>now i'm lost in two conversations.
22:30:45  <trevnorris> bnoordhu1s: if you know you won't have more than N arguments then it's easier to work w/. If you're expecting any number of arguments then there's a little trick you can do.
22:31:04  <bnoordhu1s>othiym23: it leads to infinite recursion for one :)
22:31:12  <trevnorris>piscisaureus_: that's what i'm trying to figure out. if it fixes *your* issue. :)
22:31:19  <bnoordhu1s>maybe not infinite, you'll get a stack overflow exception soon enough
22:31:22  <piscisaureus_>trevnorris: the way to find out if I port tasks to use your new API - but I can't do that within half an hour...
22:31:32  <trevnorris>bnoordhu1s: do you have the sample somewhere? I can show you the fastest way to get this done.
22:31:49  <othiym23>hmm... maybe I got it wrong, but there's an existing version of that pattern in use in a bunch of places in Node core
22:31:50  <piscisaureus_>trevnorris: so i can't do it right now. but maybe I can guess, so let me look.
22:31:53  <trevnorris>piscisaureus_: ah, I see. then get some sleep. I don't plan on landing this tonight. just wanted some feedback.
22:32:07  <bnoordhu1s>trevnorris: oh, it was pretty much that oneliner really. the function itself does the equivalent of function T(x) { this.x = x }
22:32:51  <bnoordhu1s>imagine for the sake of discussion that the actual number of arguments is anywhere between 1 and 20
22:33:12  <piscisaureus_>trevnorris: well - no I need to monkey patch the constructor
22:33:17  <trevnorris>bnoordhu1s: oh, yeah. if you're just expecting x then it's a simple: function T(x) { if (!(this instanceof T)) return new T(x); this.x = x; }
22:33:28  <othiym23>ah, I see, it's the arbitrary number of arguments that's the asspain here
22:33:48  <bnoordhu1s>yep
22:33:49  <trevnorris>bnoordhu1s: ok. give me a sec and I'll write you an example that gets around that problem.
22:33:54  <piscisaureus_>trevnorris: the elephant in the room is that Tasks add significant stuff to the EventEmiiter
22:34:34  <othiym23>if ES6 actually splits apart allocation from initialization, things like this should get simpler
22:34:36  <trevnorris>piscisaureus_: let's go over that tomorrow when I have a chance to look at the amount of *significant stuff* you're mentioning.
22:34:46  <piscisaureus_>alright
22:34:50  <piscisaureus_>I want to get sleep too
22:34:53  * bradleymeckquit (Quit: bradleymeck)
22:34:53  <piscisaureus_>thanks
22:34:58  <othiym23>and if people start actually writing ES6, maybe these kinds of gross hacks will become less necessary
22:35:03  <trevnorris>othiym23: well, if v8 supported the function T(a, b, ...args) { } syntax it'd be solved easily.
22:35:11  <trevnorris>piscisaureus_: night :)
22:35:14  <othiym23>that too
22:35:24  * felixgequit (Quit: felixge)
22:35:33  * kuebkquit
22:35:39  <othiym23>they're talking about nerfing arguments.length altogether in ES6 right now on es-discuss
22:35:59  <bnoordhu1s>nooo! how will we do ad-hoc function polymorphism now!
22:36:07  <trevnorris>othiym23: well, other than the crap ton of optimizations v8 has done for arguments, I don't have an issue w/ that.
22:36:24  <piscisaureus_>There are libraries out there that use it tho
22:36:29  <piscisaureus_>express , for one
22:36:34  <trevnorris>bnoordhu1s: easy. it's function T(a, b, ...c), where c is an array of all additional arguments :)
22:37:04  <bnoordhu1s>right :) so i guess the verdict is there not really a shorter solution?
22:37:07  <bnoordhu1s>*there is
22:37:09  <othiym23>piscisaureus_: express uses Function.length
22:37:21  <piscisaureus_>oh
22:37:24  <trevnorris>bnoordhu1s: yeah there is. if i'd stop typing in irc and actually make you an example :P
22:37:26  <othiym23>and also that is a horrible, horrible thing about Express that I wish to expunge with cleansing thermonuclear fire
22:37:26  <trevnorris>one sec.
22:37:34  <piscisaureus_>oh I thought that was wat bnoordhu1s was talking about
22:37:52  <piscisaureus_>Why nerf arguments.length? Not just an Array?
22:38:04  <othiym23>no, bnoordhu1s is talking about reinvoking a constructor from within itself if it has a variadic args list
22:38:46  <othiym23>piscisaureus_: it leads to spec complexity, especially when splat arguments, argument initializers, and optional arguments are added into the mix
22:38:53  <trevnorris>piscisaureus_: to save resources. you have to explicitly state you want an array of additional arguments by using the ...arg syntax as a function parameter.
22:39:10  <piscisaureus_>ah right
22:42:39  * indexzerojoined
22:42:48  <bnoordhu1s>next challenge: create an object that inherits from Uint8Array!
22:43:05  <Domenic_>arguments / arguments.length is never going away; TC39 can't break the web
22:43:05  <trevnorris>bnoordhu1s: one at a time man. one at a time. almost have a good example of your first.
22:43:16  <Domenic_>it's just that they're trying to figure out a way for programs to never have to use it.
22:43:35  <Domenic_>bnoordhu1s: that is possible in ES6 as specced (but presumably not as implemented).
22:45:32  <bnoordhu1s>Domenic_: right. doesn't seem really possible right now
22:45:53  <bnoordhu1s>i can make it work half but it ain't pretty (or efficient)
22:46:04  <Domenic_>it's part of the whole allocation-initialization split ES6 brings
22:46:11  <bnoordhu1s>the v8 people want to phase out v8::Object::SetIndexedPropertiesToExternalArrayData()
22:46:28  <bnoordhu1s>because hey, we have typed arrays now, right?
22:46:50  <bnoordhu1s>but that method is what makes Buffer objects work so that would break node pretty bad
22:47:14  <bnoordhu1s>and i don't think typed arrays are going to cut it just now
22:47:24  <Domenic_>wow that is pretty bad.
22:47:38  * indexzeroquit (Ping timeout: 245 seconds)
22:48:30  <bnoordhu1s>it's curious that you can set this.__proto__ = new Uint8Array(n)
22:48:38  <bnoordhu1s>but then obj.byteLength throws an error
22:49:10  <bnoordhu1s>"TypeError: this is not a typed array." - lies >:(
22:49:49  <othiym23>sounds like you're going to have to do some of that from the C++ side
22:50:05  <othiym23>aren't Uint8Arrays exotic objects in V8?
22:50:17  <bnoordhu1s>no, they're native in newer versions
22:50:25  <trevnorris>bnoordhu1s: wtf you're serious??!?!!!?!!?!?!?!?!?!?!?!?!!?!?!!?!? <-- keep those going for a while
22:50:42  <bnoordhu1s>check the v8-users mailing list if you don't believe me :)
22:51:08  <bnoordhu1s>https://groups.google.com/forum/#!topic/v8-users/Qxfj8hN6_P4
22:51:17  * piscisaureus_quit (Ping timeout: 248 seconds)
22:51:18  <trevnorris>the rage of that thought makes me want to walk over to google campus right now and kick their asses.
22:52:05  <bnoordhu1s>good thing then for the v8 team that they're based in munich :)
22:52:22  * trevnorrisgoes to expedia.com
22:58:15  * indexzerojoined
22:59:09  * indexzeroquit (Client Quit)
23:07:14  * mikealquit (Quit: Leaving.)
23:08:55  * piscisaureus_joined
23:11:19  <trevnorris>ok. i might have been a little heavy on the adjectives. but of all the changes v8 has forced upon us, this one makes me want to rage quit.
23:11:59  * skabbesjoined
23:13:56  * rendarquit (Quit: Leaving)
23:17:15  <bnoordhu1s>yeah. i've posted why i think typed arrays are not a replacement for buffers
23:17:51  <bnoordhu1s>if the v8 guy doesn't agree, i'll challenge him to try and patch node :)
23:18:25  <bnoordhu1s>so, dart 1.0 is nearly out and google did an 'official' release of pnacl
23:18:42  <bnoordhu1s>you can't say they aren't trying
23:21:46  <trevnorris>bnoordhu1s: what do you mean by "can't say they aren't trying"?
23:21:50  * AvianFluquit (Remote host closed the connection)
23:22:24  <bnoordhu1s>trying to change the web
23:22:29  <trevnorris>ah, ok.
23:22:41  <bnoordhu1s>i'll leave it unspoken whether for the better or the worse
23:22:46  <trevnorris>heh
23:23:12  <trevnorris>bnoordhu1s: i owe you like a dozen beers for keeping up on the v8 mailing list and catching that.
23:23:34  <bnoordhu1s>everyone, you saw trevor saying that, right?
23:23:44  <bnoordhu1s>trevnorris: you can't un-say it now
23:23:47  <MI6>joyent/node: Tim Wood v0.10 * c9d93f3 : events: don't call once twice - http://git.io/_qrpLA
23:23:53  <trevnorris>heh.
23:24:05  <trevnorris>bnoordhu1s: next time you're in town. :)
23:24:37  <bnoordhu1s>indutny: did you run benchmarks for that change?
23:25:07  <indutny>bnoordhu1s: I believe it has no effects on them
23:25:21  <bnoordhu1s>yeah, i don't think so either but it's good to verify these things
23:25:23  <indutny>bnoordhu1s: but you can run them if you want
23:25:26  <indutny>:)
23:25:35  <indutny>bnoordhu1s: I verified that it affects only .once() performance
23:25:40  <indutny>and it wasn't really that good anyway
23:25:46  <bnoordhu1s>landing a patch is like vouching for it
23:25:52  <bnoordhu1s>so now you're on the hook for it
23:25:52  <indutny>haha
23:26:02  <indutny>well, there is a bug
23:26:07  <indutny>and it fixes it
23:26:12  <indutny>I know only one alternative fix for it
23:26:21  <indutny>and it'll introduce performance issues for every emit()
23:26:28  <indutny>and perhaps some bugs
23:26:46  <indutny>I've seriously considered possible alternatives
23:26:53  <bnoordhu1s>yeah? like what
23:27:59  <trevnorris>bnoordhu1s: are you expecting at least 1 argument?
23:28:12  <bnoordhu1s>trevnorris: yes
23:28:29  <trevnorris>cool. have a quick little pattern for you. let me gist it.
23:30:16  * mikealjoined
23:31:07  * brsonjoined
23:31:15  * Kakeraquit (Ping timeout: 245 seconds)
23:31:33  * piscisaureus_quit (Ping timeout: 246 seconds)
23:32:26  <trevnorris>bnoordhu1s: ugly, but fastest implementation I've found: https://gist.github.com/trevnorris/7440737
23:32:34  <trevnorris>when you're expecting N arguments
23:33:49  <bnoordhu1s>trevnorris: ah, right. that's clever :)
23:34:02  <bnoordhu1s>not briefer however :)
23:34:18  <trevnorris>hehe, yeah. definitely not. but faster for sure :)
23:34:33  * defunctzombiechanged nick to defunctzombie_zz
23:34:36  * pooyaquit (Quit: pooya)
23:34:40  <MI6>nodejs-v0.10: #1596 UNSTABLE smartos-x64 (4/604) smartos-ia32 (4/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1596/
23:35:53  <trevnorris>bnoordhu1s: also, just fyi, accessing the arguments keyword in a constructor adds 50ns to construction time. not sure why. need to check the assembly output.
23:36:23  <trevnorris>but Function#bind() is slowest of them all :P
23:36:47  <othiym23>such a bummer
23:36:50  <othiym23>it's so handy
23:37:04  <othiym23>binding, partial application / currying, etc
23:37:21  <bnoordhu1s>trevnorris: i think that referencing the arguments object makes v8 always create a closure context for the function
23:37:22  <trevnorris>othiym23: and accessing the arguments keyword from a function called from C++ adds 200ns. still not sure why. but benchmarks say so.
23:37:33  <trevnorris>bnoordhu1s: ah, interesting. thanks.
23:37:42  <othiym23>trevnorris: because arguments is fucking bizarre, is why
23:37:49  <othiym23>trevnorris: does enabling strict mode change the numbers at all?
23:38:11  <bnoordhu1s>i'm betting yes
23:38:12  <othiym23>(because in sloppy mode arguments also has a trap-door exit out to .caller and .callee that is not free to set)
23:40:04  <MI6>nodejs-v0.10-windows: #317 UNSTABLE windows-ia32 (10/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/317/
23:40:09  <trevnorris>v8 could use some dead code elimination. even adding if (false) arguments; slows down the constructor.
23:40:57  <othiym23>doesn't it have dead code elimination, albeit at the lithium level?
23:43:18  <bnoordhu1s>othiym23: barely
23:43:31  <othiym23>sucky
23:43:55  <bnoordhu1s>yeah. DCE is difficult when you have running time constraints
23:43:58  <othiym23>if I didn't, like, have a job, I'd spend some time getting my head more around crankshaft and try to fix some of the JIT issues around closure contexts
23:44:11  <bnoordhu1s>having said that, chakra is pretty good at it for some reason
23:44:39  <trevnorris>really? wouldn't've guessed.
23:44:52  <bnoordhu1s>othiym23: the biggest one is that inner and outer closures often share the same context. makes it really easy to leak a lot of memory
23:44:59  * c4miloquit (Remote host closed the connection)
23:45:06  <bnoordhu1s>i kind of understand why it works the way it does but it still sucks
23:45:33  <bnoordhu1s>trevnorris: i guess it's because chakra does parallel recompiles
23:45:55  <othiym23>I'd just like it to be a tiny bit more aggressive about partitioning closure contexts so that closure code could be JITted
23:46:05  <bnoordhu1s>its optimzing compiler runs in another thread so it doesn't have to worry about blocking the main thread for too long
23:46:06  <othiym23>I freely admit I don't understand all the intricacies of doing that correctly
23:46:08  <trevnorris>wow. that's a nice little feature.
23:46:31  <bnoordhu1s>yeah. v8 experimentally supports parallel recompilation but it doesn't work very well
23:46:56  <trevnorris>but hey, they're dropping support for one of their most used features! :P
23:47:14  <bnoordhu1s>yeah. well, i guess we've made it clear why that's a bad move
23:47:34  <bnoordhu1s>it's not as if the feature itself is outright broken like Persistent handles were
23:47:47  <groundwater_>hey, can i ask you for manta help?
23:47:55  <bnoordhu1s>who is you?
23:47:55  <groundwater_>whoops, wrong channel
23:47:59  <bnoordhu1s>ah okay :)
23:48:03  <trevnorris>if they seriously decide to go through with that, the only way around it I can see is to create a new class that inherits from their ArrayBuffer class and do some really crazy hacking.
23:48:38  * brsonquit (Ping timeout: 244 seconds)
23:49:01  <bnoordhu1s>let's assume for now that the v8 people are reasonable people and will see the errors of their ways after our posts
23:49:23  <trevnorris>heh, ok. i'll hold on to that hope.
23:49:35  <bnoordhu1s>and if they don't, we'll catch a plane to munich
23:50:06  <othiym23>bnoordhu1s: or you can just revive your spidermonkey patch and then we'll just cut over to that
23:50:10  <othiym23>no problem
23:50:11  <trevnorris>sounds good to me.
23:50:20  <tjfontaine>if we abstract tot he addon layer ...
23:50:21  <tjfontaine>:)
23:50:26  <trevnorris>(to bnoordhu1s, not cutting over to spidermonkey)
23:50:45  <trevnorris>I know I work at mozilla and all, but ripping that sucker out of moz-central is ridiculous
23:51:22  <trevnorris>and, you forget that spidermonkey supports every possible experimental JS feature available.
23:51:42  <trevnorris>spidermonkey is the playground for engineers where ideas go _before_ they actually become proposals.
23:51:44  * skabbesquit (Ping timeout: 244 seconds)
23:51:45  <othiym23>trevnorris: http://bit.ly/1bBuSev
23:51:47  <othiym23>EVIDENCE
23:52:13  <othiym23>did I really forget?
23:52:15  <othiym23>I wonder...
23:52:47  <trevnorris>haha. that level of taking out of context would make you one great politician.
23:53:03  <othiym23>fortunately, I only use my powers for cheap shots
23:55:08  * dshaw_quit (Quit: Leaving.)
23:55:15  * skabbesjoined
23:57:27  * pooyajoined
23:58:21  * bnoordhu1squit (Ping timeout: 272 seconds)