00:07:46  * plutoniixjoined
00:50:43  * AtumTquit (Remote host closed the connection)
03:42:16  * plutoniixquit (Quit: Leaving)
04:06:27  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
05:10:50  * Guest59joined
05:58:53  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
06:04:30  * Guest59joined
06:13:52  * Guest59_joined
06:16:37  * xaxxonquit (Quit: xaxxon)
06:16:44  * Guest59quit (Ping timeout: 260 seconds)
06:23:20  * Guest59joined
06:26:06  * Guest59_quit (Ping timeout: 256 seconds)
07:21:44  * Guest59quit (Ping timeout: 246 seconds)
08:19:43  * plutoniixjoined
09:30:11  <trungl-bot`>Tree closed by [email protected]: closed (https://ci.chromium.org/buildbot/client.v8/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/21087 from 600641338d160ce2dc82d3cdec0f414946409b81)
09:34:13  <trungl-bot`>Tree opened by [email protected]: open - [email protected] fixing MSAN
09:40:17  * xaxxonjoined
09:42:16  <trungl-bot`>Tree opened by [email protected]: open
10:14:29  <trungl-bot`>Tree closed by [email protected]: closed (https://ci.chromium.org/buildbot/client.v8/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/21088 from 5945e1ccd0e97e995e5fdbb19f2ded084e2c444a)
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:38  * mylesborinsjoined
10:28:19  * plutoniixquit (Quit: Leaving)
10:57:49  <trungl-bot`>Tree opened by [email protected]: Tree is open (Automatic: Boa sorte!)
11:10:15  * AtumTjoined
11:38:42  * xaxxonquit (Quit: xaxxon)
11:41:09  <trungl-bot`>Tree closed by [email protected]: closed (https://ci.chromium.org/buildbot/client.v8.fyi/Android%20Builder/8043 from d096508fe847e77d4922086fc26f9d90f51ec6ca)
13:12:53  <trungl-bot`>Tree opened by [email protected]: open
15:10:06  <bradleymeck>i'm looking into cross realm caching for https://github.com/bmeck/proposal-richer-keys/tree/master/compositeKey and was wondering if anyone has had gripes about implementing it for Symbol.for
15:25:24  * Wes-joined
15:26:31  <caitp>bmeck: what do you mean by caching?
15:28:24  <caitp>the weakmap from the polyfill works cross-realm doesn't it?
15:30:29  <caitp>i guess I should read the polyfill instead of just the readme, think I misunderstood.
15:32:15  <bradleymeck>caitp: Symbol.for('x') returns the "same" primitive if called in any realm
15:32:33  <bradleymeck>I'm talking about the same behavior, can't be polyfilled exactly
15:32:48  <caitp>right
15:33:36  <bradleymeck>but am wanting to have the same reference returned for all the component parts of a compositeKey/compositeSymbol for any Realm
15:33:51  <bradleymeck>so similar in nature
15:34:37  <bradleymeck>maybe cache isn't the right word, table is probably better but I don't like table for things that add/remove over time really
15:36:55  <bradleymeck>one question that I have is the fact that these objects wouldn't really have a realm associated with them
15:37:00  <bradleymeck>idk if engines care though
15:38:48  <bradleymeck>would change v8::Object::CreationContext though I guess somehow, or at least be unusual for it
15:41:29  <caitp>yeah, I think what you want is something like a NameDictionary in the heap root list, which treats its keys as weak
15:41:34  <caitp>and not necessarily strings
15:42:33  <caitp>I dunno how far along the proposal is, and the readme seemed to indicate that some of tc39 don't want it to be cross-realm?
15:44:15  <bradleymeck>caitp: not a strong position but some wanted to look into being idempotent per realm (aklein was only person in particular w/ a more than mild opinion)
15:44:25  <bradleymeck>having it be per realm has some complications though
15:49:59  <bradleymeck>caitp: oh, and the dictionary strongly holds things until a component GCs so not sure if that matches your idea, the keys are not a simple Name for compositeKey
15:51:55  <caitp>I did understand that
15:52:32  <caitp>I guess if GC of a single component gets rid of the whole thing, that's maybe a bit different than what I thought, though
15:53:02  <bradleymeck>once a single component goes through GC then you can't get the key anymore using those functions
15:53:23  <bradleymeck>since you can't populate the whole list of components anymore
15:57:32  <caitp>interesting
15:58:16  <caitp>I'm surprised you went that route instead of pushing for a CompositeWeakMap/Set primitive :p
15:59:16  <caitp>usually people are happier with primitives that let userspace handle the higher level aspects of use cases like that
15:59:40  <caitp>instead of baking something into the platform because some specific js framework (or Node) wants to use it
16:00:36  <caitp>but, I'm sure if it gets to stage 3 it'll get implemented quickly
16:24:02  <bradleymeck>caitp: I'm not sure how CompositeWeakMap/Set is more primitive
16:24:16  <bradleymeck>that seems much higher level to me
16:25:11  <bradleymeck>most class stuff seems to be something I avoid due to how complex it makes features and carries higher level abstraction and the problems of it
16:25:31  <bradleymeck>hence https://github.com/bmeck/proposal-richer-keys/tree/master/collection-rekey#why-not-encourage-extending-collections
16:33:39  <caitp>bradleymeck: the higher level thing is "we want to use a global (and cross-realm) weak-composite collection to access Symbols"
16:33:54  <caitp>but, you could use it for any number of things really
16:33:59  <bradleymeck>i'm not sure how it is higher level
16:34:13  <caitp>so, if you expose the collection as a primitive, those use cases could be handled in userspace
16:34:32  <bradleymeck>and you can create the collections with that function
16:35:01  <bradleymeck>one doesn't add inheritance and has an idempotentcy that is hard to implement in userspace without standardizing
16:35:23  <bradleymeck>how is the collection more primitive than a function is my question still
16:35:33  <bradleymeck>it also isn't as specialized as subclassing so it seems lower level to me
16:36:00  <caitp>"the collection is re-usable for different use-cases, the stdlib function is usable for one thing and userspace can't do anything they want with it"
16:36:13  <bradleymeck>you can use the same function for all those types of collections and probably more
16:36:22  <bradleymeck>caitp: what can't userpsace do with it?
16:37:52  <caitp>for instance, your application is modular ok --- diferent parts of it need to associate different data with the same composite key
16:38:08  <bradleymeck>k
16:38:22  <caitp>so, there are ways to do that with a single global collection, but it's probbably weirder to do it
16:38:36  <bradleymeck>the compositeKey function just gives a key
16:38:48  <bradleymeck>you just make 2 maps for your different data for example
16:39:08  <bradleymeck>compositeKey isn't some specialized Map that userspace can store data into
16:39:27  <caitp>ok, the composite store is
16:39:51  <caitp>but, then it still means the key has to be an Object, just so it can live in weak maps
16:40:06  <bradleymeck>sure, but not sure how that breaks the use case of storing different data in different places
16:40:37  <bradleymeck>caitp: compositeSymbol has a Symbol form for when you don't want to weakly store the data
16:41:11  <bradleymeck>they both are just about abstract concepts of making a key so that userspace can store data with an ordered group of values
16:41:21  <bradleymeck>they don't really confine you to a specific colleciton type
16:41:25  <bradleymeck>collection*
16:43:03  <caitp>I'm not sure it's better than just having new collection types
16:43:07  <caitp>but that's just me
16:43:19  <bradleymeck>I don't think collection types are the right way to approach it ;-p
16:43:45  <bradleymeck>more limited and suffer from the problems similar to why rekey is trying to be an argument on the base class of collections
16:43:54  <caitp>if the composite store is a collection type, compositeKey() is doable in userspace
16:44:14  <bradleymeck>both can implement the other
16:44:33  <caitp>well you want it to be rooted, you can't make it rooted yourself
16:44:45  <caitp>it'd be weird to let userspace root whatever they want, but that seems doable
16:45:07  <caitp>just so that it lives beyond whatever realm
16:45:29  <caitp>but then again, what makes that important, I dunno
16:48:25  <bradleymeck>it reduces size of the trie and matches Symbol.for which is vaguely nice
16:49:20  <bradleymeck>caitp: "it'd be weird to let userspace root whatever they want", not sure i understand the concern
16:49:35  <bradleymeck>you can create CompositeMap/CompositeWeakMap/etc. still in userspace
16:50:52  <bradleymeck>you can even unroot it if you just put some constant at the front of your compositeKey arguments: `const subroot = {}; const mycompositeKey = compositeKey(subroot, ...);`
16:52:14  <bradleymeck>anywho, feel free to open issues if you think some use case is poorly done / missing
16:54:39  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
17:43:57  * Guest59joined
18:40:13  * seventhjoined
19:42:35  * Guest59_joined
19:46:14  * Guest59quit (Ping timeout: 256 seconds)
20:00:23  * seventhquit (Remote host closed the connection)
20:09:14  * Guest59joined
20:12:32  * Guest59_quit (Ping timeout: 250 seconds)
21:23:21  * stalledquit (Ping timeout: 240 seconds)
21:41:42  * stalledjoined
22:09:16  <trungl-bot`>Tree opened by [email protected]: open (Tracking purple V8 Win64 - msvc bot - crbug.com/841545)
22:26:21  * RT|Chatzillajoined