00:36:35  * esasquit (Ping timeout: 265 seconds)
01:19:40  * plutoniixjoined
01:41:27  * seventhquit (Ping timeout: 244 seconds)
01:52:12  * enaqxjoined
02:11:28  * jgijoined
03:14:45  * plutoniixquit (Quit: จรลี จรลา)
03:19:55  * jgiquit (Quit: jgi)
03:33:31  * plutoniixjoined
04:11:27  * katuquit (Ping timeout: 240 seconds)
04:14:13  * jgijoined
04:26:35  * enaqxquit (Remote host closed the connection)
04:49:21  * enaqxjoined
05:19:13  * jgiquit (Quit: jgi)
05:28:16  * jgijoined
05:33:23  * jgiquit (Quit: jgi)
05:39:24  * deavidquit (Ping timeout: 250 seconds)
05:51:58  * deavidjoined
06:04:22  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/1843 "V8 Linux - nosnap - debug - 1" from ef268a83be4dead004047c25b702319ea4be7277: bmeurer@chromium.org)
06:22:24  * deavidquit (Ping timeout: 264 seconds)
06:24:35  * deavidjoined
06:25:32  <trungl-bot>Tree opened by machenbach@chromium.org: Tree is open
06:39:37  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "bot_update" on http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/1539 "V8-Blink Win" from 298d4a6b7636f9c8aace971e8fe35500fbd40392: bmeurer@chromium.org)
06:41:38  <trungl-bot>Tree opened by machenbach@chromium.org: Tree is open
06:54:45  * mostynbjoined
07:33:03  * rendarjoined
07:52:07  * JoWiejoined
08:04:59  * enaqxquit (Remote host closed the connection)
08:06:54  * enaqxjoined
08:13:59  * enaqxquit (Remote host closed the connection)
08:15:37  * enaqxjoined
08:36:25  * kenansulaymanquit (Ping timeout: 264 seconds)
08:59:48  * aperezdcjoined
10:53:31  * plutoniixquit (Quit: จรลี จรลา)
11:38:35  * kenansulaymanjoined
11:38:59  * kenansulaymanchanged nick to Guest50310
11:39:26  * dobsonquit (Ping timeout: 240 seconds)
11:45:43  * dobsonjoined
12:04:09  * Guest50310quit (Changing host)
12:04:09  * Guest50310joined
12:05:51  * Guest50310changed nick to kenansulayman
12:23:59  * enaqxquit (Ping timeout: 260 seconds)
12:24:42  * enaqxjoined
12:37:06  * aperezdcquit (Quit: aperezdc)
13:08:06  * rmichnikjoined
13:09:59  * bobmcwjoined
13:24:28  * thefourtheyequit (Quit: Connection closed for inactivity)
13:44:29  * plutoniixjoined
14:02:32  * dchermanjoined
14:04:35  * aperezdcjoined
14:24:04  * enaqxquit (Ping timeout: 246 seconds)
14:26:22  * esasjoined
14:28:21  * davi_joined
14:28:44  * davi_changed nick to Guest64984
14:39:10  * jgijoined
14:45:14  * ofrobotsjoined
15:00:49  * C-Manjoined
15:03:04  * dcherman2joined
15:03:05  * jgiquit (Quit: jgi)
15:03:35  * ofrobotsquit (Quit: Textual IRC Client: www.textualapp.com)
15:06:35  * dchermanquit (Ping timeout: 265 seconds)
15:36:14  * dobsonquit (Ping timeout: 240 seconds)
15:36:24  * mostynbquit (Quit: Leaving)
15:39:42  * dobsonjoined
15:44:57  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
16:01:46  * jgijoined
16:02:54  * scottmgjoined
16:30:41  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "bot_update" on http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/4902 "V8 Linux64 - debug" from 057514d3fa79af4732e136f5daad4b805a65e569: ulan@chromium.org,vogelheim@chromium.org)
16:46:49  <trungl-bot>Tree opened by vogelheim@chromium.org: Tree is open ("bot_update" fail on "V8 Linux64 - debug" doesn't look like it's related to the changes)
17:42:07  * esasquit (Read error: Connection reset by peer)
17:57:40  * esasjoined
18:16:49  * Guest64984quit (Ping timeout: 246 seconds)
18:57:09  * davi__joined
18:59:10  * bnoordhuisjoined
19:04:32  * dchermanjoined
19:07:12  * dcherman2quit (Ping timeout: 244 seconds)
19:13:19  * enaqxjoined
19:21:26  * enaqxquit (Ping timeout: 250 seconds)
19:25:50  * enaqxjoined
19:34:40  * dcherman2joined
19:36:17  * rendarquit (Ping timeout: 265 seconds)
19:37:32  <caitp>how hard would it be to create an inline version of CreateDataProperty()?
19:37:46  * dchermanquit (Ping timeout: 255 seconds)
19:39:02  <caitp>I think the IC infrastructure still needs to be used to find the slot within the object which gets stored, but not totally sure
19:42:03  * rendarjoined
19:42:16  * JoWiequit (Quit: Connection closed for inactivity)
19:50:54  * enaqxquit (Ping timeout: 250 seconds)
20:00:19  * esasquit (Read error: Connection reset by peer)
20:00:27  * enaqxjoined
20:11:47  * enaqxquit (Ping timeout: 244 seconds)
20:18:05  * enaqxjoined
20:23:27  * C-Manquit (Quit: Connection reset by beer)
20:23:52  * davi__quit (Ping timeout: 246 seconds)
20:25:44  * scottmgquit (Ping timeout: 244 seconds)
20:28:45  * jgiquit (Quit: jgi)
20:43:58  * bobmcwquit (Remote host closed the connection)
21:01:25  <aklein>caitp: good afternoon, finally back from vacation and finishing wading through email
21:02:47  <caitp>I was just about to reply. It seems to be a problem with Chrome's console.log, which outputs `[1]` for the 2-argument case, despite the length being set correctly and having its own data property
21:02:57  <caitp>so, that was misleading
21:03:11  <caitp>it's also doing some other weird things, like throwing the setter error whenever the array is inspected, which is weird
21:03:42  <caitp>but anyways, I'm happy to leave it unmerged until we can do it in a spec-correct way with %_CreateDataProperty().
21:07:06  <caitp>but, the argument for not leaving it unmerged is, you get a 2-3x performance boost, which for any legitimate application is not observably incorrect
21:08:19  * enaqxquit (Ping timeout: 246 seconds)
21:10:47  * enaqxjoined
21:11:42  <caitp>anyways, hope the vacation was a good one, let me know what you think of those
21:13:06  <aklein>caitp: I understand the concern, but the right way to address that is to figure out how to do the spec-compliant thing in a fast way. we really try to avoid purposeful spec non-compliance
21:13:42  <aklein>caitp: I'm also hesitant to poke the desugaring much more without getting more feedback from bmeurer
21:15:40  <caitp>that's fine
21:15:57  * jgijoined
21:16:19  * scottmgjoined
21:16:34  <caitp>this should be easily converted to spec-correct with an inline-able CreateDataProperty
21:18:16  <aklein>it's definitely unclear to me how doable that is; bmeurer is _also_ worried about adding more %_ intrinsics (at a high level, there's some discussion to be had between the language team and the runtime/compiler folks; we
21:18:30  <aklein>'re hoping to set up a broader public list for such discussions)
21:18:52  <caitp>mm
21:44:24  * bobmcwjoined
21:49:24  * bobmcwquit (Ping timeout: 264 seconds)
21:56:10  * aperezdcquit (Quit: aperezdc)
22:04:19  * dcherman2quit (Ping timeout: 246 seconds)
22:04:48  <caitp>Well, for what it's worth, based on performance and correctness, Mozilla's implementation seems to be using an inlined CreateDataProperty, although I'd have to take a closer look to be sure
22:12:17  <aklein>caitp: I believe that an inlined CreateDataProperty and this desugaring is one way to do it, but given that bmeurer's worried about the use of %_ArgumentsLength(i), some higher-level rethinking might be the way to improve performance here
22:12:30  <aklein>are, %_Arguments(i) that is
22:13:54  <caitp>arguments access doesn't seem to be the major hotspot, and the approach he suggested wrt loop unrolling seemed like it could create a code size explosion
22:14:04  <caitp>i dunno
22:15:18  <caitp>maybe I misunderstood what he meant, but the switch statement thing seemed potentially bad without a lot of static info
22:16:11  * dchermanjoined
22:16:21  <aklein>let me go read his original message on that review; the main thing he mentioned to me in conversation was that %_Arguments(i) defeats inlining
22:18:21  * scottmgquit (Ping timeout: 244 seconds)
22:20:41  <aklein>so he's focused here on a particular case: inlining a call to a function that uses rest params (where the call doesn't use apply() or spread)
22:21:01  <aklein>I agree it's not obvious that inlining such calls is the biggest win, compared to other overhead
22:23:00  * plutoniixquit (Quit: จรลี จรลา)
22:24:45  <caitp>anyway, I have some other CLs that are a lot less scary, the perf test for rest parameters, and a bugfix for shorthand properties / binding patterns
22:24:55  <caitp>if you have some time today it would be great if you could take a look
22:25:45  <aklein>caitp: yeah I'm working through your bugfix right now; would you mind landing a fix separately from the refactor?
22:26:52  <caitp>the 3 patchsets are just different solutions for it, the third one includes a refactor and avoids the "hack"
22:27:10  <caitp>so if you just look at the other 2, they're hackier solutions that still fix it
22:27:28  <caitp>the 3 patch sets that aren't "add more tests" or whatever
22:28:27  <aklein>caitp: so I should choose the one I like and lgtm that one? :)
22:29:03  <caitp>yeah, pretty much
22:29:29  <caitp>or if you think the hacks could be a bit better, I can fix those up first
22:30:24  * RT|Chatzillajoined
22:33:35  <aklein>caitp: the hacks look all right at first but I agree that it's really hard to reason about them, working through the refactored version now.
22:43:18  * scottmgjoined
23:03:25  * dchermanquit (Ping timeout: 264 seconds)
23:06:28  * enaqxquit (Remote host closed the connection)
23:08:52  * rendarquit
23:11:43  * jgiquit (Quit: jgi)
23:13:57  * jgijoined
23:18:37  <aklein>caitp: ok, digging into the param scoping patch now
23:18:40  * enaqxjoined
23:22:01  * saapasquit (Ping timeout: 264 seconds)
23:28:06  * bnoordhuisquit (Ping timeout: 244 seconds)
23:33:47  * saapasjoined
23:43:22  <caitp>i think i mentioned it on the patch, but something which could probably get similar perf gains is doing a better job of eliminating unnecessary hole-checks
23:45:47  <caitp>which I'm sure we want to do anyways