02:50:16  * Net147quit (Ping timeout: 264 seconds)
02:51:34  * Net147joined
03:35:16  * Net147quit (Ping timeout: 264 seconds)
03:37:09  * Net147joined
05:05:53  * plutoniixquit (Quit: Leaving)
05:16:04  * Net147quit (Ping timeout: 264 seconds)
05:19:19  * Net147joined
07:22:00  * plutoniixjoined
08:09:34  * seththompsonquit (Ping timeout: 240 seconds)
08:09:50  * seththompsonjoined
08:26:27  * Net147quit (Ping timeout: 276 seconds)
08:29:06  * Net147joined
08:40:41  * vanillaSpeedLovequit (Quit: Page closed)
10:47:25  * Net147quit (Ping timeout: 258 seconds)
10:47:58  * Net147joined
11:40:04  * plutoniixquit (Quit: Leaving)
11:56:04  * bobmcwjoined
11:56:04  * bobmcwquit (Changing host)
11:56:04  * bobmcwjoined
12:06:59  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check - extra" on http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/11134 "V8 Linux64 TSAN" from 58524d6df343911c2ea1f3793718cb012f7e813c: [email protected],[email protected],[email protected],[email protected])
12:15:02  <trungl-bot>Tree opened by [email protected]: open
12:40:41  * aperezdcjoined
12:50:17  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check,Bisect 58524d6d.Retry" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/8521 "V8 Linux - nosnap - debug" from cbe5d41d88f35dc8ee29d2e0f9ce739d9e132481: [email protected],[email protected])
12:57:21  <trungl-bot>Tree opened by [email protected]: Tree is open (Automatic: بالتوفيق!)
13:25:09  * bradleymeckjoined
13:46:57  * Net147quit (Ping timeout: 265 seconds)
13:48:07  * Net147joined
14:50:30  * plutoniixjoined
14:50:44  * bradleymeckquit (Quit: bradleymeck)
14:52:27  * bradleymeckjoined
14:55:12  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Presubmit" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20presubmit/builds/10077 "V8 Linux - presubmit" from 779e3d6df00d53ca46a0b1b40752cd16da29f098: [email protected])
15:09:23  <trungl-bot>Tree closed by [email protected]: closed (epertoso fixing)
15:16:26  <trungl-bot>Tree opened by [email protected]: open
15:19:01  * seventhjoined
15:33:03  * seventhquit (Ping timeout: 258 seconds)
16:04:04  * bradleymeckquit (Quit: bradleymeck)
16:12:40  * bradleymeckjoined
16:23:53  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:39:07  * seventhjoined
16:53:19  * ofrobotsquit (Ping timeout: 252 seconds)
16:53:39  * ofrobotsjoined
16:54:48  <dherman>what's the difference between Array::Get and Array::CloneElementAt?
16:58:08  <dherman>and is there no fast path for getting a C++ array of handles to the indexed elements of an array? looping through and doing a Get of an Integer for each index, re-checking the length on every iteration in case of side effects, seems to be extremely slow
17:00:01  <caitp>dherman: let me check
17:05:04  <dherman>thx!
17:08:41  <caitp>there are fast paths, but
17:08:46  <caitp>they may not help the API much in particular
17:09:10  <caitp>see ElementsAccessor, particularly the FastElementsAccessor subclasses
17:09:35  <caitp>hopefully, the API is able to make use of it, but I doubt there would be much of a difference made
17:09:42  <caitp>at least not for single Get() calls
17:10:08  <caitp>well, no, fast case there would still be a lot quicker than slower elements representations
17:10:24  <caitp>but you still wouldn't see the same advantage that you do in algorithms that iterate through fast elements in a tight loop
17:11:26  <caitp>the main difference seems to be that CloneElementAt() is deprecated, and apparently it creates an actual copy of JSObjects in the array
17:11:40  <caitp>and it looks like it fails to do anything if the array does not have fast elements.
17:12:11  <caitp>probably was used for something DOM-related at some point, and the new recommended API reflects the proper MOP operations, is my guess
17:31:17  * thefourtheyequit (Quit: Connection closed for inactivity)
17:32:31  <dherman>caitp: thanks! ElementAccessor is public API?
17:32:57  <caitp>no
17:33:06  <dherman>Oh sorry that's what I was asking about
17:33:18  <caitp>yeah, there isn't really stuff in the API for it
17:33:18  <dherman>I should've been clearer
17:33:25  <caitp>I was trying to explain that
17:33:59  <caitp>I don't think it's really feasible to expose fast arrays to the API, I think the api would break too often
17:34:23  <caitp>but that's something to talk to cbruni about I guess
17:34:30  <dherman>Ok
17:48:47  * Meepjoined
17:51:28  * Tweth-U-PDSquit (Ping timeout: 264 seconds)
18:00:11  <caitp>actually, I dunno
18:00:25  <caitp>maybe it wouldn't be too bad to expose some version of the elements accessor to the API
18:18:20  * Tweth-U-PDSjoined
18:20:12  * Meepquit (Ping timeout: 240 seconds)
18:26:57  * bradleymeckquit (Quit: bradleymeck)
18:54:06  * bradleymeckjoined
18:55:16  <aklein>yeah, that would be nice
18:55:20  <aklein>but scary
19:01:37  <caitp>it wouldn't help most API objects that use elements, because of the interceptors
19:04:10  <caitp>aklein: do you know why the bootstrapper creates a function for JSON, even though it doesn't seem to be exposed to anything?
19:05:40  <aklein>weird
19:06:36  <aklein>I'm trying to imagine what breaks if you change that to just use Object as the constructor
19:08:01  <aklein>it dates back to the beginning of time
19:15:47  <aklein>random guess: it's used to make JSON.toString() return '[object JSON]'?
19:17:17  <aklein>that is, in ES5, it sets [[Class]] to "JSON"
19:19:02  <aklein>yup
19:19:08  <caitp>hm
19:19:25  <caitp>of course, nowadays it uses @@toStringTag for that
19:19:26  <aklein>clearly we need some test262 tests that delete @@toStringTag off of objects that aren't special-cased in O.p.toString() :)
19:21:27  <aklein>how did you happen to run across that?
19:21:53  <dherman>caitp, aklein: I don't know the ElementAccessor API but just an ability to say something like "please give me an array of the own indexed properties of this Array.isArray array" seems like it should be able to be faster than Get, and doesn't expose any internals of v8
19:21:55  <caitp>was setting up the Intl object in the bootstrapper to install some of the C++-ified builtins on it, and started by copy/pasting from JSON
19:22:23  <aklein>Intl definitely doesn't need it
19:22:25  <dherman>(Give me a c array that is)
19:22:49  <aklein>dherman: yeah, there's been some talk about such an API, which I agree feels much safer
19:23:57  <caitp>is this still about the rust bindings thing or whatever it was?
19:24:03  <aklein>the "trouble" is that most API changes are driven by Blink, and there's such a tight feedback loop between blink and v8 that things often get solved in some other way (e.g., we're currently looking at moving our Structured Clone implementation from blink into v8, which was the most recent request for this API)
19:29:28  <dherman>caitp: ya
19:32:18  <caitp>what is the main problem point that you're wanting to solve? could always try to escalate the discussion about it and make a solid case for extending the Array API (which is admittedly very thin)
19:39:23  * zvjoined
19:42:11  <dherman>caitp: it's just common when writing a native module that you want to pass n things across the boundary from JS into c++ (or rust in my case)
19:42:25  <dherman>And the cost of crossing the boundary is super high
19:42:44  <dherman>For lots of reasons, but this is one that's showing up in an example app I've been building
19:45:44  * Net147quit (Ping timeout: 260 seconds)
19:48:43  * Net147joined
19:50:33  <caitp>well, why not write up the behave your want from it, I guess
19:50:40  <caitp>behaviour*
19:50:53  <caitp>maybe Node would get something out of it too
19:56:45  * seventhquit (Ping timeout: 276 seconds)
20:05:06  <aklein>dherman, caitp: yeah, I think the right next step is to file a bug with use-case(s)
20:05:21  <aklein>will help the folks who work on the API to prioritize with respect to other ongoing work
20:06:05  <aklein>caitp: I would lgtm a change that got rid of the extra functions that are only there to support ES5 requirements.
20:06:23  <aklein>no legacy code could possibly depend on this, since it would have no knowledge of toStringTag
20:20:26  <caitp>hmm, chromium has std::regex as a "banned" feature because "too many regex engines already in chromium, use re2 instead"
20:24:37  <caitp>but I don't think I want to add an re2 dependency, and I don't think I want to use JSRegExp for this :<
20:28:12  * Net147quit (Ping timeout: 240 seconds)
20:33:22  * Net147joined
20:35:21  * bobmcwquit (Ping timeout: 250 seconds)
21:00:04  <caitp>speaking of the API, it seems weird that RegExp is exposed through the api, but not most of the useful operations specific to RegExp
21:00:50  <caitp>and using them from C++ is in general is pretty unfriendly
21:04:59  <dherman>aklein: I have a few thoughts but it's not 100% coherent. would it be better to just share my thoughts and have the discussion in the bug thread, or to try to work out a more concrete proposal first?
21:09:34  * NewNewbiequit (Quit: Connection closed for inactivity)
21:42:17  <aklein>dherman: I don't think your proposal has to be super-concrete for this purpose, I think the general shape would be valuable
21:43:28  <aklein>caitp: I understand using JSRegExp isn't ideal, but could you get by with it to start with?
21:44:13  <aklein>caitp: and there would definitely be value to Blink in having regexp matching exposed in some way via the API (probably not on v8::RegExp, but somehow)
21:44:30  <aklein>right now the bits of DOM that use regexps do something really ugly like keep a separate v8::Context around just for this purpose
21:46:16  * bradleymeckquit (Quit: bradleymeck)
22:07:33  * koldbrutalityquit (Ping timeout: 240 seconds)
22:13:15  * plutoniixquit (Quit: Leaving)
22:18:01  * bobmcwjoined
22:18:01  * bobmcwquit (Changing host)
22:18:01  * bobmcwjoined
22:22:23  * bobmcwquit (Ping timeout: 250 seconds)
22:33:01  * RT|Chatzillajoined
22:45:04  * koldbrutalityjoined
22:53:36  * Net147quit (Ping timeout: 265 seconds)
22:59:34  * Net147joined
22:59:57  * bradleymeckjoined